Congratulations to the Vue team, this is definitely a big win for them.<p>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.<p>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.
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.<p>The Github Commits[1] example on their documentation has a load of stuff that just doesn't sit right with me.<p>Things like<p><pre><code> v-for="record in commits"
</code></pre>
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?<p>Similarly, accessing properties like<p><pre><code> :href="record.html_url"
</code></pre>
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.<p>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.<p>^[1]: <a href="https://v3.vuejs.org/examples/commits.html" rel="nofollow">https://v3.vuejs.org/examples/commits.html</a>
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.<p>If only the Vue team could understand, we don't want React features. We'll use React when we want them. We want Vuejs.
Most of the discussion behind this decision, including feedback directly from Evan You (author of Vue), is here: <a href="https://phabricator.wikimedia.org/T241180" rel="nofollow">https://phabricator.wikimedia.org/T241180</a><p>It's pretty interesting to read through.
Love Vue.<p>Polymer 2.0 with its HTML imports still offered a better DX in my opinion.<p>Svelte offers a better DX than both of those frameworks.<p>I don't even bother with FE anymore, more focused on BE/infra - but Svelte is always a pleasure to work in.
Am I the only one who still has a preference for vanilla js?<p>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.<p>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?
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.<p>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.)<p>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.<p>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.<p>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).<p>Still miss Vue's simplicity at times but having rock solid TypeScript support is something I value more.
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.<p>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.<p>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.<p>So if the Wikipedia team knows Vue very well and yield its powers, may the force be with them.<p>Use the framework your team knows best. It’s really about the players more than the instrument.<p>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.<p>Seems Wikipedia chose Vue because folks knew Vue in depth. That’s a good way to move forward.
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)<p>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.<p>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<p>Am I the only one here who absolutely <i>hates</i> 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…
No obvious advantage or win for wikimedia?<p>* More complex, slower build process.<p>* Increased barrier for development.<p>* 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.<p>* <a href="https://htmx.org/" rel="nofollow">https://htmx.org/</a>
Wish Vue would just adopt JSX. Any web framework that invents another templating language force users to learn a whole new thing with it's own gotchas. So much unnecessary mental overload.
Good luck getting any libraries working. Good luck using graphql. Good luck getting the tooling stable. Good luck getting a PR on the main code base done. Vue in production is a minefield of nightmares.<p>Rather have Facebook as a single point of failure than some random dude who has other things that consume his interest.