At my last job we did a comparison between Vue and React before rewriting a major frontend application.
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.
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
> 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.
You're writing scss within the text blocks. You're correct that you need some understanding of JS.
I've never worked with designers that wrote css, I'd also probably not trust them to do so (my own failings).
I don't agree that it looks like an unholy mess (hyperbole may be lost on me), but I can see how it could be jarring at first look. I had a similar reaction when I looked at Relay (https://facebook.github.io/relay/), when they used literals for data fetching.
So, yeah, you lose all the syntax highlighting etc. that comes with just writing normal CSS. I don't think it's unreasonable for a designer to object to that - how would you feel if you were presented with a build system that required you to write all your JavaScript inside one big string statement?
Maybe it's just me, but I don't find it intuitive at all. `styled` has properties for, I assume, every HTML tag? But it can also be called as a function for inheritance purposes? And that inherited call appears to use the same tag as its parent... but what if I want to reuse styles across different tags? How could I define some shared CSS properties I'd use across different elements?
Don't get me wrong, it is cool stuff. But it also feels far too much like hand-wavey magic stuff. I've literally never used Vue before, but looking at this page:
I have zero confusion about how to write styles for it. And I really don't understand why styled-components would be worth the extra effort by comparison. What does it bring to the table? It's different without a compelling reason for being different.
> I mean, same way with Vue really. If the editor didn't know wtf a Vue file is, you'd lose all the integration too.
In a way, that's fair. In another way, the example single component Vue file I linked to is an HTML file. It has a <script> tag and a <style> tag. Just associate .vue with HTML and you're done.
That gets to my broader point as well - styled-components reinvents the way you declare styles and the way you apply styles, and requires the entire thing to be written as a JS file. And for what? I still don't understand what the advantage is over a syntax everyone already knows (and has validators for already!)
If you remove styled-component specific tooling from the equation to simplify the argument and just use Glamorous instead of styled-components (which are very close to the same thing except the later is just JS), then it's exactly because of tooling.
The reality is that tooling for templates (even Angular or Mustache style) is pretty terrible. Tooling for CSS is just as terrible. Static analysis or doing simple things like interpolation of data is pretty darn bad.
But JavaScript tooling isn't half bad. It's not the best there is, but its still reasonably advanced. Thus you have React, which is basically just JavaScript and objects. Sure JSX, but when used in React, it's just sugar to define those objects (hyperscript would work just fine too if you don't want to use a compiler, and early on in React's life just creating the objects from factories was just fine. Certainly better than weird templates with bad tooling).
Once it's all javascript, everything works: my linter works (and is certainly more advanced than css linters), both major type systems work, my refactoring tools work, and I have all the language at my disposal without learning anything new to do stuff like conditionally showing or hiding things. No need for an ng-if, v-if or whatever.
The same logic keeps going with styled-components. Associate the styles with a plain old JavaScript object, using javascript constructs (in this case, template strings), and all the tooling to manipulate them, interpolate them, or type check them just works (eg: TypeScript isn't bad at typing interpolations in template strings). And if that's not good enough, Glamorous is just objects so it's even easier.
Now I mentioned both styled-components and glamorous...normally this logic would heavily favor the later, but for some reason, tooling for styled-components have gone above and beyond to make up for the shortcomings of template strings, so it ends up working better for me.
Maybe someday some very motivated people will make tooling for the non-JS parts of ecosystems that are not "all JS", and this point will be moot, but right now the React ecosystem is the one that lets you most heavily lean on tools.
It's probably why it doesn't look so great from a newcomer perspective though: if you're not at a point where you're trying to squeeze every last bits of power from the tooling ecosystem, then it's just overhead and a waste of time.
Is it bad to write without all these JS tools?
We just use Visual Studio and include the standalone Vue.js file. We write plain css (no sass etc) and js with some occasional JQuery. We don't use Nodejs and its build tools (Kinda don't like the complexity all those tools bring. You are more worried about the tooling than the actual problem at hand). We use Ajaxmin and Httpcombiner. That's it for Frontend.
Vuejs is great. Found it to be easy and simple to understand. Big thumbs up for Evan You.
It's not bad at all. You just have different requirements. I prefer React, but if the apps I was working on came to change in requirements, I'd be very happy to have Vue as an option. I don't think having 16 different major frameworks that overlap in functionality is healthy, but having a handful of fairly distinct ones that overlap on some points is just a good thing.
We have hundreds of full sized frontend applications, millions of lines of both javascript and scss. Thousands of extremely complex i/o operations and algorithms. We push the tools in the ecosystem to their limit and have to write our owns where they fail us.
And when I'm at home making a small app, create-react-app and VSCode, then npm install-ing styled-components, is all I need to replicate 80% of the above. It's all just JavaScript so all my tools just work the way I expect them to.
Not everyone needs (or want!) this. And that's okay.
Agreed.
The webside ecosystem is in a high state of flux. It has to be streamlined somewhere. Does it need a fundamental architectural change? Would like to see things a bit more saner ;)
I would argue that the right boundary for designers to be working with front-end people is via central company style assets, and not at the component level where ad-hoc styles should be stored.
It seems a little odd that the front-end designer, who is in our hypothetical not comfortable enough to actually work on component themselves, would be brought in to tag-team with someone else who also doesn't feel comfortable enough to do the work themselves.
I much prefer putting the styles in a separate {componentName}.scss file, import'ing that into the component and using the Webpack Extract Text Plugin:
You can work with two files per component if you must truly put the styling in another file.
One of the boons of react is that you can create a set of reusable base components that can be built upon throughout your app.
If you can code-split the app, lazy-loading components as needed, and if you can cache all of the static app anyway, why does it matter if the presentation is tied to the logic?
The same can be said for vue.js. :)
The two languages have many merits and they both make their own sacrifices. But they are ultimately two peas of a pod.
Like Thor and Loki.
But who is Thor and who is Loki? ;)
Why do packages like this need to be ported or re-implemented for Vue rather than referenced? That package hasn't been updated since August while the root styled-components library has ~700 closed issues and 11,300 watchers
I've seen it with other stacks as well with almost complete re-implementations, a lot of duplicated effort and it feels like it goes against the packaging philosophy for javascript
20 minutes vs an afternoon is probably not a great gauge for making technology choices.
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.
I don't mean to be an arse, but if you agree with my point, then maybe you can see why I disagree that your "that and" is a valid strike against React/in favour of Vue.
Simplicity makes picking up the unfamiliar easier. You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.
> Simplicity makes picking up the unfamiliar easier.
The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve.
> You can't accurately deduce from time alone that the time to pick up Vue was based on familiarity with similar libraries.
True, I was really just suggesting questioning instincts when evaluating tools based on the initial 'time to get started'.
> "The talk I referenced talks about how the opposite is often true. Tools that result in objectively simpler systems can come with a initially steeper learning curve."
I'm aware of Rich Hickey and Clojure. In my experience with Lisps, although they are superficially simple, they make you do more abstraction work than is necessary in more commonly used high-level imperative languages. Lisp seems to strongly encourage building a high number of helper functions, which is fine if you're highly opinionated about how a job should be done, and less so if you just want to import some battle-tested libraries and write something that gets the job done. I suspect this is where the learning curve with Clojure really comes in, in that it's more closely related to being learn how to architect an application in a Lisp-friendly way than it is about getting familiar with the language.
Totally agree actually, I love all Rich's talks and agree with almost every word of Simple Made Easy but I don't necessarily agree with the conclusion he takes it to (Clojure).
I've heard it suggested somewhere that possibly the leap is in believing that 'a simple thing + a simple thing = a simple thing'.
npm install -g create-react-app
create-react-app my-app
cd my-app/
npm start
Your sentiment is correct that tooling around these pieces of technology needs to always be first class. React failed miserably, and Vue did an AMAZING job.
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.
I used that. I took me a huge time just to understand what all the tooling was doing, how to integrate it in my current stack and how it was going to affect my current project.
My pet peeve with react is that I can't just code. I have to stop every 10 steps and reflect on the tool I use, instead of the problem I'm trying to solve.
I have no idea what you are talking about. React doesn't require any tooling. Drop a reference to React from some cdn in your HTML file and you are good to go. People confuse the myriad of libraries and tools complementary to React for React. You don't need create react app for Hello world.
Create React App gives you a zero configuration way to not only write hello world, but also bootstrap a non-trivial production ready application. In the company I work for, we were previously using JSPM/SystemJS/Gulp. We replaced all of that with create-react-app. It allows you to very easily bootstrap existing applications on top of it: http://fredrik.anderzon.se/2016/12/04/adding-create-react-ap...
And if you want full control of your project, you can "eject" and CRA will generate the webpack configuration file being used so that you can tweak to your heart's content.
I use React daily, and the whole experience has been extremely pleasant.
> My pet peeve with react is that I can't just code. I have to stop every 10 steps and reflect on the tool I use, instead of the problem I'm trying to solve.
Thank you! Every time I've tried react (and enough attempts were made to finally decide it was just not for me), there was always something in the back of my mind that I didn't like and I just couldn't put it to words. You just described what it was.
And, if one forgoes tooling, then the situation is like the one you described in your previous comment: an afternoon just to get a "Hello world".
As far as the actual libraries themselves go, if any of Vue/Angular/React are the new jQuery, it's Vue. It's the smallest of the three, but more importantly it's the easiest of the three to drop into a page without any tooling.
I have a hard time understanding why this "drop in" experience is so important. Are you all writing simple contact us forms or something incredibly simple?
Any application that I've built which actually required a technology like Vue or React was a significant undertaking and a few hours getting up and going (not that either of them require anywhere close to that) is nothing.
I don't see how jQuery could have been anywhere near as ubiquitous if it had required a build step.
It makes experimenting easier for beginners, for people considering switching to it, for people who are already using it and want to try something outside the context of their existing codebase, for people writing tutorials and demos, etc.
The less bullshit to wade through when using a tool, the more situations it will be applicable to, regardless of skill level or project size.
That's just it though, Vue & React aren't for most web sites. There is no point in pulling either in unless you are building something much more complex than where jQuery would suffice. There is no need for a technology to be "ubiquitous", just that it is going to meet the demands your application has for it.
Actually vue is so small and simple you can just drop it anywhere. Even on non JS heavy website. It's a bit like redis. Low price. Always nice to have. Very reliable.
First, as a learning experience it's easier. In the HN bubble it's easy to forget most web project out there don't even have npm installed. I regularly train dev that just learn what ajax means.
Secondly, a lot of my projects just don't need anything else. If i have a 2 weeks contract with a client, i'm not going to setup webpack, a ci server and docker.
Having the choice to scale up or down is an amazing feature.
Which order did you attempt to learn them in? Is it possible taking the time to attempt to learn react affected how easy it was to pick up Vue? I know we love to hate on React here but they are very similar. Can you identify what in particular is so confusing with regards to react vs. vue? They have a very similar API.
Vue dlc is better. Vue doesn't require webpack. All vue tutorials agree on how to so things and they work the first time you try them. You son't have to learn a new way to do templates or pass data. You can start withou components. You can even start without npm.
In summary, vue offers a simpler hands on experience while allowing smooth learning curve to more complicated setup matching react's.
React just throws you in unkown waters and say 'now swim'. And on the side of the river, 3 persons are screaming to you contradictory advices.
Vue requires webpack when going for anything beyond a simple hello world experience. At some point beginners are going to have to enter the real world.
BTW - You don't need webpack for React either. It is entirely possible to write React without it.
> Vue requires webpack when going for anything beyond a simple hello world experience
Not at all. That's the beauty of it. A lot of projects just drop Vue in a script tag and use no components. There are 1000's of projects out there with such a scale that anything else would be overdoing it.
> BTW - You don't need webpack for React either. It is entirely possible to write React without it.
Technically yes. But realistically no. First, you will find almost zero doc/tutorials on how to do so. All the ecosystem and community assumes webpack, and a top-down component architecture. If you ask on a forum how to do x, people will promptly tell you to use Redux. And the React API is clearly not comfortable anyway without tooling.
It's a bit like saying "well you could perfectly code a Java project without an IDE". Yes you can. But who would do it ?
>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>
If I end up going with Vue, I'd probably do that. It looks like a lot of boilerplate though ...
Is there any tool from the Node ecosystem designed to reduce that boilerplate?
I started off hating the idea of single page components; I'd have much rather had a component reside within a directory (with template.html, style.sass and script.es6.js files or whatever) but in reality, so long as you keep your templates light and do any heavy lifting elsewhere, it's quite manageable.
Newer JavaScript functionality makes that work nicely.
Well, this approach of single file components (.vue) containing separately scoped HTML, CSS and JS is what the Google Polymer team were recommending all the way for the last several years, but it seems no one was listening to them.
> We discovered that VueX makes our lives easier. If you are writing a medium to large feature, use VueX. If it's a tiny feature, you might get away without it.
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.
Rookie Vue dev here. I found Vue super easy to understand and to start using for my own simple stuff basically from day 1. Gradually as my tiny projects grew in complexity, I naturally started to feel the need to manage state better. And again, Vue docs led me gradually thru pure-Vue solutions towards VueX. It all felt very naturally, the documentation didn’t push me to anything, just gave me answers at my pace. Can’t say the same about React, even though I’m a big fan of both.
Vue documentation is just superb. Kudos to those wrote it. Evan Yu, in particular. Only those who understand a topic very well can present it so simply.
Hey ng12, author here. I totally agree with you. I am the biggest proponents of keeping things simple. I initially was hesitant to introduce Vuex. I've written a few huge apps in Vue without anything else but Vue. The cool thing is you can, of course, continue to do that. But again, you just have to follow some strict patterns. Or, to make it simpler, you can get some help from Vuex and let it help you follow those strict patterns. Either way, one is best off if they follow a strict pattern. If not self guided, then library guided. Especially on a big team you can reduce the stress of that strictness if everyone uses Vuex. With so much code flying through GitLab, Vuex is the answer, for quicker code reviews.
I guided my (small-ish) team away from VueX when we reached for VueJS earlier this year in an application. I based these decisions, at least in part, off of the GitLab engineering teams efforts, as well, for what it's worth. We are all still happy wth that decision. I don't have much more to add to the discussion but to say that it's very nice knowing that if we reached a certain level of complexity that we could, fairly easily, introduce VueX and be back at our previous pace without a lot of hubbub.
From my experience telling people this doesn't work as everyone thinks they are smart enough to avoid the trap. Like many companies going into China assuming things will be easy. Code ends up complex yet works because the complexity was successfully wrangled, missing the point of complexity reduction rather than wrangling.
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.
One cure for this is to have someone who cares solely about simplicity, as an ideal above all else, in charge of technical decisions.
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 think one reason for that steep learning curve might be that many aspects of React, namely component lifecycles and state management within components, are abstracted away or simply moot once you start managing state with Redux. Also, while the two libraries work great together (I consider Redux indispensable for new React apps), they aren’t really similar as far as library design and patterns are concerned. Finally, there is something to be said about the mental overhead added by Redux middleware. If you’re dispatching async actions, you’re probably using Redux Thunk. If your app has forms, you might be using Redux Form (I honestly avoid it because its own abstractions and Field components end up getting in my way). Ultimately, the process of learning how to use all of these tools in tandem can feel somewhat disjointed, especially when you’re also integrating them with other parts of the web stack, modern and in some cases legacy.
I’ve never used Vue but I’m also curious to see how it and VueX fares in this regard.
What Vue can do is create a well-designed state management library that works out of the box without umpteen lines of boilerplate... and that's exactly VueX.
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))
To be fair, you don't really need to declare your constants elsewhere. This is just a pattern people stuck with, because they're stubborn about constants, I think. Doing a find/replace is so incredibly easy that it's kind of silly to add a bunch more boilerplate to protect against one DRY quip.
I'm a really big fan of the Ducks pattern where your action types are private to each reducer unless they're explicitly exported as an API. In my own code I don't even do that, instead exporting a function which operates on the state.
Hm, interesting. I like it. I'm also curious about how selectors come into play here as well (exported getter functions for shielding app from reducer state shape).
You might still need to place actions/selectors in their own directory since they're not necessarily specific to any reducer. I believe this is how sagas are organized, though.
Vuex is simpler than Redux. First you don't have to grasp the Container/Component pattern. Second you have less middleware ("what, you don't use redux-saga and redux-think?").
Vue and Vuex seem less clever JS (shiny es6 features), less clever programming (mutability etc) which I feel may be a detriment for complex apps in the long term but it is simpler.
(I may be biased because before Vue and React/Redux I did Angular1 & React/Reflux and I view Vue as a Angular/React mix and Vuex is not far from Reflux)
That's not part of Redux, it's a separate design pattern you can use with any Flux architecture. React-Redux doesn't even require you to do it that way, and for good reason: you might not need it. There's nothing wrong with just importing a store reference wherever you want it. That's a totally reasonable pattern for some applications.
This illustrates my point I guess. There's so many people thinking about how to architect and implement React applications that there's a lot of cargo-culting.
I disagree that its "literally" the same. Vuex requires you to mutate state, through their API (if declaring new/dynamic properties). Redux is agnostic about how you handle state, but encourages immutability. Vuex is inherently not immutable, its coupled to the vue reactivity system which is based on mutations & memoization.
Vuex & Vue are the easier APIs to learn. Not only that the developer ergonomics are just better for Vue's API. For example in vue you have "mounted()" instead of "componentDidMount()" or "ngOnInit()". Likewise, redux requires learning CS terms (if you don't know them) like thunk, saga, memoized selectors, etc. Vue uses more layman's terms, like "computed" instead of "memoized selector" which just makes it easier to learn.
My big hangup with Vue is having to declare reactive properties up front. It's author says this is a best practice anyways, but it leads to hard to debug issues when you accidentally declare new properties at runtime & you get race conditions. With react & redux both making immutability possible & encouraging immutability, you get easier to debug apps. But there is a more up front investment.
I also really love Vue's single file components. I know you can do that in Angular & React, but again the API is just so much more ergonomic in Vue.
Is it? I thought Redux abstracting out the thunk layer was silly until that line of thinking lead to Redux-Saga. It actually seems to have been a pretty smart move.
There's vuex-saga as well. Something built in would have been nice because even though sagas are cool, the learning curve is steep enough for me to avoid it in projects.
It avoids it by design. Most of my vue project only uses vue. Not even webpack. Just the static vue file. I don't even have that many components because view doesn't force that on me.
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.
This might be a dumb question, but what’s the best way to actually use this to make a real application? I’m talking speak to a database and hook up a backend. I’ve enjoyed using vue from a “this is a neat way to make components” but I’ve never successfully been able to do anything with it. I understand it’s just the “view” and not a full MVC like rails but I want that to exist. I want it super opinionated and favor convention over configuration.
I haven’t found anything nice for a guide in building a real world application like this. Maybe it would involve multiple things vue + ? + Postgres or Mongo or some other option. But I want love something that would hold my hand start to finish connecting the dots.
Academind has a great video series on creating a Vue app that uses Firebase as the backend, and anyone can follow along and reproduce the results. He also uses Vuetify for the sake of having some prebuilt UI components.
https://www.youtube.com/watch?v=dIkPb8krORU
Yes you need a lot more tools. A backend framework with a REST API plugged to a data base is common way of doing it. Personally I use Django + Django Rest Framework a lot on the server and axios to query it on the client. But you mileage may vary.
I would love to see a start to finish crud example of the "least" amount of magic and copy paste code for a guide on setting this up. I've messed around with Django and it seemed harder to grasp than rails due to using regex out of the gate to apply a simple route as opposed to get/do or resources.
The whole component russian dolls with data/callback passing is something most beginers have a very hard time to grasp. Add webpack to the mix, make them fight with JSX that doesn't want to do what they need and voila, you get a sad student.
Starting with vue is just: add a script tag, put your template here, now your data here. Done.
Uh, you pass data & callbacks through props in vue also, unless you use a single component. Why not just compare it to using a single component in react then also and be honest?
I find Vue and angular way more complex then reactjs mainly Due to them having their own syntax and I find jsx far better then template strings.
For a Js developer reactjs would be easy. But if your not that experienced or just HTML guy then I can understand why they find vue/angular easy. Both have a framework built in for routing, css , http. You just need to learn their syntax and nothing much. With reactjs you need to come with your structure, find the correct routing, state managements,css libs etc
I disagree. I was going to use react for a personal project and got stuck because of documentation and the various blog posts and tutorials all being different and using different libraries and patterns etc etc. This made getting a basic hello world impossible for me. (I’ve since used react and it’s now trivial but starting out was not easy, barrier to entry is still higher than vue.)
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.
Then it's an unfair comparison. Vue does state management out of the box. React really doesn't. Yeah, it has setState, but that's nothing compared to Vue.
I've been learning React lately, and many tutorials, even those targeted at beginners, include Redux. Many seem to be a sort-of cargo cult without any understanding of why they're using Redux, and in many cases, there's no reason to introduce Redux into the mix. I've also noticed a lot of tutorials are content marketing from companies wanting to sell bolt-on services and tools, which is pretty weird; I've never used a language/ecosystem that had so many hangers-on before. And, it leads to the same situation: "Learn React (plus these other complicated things that we want to sell you)!"
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.
There is a big problem with the commercialisation of React. More and more companies are using learning resources as marketing material. And now one popular JS developer has started beginning his GitHub readmes with advertisements for a paid JS course. It's a far cry from the open, guileless sharing culture of webdev 10 years ago.
I'm somehow less bothered by the latter. Folks gotta make a living, somehow, and sometimes people have to make choices between doing OSS development or having a real job and doing a lot less of the OSS work.
But, the learning materials and marketing are the ones that bug me...especially the ones that neglect to mention that the materials cover React+product, and only mention React in the title. You might not even know it's marketing until you've read half the darned thing and the crux of the thing turns out to be "now create an account here and use this service to outsource the specific thing you googled to learn how to implement yourself". GraphQL has a lot of the same thing going on. It's like "how to draw an owl", only instead of "now draw the rest of the fucking owl", it's "now send us money every month for the rest of your app's life and we'll draw an owl for you".
I'm a Redux maintainer, and I spend most of my free time answering questions about React and Redux.
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.
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.
That's not really a fair position to take. It basically allows you to believe that React and Redux don't need to be learned together.
Put yourself in the shoes of a CTO at a new startup. They need to decide whether to build their company on top of React or Vue. They need to make this decision quickly.
Is it really fair to say they don't need to learn Redux? And that maybe Redux won't apply to their situation?
Of course Redux will apply, because Redux is for all intents and purposes how you manage state at scale. And everyone who's entering the field who isn't a junior dev is thinking "We need to come up with a way to manage state at scale. Does Vue help us do that, or are we stuck with React+Redux?"
It really doesn't help matters when you look into big players like airbnb and discover that they wrote their own state management framework rather than use Redux. They even have a two week onboarding process for new devs that teach them how to write features using their blend of tech. It's a bit... Eh... The whole thing just feels like WPF, a dead technology that few people here have probably heard of. There must be a simpler way.
> Put yourself in the shoes of a CTO at a new startup
My first step is to hire someone that knows how to build a FE app. We'll use the tool that someone is familiar with.
If you're a CTO of an incubator startup with 2 people straight out of college who learnt Python and basic JavaScript and you're trying to build a serious web app from there, well, it doesn't really matter what you pick, you'll have to rewrite it in a few months anyway (that's a pretty common scenario).
If you're the CTO of a new startup, don't pick a technology to build your startup in without building something with that technology first.
Build something small. Learn React. When you're comfortable, and your small app grows in to something a bit bigger that might merit it, learn Redux.
Then, build something small. Learn Vue. Repeat.
Now you understand both options enough to make an educated decision. Feel confident building your big, gotta-get-it-right-off-the-bat startup project in whatever works best for you.
Certainly, and that's the way to do it. My point is, you end up converging on learning Redux. You really do learn Redux no matter what, so it's kind of a myth that you "don't need to learn Redux."
Theoretically, you can get by without learning it. In practice, the moment you try to build a real company, you need it. That necessitates learning Redux.
I think this is an uncomfortable thought because it implies that Vue is way easier for devs to get into, and that's step one to displacing React+Redux. But that seems like an uncomfortable truth.
Whoever is in charge of React needs to give Vue the Snapchat treatment. Take them seriously as competitors. There's still time.
I don't understand your argument -- wouldn't it follow then that Vue devs converge on learning VueX? VueX is very similar to Redux, I don't see how that's a point in Vue's favor if our metric is time spent learning.
It's roughly a bajillion times easier to learn. And that counts for a lot.
You have to take yourself out of the "experienced React+Redux dev" mindset and put yourself in the shoes of "Experienced dev looking to invest in one of two ecosystems" mindset. Which one is the path of least resistance?
The point is, React+Redux people would love to believe that it's "Vue+VueX." But in reality, it feels like "just vue." A sword is stronger as a single piece, and Vue+VueX feels like a single piece.
It's up to people to learn both and decide for themselves, but my argument is simply this: it's a mistake to underestimate the traction Vue is gaining.
There's a strong temptation to blame the dev: They're not smart enough, they should have been able to pick up Redux easier, Vue+VueX is the same as React+Redux. But all I can do is report my experiences, and an honest survey of the ecosystem would lead us to conclude that Vue+VueX is far easier to learn without sacrificing any flexibility for your company in the long run.
I think you've made several assertions about Vue which reflect an inherent bias. VueX and Redux are _remarkably_ similar libraries and I think your assertion that VueX is easier to learn (egregious hyperbole aside) is a pretty weak argument.
To be clear: I like both React and Vue and am fundamentally skeptical of arguments that one is significantly better/worse/different than the other.
> Put yourself in the shoes of a CTO at a new startup
Okay, how big is our web application? A few pages with a form? We'll avoid Redux for now. We might even avoid React.
It's like anything else: should you set up a Spark cluster if you're only processing Gb's of data? Probably not, but you might need it some day -- so make your best guess.
The majority of complaints I hear (either at work or online) about React are actually about the React ecosystem -- they have trouble with Webpack or Redux and throw the baby out with the bathwater. I think very few people learn React by writing a pure app (e.g. hand-compiled, no state library).
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.
The thing is, even if you want to hold yourself to a simple React-only app, the moment you want to leverage someone else's work, you are thrown into the shark-infested waters of the React ecosystem.
I think React is very cool, and I haven't tried Vue, but everything on this thread points to it being a much better learning experience, and might be better for small or middle-sized projects.
While I personally avoided this pitfall and learnt React alone before Redux, I have not meet anyone else who did the same. Literally everyone I've talked to about learning React did so (or tried, and failed to do so) with both, up front.
Wow, I wonder where people are getting the idea that they need to learn Redux. If you start a new job at a company that uses React, then you probably need to learn React + Redux simultaneously. But if you're just picking up React, Redux isn't useful whatsoever.
> Wow, I wonder where people are getting the idea that they need to learn Redux
Because everyone with a React job or substantial React project uses Redux (or a similar library). It is common for junior devs to rush through learning libraries in hopes of being employable or a "real developer" as soon as possible.
If you are working with React in a professional setting, Redux is practically the default choice for state management. If you are building something in a professional setting with React, there's a pretty good chance it's complex enough that it needs a state management library like Redux to do well.
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.
I would strongly disagree that it is ok to use jQuery with Vue. I mean sure, it's ok in that most of the time it isn't going to hurt or break anything, at least if you are just using it to query elements from the DOM.
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.
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.
Looks like I misread. They ultimately reached the conclusion that using jQuery was not ok. Good for them.
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.
Plus, although fetch is tremendously better than XMLHttpRequest, it still has quirks. It doesn't send cookies by default. The promise resolve on success on code 400 and 500. Headers are verbose. You have to encode and decode json manually. You have to force CORS for it to work.
AFAIK, their old codebase was full of jQuery and they are replacing some parts with Vue, hence they use both. They might not have used jQuery at all if they were starting from scratch.
Perhaps not, but there is no reason to use jQuery within the Vue components. Doing so now means that it is basically there to stay. That may be acceptable, but it is definitely unnecessary.
In general it's best to push your comfort boundaries. It's called learning. I'm not saying React is better than Vue (I honestly think they are very similar). Just that picking a technology based on whether it challenges you or not is probably not the best strategy.
I strongly disagree. Parent poster specifically states 'as a long time jquery dev...', so their objectives almost certainly do not aline with those of a student. Indeed, "picking a technology based on whether it challenges you or not..." Has almost no value at all for a prudent, real-world dev making real world software.
I think it has a value if you value long term employability > short term employability.
If you mainly choose technology based on the fact it doesn't take any effort to learn at all, you will soon hit a wall on what software you can use overall.
The problem is experience in jQuery and even Angular 1 are not relevant to the issue of why React (or even Vue for some) may be perceived as difficult. They use a very different model.
Emacs was very difficult for me when I first started learning it. It was much more difficult than using a simple text editor (and this was with 10 years of programming experience)! Yet I persevered and you know what? After giving it some time and learning it properly I found myself vastly more productive with the tool.
Some things don't lend themselves well to immediate gratification. If the OP provided even a hint as to why React was more difficult for him I'm guessing it's not something with React but rather that he was using two completely different state management solutions.
Curious, how long did it take before you before emacs was your go-to choice?
I'm a big vi and sublime text user but always open for better tooling.
btw - I actually agree with you on the learning thing but React just sucks. I'm able to get shit done with Vue and at the end of the week I haven't wasted three afternoons learning jsx/webpack/deployment/relearning-a-new-way-of-doing-css blah blah. I say this with some hesitation but CSS is a solved problem in my opinion with Sass.
What was it about React that made you feel stupid? I can see how Redux would make someone feel that way but react is so simple I'm having a hard time visualizing someone not liking it for that reason.
Imo, doing it the "right way" and scalable requires a fair amount of knowledge about React before you pick it up. Things like ducks structure, redux thunks, store vs local state and other advanced usages. While not strictly necessary, it becomes increasingly important when building a large application. And then each of these are not official plugins so there's lots of differing opinions on how these pieces fit together.
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.
Whats with the insults? I can get preferring one platform over another, but insulting people is just lame.
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
> They can't be that stupid when a lot of modern javascript framework components are either direct clones of, or influenced by, their work
The JS ecosystem is like the baskin robbins of st. Which is mind-blowing because JS has gotten so much better and browsers have gotten so much better in the past 10 years. Yet the apps people are creating today are worse that the st people were creating with IE8 and jQuery.
I am hardly the only one who has recognized this as a problem. I see an article from a major dev on the same topic on a regular basis here.
Pointing out that people can make crap isn't an argument that supports your assertion that the developers of a tool are stupid.
Can you list off any tools that you like where there aren't any people using them to make crap? Does the fact that some people produce junk undermine your success using a tool? Or is it actually inevitable that people will use a tool to produce garbage?
I'm very happy the React and Vue projects are headed by people like Evan You and Dan Abramov, not HN commenters. The hostility in these threads is upsetting. There is no best approach and both React and Vue have their worth, if you like them or not.
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.
It’s true, that H.N. Commenters guy is a real piece of work.
... 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 personally have been bitten by the two way binding and CSS in JS "feature" more than once. As an angular developer for two years, it frustrated me to no end.
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.
Why is GitLab putting data into their html? "You can pass your endpoints in through the data attributes." Why store endpoints and other js related data on a DOM element. This sounds like a left over paradigm they kept from their jQuery mindset, or am I mistaken?
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.
HTML is for displaying information, not being littered with things js needs to query for and access. That's the whole point of using something like vue?
Put a function on the vue component that will make a request, keep all the data stuff in vue.
>There is nothing wrong with storing some information in the DOM.
Except you're coupling your application state with the document model. If you ever do anything to change the DOM later on, (like installing React into your codebase) it'll come back to bite you in the ass hard, as now you need to find a means to communicate state that you just threw into the DOM like it were a slightly more acceptable global variable.
This is not the same as what gitlab is doing. React had attributes in order to remount correctly on the client side after a server render, this was removed. Using the latest react versions have nothing on the dom that isn't specifically needed to render correctly.
I don't know GitLab's exact motivations although I noticed the same thing. I suspect it might be because they're using Vue components on already existing Server Rendered pages as opposed to a full SPA, so by passing the endpoint in the template they can allow the actual URL for that page to be set in the controller, maintaining cohesiveness.
E.g. on the server-side .html.erb they'd have something like
Just feels like you're halfway following good JS practices. Ex: using Vue is great, but still rendering templates the "old way" instead of server rendering correctly for the whole app and having components remount. Totally get your point :)
I don't disagree but the real power of Vue is that you can immediately start using it in your existing application without having to jump to a full SPA. Vue works just as well when added to a single page or feature in an existing application as it does in a full SPA
I wanted to build something in Vue a few months ago. I really like the single-file-component thing. I also like the code to update automatically and my browser to refresh.
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.
I'm in a similar boat right now, I started exploring Vue with the vue-cli default template and VS Code.
Webpack and the associated npm ecosystem scares me to no end. When it works, it works wonderfully but it is so incredibly fragile and built upon assumptions that might change if you do not use the exact flavor of tools and utilities the creator of the template does.
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.
I'm actually writing about this right now. I've worked with a lot of teams that have kicked off big, production-grade applications with boilerplates like Create-React-App. Your intuition is right: they get to prod having no idea how their buildchain works, and once something goes wrong they're stuck.
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.
This is one of the most aggressive, defensive, and religious comments thread list I've ever seen in a highly rated HN post. Not sure what to take from that.
Javascript libraries and their preferences are always a high tension discussion because at the end of the day, it often comes down to whether you made the right decision for years to come.
Totally agreed. Unfortunately (and fortunately, depending on how you look at it), there is no single benevolent dictator of JS to help you make your decision like in other communities.
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.
This explains a lot of fanboism in general. Like when I would argue about how Xbox > PS3 on forums as a kid because my parents certainly weren't going to buy me both.
I was stuck with the Xbox so I had to validate that reality to myself by defending it on the internet.
I hope one day more web developers will realise all the major JS frameworks are just a band aid to plug the gaps in vanilla JS. It should be easy to build web apps using vanilla JS. No frameworks pushing a certain way of working, just a reliable batteries-included language that you're free to extend with your own application-specific extensions and mix-and-match external libraries, just like desktop app developers have taken for granted for over a decade.
Say that your opinion is correct, and every web developer agrees with it. What could web developers do about it? The gaps you are talking about in vanilla JS does exist, so until they're plugged, web devs would still prefer to use these frameworks until the standard bodies and browser vendors make a better alternative.
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 love me some Vue. VueX is actually quite simple, especially compared to Redux. It doesn’t try to invent too much new terminology.
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.
Although they are very different under the hood, as a developer the experience vue gives is very much like component based angularjs (version 1). Yet everyone seems to hate angular 1, while they love vue. I really can't see why.
So I've used Vue for personal projects before, it's really nice. I lead the dev on a small team within a large corporate company, we focus on React & Angular(io).
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.
While Evan is currently the main force behind Vue, there are many large companies with stake in it, as well as a reasonable number of contributors. Personally I prefer the current state of operations over the dense bureaucracy surrounding some other libraries, but you’re obviously free to disagree.
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