Vue vs React: Best Choice for Startups | Hacker News Reader

Vue vs React: Best Choice for Startups

swimm.io

63 pointsmorchen73 comments

The things I most value about React (and other similar libraries) but seldom see mentioned in these kinds of comparisons are:

- 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.

As a Vue developer I appreciate this post, explaining how data/template proximity of React can be advantageous. If you like data/template separation Vue might be worth a shot.

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!

I wouldn't say that data/template proximity is required or desirable in React.

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 think probably my proximity point is less clear than it could be. The “proximity” I find appealing is that a component is either a function of data (“props”) returning the rendered structure, or an encapsulation of props and state returning the same... and in those cases (especially with static type checking) makes it easy to understand and navigate data flow, in a way that a template separate from its data types usually isn’t. Of course it’s good to separate the business logic from the rendering, but that still produces a more clear understanding of the data flow.

thanks for the clarity

Pardon the derailment, but "To each is own" is a fascinating mondegreen [1] I've been seeing surprisingly often lately. The classic phrase was the strangely gendered "to each his own [choice]" and the "proper" phrase is probably "to each their own [choice]". "To each is own" implies something else, but I'm not entirely sure what. "To each is own[er] [of choices]" perhaps?

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.)

[1] https://en.wikipedia.org/wiki/Mondegreen

In my idiolect, changing the gender of pronouns inside of idioms is highly marked, even though I use singular "they" as the epicene pronoun.

> 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[0].

[0] https://www.cambridge.org/core/journals/language-in-society/...

"Strangely" was my simplistic way of very briefly glossing over that history that those "prescriptive grammar" changes was a I feel strange period in the language where Classical Latin studies influenced a redirect of the language's course that shifted a lot of idioms from say their Shakespearean Middle English states for some weird idea that being more like Classical Latin was a good thing for English.

Probably a typo on "to each his own"

haha interesting, I think I was trying to emphasis personal preference, some of what picking a framework comes down to.

I am starting a new web project next week (first web project in years), thank you for your explanation. I like treating code as data and vice-versa so i figure REact will be better for me than Vue, despite my initial choice. For sure it will be better than vanilla+Jquery :P

I’d strongly encourage looking at Next.js (with TypeScript if you prefer or have an open mind to it; TS support is first class now with no additional action needed than using .ts/.tsx files). It’s really great out of the box for many common web needs, has sensible defaults but easily configurable using other common tools, provides SSR/SSG/many optimizations out of the box, and a great track record of continual improvement.

Re: comparing to jQuery.

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)

It's interesting to me because, although I'm not frontend so have limited experience with those, I have the exact opposite opinion of Vue.

> 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?

> Vue includes a whole templating language, that have control structures in addition to JSX features (v-if, v-for, ...)

This is why I like JSX better than idiomatic[0] Vue. Using SGML syntax for programming logic or other things it was not designed for ends you up here:

https://news.ycombinator.com/item?id=19951229

[0] 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.

I started using Vue in 2015. I still maintain a couple of project with it but it's not my default choice anymore.

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.

I chose Vue because I despise Facebook from the bottom of my soul and I don't want to use tools made by them. That's it.

React is actually fantastic, but I'm an old frontender and using React instead of Vue won't really do much for me - I'd still face the same problems, which are related to business logic. Ultimately, we all end up writing JavaScript when all the nice boilerplate, buzzwordy paradigms and rendering issues are taken care of.

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 despise Facebook from the bottom of my soul

Why?

I learned Vue first, then when they announced hooks, I thought, why not learn React as well? Now I only use React, due to how it maps so cleanly onto functional programming paradigms, along with Redux. I can use maps and folds in my JSX, everything is a function.

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.

Svelte is better than Vue and React, IMHO, especially for typical startups building typical websites. Svelte is faster to learn, makes smarter decisions, and has compile-time checking.

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.

To me the lack of type checking support in svelte (or vue) templates alone is already a mayor 'developer experience' deficit compared to tsx.

This is the one thing that gives me pause about Svelte. I see a lot of quality of life improvements there compared to react but full type checking all the way through to templates is massively helpful.

Been using all 3 for some years now and I 100% agree with your points.

Also focused on Svelte now.

So what you're saying is that the framework that's got the least active ecosystem, least amount of devs that use it and that you can hire, least amount of resources is the best for startups - companies that need to grow, find employees, onboard them and teach them the tooling; and the best choice is the least supported one?

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.

Re-read what they wrote.

Over the span of 5 years, I wrote and maintained a react application that grew to about 100k LOC. I migrated it over time from createClass to classes to functional components, from JavaScript (w PropTypes) to Flow to TypeScript, from webpack to RCA, from flux to redux. I feel that in these comparisons what tends to be missing is what options each framework present when your code base reaches a size when the current structure becomes a burden. React fairly easily allowed gradual improvements, adding typing without needing a massive rewrite, codemods, RCA, etc.

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.

I think it's not a question of Vue vs React, though they both help create reactive frontends, but the right comparison is Vue vs Svelte because of similarity in approach. Vue3 is replica of Svelte's approach but Svelte is hands down the better of the two.

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, ...

Does svelte really has that much presence in industry?

People have difficulty finding devs with experience in vue, i don't think svelte would be doing anything better in that respect

> Does svelte really has that much presence in industry?

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?

I hate to be a stickler on this but... She has 1 year of engineering experience. I cannot take this seriously because while it will definitely be a useful "hey, here's a take from a jr engineer" but having written Backbone.js (and precursor) code and then React code, I can say that while Vue and its inspirations come from some evolutionary beginnings, React has by far made every front-end problem I had in the past trivial. I'd like to see lessons from people who had to maintain a Vue or React application for 1.5 years say which one is easier to get engineers working on, and structuring better.

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.

The author is right under the title of the article: Gilad Navot. Looking at the gray in the beard in Navot's picture on the about page, I'm guessing that Navot has more than one year of engineering experience. (I'd also guess that Navot's preferred pronoun is not "she", else she would ditch the beard)

The subject of the article is a question posed to the author by a junior engineer with 2 months experience. The author seems to have a lot more experience.

By make the problem trivial - do you mean reacts problems are so huge that old problems seem insignificant, or do you mean that react is so good it solves all the problems you faced before?

The extra cognitive load that results from having to use Vue's templating DSL (domain specific language) makes it worse than React IMO. You have to context switch out of javascript and then back again. It is tedious and unnecessarily.

Multiple that by the number of frontend engineers you have across the org.

I wonder what the cognitive load of reading the byline and the first line of the article is.

JSX is a templating language too. Yes, it's intertwined more easily with JS but it's still a syntax you have to learn. As someone that used plenty of such languages (Handlebars, etc) in the past, and still does today.. people make too much of this sometimes.

The big win of JSX is that you get full type checking on your templates as well as your code if you use Typescript. On bigger projects this is a huge help.

Until more people than just Evan write code for Vue, I won't really feel comfortable using it in any legitimate capacity beyond toying around. I think Vue is far and away the best developer experience in terms of FE frameworks that I've ever used. React is more popular (rightfully so) and has better employment opportunities, but I think Vue is a legitimately much better FE tool in terms of productivity and usability.

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.

Genuinely curious. Why is angular not in the conversation? I use angular regularly and love it.

Hey high five. I do as well :)

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.

Could you please explain your ”were better” argument?

I mean easier to try out and transitions into.

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.

I find Angular very pleasant to deal with, but I mainly favour it due to the separation of typescript, html, scss. Each time I try using React, I'm unable to overcome the uneasiness of the html being right there mixed in with the JS. I can appreciate that not everyone is equally bothered by it and that's fine too. But I definitely feel Angular has a place in the conversation.

I favour Angular for this reason too. Also, my team is spread across 2 continents, and working with a much more opinionated framework makes it easier to keep the codebase more consistent and readable by everyone.

Same here, really love it and I'm relieved to use it when I get back from working on a React project.

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)

What do you love about Angular? I'm using it and i find it so overcomplicated, so convoluted, not obvious in any way and with a really bad dev experience.

None! Don't use these tools they massively complicate everything.

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.

not sure why you're being downvoted. SPA's have their place but I agree with you that they are being heavily overused.

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.

Just to add a quick anecdote to this. We have a massive webapp done using React using all the fancy tools.

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.

You should look from the perspective of developers who are not web developers. It's an insane fucking mess out there. SPAs (especially structured ones like angular) can give a developer a shot at creating a structurally sound interactive webpage without wanting to kill themselves.

1. Angular, React, Webpack, all these stuff add to the mess. They don't take away from it. A well organized framework can still provide a good developer experience.

2. The user experience really, really suffers from this toolchain.

There's definitely an argument to be made about the second point. However many people accessing the SPAs have a fast enough internet connection that it's actually a better experience to download it all in one go. Also, "tens of megabytes" is a VAST exaggeration.

I'm looking at the application I'm responsible for. Downloads 3M Gzipped JS assets and takes > 250M "on initial load" and I feel sick to my stomach.

What does your build script look like?

Pretty normal webpack config. We recently changed from babel to esbuild and are very happy btw.

Vue just feels so good to work with vs react. However it's going to be easier for companies to find experienced react engineers than Vue engineers. That is always a big consideration if you are a start up trying to push product.

Is there a more informed comparison blog post than this one? This one doesn't clearly address the business value questions of one framework over the other. A startup that needs to build and sell a product shouldn't care if a project is backed by Facebook (and if they do, seriously, what are they doing?). And some of the arguments are shallow and off base, like "everything being JS," that wouldn't be useful to any company actually wanting to make this comparison.

This is NOT a blog post I would use to assess these two libraries for a startup.

Having used React commercially for around five years and Vue for two and I don't feed this article really hits the mark.

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.

> know (and interact) with their parent components directly

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".

That's correct. However in Vue I have access to $this.parent which is an instance of the parent component. My child component can read data directly from it, even modify state of the parent by reassigning values.

Important note here is using $parent is bad form and discouraged in the vue docs[0]

0. https://vuejs.org/v2/style-guide/#Implicit-parent-child-comm...

I learned Vue 2 a couple years ago for use during personal projects. It's been nothing short of a joy to work with (even though there have certainly been some beginner frustrations). Vue presents topics clearly and implements them in ways that allow me to be productive without getting caught up in the Webpack and transpiler madness. For the same point from Swimm - you can add as much or as little Vue to a project (can personally attest to this point).

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.

I've used both, and I think Vue is great for simple projects. When you start adding things like routing, and need to manage states across several different components, things start getting a bit more complex.

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.

Web Devs love being hipsters.

I preferred React over Vue.js because the first one can be truly functional and it is easier to containarize and to use as library, whereas the second one is a pure mess of state, and copied/synced status.

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.

> Indie at its core. While it’s my personal opinion, many developers appreciate tools that are not backed by tech giants (for example React backed by Facebook, and Angular by Google), but rather grows from a community and that is why it is highly oriented to developer needs.

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.

The single most important difference between react and vue is that vue has 2-way data binding while react doesn’t.

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...

Saying 'it wasn't even a question' disrespects the fact that it certainly is a question. The decision seems to have come before the reasons.

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.

The only benefits React has over Vue is popularity, unmounting components (I think that's whats being referenced), and docs?

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.

I fail to see how any of this reasoning is compelling when deciding for a startup

I think vue is for people that don't know frontend much but will enjoy the quick benefits both in features and structure. It's nothing crazy but it lets you prototype without creating hell. It's very very good in that role. A kind of python fend reactive sibling.

The community is filled with people from react/angular backgrounds.

oh so I'm niche.

Reply on news.ycombinator.com