Vue 3 Beta
github.com
github.com
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
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)
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.
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.
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.
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.
For any serious development I stick with 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.
Vue tries to keep code and HTML separate.
React says "everything is code".
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 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.
However, you can still use JSX and TSX with Vue if you want. Or mix them.
You might find useful information here: https://phabricator.wikimedia.org/T241180
(The Wikimedia Foundation describes why they went with Vue.js instead of React or other competing libraries)
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.
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.
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.
export default () => <div>{1+1}</div>This is neither valid JS or HTML.
is
export default function () { return React.createElement('div', null, 1 + 1) };
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.
But in reality it's a DSL.
I have never read anyone bragging about DSLs in javascript. So react's marketing seems dodgy.
Also is Babel a transpiler or compiler for JSX? And is React useful without JSX?
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.
I don't take issue with how React works, I take issue with how it's being presented to new users and outsiders.
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.
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.
Vue embraces web technologies. JS is to enhance your HTML.
React is a javascript-first, FP-first mentality.
Minor point: vue benchmarks slightly faster these days. The react runtime has gotten pretty thick.
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.
The approach of using a compiler instead of a framework makes a lot of sense and I personally believe it's the best way forward.
I recommend watching the talk here; https://svelte.dev/blog/svelte-3-rethinking-reactivity
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.
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.
Reacts needs Suspense because it's quite slow and bloated in comparison.
See this video Rich Harris made when comparing a visualization use case:
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.
Svelte can target web components, which allows you to use it in just a portion of a web page, just like react.
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].
[0] https://www.swyx.io/writing/react-survey-2019/
[1] https://github.com/typescript-cheatsheets/react-typescript-c...
[2] https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...
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!
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.
For anyone else, yeah, they should probably be using TypeScript in 2020.
If yes, why do you not use it often now?
Edit: read it wrong, nevermind.
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.
> time spent fixing things that would have been caught [by Typescript] out weights the cons of using typescript
It's not fair - Microsoft and co. have done a tremendous job with the implementation and documentation of Typescript. But the reality exists nonetheless.
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.
[0]: https://2019.stateofjs.com/javascript-flavors/typescript/
Thats like saying only 50% browsers can render html so its standard.
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.
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.
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.
26%, 33%, or 36% are some estimates.
1. https://managewp.com/blog/statistics-about-wordpress-usage
Blocks are essentially react components with a bunch of wordpress apis hooked in / around it.
*Depending on who you define as God, the creator of JS?
That doesn't mean everyone needs to use it.
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.
Put method in data or prop? It actually works, but why would you do that when there is a field called `methods`?
The setup method seems like a slightly enhanced data() that allow you to place things in a more free way.
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.
> “Build a Hacker News Client with the Vue 3 Function-based component API, Vuex and vue-hooks by Coding Garden with CJ on Youtube (video)” [1]
No idea if that video is good but 146:0 liked it.
Edit: comment mentions that “Building of Hacker News Client starts at 33:18”
[1]: https://youtu.be/g9bSmxnx-O0?t=318 (starts at 5:18)
https://krausest.github.io/js-framework-benchmark/current.ht...
Yeah it's significantly faster and smaller than Vue 2.