There was a big thread a few months ago about these features: https://news.ycombinator.com/item?id=21391381. Is there
significant new information [1] since then? If not, this is substantially the same story and we should wait for the actual release [2], since there will certainly be another big thread then.
For someone with little experience with the modern front-end development, what are the reasons to choose Vue over React or vice-versa? Are they both just different flavors of the same patterns or is there a philosophical difference in the two?
Vue is kinda the unofficial successor of Backbone.js, Angular 1 and friends. You write templates mixing HTML and Vue syntax that you bind to DOM elements. You can pass data and event handlers to your templates. You separate your markup, your CSS and your JavaScript like you have always been doing. It just works. Pretty easy and quick to get started, even without a big programming background.
Meanwhile, React lets you write your UI with JavaScript functions, which is completely different from anything I've seen before. You develop a bunch of functions and reuse them everywhere. Since functions are first-class citizens in JavaScript (i.e. you can pass a function as argument to a function and a function can return another function), there are pretty cool patterns in React. Like functions that enhance or inject styles or logic into your components (which are just functions too). This offers a lot of composability and reusability options to design and code your applications. (personal tip: Add TypeScript and VSCode on top of it to make your productivity skyrocket)
They're pretty similar, but Vue enforces structure and good patterns early on in the development cycle. React gives you more freedom.
I've been a consultant using both for over 3 years now, full time and I can tell you I just use Vue these days. Everything is more readable, well-organized when the project is finished. You could do the same with React too, but it puts the mental burden on you.
I think performance-wise as well Vue is faster (it used to be). Not that it matters a lot.
But, if you are a company, it's easier to find React developers than Vue developers.
Also, in big company environments, teams using React always end up in messy code that's not maintainable because of the freedom the framework gives as opposed to teams using VueJS.
So you need to pick the one that fits your use-case.
> Also, in big company environments, teams using React always end up in messy code that's not maintainable because of the freedom the framework gives as opposed to teams using VueJS.
This is debatable...
> But, if you are a company, it's easier to find React developers than Vue developers.
... and this is probably one of the reasons why you've found more "messy" projects in React than in Vue.
In other words: people who know what they like (and hence probably do a good job with it) pick either Vue or React. Teams that don't know pick React because it is more widespread, easier to hire for, etc.
> Vue enforces structure and good patterns early on in the development cycle
Could you expand on this? They're both tools for building components, how does Vue enforce more structure? FWIW I usually expect the same high-level structure for applications with both frameworks.
They're pretty similar. I prefer React because the JavaScript-first approach is much better for large applications. It leads to a smaller API while simultaneously giving you more control over how things work. Also Vue has a lot more magic to it which you might care about on a large project.
The use case I recommend Vue for is when you just want a quick drop-in solution. For any serious development I stick with React.
Isn't this a bit disingenuous given Vue's usage in true, scalable production capacities? I'm not the expert but companies like Netflix, Adobe, and GitLab have Vue deployed at scale. Since when was "quick" synonymous with "not sufficient for serious development"?
To my understanding the biggest reason GitLab chose Vue was because they were able to easily mix it in with their existing stack. That's part of what I was referring to by "drop-in". You can do the same with React but it's more heavyweight unless you plan on porting the lion's share of your app to React.
As for the others I'm not sure what they're using Vue for specifically and can't really speak to the technical reasoning behind it. I'm not saying that you can't do serious development in Vue but rather that all else equal I will guide teams to adopt React, mostly for the better developer ergonomics.
There's nothing trivial about being "drop-in". Usually these are complex apps running on traditional web frameworks and/or use server-side rendered pages where Vue excels in adding front-end interactivity because it uses HTML templates by default (with that HTML coming from the server).
Having spent years in the old "MVC html template framework" world, I used to be in the former camp. But nowadays I find JSX/TSX incredibly convenient. It's nice that a component is represented by a single javascript(ish) language.
I agree on the templating as code, in terms of ease of us. (Already know JS? Learn nothing. With maybe the exception that "class" is now "className". `<Foo bar="1">` is a construct for `React.createElement(Foo, {bar: "1"}, null)`. It's wonderful.)
I would imagine Vue is a much lighter, far less opinionated version of Angular. I've never been able to understand why templating is superior. And I want a strong argument that makes me seriously appreciate it, even if I don't change my mind. I've yet to see it. One gripe, at least with Angular templating, is templating constructs that are defined globally feel like leaky abstractions. Angular Pipes, for example. When I see a pipe, it's hard to find where's it's defined, where as React components are imported at the top of the file.
Because I already know the language, it's easy to conceptually build on top of that, which is why JSX is simple. But templating essentially defines a whole new language on top of it. It's not an insurmountable barrier, but it increases friction.
Maybe there's different brained folks where either "everything as code" vs. "HTML templating" is simpler.
well, one reason why templating is good and one of the things we are expecting in Vue3 is fine grained optimization of updates. Because the templates are essentially a well known interface for change, you can optimize UI patching.
However, you can still use JSX and TSX with Vue if you want. Or mix them.
I think it's just easier to ramp up in Vue.js than in React. The Single File Component approach is easy to grasp for beginners since it just looks like an HTML file with three main tags: template, script, style.
IMO it's a huge difference in learning curve too. In Vue I was up and running in a day or two but React took me weeks to really feel like I knew what I was doing—and I learned React after I learned Vue.
Single File Component tells you where you need to put things. You don't need to figure it out yourself and build up your own organization and patterns on top of Vue. You just start building the application.
It's not a completely apt comparison: but Vue shares more in common with Rails than with Node development—at least in terms of grokking. My understanding is their performance is virtually the same. Some applications perform better on one vs the other.
I started a project in Vue and strongly regret it. At some point I would like to switch to React.
The biggest reason is that React works properly with Typescript. Vue can't type check anything in your templates, you can't type check Vuex (its state management system), you can't type check injected dependencies. Everything is strings. This means you'll spend a lot more time chasing down runtime errors and writing tests than with React. A lot more time.
Other differences:
* React doesn't have events, but frankly you should not use them in Vue either - use callbacks instead.
* CSS has to go in a separate file in React. That is a little annoying to be honest.
* React has an API split between traditional class-based components and function-based components ("Hooks"). They say to use Hooks in new code but I've seen some things that are really awkward to do with Hooks. Still you can just use class-based components if you like (same as with Vue).
* The React NPM package has something like 5 dependencies. Vue has something like 1000. It's basically impossible to avoid the NPM insanity if you use Vue.
* React has better documentation. Not that Vue's is bad, it's just not as extensive as React's.
* React is way more popular. Easier to hire people to work on it, bigger community to get help from etc.
* React has better tool support. Everything supports JSX/TSX. Not many things support .vue files. For example if you define a type in a .vue file you can't actually import it from any other Typescript files. Quite annoying.
There are probably other things I've forgotten. If you're using the class-based React approach then yeah they are quite similar; React is just much better engineered. If you are using React Hooks then it is quite a different approach to Vue.
For me Vue biggest advantage is it's simplicity. I haven't learned much about Vue 3 yet but Vue 2 can still run the good old jQuery way and all you need is a script tag (no weback, etc). Also I find the syntax super easy and minimal.
A valid vue component can be as simple as {template: <div>{{1+1}</div>'}
Ofcourse you can extend it all you want and it even comes with its own cli but the fact they've managed to keep things so simple is what I love most about it.
If your concern is for beginners, I can appreciate that. But for anybody developing an enterprise grade application, using a transpiler isn't an appreciable barrier to entry. For beginners, there's create-react-app, vue cli, and angular cli. So you can get started immediately, without even knowing what a transpiler is.
Call it what you want. The point is instead of inventing an entirely different template language, JSX adds a little bit of HTML/XML-like syntax to JavaScript. You use regular old JavaScript operators and functions for things like conditionals and loops.
You don't have to use JSX with React, but the vast majority of people do, because they aren't dogmatic about it not being "pure" JavaScript or whatever.
Superficially the first thing that most developers I've spoken to notice is JSX vs HTML-based templating. But both frameworks are very similar. I started with Vue and when I took a job which used React I found that I already knew how things worked.
Beyond that, I would say the biggest difference between the two is that Vue is the scope of the framework. Vue includes much more in the framework itself and as first-party helper libraries whereas React relies heavily on third-party packages of which there often many competing options and which one is used varies from company to company and project to project.
They achieve similar goals, it's all about how they go about that.
React is pretty opinionated; it wants you to do things a certain way. There's a very good reason for that way too: Facebook arrived at that opinion after solving some serious real-world problems.
Vue seems to steer around any strong opinions. It feels like something that the W3C would have come up with, it feels like it belongs in a browser. You can use mostache-like templates (which approximate web components), or you can use JSX, or you can use no-frills raw JS (which really set it apart for something I was solving).
It is mostly aesthetic parameters. There are functional parameters, but you're in rare company if you care about them.
For my uses Vue is actually much more friendly towards non-standard environments but that’s never been a selling point it’s just a bonus. I heavily use TS, Components, and VueX so Vue 3 here looks pretty good to me. I’ve seen more devs in my shop take a liking to react due to it being slightly more mainstream. Vue doesn’t offer an OOTB solution to everything as much as react does but the other side of the coin there is that it’s more adaptable to uncharted territory. I think for devs out there that just desire a few things and they’re ready to start coding Vue is the perfect framework.
For larger applications using JSX together with Typescript means you get type checking in model code and view code. For that reason alone I'd go with React for bigger apps.
I like that I can embed a bit of vue code into an existing web page. Bit like old school javascript. AngularJS 1.x was like that too and the inspiration for Vue. React/Angular require a whole build process with NPM/webpack etc etc to create a SPA.
React is more popular, which is a gift and a curse. It leads to a lot of amateur coding, which is quite bad, but if you just want to glue something together, you can find the parts.
Vue itself is both smaller and more full featured than React. To make a working React you need to add a lot of parts (React DOM, CRA, Redux, React Router, CSS in JS…) which are often only semi-official, whereas Vue has solutions either built in or officially supported.
I honestly wouldn’t recommend React per se to anyone who has a choice, but it’s good to be familiar with it to get a sense of how the trends are moving, and they often have ideas that inspire (built in or officially supported) parts of Vue.
When anyone I talk to asks me about developing modern web pages, I point them to Vue, and they have all come back with praise for it. I can't imagine doing that with React or Angular (I'm in the middle of a pile of Angular wishing I was somewhere else). The learning curve and simplicity, to me, is the number one killer feature of Vue.
I've used Vue, React, Preact, Mithril, Inferno, Imba, and Angular for the past 6 years. I started doing front end in the late 90s btw.
I tried Svelte for a small project last year and liked it. A couple of weeks ago I evaluated it more seriously and decided to go with it for my current big project.
I was initially attracted to Svelte by the performance and small bundle sizes but was concerned about all the custom syntax, single file components, and the pragmatic magical approach. But oh boy after using it for a couple of days you become super productive really fast. I think this is actually its best feature.
Apparently scheduling/skipping renders is hard with this approach, since render function gets compiled away and becomes hardcoded DOM calls in the result bundle. React with Suspense takes a different approach here and allows to suspend renders, skip slow renders (I think) till they're ready, prioritise keyboard input, etc.
It's essentially a similar tradeoff as in AOT vs JIT. Even though AOT brings the compilation step forward, JIT would have much more runtime context for better performance.
I’ve been using Svelte for nearly all my personal projects for a while and I absolutely love it. The only thing I really wish it had was typescript support, which I think is in the works.
> The approach of using a compiler instead of a framework makes a lot of sense
I agree, I wish it wasn't an entire framework though and more of a front-end library like react. I've learnt long ago not to invest too much into a single tool.
I should've said "rendering engine" rather than "front-end library", to still be able to use things like redux, css processors, etc. But your comment made me realize that may not actually make sense. I'm still generally hesitant when a single framework takes over the entire chain.
How significant is the adoption of TypeScript? Angular was built with it; React now recommends it too. Is this really the ratification of TypeScript as THE front-end language?
React itself is written in Flow, but the React team doesn't make any official recommendations as for language or static type syntax to use.
That said, a recent survey of /r/reactjs readers [0] showed 50% using plain JS, 48% TS, and only 2% using Flow . Given that the React ecosystem probably has the most Flow users, I'd say it's safe to describe Flow as dead.
From my viewpoint, TS has more than hit enough critical mass to survive for the long term:
- Microsoft is heavily invested in its ongoing development
- The Angular community requires use of TS
- Per that stat, it's reached solid adoption in the React community (see guides like the React+TS Cheatsheet [1])
- Where CoffeeScript introduced new syntax entirely, TS's focus on being a superset of standardized JS means that there's both less to worry about compat-wise _and_ it can be seen as a way to use new language features instead of Babel.
So, seems like it's going to be around for a while.
I wrote up my thoughts last year on my own experience learning and using TS from both an app dev and library maintainer's perspective [2].
Which makes me sad: I've built two production systems in Flow, and I found it absolutely delightful, with the caveat that I specifically chose all third party libraries that supported Flow as well. It's type system (and `import type` instead of Typescript's overloading of `import`) was ridiculously powerful, and back then significantly more-so than Typescript. That's no longer the case, of course, Typescript has smartly stolen most of the advantages Flow had, and it has so much more support from the outside world that it'd be silly to use Flow today.
On top of that, I think a lot of the momentum of a powerful type system for front-end development has moved (in the React world) towards Reason anyway. Between Typescript and Reason, we're spoiled for choice in building robust front-ends that stomp bugs early and often!
Yeah, I only briefly dabbled with Flow myself a few years back. By the time I got around to looking at TS and Flow again, it was clear TS had won.
Someone asked me the other day why TS had gotten more popular than Flow, and this was the summary I gave them:
> Early on, Flow was considered to be better at actual type-checking. But, the TS team has kept cranking out releases on a monthly basis, and mostly caught up in that regard.
> The TS community put a lot of effort into defining types for libraries, which convinced lib authors to write libs in TS, which convinced people to adopt TS because there were more libs with types.
> Meanwhile, the Flow team was pretty quiet, there were complaints about Flow sucking up memory and crashing, and Flow anecdotally seemed to have a lot of breaking changes in its analysis that made upgrading a pain. (The breaking changes were likely making the analysis better, but compilation errors are compilation errors).
> Eventually it hit a tipping point and TS adoption reached critical mass. Now, very few people outside of FB use Flow.
Reason looks interesting, and it's certainly got some very smart folks working on it, but it's still very much at the "niche experimental toy" level compared to TS.
It's important to remember that there are still a lot of front-end folks who aren't interested in application engineering, but still might find these frameworks useful. For those kinds of people, static typing is a harder sell.
For anyone else, yeah, they should probably be using TypeScript in 2020.
I adopted typescript shortly after it’s release and went through growing pains in the first couple years. I don’t use it often now. And it ALWAYS comes back to bite me in the butt when doing any decent sized project. If I had to guess time spent fixing things that would have been caught out weights the cons of using typescript
I recommend it.
I dont use it because I dont think I need it. I think mostly because I fall back into old patterns that are easier for me to do. I got burned a bit with original build system having to create all my interfaces etc.
I read the exact opposite: that they regret not using typescript for non-trivial projects because tsc would have prevented dumb mistakes due to a lack of types.
Correct.
Small project turns into a bigger project, I think I can get through some complicated piece and BAM. I'm fighting silly typing issues and writing tests for stuff I would never have to do if I used typescript. While majority of my stuff is not that complicated, it seems there is always something.
I also wear a bunch of hats. So retaining all the new knowledge gets a bit hard. Sometimes its easier for me to fall back to patterns I used over the past 20 years of full stack development. If I had the time I would use typescript everywhere.
Correct. Most of my projects now and days are under 300hrs greenfield stuff. I do feel typescript can be a little more overhead to get started, once you have some well established patterns IMO its great for more enterprisey projects.
The tooling for Typescript still isn't good enough to claim that accolade. There are still combinations of libraries, linters, editors, and frameworks, that throw opaque errors that will roadblock students and junior developers significantly. Ultimately until browsers can accept Typescript directly without a compilation step it will remain a second-class citizen. Until then, all of Webpack, gulp, parcelJS, problems and inefficiencies are Typescript's problems and inefficiencies.
It's not fair - Microsoft and co. have done a tremendous job with the implementation and documentation of Typescript. But the reality exists nonetheless.
You're right the tooling could be better and that TS trips up beginners. Promises trip up beginners as well though but that doesn't mean they're not standard.
TS is very, very close to being standard practice. It's already being used by over 50% of JS developers [0]. It doesn't have to be beginner/tooling friendly to be widespread.
I never said it was standard. I said it's very, very close. 50% (actually 58.5% of just those that would use it again) is certainly within the realm of critical mass.
Typescript (the compiler), documentation, etc. as a language is pretty darn good. It could have more production ready examples, tutorials, and paths (I'd recommend a look at Microsoft's ASP.net Core tutorials which cover production-level material).
But as I said the problem is Typescript inherits the whole mess of bundlers like Webpack and Gulp because they are REQUIRED to make any of it work in production. Ideally Typescript would own the entire bundler step - the closest example would be .NET owning the LINQ and Identity tools/libraries to make the .NET experience so much better.
dealing with different JS environments, getting imports right, importing Vanilla js.
ie. if i am building an electron app, we have atleast 4 different JS environments (UI thread, background thread, web worker, nodejs worker, nodejs-fork, test-runner environment) that all have different levels of compatibility with different JS standards.
importing and exporting libraries in mixed mode is the worst thing about JS, bar none. The amount of obscur errors one needs to deal to get a debug-source-code-stepable pipeline up and running astounding.
Please be careful with anointing winners, that stops people from exploring and evaluating all the options, and encourages force feeding whatever is “in” into their projects.
Well, it's pretty clear in this case. Typescript has even more traction and better integration (like VSCode's magical definition fetching) than I think anyone could have imagined. It dominated its reasonable competitor, Flow.
It's kind of a freak win. I think we can say confidently that nothing is going to usurp it.
Not like any compile-to-JS language has come close even when JS was at its worse. Now JS is so good I don't even know why I'd use another dynamically typed language.
We rarely get blindsided by what actually gets traction because almost nothing does. Something that looks like Typescript isn't going to beat Typescript. Something that's more foreign looking certainly isn't either.
I mean there's the typed functional set, PureScript, Elm, BuckleScript, Reason, etc., that compete with TypeScript on type systems why compiling to JS while offering better ergonomics for FP-style code.
They could be serious contenders only if they coexist gracefully with the rest of the JavaScript ecosystem: e.g., here's this new awesome type system, but oh... You can't use React + Redux + Material UI with it, it's might be D.O.A to a certain segment of engineers since it has no real practical application for solving today's front end engineering problems with them.
First off, not everyone likes those technologies for a variety of reasons--and solving a front-end solution a an alternative is valid. Outside Elm, PureScript, BuckleScript, and ReasonML all work fine with JavaScript libraries and have React interop/wrapper libraries already. I may dislike it, JSX is supported out of the box with ReasonML. I think some pain with JS interop could be worth the trade-off for either better types, managed IO, no null by default, immutablility by default, no option for any, exhaustivity, and the list go on--not just as a linter feature or a config option but built into the language.
Probably not. The numbers I’ve seen suggest that far less than 5% (I think it was 2%) of websites use a library like react, Vue, or angular. Of course, you can use Typescript on its own, but if you are using Typescript, chances are you are also using one of the big 3.
I think it's worth clarifying that Vue 3.0 won't require you to use TypeScript. I think the way to think about this is that tooling will ideally improve for a lot of JS devs regardless of whether they decide to use types or not.
I don't get the hype. We wasted a lot of time fighting the compiler and warnings and errors, and then falling back to `any` and by then, why not just use Javascript the way God Himself intended.
Anyone have details on what it means that Vur 3 can “more easily target native?” Is there something about Vue that’s been keeping Vue-powered Nativescript, Ionic, or Quazar from having feature parity with React Native?
The new Composition API definitely looks interesting. But it's also kind of a shame that there are now two very different ways to write the same functionality, both blessed by the framework.
The first version jumped right in and solved an immediate problem. Even with the best foresight possible the designers simply could not see all the problems they would run into.
Or even if they did, sometimes pragmatism forced fixing issues down the road.
After doing this for over 20 years (I build software coders/designers/laymen use) I am really impressed with how well Vue was designed to start with, and the migration path (at a glance) looks nearly painless from v2 to v3.
I think the original plan was to eventually phase out the Options API, but the community pushed back during the first RFC phase resulting in the dual API solution.
Although the benefits of the Composition API are clear-cut, the Options API is beloved by the community for its ease of use and clarity. For me personally, it will be hard to switch since I'm not a heavy user of mixins and I don't venture too far beyond simple components. However, I still need to learn the Composition API in more detail so I can make a more informed decision. Evan and the Vue team worked very hard on v3 and I trust them to make the right decisions.
what I found is the composition API is actually nicer to deal with not even considering mixins. Because things are grouped together you don't end up moving around your files so much so it ends up being quicker.
Is the Composition API going to be the only way to do things in some future version of Vue? I see why you’d want the elegance of it but also it seems to trade having to know which properties this has for having to strictly order property and method declarations. It’s like we went from declarative to procedural components and I am not sure I like it.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...