- Rendered components are a data structure, not a template. As a result, React is renderer-agnostic (enabling libraries like React Native, trivial SSR, even rendering to arbitrary APIs like smart TVs), and it’s simple to manipulate those data structures (allowing a variety of abstractions and optimizations that are substantially more complex and error prone when the rendered product is an HTML string or DOM tree).
- Quite a lot of common problems can be solved with pure functions (props in, rendered structure out), which are simple to reason about and maintain, and rarely require any advanced knowledge of anything besides HTML/JSX.
- Static type checking and automated testing of JSX are well supported, and trivial to run without a heavy (eg browser) environment, out of the box.
- The proximity of data and rendered structure is easy to reason about, navigate, and validate.
I’m sure these qualities can be achieved with other UI frameworks whose default rendered product is templates, and perhaps I underestimate the extent to which they’re priorities in Vue (or Svelte, or any other library not defaulting to JSX), but since they so rarely come up in these comparisons or the other libraries’ elevator pitches, I assume they’re just not high on their priority lists.
Vue 3 is introducing a detached renderer, and given it's amazing component boundaries and decision caching it will give React a good run for the money on things like native output.
Vue 3 also introduces the composition API utilizing other features mentioned.
To each is own!
Yes, you _can_ do fetching and rendering in a single function, but that doesn't mean you should.
I will even go a step further and say that, in React, there is no data-part. React is nothing but a really powerful templating system.
(EDIT: It's actually more nuanced, but this is how I approach it.)
The data-layer is usually handled by another library like Redux, Apollo Client or React-Query/useSWR.
I've seen it like two or three times in recent weeks and find it fascinating. (Sorry, not trying single you out, or derail the conversation too much, but armchair linguistics is a hobby of many on HN and somewhat curious if others have spotted it.)
> The classic phrase was ... strangely gendered
I don't think it was "strangely" gendered; despite recent growth in the corpus frequency of singular "they", many formal manuals of style still prohibit its usage, preferring "one" as the epicene pronoun. Singular "they" has existed for about as long as Modern English, but generic "he" was significantly more common throughout the 20th century. Given how long idioms take to change, generally speaking, I think it should be unsurprising that this usage of generic "he" remains common.
The classic paper on this is "Androcentrism in prescriptive grammar", from 1974, which presents the argument that singular "they" was more common before the prescriptive grammar movement in English, which greater increased how common generic "he" was.
A lot of the ease and benefits depends on your style.
If your code pattern was to have variables holding your state and rendering html based on that, you will have an easy transition to React ( and likely didn't suffer horrible pains with jQuery).
If your code style is to update the DOM to reflect your state, and when you need to know something about state, you read the DOM, then React will feel odd and complex (and you likely have had jQuery projects work great until they hit a level of complexity and then they suddenly become brittle and hard to change)
This is why I prefer React - the best practices if React are just the best practices for functions. (That and I don't like the pseudo js syntax of Vue with the mysterious scoping)
> Vue is Lightweight and Flexible
> Vue is less intrusive than React
The standard React might be heavy, but the core reactive code and the part I use are definitely much lighter. It's just reconciliating virtual dom trees that are explicitly built by my code. Vue hooks into all data objects, to react to mutation. Vue includes a whole templating language, that have control structures in addition to JSX features (v-if, v-for, ...). Vue is supposed to be used in .vue files, that are a unique way to organize code, and is going to require special support for your editor, linters, and other tools.
> The html/css and JS are separate while in React everything is in JS.
My HTML is at the bottom of my my JSX file, in the render() method I keep at the bottom. My CSS is in CSS files. In Vue, the correct way seems to be using the <template> and <style> sections of the .vue file. Is that more separate?
I have nothing against Vue per se, and opinionated frameworks have their merits, but do Vue developers agree with the author's stance?
This is why I like JSX better than idiomatic Vue. Using SGML syntax for programming logic or other things it was not designed for ends you up here:
 I am aware that JSX is possible with Vue, but I believe it's rarely used. If you think I'm wrong, wait to correct me until after you correct the article author, who says that Vue projects all follow the same structure.
It's a bit lighter than React but if you care about weight, Preact, Svelte, Mithril, Solid, Inferno, and others would be a better choice.
It's not more flexible than React. Quite contrary. At least for Vue 2 (I haven't used the composition API of Vue 3).
Having used both for some years, I find Vue to be more intrusive than React. In some aspects Vue is more pragmatic but OTOH it's quite inelegant.
I recommend Vue to people getting started with modern front end, specially because you can use it without a build setup and just the JS basics. It's great for backend devs, or designers that only know HTML and a bit of JS. I don't really see the point for experienced JS devs.
Therefore, the only comparisons I respect are subjective ones. I like Vue. I'm expressive with it and can take care of the goals I have to achieve. I've no reason to try something different, and that also makes me incompetent to judge React in detail as I haven't used it to the same point I've done with Vue.
> My HTML is at the bottom of my my JSX file, in the render() method I keep at the bottom. My CSS is in CSS files. In Vue, the correct way seems to be using the <template> and <style> sections of the .vue file. Is that more separate?
You can split your HTML / CSS / JS into separate files, or combine everything in one, or do a mix of whatever pleases you, or you can simply use JSX with Vue.
I prefer to split everything in its own file, it makes it easier to find.
I didn't like how with Vue there was something extra other than pure JS, which is their templating language, and the fact that you have to do stuff like registering a plugin for a library instead of just saying `import x from 'x'`. Plus due to being a templating based framework, TypeScript support isn't as good as React, though it's better in Vue 3. There were little things like that shifted my preference away from Vue and towards React.
Oh, and React just has a lot more libraries.
I teach all 3 to teams, and the top advantages of each as I see them: React for job opportunities and pre-built sophisticated code (e.g. Telerik Kendo), Vue for easy on ramp for JS/CSS/HTML developers who want to phase in dynamics (e.g. sprinkle ins akin to Alpline JS), and Svelte + Sapper for the best developer experience and fastest sites.
Also focused on Svelte now.
I'm not trying to offend you, but if you teach people all 3 frameworks and you tell startups to use the least supported one - can you see why that might horrible? Honestly, I'm skeptical about your ability about any of the 3 frameworks, you teaching them to people doesn't attest to your ability at all. Suggesting to use the least supported one - does.
I despise React, I suggest React to all the newcomers. Reason: larger market. They'll get a job quicker. They'll find resources to learn it at any corner.
Whenever I've looked at Vue, I can't help but get the feeling that you're likely stuck with what you started with. When I look at a Vue component vs it's TypeScript equivalent, I can't say I see a trivial upgrade path.
In my opinion, the next version of Svelte which embeds Sapper into the framework would be the ultimate death of Vue, and really challenge the dominance of React/NextJS!
Almost all front-end engineers I know or I've watched on twitch or youtube, do the ranking as:
1- React (because of career potentials)
2- Svelte (because it's actually the best experience)
3- Vue, ember, ...
People have difficulty finding devs with experience in vue, i don't think svelte would be doing anything better in that respect
I hope it won't get any significant traction because I'm tired of yet-another-almost-same-but-different frontend dev option, why couldn't it be a contribution to React or Vue but separate entity instead?
In any case, I respect the battle, and I hope both React and Vue create concepts that the other camp likes and copies. Having more than 1 "standard" is always a good thing.
Multiple that by the number of frontend engineers you have across the org.
If you look at the additions graph, though, you'll find Evan You with +500k, and the second highest contributor with +7k. I just couldn't feel comfortable trying to build a company on a single person like that.
Angular has botched the first 3 years of its existence with breaking changes every major release and catastrophic bundle size. And it shares the name with angular.js - one of the most dreaded frameworks of the past for mostly anyone that had to maintain a few years old angular.js projects. And it's the most frameworky of the bunch, thus it comes with a heavy stack.
Vue & React were better, leaner, easier alternatives. Angular just survived, because it's super heavy in use inside google. I guess it will never catch up to vue or react again. Maybe with rebranding. But maybe they don't want to as it serves google well already.
Like vue even works without a build, just create an empty html page and import vue and you can fiddle away.
Also angular wants to own the entire page, which makes transitioning parts of a page not the easiest. And if you did anyway (like we did) you ship 1MB+ of framework just for the smallest widgets.
In angular there is so much stuff upfront, its just a bigger barrier to get beginners interested in.
One of the reasons it's not mentioned is because of the bad fame. Especially here on HN it's almost exclusively being hated on.
I learned to ignore the hate and continue working with it. Version 11 is awesome, and we had a great update party with the Angular Team on the official discord (https://discord.gg/angular)
The two biggest difference between them I've noticed is that Vue has been more "batteries included". The Vue authors have made all the choices (and integrations) around routers, state management etc for you. If you like the decisions they've made then that's great, if you don't then you might find yourself using less polished libraries.
The other is what I think has lead to Vue's popularity, that is, it allows you to get away with more and not in a good way. React makes it quite hard to deviate from their model of doing things. I.e. state flows down via props and back up via callbacks. However, with Vue, it's quite possible for components to know (and interact) with their parent components directly, i.e. call methods on them, modify internal state. This makes it easy to get things going but leads to all sorts spaghetti code down the track. React does its best to stop this kind of behaviour.
In summary, Vue has gained traction not only from it batteries included approach (and being novel) but also because it allows you less frustration when developing and doesn't try to stop you from writing terrible code like React does.
Do you have that backwards, or is there something I'm missing? In React it's easy for child components to interact with their parents by calling callbacks. What's hard is to call methods on children and interact with their state... the answer is always "lift state up".
Vue is less ceremonious than Angular and that's a huge selling point in my opinion. I have pity on folks who have to learn Angular.
I've never touched React. Given that React is so popular, (I imagine) there to exist a superb amount of info on the web targeted towards beginner and getting started audiences to make it difficult to wade through all of the bullshit. There's significantly less bullshit on the web about Vue which I find helpful because that generally means the existing content is not totally beginning oriented. Maybe I'm biased on this topic idk.
Single Page Applications were the wrong direction for us. Tens of megabytes of massive js libraries built using bundlers and minifiers and shims and whatnot, only to render something on the screen that would've been rendered with pure html using ssr.
Honestly I enjoy coding with React a lot. Components are a really robust way of reasoning about UI logic. But it's not worth the problems it solved.
The usecase for SPA's is really small. Maybe Slack should use React sure. But not all the other apps out there. Look at Github and Heroku. Smooth, beautiful and fast experiences. So reliable.
I miss the old days of Smarty + jQuery UI. That was a better direction.
Had we invested this much effort into that approach, we would've had a much better performing web today.
I've seen plenty of applications that could have easily been a collection of server driven pages broken into an api and spa. I think it comes down to a few things where SPAs are great.
1. Programmers padding their resume. react looks more marketable that any server side templating technology
2. fomo, what if later we want to add something that needs it
3. seperate api/frontend teams, spas make seperating responsibility easier. two seperate codebases.
of course it has its downsides
1. you're maintaining a communication bridege between two different applications. This entails a context switch if you're a developer hopping back and forth.
2. more failure modes to handle. Only so many things can go wrong loading a page. If an SPA breaks, it can render the entire page unusable. You also need to have error. handling code for inputs on both your frontend and backend.
3. large file sizes to download. This one has been beaten to death but it still holds true.
Ive personally found a nice middleground with phoenix liveview. Its slightly more work than a tradtional page driven app while giving me teh ability to create all the features I was being asked for that before would have warrented an SPA. I hear livewire and stimulus reflex are great too.
2. The user experience really, really suffers from this toolchain.
One day I had to code a relatively complex email to send to clients, so I had to go back to template rendering.
What a joy it was. I realized what a mental burden React and it's ecosystem have become.
And I'm not trying to argue one is better than the other, just that the idea that Vue is so simple and easy is only true when your project is simple and easy. I feel it's a little dishonest how Vue is presented to beginners, and for more complex needs Vue isn't any simpler than React.
Edit: I should add that I used Vuex, which feels like the exact opposite of the whole "intuitive" approach that Vue is going for.
That became even more important when I was adding F# (fable) to the question and Vue reactiveness only worked when I modified their observable instances. At the end the architectural difference was just too important.
Vue is nice is you just stay within its walled garden/pattern using the ilusions they created.
This is NOT a blog post I would use to assess these two libraries for a startup.
This is a great point - and quite true in my experience as well. I would not build a business using an open source project backed by a tech giant.
It leads to completely different ways of organizing code.
I much prefer react, in that it really feels like functional programming with immutable data.
But I know a lot of people who are much more at ease with vue.
My point: it’s not about “lightweight” or “non intrusiveness”. It’s really about how your data flows through your app...
Reading through it bears that out. The actual reasons given are not convincing, and a lot of them can be discounted if you start with create-react-app rather than DIY React.
I don't think any of these would crack the top 5 of any devs list of React vs Vue. Maybe docs, but Vue has pretty decent documentation from what I've seen.
React has legit advantages over Vue (and vice versa), but this comparison doesn't even begin to touch on them.