We did a POC in both React/Vue and ended up using Vue mainly due to the following reasons:
Single File Components
Single file components (.vue files) is the best thing about Vue. I understand this might be a personal preference, but we wanted to avoid CSS-IN-JS. Our designer could churn out neat html/css, but was a beginner in Javascript. With Vue's single file components, he could also hack parallely with us while iterating on html/css.
Standard / Official way of doing things
This again is a personal preference but Vuejs comes with a recommended way to do a majority of things. Vuex(state management) and Vue-Router are provided/maintained by same Vue core team.
React at times can be overwhelming for beginnners, just because of the amount of choice available
Example:
Google Search for 'React CSS style' [https://www.google.co.in/search?q=react+css+style] points to a bunch of links all of which link to valid solutions, but I have to go through a few of them before I get what I am looking for.
Similar search for 'Vue CSS style' [https://www.google.co.in/search?q=vue+css+style] all top links lead to official documenation on vuejs.org.
Excellent documentation
Also, as a team we were primarily writing Angular 1 when we decided to choose a frontend framework for newer projects. I feel this also made our transition to Vue easier vis a vis React
import styled from 'styled-components'
const Container = styled.div`
padding: 10px;
background: ${
({ isHovered }) => isHovered ?
'green' :
'red'
};
`
const H1 = styled.h1`
font-size: 15px;
`
const P = styled.p`
font-size: 10px;
`
const MyComponent = ({ isHovered }) => {
return (
<Container
isHovered={isHovered}
>
<H1> Hello <H1>
<P> This is a thing </P>
</Container>
)
}> Our designer could churn out neat html/css, but was a beginner in Javascript.
I write JS every day, and frankly that code looks like an unholy mess to me, so I can't imagine what it looks like to a beginner. Is "styled.div``" a function call? It's not self-evident. How do you do inheritance? Is that a template string with functions inside it? Would that CSS autocomplete?
That code looks very much like it sacrifices ease of writing CSS for ease of writing JSX. That isn't the correct tradeoff for everyone.
I highly recommend watching Rich Hickey's "Simple Made Easy" [1] talk which covers how the right ("simple") choice may not be the "easiest" (convenient, most familiar) one.
https://github.com/facebookincubator/create-react-app
npm install -g create-react-app
create-react-app my-app
cd my-app/
npm start
I'm probably starting to sound like a shill for React. I've used both and love both. I do like that React is "just javascript", which I think is why I use it.
From the Vue documentation [1]:
>Even if you don’t like the idea of Single-File Components, you can still leverage its hot-reloading and pre-compilation features by separating your JavaScript and CSS into separate files:
<!-- my-component.vue -->
<template>
<div>This will be pre-compiled</div>
</template>
<script src="./my-component.js"></script>
<style src="./my-component.css"></style>
Is there any tool from the Node ecosystem designed to reduce that boilerplate?
Thanks for any insights!
[1] https://vuejs.org/v2/guide/single-file-components.html#What-...
Newer JavaScript functionality makes that work nicely.
Almost all of my components fit on one screen.
Another issue with CSS-IN-JS seems to be security - as it opens up another vector for cross-sight scripting attacks - see here for example. [1]
If I end up going with React, I'll probably avoid CSS-in-JS outside of React Native.
>You can’t use CSS in react-native apps. But you can use CSS-in-JS with styled-components. [2]
Disclaimer: met James K Nelson of reactarmory.com at #hntokyo on Thursday - otherwise unaffiliated.
[1] https://reactarmory.com/answers/how-can-i-use-css-in-js-secu...
If you like that, why not go with Ember?
I feel like this is Vue starting to get the React treatment. React was (and still is!) a very simple library until people realized they needed to do fancy things to make complex applications manageable. Redux came out, everyone fell in love with it, and React+Redux became an official couple. This lead to the perception that React has a steep learning curve because new developers were learning React+Redux without learning React first.
I wonder what Vue can do to avoid the same pitfall.
Thematically, it may be a result of obsession over tools instead of product which occurs in other areas like photography, writing(hipster typewriters), and others. In tech, technology as lever supports a "hacker" mindset of getting 10 for 1. However this misses the point of hacking to get around your weaknesses in order to focus on your core competency which MUST intrinsically have value instead of being an empty shell.
The core competency for many client side developers is probably more rooted in a form of design than pure technical ability. Design, like music, writing, speaking, and art have incredibly low barriers to entry. This can create an arrogant mindset from people coming from more rigorous disciplines. Instead of focusing on the thing that must be done, they try to take shortcuts that only have the appearance of reaching the goal.
When you're hyper-vigilant about simplicity, you end up creating the simplest design that meets the goals. It takes a little extra time, but it's so worth it.
I’ve never used Vue but I’m also curious to see how it and VueX fares in this regard.
If you love to type, though, I highly recommend Redux!
const ADD_TODO = 'ADD_TODO'
import { ADD_TODO } from '../actionTypes'
function addTodo(text) {
return { type: ADD_TODO, text }
}
dispatch(addTodo(text))Also you don't have to import your actions, it's just a smart thing to do. This gives me heartache a bit: https://github.com/vuejs/vuex/blob/dev/examples/counter/Coun...
It's good enough and fast enough as it is for most medium side projects.
And the awesome thing is that you can scale it up for this one big project you need it for.
Trainer here. I train in React and in Vue.
My students do 3 times the work with raw vue than in raw react. Every one of them. All the time.
It's not even on the same map.
Vue on the other hand was so simple. And the documentation made getting hello world done in a few minutes. This got me off the ground and made me feel productive as I felt I knew right away what vue was doing at a most basic level. Then it was just constant learning on top.
But I think it’s good that there’s competing library, though the problem domain felt eerily similar.
Not me.
I mean, it's necessary, at some point, to see a full system that uses all the tools for delivering a real application. But, it is definitely a lot of concepts to grok at once. I actually found it most useful to see tutorials that started without even using React, and built up from first principles to what React does (given that React is conceptually very simple, this isn't so crazy...a toy version of React can be built in an hour or so, so it's perfect for a video or article; much of the complexity in React is in making it fast rather than in making it work). But, that may not be a necessary first step for people who have more frontend or reactive programming experience than I have.
Yes, since probably early 2016, many tutorials have basically said "you need to learn React and Redux together", and that's the message that a lot of junior devs have been taught.
However, my own advice is the same as Dan Abramov's: you should focus on learning React first. Once you understand React thoroughly, then you'll better understand why a state management lib like Redux _may_ be helpful for your situation.
React itself is an incredibly simple library: you can explain the entire thing in a few sentences. In my experience it has an undeserved reputation for being more complex than Vue.
Almost everyone I know learning React in a professional capacity ends up having to learn Redux at much the same time, my experience is very much the opposite.
However, I would argue that is not ok in that it should never be necessary and it's use would be a code smell to me and indicate that the code in question is likely not using Vue properly.
I suspect it would be more valuable in the long term to ask people to take more time and learn to use Vue instead of jQuery to solve the problem at hand.
Edit: I should note that Gitlab came to the same conclusion and I misread their comments on it as accepting the argument that it would be ok for querying the DOM. What the article says:
> At first I had several discussions about using jQuery with Vue. Some had said it might be OK, but only in read-only (querying) situations. However, after doing the research, we found that it is not a good idea to use jQuery with Vue. There will always be a better solution. We found that if you ever find yourself needing to query to DOM within a Vue architecture, then you are doing something wrong.
This I completely agree with.
First, you can gradualy migrate from jquery dom to vue. As both are very light, having both is not bloated.
Plus, you need something to do ajax anyway, and if your site uses it, why add axios as well?
Actually I'd say that vue is probably the best tech if you want to progressively improve a legacy jquery heavy website instead of doing a complete rewrite.
I would argue as well that AJAX requests don't belong inside Vue components. They belong in services and those services should ideally be behind the Vuex store, but there is nothing wrong with not using Vuex.
If we were just talking about using jQuery for AJAX given that you already were using it, then sure that's fine, use it instead of adding something else like axios. From the article what was being proposed was using it to query the DOM. There is no use case for that with Vue.
I have a hard time taking seriously the opinion of someone who bases their sweeping global assertions on "research" and not on actual experience.
With Vue you can write a scalable understandable application using the documentation. The same criticisms do certainly apply, but many of the advanced features are worked into the application.
For example Vuex is bundled into Vue and has verbose and opinionated documentation on how it lives in your vue application.
The React and Redux developers are incredibly good at what they do - they've also spent a lot of time putting out material, books, video courses, blog posts, talks help everybody else understand the new paradigm they've created
They can't be that stupid when a lot of modern javascript framework components are either direct clones of, or influenced by, their work
Every time I see a topic about Vue or React (or practically anything JS related) I see the polar opposite of the disarming friendliness coming from the community leaders on Twitter.
... But in all seriousness, there is a diversity of viewpoints here. It’s a conversation and people vote up things they find thought provoking. Would you prefer only people who think React and Vue are great post here?
I'm talking about comments like
"God this is horrible. It's ugly. Hard to read."
"ugly piece of code"
"React failed miserably"
"The JS ecosystem is like the baskin robbins of st"
and so on.
React took time to learn, but it was definitely worth it. The one way data flow and explicit event handling (aka no ng- or v- tags) just seems cleaner to me.
Of course this is no way a critique of Vue. Its a great framework for people who want that sort of thing.
Our frontend application was originally built with Rails. When we added Vue, we did not refactor our entire code base.
This means that we've kept the existing server rendered pages. Once the page is rendered we build our vue app on top of it.
The reasons why we pass certain data through HTML is: 1 - Avoid duplication. Our endpoints and paths are still built in rails, by passing them through data attributes we keep only one single source of truth 2 - Passing data from the server to the Vue App Some data is not being sent through the API, but we still need to access it. For those cases we also use the data attributes.
We know that this is not ideal but it was a mid term solution that allowed us to quickly add Vue.
You can read more about our architecture with Vue in this blog post: https://about.gitlab.com/2017/06/29/gitlab-at-vue-conf/
This "hurr jQuery and everything it brought sucks" mentality is not good.
Put a function on the vue component that will make a request, keep all the data stuff in vue.
E.g. on the server-side .html.erb they'd have something like
`<div... data-endpoint="@controller.url">...</div>`
I decided on Webpack. First time using it and no idea where to get started. I ended up downloading some boilerplate webpack / vue / vueX that now does everything for me, but I have no idea what webpack is actually doing or how it is doing that. I'm not even sure how big this stack is... how big is my chain of dependencies here?
Am I going to be in trouble at some point? It feels like I'm on borrowed time here and my little house of cards will come tumbling down soon.
For a long time, the way webpack worked in the Vue template was at least 70% black magic to me. I had some issues with it, sometimes I solved those issues after google-ing a lot and landing on completely unrelated projects Github issues for a fix. I never quite felt that I had mastered that whole ecosystem like I felt I had mastered my regular programmin languages and tools.
My day job is C# and my day IDE is VS2017. I've been given permission to explore doing a new application in .NET Core with Vue. So, I've started to translate the default template from vue-cli to Visual Studio and I have learned a LOT by trying to glue these pieces together that no one else seems to have glued together for me. Luckily, MS has done a lot of work to make React play nice with VS2017 and that seems to benefit Vue as well.
I'm not quite there yet, a few last issues remain. Most of them have to do with Intellisense's understanding of Typescript vs. Webpack's understandinf og Typescript. Some remain unsolvable for now (Single File Components using Typescript and SCSS).
Still, the point I'm trying to make is that being forced to read through the entire thing has increased my understanding of the Webpack process immensely. I feel like I'm at 80% mastery now.
You really don't want your first time reasoning about your build process to be some kind of deployment disaster or production bug. And that's exactly what these tools are selling you.
I think this quote from this article is a good summary of this discussion: "Scala people don't have time for redditing and blogging, they're busy getting crap done."
While it might seem like all the JS devs are arguing on here over their choices, there are many folks who are silently being incredibly productive with whatever tool they choose.
I was stuck with the Xbox so I had to validate that reality to myself by defending it on the internet.
It's no different on HN.
Web Components might be the solution, but it's not exactly ready yet: https://caniuse.com/#search=components
To understand how to improve JS, try writing in vanilla JS (no frameworks) and find the common pain points. Organise with fellow JS developers to get features to address these shortcomings in the EcmaScript standard. Once this is done, use tools like Babel to polyfill the missing functionality from the EcmaScript standards until browser vendors implement them. Rinse, repeat.
I did end up needing to reach for jQuery in two situations with Vue. First was to auto focus form inputs when the form becomes visible. For the life of me could not find a good way to do this with Vue. Second was when a particular architecture of the app required using lots of modals. Vue just doesn’t do well with components that live inside modals and need to be reset whenever a modal is opened or closed. Basic CRUD using Bootstrap modals is a huge pain, especially the Update mode. I ended up creating rather gross hacks for notifying the component in the modal that it needs to be reset.
One of the coolest things I did with Vue/VueX is having updates about server side events delivered via WebSockets. A single generic connection to the server pushes CUD events about all the relevant models to the client, where VueX duetifully executes the ADD/UPDATE/REMOVE actions for instant updates to all parts of the app.
The primary reason why I would not adopt Vue is because Vue is still driven by Evan You - which is great, but if something had to happen to the guy (and I hope nothing does), I'm unsure Vue would have the long term support & drive it does right now.
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2...