Congratulations to the Vue team, this is definitely a big win for them.
Reading through the RFC is really interesting. They specifically call out the dependency on Facebook as effectively being React's Single Point of Failure, citing their negative experiences with HHVM.
And for all of the love that people give React's big shifts (like hooks), the RFC specifically counts this against them, given that best practices have shifted so drastically in the last few years.
Although I understand what you saying about big shifts and kinda shared your opinion, specially about hooks, I started a new project from scratch last week and decided to give hooks a try (and, for reference, I've been using React on a daily basis for 5 years).
Oh boy I was wrong.
Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially when before you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug and use with TypeScript, and eventually making it a nightmare to understand and maintain your component. I'm not surprised that every React library added a hook API to its core.
At the end of the day it makes me more productive, so I guess that big shift was also a big win.
I don't know. I'm not as familiar with Vue, but React's ecosystem is in such a good spot right now. Between things like RTKQ (or react-query), Material-UI, and react-hook-form, the abstractions over common web use-cases are just so terrific to work with nowadays.
And then just being the larger community, I just feel like all there's more examples in general for everything. Most things default to React as the guiding implementation.
I agree with that. Its been like a twilight zone interviewing for anything frontend in Silicon Valley the last couple years as they "me too" for React, while I use Vue on my own projects.
Now, the original reason I chose Vue was mostly around a small client side package size, but all the SPA frameworks have some version that prides itself in small client side package side now, and they mostly reach parity on similar concepts.
Facebook is a steward not a dependency. React has been free and open source and largely driven by the needs of the community. Right down to that time when the community cried out about Facebook's odd license clause regarding patents. And they changed it.
But I can't imagine modern technology being where it is without big shifts. Perhaps that is not good for very long term projects. We'll see how Vue fairs in the long run if they never make any big shifts, I suppose.
Then again, none of the big shifts in React broke anything permanently, did they? I could be wrong about this, I haven't been paying attention since the very beginning…
I feel like I'm in an alien world when it comes to Vue - it has this weird pattern of making strings do loads of heavy lifting.
The Github Commits[1] example on their documentation has a load of stuff that just doesn't sit right with me.
Things like
v-for="record in commits"
to loop over something is insane to me - this isn't code, this is a string inside a html attribute! How can you get any sort of good type analysis/variable checking/syntax highlighting inside this?
Similarly, accessing properties like
:href="record.html_url"
has the exact same issues - what if there's a typo here? My IDE can't highlight that this is wrong because it's *not code* and is just a string.
Maybe I'm just the odd one out here, but vue (and angular) love to use strings as a makeshift programming language, which to me is a major smell.
> My IDE can't highlight that this is wrong because it's not code and is just a string
Code is just a string too, treating the 'code' inside the string literals after the v-for is just an extra level of syntax handling - The IDE I use (Intellij) can handle it just fine.
Yeah, this isn't really an issue; it's just a templating language. You can get an extension for your IDE to make it syntax highlight correctly. That's like saying a .js file is just a string. Um, yes I guess sure? All code is just a string. HTML is also just a string. Vue's HTML templating syntax is also just a string, but it's also code. It's code that's mainly HTML, with certain spots that allow full JavaScript. And just like normal code, you can have compile time errors, syntax errors, runtime errors, etc.
Also as a side note: I'd say the best thing about Vue isn't it's templating system, but the fact that it's truly reactive. In react, only rendering is truly reactive. If you have reactive variables that depend on each other, then you have to manually mark those dependencies. Vue can deduce that dependency graph automatically, which makes coding much easier. It's like a giant spreadsheet.
Vue is brilliant when you actually use it. Nothing you've mentioned is remotely ever a problem in my experience. Also :href="xxx" isn't a string, that is javascript in there.
You won't ever have more than 10 characters at most in an attribute, and if you do you make a method for it and call the method.
The other alternative is JSX type stuff in react where you are injecting full JS into the templates which is like committing seppuku to me. Vue is so much nicer to use than react IMO, and I've used both extensively.
All code is text. There is no pure "code" representation, text inside attributes being parsed as JS is no different than parsing text inside some <script> tags.
Also modern component-based JS frameworks all work the same way. The UI definition is a template that's compiled into a render function which produces the final output during runtime. Each framework uses different syntax: React uses JSX which is a domain specific language (DSL) that mixes HTMl-like tags into Javascript. Vue uses HTML with directives on top. Angular, Svelte, etc all use their own formats.
You can even mix and match (use JSX with Vue) or write your own render function if you want, but it's the same text->parsing->lexing->compilation cycle that every language goes through before turning into actual CPU instructions.
I'd clap harder if Vue weren't so desperate to become React and focus on their own strengths. React certainly appealed to a lot of devs who at best disliked working with HTML & CSS, but Vue welcomed everyone with an excellent gentle slope to gently move devs away from direct Dom manipulation and embrace reactive paradigms. Folks with small shops could now refactor their codebases with relative ease.
If only the Vue team could understand, we don't want React features. We'll use React when we want them. We want Vuejs.
Agreed, Svelte is by far the most productive FE I’ve used. Coming from a jQuery/templating background, at first felt Vue was the most intuitive to use (React felt alien, Angular overly verbose)…
Until I met Svelte…Vue, minus the BS. A clean template system, less boilerplate, no Virtual DOM, nice Typescript support, intuitive state mgmt.
Btw if you liked Polymer 2.0/3.0 you may also like Lit (formerly lit-element)[0].
It has a less "proven" ecosystem around state/async action management and some other concerns (i.e. there's no redux/vuex), but the controller paradigm[1] looks pretty fresh and interesting. I'm of the belief that most of the time doing an async request or two and some caching and good architecture is enough for most app (not everyone needs the flux pattern).
Lit is by the best implementation and standards-compliant component-centric library IMO. Tried a bunch of them back when I was trying to figure out if there's a better way to handle state in a component-centric world[3].
Am I the only one who still has a preference for vanilla js?
Maybe it’s just my use cases, but every time I try to use a high level framework like vue or react I am immediately bogged down by unnecessary abstraction and complexity.
Again, I’m no UI dev so please correct me if I’m wrong! I have pretty simple needs for web app UI usually…I’m not trying to build Facebook. Why do I need react/vue/whatever?
Have you tried Vue? It’s very different than React because you can just augment your HTML with what you need, it’s not all or nothing. What’s complex and usually overkill for small projects is the "modern" build tool chain, but you can ignore that and just add the <script src> and be done with it (same with React BTW). You can get familiar with AlpineJS which is kind of a minimalist Vue.
Working without a framework in a team, you can easily have a situation where each developer comes up with novel solutions to various basic and essentially common problems. I've seen it happen that each dev invents their own way of working, their own micro-framework, and the others are mostly unable to work productively in the others' particular styles.
This can of course be countered by pair work, extensive reviews, creating best practices, etc. However, there's a value in adopting something that already comes with those, instead of inventing them from scratch. The correct answer really depends on your situation and team size, I guess.
Huh. They're still deciding on whether to use Vue 2 or Vue 3... To me that's a definitive sign that Vue chasing after React's insane hooks system was a bad idea. I hope they figure out how to heal the rift before it's too late before we get another Python 2/3 situation.
A solid choice and well reasoned. It was a joy to read all of the discussions.
Been following Vue and Evan’s work since 2015, before it even reached 1.0. I think it strikes a good balance between the freedom of React and the rigidity if Angular. (Interpret the terms “freedom” and “rigidity” as you please.)
My only problem with Vue 2.x was the bad TS support, but I trust 3.x solves that.
I really enjoyed working with Vue 2 until I started using TypeScript.
Vuex, the goto state manager just wasn't built for it (I ended up using vuex-module-decorators). Type safe templates were only partially possible with Vetur (vs code extension) but it was slow and resource hungry. I'm sure in Vue 3 this is much better now, but while evaluating to migrate to v3 this wasn't the case.
I became interested in React, because I was looking for a way to generate type safe email templates. Started using .tsx files with a library called typed-html and loved it so much that I end up migrating to React (now rendering email templates with ReactDOMServer.renderToString(element).
Still miss Vue's simplicity at times but having rock solid TypeScript support is something I value more.
For anyone alarmed about moving towards a SPA, and potential performance impacts etc, read the comments towards the top of this link from the Vue Team Lead and proposal co-author. They address the most obvious concerns.
Thanks for the link. A lot of people went out of their way to criticise Vue which makes me wonder how the general opinion of Vue has changed in the last year.
Over more than a decade I have gone through Adobe Flex, jquery, vanilla js, angular 1 & 2, vue 1 & 2, React, a bit of svelte, web components, my own custom state mgmt libraries.
The fundamental idea behind most modern FE frameworks remain the same. View is a function of state. The hardest problems in FE are state management and CSS/dom layout.
So as long as someone knows what they are doing any of the modern frameworks do a decent job. I have seen bad code in every framework.
So if the Wikipedia team knows Vue very well and yield its powers, may the force be with them.
Use the framework your team knows best. It’s really about the players more than the instrument.
I personally like React. It solves many of the pain points I’ve experienced over 10+ years. I’ve invested a lot of time learning it in depth. If someone told me to write react from scratch with hooks api, I know how to do it.
Seems Wikipedia chose Vue because folks knew Vue in depth. That’s a good way to move forward.
> Svelte, Inferno, and Preact are aggressively optimized for performance but have much smaller communities of users (Preact suffers from this issue to a lesser extent, but only as long as it maintains a very high level of compatibility with mainstream React, which may not be the case forever).
Picking Svelte is risky, given its low adoption. I'm not saying Svelte won't ever be widely adopted, but there's a risk that it fades away and you're stuck using a dead framework.
Svelte and Vue are actually very similar in some ways. Personally, I hope Vue creates an option to compile its components into static components like svelte; having the option to have a runtime component or a static compile time component would be super powerful!
react is api stable, but not api stable if you know what I mean. with react, the ground is always shifting underneath you, which something like wikimedia probably don't have the resources to keep up with. even, as someone who has done react professionally, I can advise any small nimble teams, out there react ain't for ya. it don't love ya. however, for the big enterprisey apps, yeah react is good.
From reading the RFC, I do feel like the choice for Vue.js was already made from the get-go. A few of the concerns laid out were brushed aside without much pondering (At least pondering within the thread, I don't know about the IRC channel)
Vue's deprecation process is still a big problem in my view. Migration from Vue 2 to 3 is a painful one, while React doesn't have this problem.
You can argue that component writing practices have changed over the past years in React, but the old ones all still work, while Vue 2 components just don't work in 3.
EvanYou's comments about a future "compatibility build" for 3 that works with 2 is honestly still a bit worrying. I'm glad it exists but it just so easily convinced them. Is there going to be a performance penalty? Will it all work out of the box?
> - Deciding on Vue 2 or Vue 3 including transition path
Am I the only one here who absolutely hates Vue 2? No TypeScript support and no type safety at all (neither for props, nor for events, nor for provide/inject); many identifiers and references are hard-coded strings, making it very hard to discover dependencies between different parts of the code; `this` gets implicitly populated with props, data, computed, methods all at the same time and in some order that still escapes me; refactoring support even in IntelliJ/WebStorm is full of bugs (hardly a surprise given the missing type safety); horrible documentation ("Here's an example" != documentation); no proper two-way binding (i.e. one that doesn't produce change detection cycles). I could go on and on and on…
That's the idea. Various tools and power-user features benefit from the things that modern JS frameworks give you. But the basic experience of reading articles should support the lowest-common denominator.
Most JS frameworks consider the SPA use-case to be the "happy path". There are a few outliers like the Stimulus family or Alpine (which I don't think existed at the time of the RFC) that expect to be sprinkled in to server-rendered HTML, but scaling these tools to full-blown apps may prove difficult.
I think Vue can operate in between these two use-cases better than some of the alternatives. Being able to compile templates at runtime is also a useful feature in a legacy environment, where you can't just transpile all the things ahead of time. You have to ship some extra code for this, but it's nothing compared to the cost of shipping (and running) all of Babel, which you'd need to compile JSX.
* ECMAScript has been evolving so quickly lately that it will probably supersede Vue in the near future anyway. The true "futureproof" choice is to continue evolving with the latest ECMAScript spec.
[+] [-] ferdowsi|4 years ago|reply
Reading through the RFC is really interesting. They specifically call out the dependency on Facebook as effectively being React's Single Point of Failure, citing their negative experiences with HHVM.
And for all of the love that people give React's big shifts (like hooks), the RFC specifically counts this against them, given that best practices have shifted so drastically in the last few years.
[+] [-] ggregoire|4 years ago|reply
Oh boy I was wrong.
Hooks are way more easier and intuitive than what I thought. It makes code so much more readable and easier to reason about. Especially when before you had to wrap your components into x number of HOCs to inject the props your component needed, risking props collision, making it really hard to debug and use with TypeScript, and eventually making it a nightmare to understand and maintain your component. I'm not surprised that every React library added a hook API to its core.
At the end of the day it makes me more productive, so I guess that big shift was also a big win.
[+] [-] buchanaf|4 years ago|reply
And then just being the larger community, I just feel like all there's more examples in general for everything. Most things default to React as the guiding implementation.
[+] [-] vmception|4 years ago|reply
Now, the original reason I chose Vue was mostly around a small client side package size, but all the SPA frameworks have some version that prides itself in small client side package side now, and they mostly reach parity on similar concepts.
[+] [-] wayneftw|4 years ago|reply
But I can't imagine modern technology being where it is without big shifts. Perhaps that is not good for very long term projects. We'll see how Vue fairs in the long run if they never make any big shifts, I suppose.
Then again, none of the big shifts in React broke anything permanently, did they? I could be wrong about this, I haven't been paying attention since the very beginning…
[+] [-] zkldi|4 years ago|reply
The Github Commits[1] example on their documentation has a load of stuff that just doesn't sit right with me.
Things like
to loop over something is insane to me - this isn't code, this is a string inside a html attribute! How can you get any sort of good type analysis/variable checking/syntax highlighting inside this?Similarly, accessing properties like
has the exact same issues - what if there's a typo here? My IDE can't highlight that this is wrong because it's *not code* and is just a string.Maybe I'm just the odd one out here, but vue (and angular) love to use strings as a makeshift programming language, which to me is a major smell.
^[1]: https://v3.vuejs.org/examples/commits.html
[+] [-] helsinkiandrew|4 years ago|reply
Code is just a string too, treating the 'code' inside the string literals after the v-for is just an extra level of syntax handling - The IDE I use (Intellij) can handle it just fine.
[+] [-] cdrini|4 years ago|reply
Also as a side note: I'd say the best thing about Vue isn't it's templating system, but the fact that it's truly reactive. In react, only rendering is truly reactive. If you have reactive variables that depend on each other, then you have to manually mark those dependencies. Vue can deduce that dependency graph automatically, which makes coding much easier. It's like a giant spreadsheet.
[+] [-] Exuma|4 years ago|reply
You won't ever have more than 10 characters at most in an attribute, and if you do you make a method for it and call the method.
The other alternative is JSX type stuff in react where you are injecting full JS into the templates which is like committing seppuku to me. Vue is so much nicer to use than react IMO, and I've used both extensively.
[+] [-] manigandham|4 years ago|reply
Also modern component-based JS frameworks all work the same way. The UI definition is a template that's compiled into a render function which produces the final output during runtime. Each framework uses different syntax: React uses JSX which is a domain specific language (DSL) that mixes HTMl-like tags into Javascript. Vue uses HTML with directives on top. Angular, Svelte, etc all use their own formats.
You can even mix and match (use JSX with Vue) or write your own render function if you want, but it's the same text->parsing->lexing->compilation cycle that every language goes through before turning into actual CPU instructions.
[+] [-] AbuAssar|4 years ago|reply
You get type checking, linting, syntax highlighting etc.
[+] [-] tomjen3|4 years ago|reply
Webstorm has zero problems letting me refactor it, because it can parse vue code in .vue files. This is seriously a non-issue.
[+] [-] jansan|4 years ago|reply
WebStorm and its bigger brother IntelliJ IDEA can handle this.
[+] [-] lenkite|4 years ago|reply
[+] [-] midrus|4 years ago|reply
[+] [-] pbalau|4 years ago|reply
[+] [-] ttty2|4 years ago|reply
[deleted]
[+] [-] vagrantJin|4 years ago|reply
If only the Vue team could understand, we don't want React features. We'll use React when we want them. We want Vuejs.
[+] [-] manigandham|4 years ago|reply
[+] [-] timdorr|4 years ago|reply
It's pretty interesting to read through.
[+] [-] skybrian|4 years ago|reply
I guess everyone’s been busy, what with a pandemic and all. :)
[+] [-] sativallday|4 years ago|reply
Polymer 2.0 with its HTML imports still offered a better DX in my opinion.
Svelte offers a better DX than both of those frameworks.
I don't even bother with FE anymore, more focused on BE/infra - but Svelte is always a pleasure to work in.
[+] [-] sebasslash|4 years ago|reply
Until I met Svelte…Vue, minus the BS. A clean template system, less boilerplate, no Virtual DOM, nice Typescript support, intuitive state mgmt.
10/10 my goto for any frontend project.
[+] [-] hardwaresofton|4 years ago|reply
It has a less "proven" ecosystem around state/async action management and some other concerns (i.e. there's no redux/vuex), but the controller paradigm[1] looks pretty fresh and interesting. I'm of the belief that most of the time doing an async request or two and some caching and good architecture is enough for most app (not everyone needs the flux pattern).
Lit is by the best implementation and standards-compliant component-centric library IMO. Tried a bunch of them back when I was trying to figure out if there's a better way to handle state in a component-centric world[3].
[0]: https://lit.dev/
[1]: https://lit.dev/docs/composition/controllers/#building-contr...
[3]: https://mrman.gitlab.io/services-as-dom-elements
[+] [-] rank0|4 years ago|reply
Maybe it’s just my use cases, but every time I try to use a high level framework like vue or react I am immediately bogged down by unnecessary abstraction and complexity.
Again, I’m no UI dev so please correct me if I’m wrong! I have pretty simple needs for web app UI usually…I’m not trying to build Facebook. Why do I need react/vue/whatever?
[+] [-] tarsinge|4 years ago|reply
[+] [-] danielbarla|4 years ago|reply
This can of course be countered by pair work, extensive reviews, creating best practices, etc. However, there's a value in adopting something that already comes with those, instead of inventing them from scratch. The correct answer really depends on your situation and team size, I guess.
[+] [-] russellbeattie|4 years ago|reply
[+] [-] gherkinnn|4 years ago|reply
Been following Vue and Evan’s work since 2015, before it even reached 1.0. I think it strikes a good balance between the freedom of React and the rigidity if Angular. (Interpret the terms “freedom” and “rigidity” as you please.)
My only problem with Vue 2.x was the bad TS support, but I trust 3.x solves that.
[+] [-] seph-reed|4 years ago|reply
I stopped using React specifically because it was so incredibly limiting. And my life has been a lot better without it.
[+] [-] adevx|4 years ago|reply
Vuex, the goto state manager just wasn't built for it (I ended up using vuex-module-decorators). Type safe templates were only partially possible with Vetur (vs code extension) but it was slow and resource hungry. I'm sure in Vue 3 this is much better now, but while evaluating to migrate to v3 this wasn't the case.
I became interested in React, because I was looking for a way to generate type safe email templates. Started using .tsx files with a library called typed-html and loved it so much that I end up migrating to React (now rendering email templates with ReactDOMServer.renderToString(element).
Still miss Vue's simplicity at times but having rock solid TypeScript support is something I value more.
[+] [-] threatofrain|4 years ago|reply
https://news.ycombinator.com/item?id=22625556 (March 2020)
[+] [-] the__alchemist|4 years ago|reply
[+] [-] seumars|4 years ago|reply
[+] [-] nojvek|4 years ago|reply
The fundamental idea behind most modern FE frameworks remain the same. View is a function of state. The hardest problems in FE are state management and CSS/dom layout.
So as long as someone knows what they are doing any of the modern frameworks do a decent job. I have seen bad code in every framework.
So if the Wikipedia team knows Vue very well and yield its powers, may the force be with them.
Use the framework your team knows best. It’s really about the players more than the instrument.
I personally like React. It solves many of the pain points I’ve experienced over 10+ years. I’ve invested a lot of time learning it in depth. If someone told me to write react from scratch with hooks api, I know how to do it.
Seems Wikipedia chose Vue because folks knew Vue in depth. That’s a good way to move forward.
[+] [-] qmmmur|4 years ago|reply
[+] [-] lifthrasiir|4 years ago|reply
> Svelte, Inferno, and Preact are aggressively optimized for performance but have much smaller communities of users (Preact suffers from this issue to a lesser extent, but only as long as it maintains a very high level of compatibility with mainstream React, which may not be the case forever).
[1] https://phabricator.wikimedia.org/T241180
[+] [-] paulddraper|4 years ago|reply
React, Angular, Vue.js are the most popular, in that order.
I hate to say might=right, but for a project like Wikimedia, choosing a mature, popular framework is important.
[+] [-] goodoldneon|4 years ago|reply
[+] [-] cdrini|4 years ago|reply
[+] [-] dzonga|4 years ago|reply
[+] [-] Daedren|4 years ago|reply
Vue's deprecation process is still a big problem in my view. Migration from Vue 2 to 3 is a painful one, while React doesn't have this problem. You can argue that component writing practices have changed over the past years in React, but the old ones all still work, while Vue 2 components just don't work in 3.
EvanYou's comments about a future "compatibility build" for 3 that works with 2 is honestly still a bit worrying. I'm glad it exists but it just so easily convinced them. Is there going to be a performance penalty? Will it all work out of the box?
[+] [-] codethief|4 years ago|reply
Am I the only one here who absolutely hates Vue 2? No TypeScript support and no type safety at all (neither for props, nor for events, nor for provide/inject); many identifiers and references are hard-coded strings, making it very hard to discover dependencies between different parts of the code; `this` gets implicitly populated with props, data, computed, methods all at the same time and in some order that still escapes me; refactoring support even in IntelliJ/WebStorm is full of bugs (hardly a surprise given the missing type safety); horrible documentation ("Here's an example" != documentation); no proper two-way binding (i.e. one that doesn't produce change detection cycles). I could go on and on and on…
[+] [-] Scarbutt|4 years ago|reply
[+] [-] katabasis|4 years ago|reply
Most JS frameworks consider the SPA use-case to be the "happy path". There are a few outliers like the Stimulus family or Alpine (which I don't think existed at the time of the RFC) that expect to be sprinkled in to server-rendered HTML, but scaling these tools to full-blown apps may prove difficult.
I think Vue can operate in between these two use-cases better than some of the alternatives. Being able to compile templates at runtime is also a useful feature in a legacy environment, where you can't just transpile all the things ahead of time. You have to ship some extra code for this, but it's nothing compared to the cost of shipping (and running) all of Babel, which you'd need to compile JSX.
[+] [-] geenat|4 years ago|reply
* More complex, slower build process.
* Increased barrier for development.
* ECMAScript has been evolving so quickly lately that it will probably supersede Vue in the near future anyway. The true "futureproof" choice is to continue evolving with the latest ECMAScript spec.
* https://htmx.org/
[+] [-] ggregoire|4 years ago|reply
[+] [-] katabasis|4 years ago|reply
Some of this code may change or get moved around based on the outcome of these tasks: https://phabricator.wikimedia.org/T286946
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] Exuma|4 years ago|reply