Vue 3 as the New Default
blog.vuejs.org
blog.vuejs.org
But Vite was a basically adding a single gem and it worked. I wasted so much time with broken Webpack stuff.
Ecosystem is as important as the frameworks.
vite is from vue3 originally, I consider it's one of the best 'by-product' from vue3, it's 10x simpler than webpack and 10x faster too, I use it for all javascript/typescript projects nowadays.
I can't say I disagree, vue3 felt like a react metoo-release, and now it looks like some features are temporary deadends requiring more tricks to manage.
This time last year I helped with adding Vue3 support to the TipTap editor and went headfirst into Vue3s internals. It’s a completely different machine.
Vue3s changes to its reactivity system is like Python 3s change to make strings Unicode.
We know you meant "composition api" but while I agree there are some good improvements sprinkled in Vue 3, I deeply lament now that we have literally two core competing APIs -- the classic "options" api, and the newer "composition" api.
Now when starting a new project there has to be a debate. Some people will advocate for trying the new thing, and as many others will be more conservative.
Worse, within a project there is now opportunity for competing technical approaches allover everywhere.
Yep, dam auto correct. Thanks!
The real kicker would be if they removed the options API, for small components, it's all you need and I find prototyping with it easier than the composition API. So I for one am hoping they don't drop support for it in Vue 4!
What I liked about Vue was that it was a simple view library. Yeah, there it goes.
There seems to be a hatred towards simple tools in our generation that I can't fathom
I like the idea of it but for what I work on the CSP non-compliance is a deal breaker (their CSP compatible build is not ready and you lose most of the alpine benefits).
https://alpinejs.dev/advanced/csp
I think that Stimulus JS offers many of the same benefits and provides a nice abstraction for making one 'element' contain multiple behaviours.
https://docs.servicestack.net/api-explorer
Originally we started out with VanillaJS & hand-rolled MVC pattern however the productivity slowed as the App was getting larger, switching to petite-vue was a major productivity boost giving us a productive reactive UI, ability to componentize our App into modular components & resulted in the fastest UI we've seen in a client UI.
Generation has nothing to do with it, but trends have everything to do with complexity and constant change.
Every generation has a couple of people earning their bread as enterprise architect.
My go to for that would be lit-html. It's part of googles Lit thing, but lit-html is un-ashamedly just a view library. All it does is render dynamic html on the client side in 3.2kb.
Having said that, Vue has always been a framework and that’s what I liked about it. It’s analogous to Django in so many ways.
But framework and complex are not synonymous. I like well designed frameworks that let me get shit done without getting in the way. Vue is pretty close to that. Django is very close to that. If I could have Vue 2.x supporter permanently I would be happy. It lacked native forms support but router and VueX made it nearly perfect.
In practice they absolutely are. The average project using a popular batteries-included framework uses a fraction of it's functionality. Composing smaller libraries will always result in less lines of code running in production. Usually by an order of magnitude.
And that's why frameworks exist. Because people want their overall environment to be simple (by means of having a properly integrated system) rather than individually simple tools.
This is effectively just systems theory 101. The complexity of a system is the result of the interaction of its parts, not just the sum of its parts taken in isolation.
There's no hatred here, I really think you're projecting.
I do server-rendered React with Restify in my day job, but I don’t really need the complexity of a full frontend framework for my fun projects.
Especially with the components feature offered by Laravel’s Blade it usually takes a while before I really start reaching for JS.
If I was building something where the Django Admin Panel could be a huge advantage I’d use DRF instead, but overall for most small projects I like it less than Express.
Front End bloat doesn’t really matter when you’re just trying to get a prototype done as fast as possible.
If it has to be PWA style, Angular.
I have people bothering me about when things will be done. Something not great that plays nicely is preferable to something great that requires configuration in these scenarios.
For who is looking around for a simpler but effective alternative to Vue I'd recommend Svelte:
Then Vue itself became complex.
Now people recommend Svelte as an effective alternative to Vue's complexity.
Will Svelte remain simple?
It's not hard to see this constant cycle of "simplicity -> people need more -> complexity -> let's jump ship" if you're a web developer with more than a few winters. Every time there's a new simple library around the corner that makes reality so much easier to deal with, but it's mostly just hype speak and this simplicity never lasts for long.
React has more mind-share and there are libraries for every feature imaginable, basically. But there is (or at least has been, historically) a lot of churn and fragmentation that is not suitable for all projects.
Angular and Ember sit at the other end of the spectrum – maybe you have all features nicely integrated but it can be hard to adapt such a big tool into a small, legacy, or otherwise non-standard project.
I think Vue occupies a nice middle ground here. There is a limited number of official libraries that more or less evolve together and cover most of what you need. But it's still totally feasible to just use the core runtime and call it a day if you don't need routing, state management, etc.
As much as I love working in Vue, Vuetify is the entire reason I use Vue today: if there were a Vuetify for Svelte I'd be using that instead.
All the Svelte component libraries, and indeed all component libraries I've ever tried, pale in comparison to Vuetify. With perhaps the exception of Quasar.
Using Tailwind after Vuetify feels like going from writing C# to assembly.
First vue-router and vuex were not ready when vue3 was released.
Now Evan You says in this very submission that Pinia is the new store library? I thought that it was destined to be vuex v5 or vuex v5's starting point, after the not-so-great v4. Very confusing. (I didn't even know about Pinia until last week actually, when looking about progress on vuex getters caching).
I'm not even sold on the Composition API. It makes sense when I read the doc but basically never when I'm in my actual projects.
However, I had to migrate a Vue 2 + TS app to Vue 3 and their guide at the time was pretty underwhelming. Props to Evan for dedicating time to migrate a sample app and publish the migration as commits, but the app was quite basic and dependency-free so I had to figure out a lot of stuff on the go. The compatibility build actually slowed down my progress as it took me a lot to figure out that I didn't actually benefit much from it and could just drop it. Till this day I don't have a clear idea about what @vue/compat is for.
Hopefully, with them pushing Vue 3 as the new default, there will be more detailed how-tos available.
When that was released (I’d need to check when but in 2021 or even late 2020) my React FOMO disappeared as I get full TS support in script and template tags.
Composition api + VueUse are wonderful together.
I’ve been lucky to start fresh with vue 3 mid 2020 (in beta?). But I and can understand frustration to migrate.
Having said that, I think it’s totally worth it.
That said, I don't think their documentation at the moment conveys why script setup is so useful (at the time of writing this comment). For example a lot of their examples in their documentation used their old API.
In my opinion, script setup + composition API is really nice. I haven't used React in a few years, so I'm not sure how it compares, but using Vue 3 features decreases the number of lines of code you have to write and maintain (in comparison to Vue 2), and I'm generally always for that. I would go as far and say that they would officially come out and say that the old API is deprecated.
I guess my only quandary is whether to use Vue 3 or just bite the bullet and use Svelte instead. If Vue 2 => Vue 3 is a decrease in 60% of the code, Vue 2 => Svelte seems to be a decrease of 65% ish. Is that extra 5% worth it? I don't know.
The issue was reported multiple times but it's not yet fixed: https://github.com/vuejs/vuex/issues/2102 https://github.com/vuejs/vuex/pull/1883
It was my own fault for not self hosting or not pinning the version, but it was still a surprise!
The only relevant discussion you can find regarding a privacy policy is a twitter thread that ends with the developer saying "I really should discourage adoption because it's getting too big."
No dig on them, but, really... at some point we need to start doing a better job of owning this stuff.
The issue was using an unversioned URL, which is a user error and has nothing to do with unpkg (other than allowing it)
related: The mess we're in (a talk by Joe Armstrong)
https://www.youtube.com/watch?v=lKXe3HUG2l4
(yes, I know, I should have vendored the dependency in the first place)
You don't need to. The options API still has 1st class support. The docs allow you to switch between composition API and options API.
Having said that, I still like Vue for a markup-first kinda of framework. React is code-first, markup later.
I tend to favour using React for most development scenarios, however, as most are code-first - and also because there are a dozen React candidates for every Vue candidate in my experience.
About 2 years ago our new tech lead decided that we would use Vue instead. Ever since that decision I found myself walking more and more into backend development. I just felt like all the Vue code we wrote felt like I was writing 2011 AngularJS code. Not sure what people find so compelling about it.
A month ago our tech lead decided we're going back to React for everything using Next. Everyone loves it. Everything is type safe and every variable has full type hints. Props are type hinted. It's great.
We had similar discussions in a company I worked for, but most of the senior devs decided that trying to align frameworks for the sake of everyone working in the same one didn't make sense. Given our size, there were more than enough teams working in React/Vue to keep people happy, but moving everything to one or the other felt like a colossal waste of time rewriting existing applications versus executing against our business goals.
This reads the same, you went from React -> Vue -> React in the span of 2 years? Sounds like a colossal waste of the company's resources.
For example, PHP7 added null coalescing or look at languages like Java and C# that have added lambda functions in the last few years.
They're adding things that have been proven to be useful. Well, I'm not sure in this case but that's beside the point.
1. Vue has automatic dependency detection 2. Vue’ composables can be used outside of vue component 3. Do not suffer from over rendering or stale closure
And that is just hooks. Vue also has first party router(vue router) and state management (pinia). Along with awesome devtools, which allow any vue library to hook into it.
Then there’s many well thought out and useful features like portals, suspense, (async state) transitions, error boundaries, server components that vue just does not offer.
Even after working on some rather big projects we never used composition API once. It feels more like a hindrance than an asset and greatly disrupts the simplicity of Vue, which is the most beautiful thing about it. But thanks to Evan's/team insight they've made it 100% option to use and so it didn't get in the way much.
Overall the number of improvements in v3 are amazing and the new native elements like <teleport>, fragements, etc are god-send if you ever had to struggle with them in v2. I really wish they didn't remove the event handler ($on) though. That really made life very easy and using a separate lib for that is a bit of pain imo.
That said, I understand that there were monumental under-the-hood improvements, some of which spawned off Vite.
Even if you think you're making sure to not fall into the trap, it always happens. The first version solves a specific problem and has enormous success, there might be some cleanup (v2), but then the Big Rewrite is going to clean up all the little issues and add in some highly requested features which will be so much easier because of the new architecture, programming language, etc. You estimate about six months, tops.
Then three years goes by.
I find the phenomenon amazing because I've experienced it personally and it's maddening. All the hours spent talking about the second system trap and planning how to avoid it had absolutely zero effect on it actually happening. It was like a black hole void where you just kept making one step forward and two steps back.
And we'll be free from having to learn a new JS framework every 6 months. And maybe even npm hell too.
Until then, time to buy another Pluralsign training course...
Today, it's Go in the backend and Svelte in the frontend, or vanilla JS for very small and simple tools.
Nothing like this did I ever see in the go or kotlin world.
I'm not very up-to-date with JS frameworks, so please bear with me. I know that new libraries pop up here and there, but if I'm not wrong, React is by far the most popular, and React has been around for almost 10 years. Vue's not much younger, and now it's 3rd major version.
Is there such a big difference between JS front-end frameworks and the rest of the world?
It's not that bad. I am lead on a large Angular 13 project and we love it, easy to work with, build, deploy. We have literally no issues at the moment. .Net 6 C# APIs on the back-end, Oracle database. It just works.
Take everything with a grain of salt.
Last I asked, it was still a tire fire, even after more than a dozen versions and after a fully mature previous framework that was replaced :-(
Basically, they now (as of Angular 12) force you to build a difference version of your app for each language you support, and either serve them up at different URLs or use cookies to serve up the right version to each user. The technical reasons make sense...your translations occur at build-time, rather than at run-time, but it's a pretty drastic change that occurred out of nowhere.
Not a fan.
I use ttag (https://ttag.js.org) with React and like it. I don’t see any reason you couldn’t use it (or another library) with Angular.
I just don't get the concept of people being like, I'm going to start a project that's likely going to take the ten years to become successful, but I'm not willing to spend the twenty hours to read the documentation so that it will be successful.
Eg: Google Cloud console downloads like 20MB of resources.
Maybe the DX is good, but from an end user perspective, Angular is far from good.
That must be a fairly large application. Consider they are pushing it internally, I have no idea how optimized that is.
When you consider this is cached, that means you only have to do that once until an update. Similar to any other software.
Look at what Electron apps do in terms of constant updates. This is similar, but it's a web page.
And the problem is not only the bytes loaded but how clunky and slow it is in general.
The Electron argument doesn't make any sense as it includes two runtimes ffs.
That's literally the biggest (publicly known) Angular app in existence, and the fact that it's slow doesn't have anything to do with Angular. E.g. FWD:Everyone pages load in well under half a second:
https://www.fwdeveryone.com/t/K3KKGbMyQbaCGDc-izuaow/venmo-f...
At this point the main things preventing it from being faster are the TTFB from CloudFront, and the fact that Bootstrap is used as a dependency.
Well, kinda? I tried to set up typescript, storyboard and tailwind the other day, via create-react-app - and it's not really clear if I can/should use npm or yarn, and what, if any bundles like webpack or esbuild/craco I need... Nor did any of the documentation/tutorials "just work" - and as final punishment I think I had to download more than a gig of dependencies.
I get that there are many layers of tooling, but when I can't seem to get half the features of qt, nor a gui for 4gl development - it does seem like there's a lot of churn and pain for limited gain.
Using Laravel with Breeze and the set up just works out of the box.
We're kind of into the next generation of frameworks (Solid, Svelte 3, Vue 3) and that's more about how much JS is getting delivered to the client. The current area of exploration is "partial hydration" where the goal is to write stuff using the component model but do server rendering and only send JS for the parts of the page that'll change client side. For quite a few classes of application this would substantially reduce the size of JS over the wire. All this is less of a benefit than the state control React brought so I expect slower/partial adoption.
More broadly, there's been a resurgence of the render everything on the server and send html diffs approach in the form of alpine and htmx. The other potential area for change on the horizon is web assembly getting host bindings support so it doesn't have to bridge through JS to affect the DOM and other browser APIs.
Maybe one or two years after that.
The real difficulty is that web UIs have to be very flexible and varied: you have different screen sizes, mobile vs desktop, and every website has a different UI vs native apps all looking similar. And yeah, there are over 100 different web frameworks most which have a particular use case, although you don't have to use the perfect tool for the job. Also, there are a few quirks left over from the old days of HTML/CSS/JavaScript.
But making a basic website nowadays on modern tools is very straightforward. Clone a vite starter project, write out your DOM in React or Vue or Svelte or Solid.js or whatever, and launch a live-server with a browser inspector to fine-tune the design. There are some especially bad JS frameworks (looking at you Meteor), but that's the case for most platforms.
Made me chuckle. Web frameworks are thin-to-medium layers of dealing with bs that web graphics are by nature and design. Their entire purpose orbits around that. Runtimes that do not suffer from these birth traumas don’t even need all that complexity. E.g. with apple core ui libraries you can in hours design a new flex/grid/stack/align/etc geometry container (which takes decades in the web), can animate things, make them cheap-scrollable, sizeable, constrainable out of box. Do you really think that web reflows and size dispatch up and down a hierarchy is a complex issue which only a “top-notch” web tech can solve?
Of course web traditionally was more game-like and does not have any guidelines and presentation standards beyond “reset”, allowing to focus on design better than the rest of the world (and due to widespread nature monopolized by a single platform), but calling frameworks which basically deal with its own shortcomings and ancient issues ahead of the world is pretty misleading.
What exactly is ahead of the world in there? My bet is on reactivity, components, caching and lazy redraws, which “weren’t a thing” before web, because, you know, jquery and comctl32.dll were bad.
making a basic website nowadays on modern tools is very straightforward … and launch a live-server with a browser inspector to fine-tune the design
Ah yes, something we had at VB/Delphi 3 times but not quite as RAD. I mean, maybe launch a live server, drop a query and see live data in design-mode, or enumerate columns and make some of them editable out of box? Or fill a form with master-detail link? You can’t. Web praises primitive/workaround things which nobody even had a name for before, so trivial and obvious and default it was.
Something better (and different) will come after SPAs, and the cycle will start again.
Servlets run on the server, I think you meant applets? If so, I'd argue a counter-point: WASM and <canvas>.
I actually think things are pretty great these days. Even amongst the different frameworks and tools, things are settling into a common set of ideas and concepts.
If you made the choice to build an app on React/Vue a year or two ago, that decision is still valid today and I think that speaks a lot for how far things have come.
It's obviously not a one to one replacement for an honest to god frontend application, especially one that can be recompiled into an offline capable native app, but where you can use it, it does a lot of lifting.
Also, I still believe that web-pages should be functional without JavaScript. For all of my traditional SSR / non-SPA projects I definitely put effort into ensuring my projects exhibit graceful degradation.
There's already a lot of things we can do without any scripting at all: animations and dynamic content, for example - and we can even use CSS trigger-tricks for basic interactivity (e.g. show/hide toggles) all without scripting. What I'd love to see next is something like WPF/XAML's declarative data-binding in HTML (but in a less broken way...) - and I'd like to be able to submit a <form> element directly as JSON, as well as AJAX-like <form> submissions that don't replace the current document, all without scripting - that's the dream (oh, and CSS positioning relative to an arbitrary named element, I could go on...).
I think this is actually not a tangent at all, but rather, it’s kinda the whole point! I doubt we’ll ever get to a point where there’s a single standard, because a single standard can’t satisfy everyone.
Is there really a JS script parsing all of that? Seems like there would be performance penalty.
It's your choice to learn a new JS framework every 6 months. If you don't want to use the new thing, then don't. Just make something valuable and use what suits your needs. That's all that has ever mattered.
* Styled select boxes
* Good cross platform datepicker with ranges that looks good
* More form validation options / dynamic form validation
* A good drag api that does edge detection well in every browser
* Bring back frames (would allow good nested routing)
* A built in rich text editor
* A good modal API (or bring it back)
* A way to submit a form via AJAX with just a property (think Rails UJS) to just render html.
How many end-users complained what a select box is not styled?
Now the only option is to replace them which is quite sad.
> (finally going to be a thing)
Similar to a link targetting an iframe, but without an actually ugly iframe.
I was thinking about something more like `<a href="..." target="#someDiv">`.
That could be some handy (albeit rudimentary) foundation to build maintainable sites on a static server without any JS or build pipeline.
I'm totally on board with building better tools and solutions. And with pointing out the flaws of tools as we find them. However it is folly to thing this work will ever end.
The de facto starting point for writing browser applications is React, and that came out almost nine years ago.
It’s fine to say React is a decade old but the way we write apps with React has drastically changed multiple times with the only real constant being JSX.
And let me be a bit proactive, yes, I know react is backwards compatible for the most part, but similar to PHP, just because the syntax is still supported doesn’t mean that’s the recommended way to write apps today.
React arguably started the churn of JS fatigue we all complain about now.
I don't really agree with this. Sure, we went through createClass -> class -> functions + hooks, but the core is still props, state, and lifecycle.
Take lifecycle. It used to be very explicit. Then hooks turned it into this weird implicit thing where you have to know how use effect works and how to only trigger something once, but then the empty array thing is an anti pattern etc etc. Now with suspense, that lifecycle is changing again in a way. I’ve seen some tutorials where the teacher refactors out of use effect into throwing a promise. But then you can have use effects inside your thrown promise and dealing with module scope potentially.
It’s late and im a little out of it, but to me, this is all a lot of churn and creates long periods of uncertainty as developers try and decide which of these features they want to use and when.
At a certain point it can get really frustrating when it feels like you need to rewrite your app to stay up with “best practices” and attract new talent into your org. It would be one thing if the best practices were making things better functionally, but I find that argument hard to justify for anyone outside of Facebook scale. Angular and Vue stuck with a more traditional lifecycle ideology and there are plenty of apps building at scale on those frameworks. That stability in low level APIs gives a community time to grow and mature without leaving a bunch of people behind.
I honestly believe React would not be anywhere near the scale of what is today based on merit alone. They were lucky to see the demise of angular 1 and learn from that mistake and now Vue is sorta suffering the same way by moving too far away too quickly from 2 to 3.
Anyway, ramble over! :)
That doesn’t sound right. The linter will certainly yell at you for doing that, and I’d be surprised if the program did not crash. The “rule of hooks” due to their implementation is that you can only call them from directly inside of a component function block, I.e. not from within an if block or a promise.
Developer choice is one of the things people cite as a reason not to use React already, since you have to pick a router, state management library, etc. What’s a couple more decisions about built-in features? =)
I will say that I feel the opposite way about hooks: I only became interested in using React after hooks were added, because classes in javascript always rubbed me the wrong way, and I want to get as close as possible to functional programming style from start to finish. We’re using it now, and reasoning about the app is much simpler than before. I can’t say how much is due to hooks specifically vs overall React app architecture, but the components are much more pleasing to my eyes!
You are already free from this. The only one putting that pressure on you, is you. Pick something and stick with it, and spend your time learning _how_ to build things, instead of _what_ to build it in.
My team understood the strengths and weaknesses, and we utilised almost all of the features that it provided.
The >2.x releases didn’t provide much value for us, and didn’t solve any problems that we had. So the motivation to migrate and refactor was low.
I still think Angular 1.x is a decent library, and have often contemplated contributing fixes/security to a fork.
However, if you see other posts from me, you would also notice that I am largely involved in projects that are quite strong in Java and .NET stacks with SSR.
So even Angular isn't there in every project.
On the other hand, once I started actually using it, I found myself liking <script setup> very much. I also like the "ref" thing because I have been pushing for this approach for a long time. Values are objects/proxies is a wasteful, yet powerful approach.
I am not going back to writing Vue 2 style components and encourage all of my co-workers 5o do the same. They are slowly but surely coming to accept it. No more lazy hacks for them
I know the churn in the Vue ecosystem is attracting a lot of resentment but I'm absolutely loving it. The Composition API is clean and effective and <script setup> takes it further to svelte-like succincity, Pinia builds on simple reactive state instead of the needless complexity of Vuex, Vite is fast, Volar finally brings type checking to templates and VueUse offers hooks for several little niceties that just make the experience more pleasant (https://vueuse.org/). The only thing I dislike is the macro based reactivity transform proposal which would auto add .value to special refs during the compile step, but that isn't even finalised yet and of course completely optional.
It's a great time to be a Vue dev and I hope they continue developing 3 because even if it's not the same library it was, what we have now is too good to lose and I love using it.
Then I realized the difference between the Options API and Composition API. That an pairing it with Typescript made things really unecessarily hard for learning. All the TS documentation assumed you already mastered the old and new APIs.
Really glad they have the Options/Composition toggle in their new docs now. Looks like I chose exactly the wrong time to look into it.
But people use Vue for ideological reasons. For some opinionated reason or another, they take issue with using a framework created by Facebook or they have some silly little nitpick about a particular detail of the API that they use to justify their zealotry. My company is now full of these "loud minority" ideologues that have successfully lobbied the entire engineering organization against React. The majority who preferred React were silenced, because they are not ideological about their technology choice and would rather just placate the people taking issue with it. And now we're rewriting perfectly functional software to be more "standardized" with the rest of the company in Vue. It's insanity.
There's certainly no industry standard for JS frameworks. It might be in your circle, but that's certainly not the case in the industry.
In my experience, I've found Vue to be a lot easier to learn and to teach to others. I can task a junior developer with a new feature in Vue, and generally speaking, the biggest changes are to simply break large components up into smaller ones. Meanwhile, I've inherited several React apps developed by shops that focus on React, and they all have weird race conditions due to 'hooks', and all sorts of code that breaks web standard.
I know a lot of people out there are very productive with React, but in my experience, the whole process is much more enjoyable when working with Vue. Neither Vue nor React are the only solutions out there, and it's important to not be too dogmatic about which tools people choose to work in.
Explained some of my reasoning on your other thread, and I'm sure others have a different set of reasons that are perfectly valid too.
Some people might fall into the ideological argument, but objectively Vue apps tend to be faster and smaller than React apps.
See this comparison of real world apps from 2020 which was probably using Vue 2, but Vue 3 is even more efficient:
https://medium.com/dailyjs/a-realworld-comparison-of-front-e...
Or these benchmarks:
https://krausest.github.io/js-framework-benchmark/current.ht...
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
Competition is good. At some point, someone in charge of React might do something stupid (like what happened to AngularJS) and you'll be happy there is a non bullshit alternative to keep the former dev team in check.
Last year, I participated in a hackathon and needed a GUI interface. So, I picked html, css and js. I took a look at current state of react (react is the most popular js framework). I didn’t like what I saw. There are many different ways to do same thing, the recommended way hooks, also happened to be most error prone, and hard to learn. Apparently, it also necessitates Eslint plug-in for catching common hooks error(validation of dependency array). To top it, vue/svelte do not have the entire class of issue at all.
I was somewhat familiar with vue 1, so picked vue. I needed a bit of refresh. With Vue docs, vue devtools, and some grit, I was able to get a working GUI and complete my project.
So, at least from my experience, some people use Vue for pragmatic reasons. Perhaps if you were to give others the benefit of doubt, you might find that they too are trying to be pragmatic
Here's to the next generation of frameworks, Svelte, Vue, SolidJS, or just literally returning HTML with Liveview/Turbo.
Vue botched their upgrade path to Vue 3 and now it's stuck in a similar limbo to Python 2/3. They "released" Vue 3 long ago but basically none of the ecosystem including officially supported libs like the Vue-Router/Vuex was ready and now a long time later many are still using Vue 2 because the ecosystem still hasn't caught up. The docs for Vue 3 when it was "released" were not good at all.
I used to host a Vue meetup and was originally excited for Vue 3, but most of the people I talk to who use Vue in their projects are still stuck on Vue 2 and have no plans of upgrading due to most UI libraries still not being ready.
Even though there is a core team now, it seems Evan himself has been less focused on Vue and moreso on Vite and tooling in general lately. I don't complain much because I love Vite, and no longer use Vue but I do know some Vue devs who are losing confidence.
---
I use React daily and at the very least they have rarely if ever broken backwards compatibility without being very fair on the ecosystem in terms of the time needed to upgrade, and releasing experimental versions for people to test/play with. Both are similar when it comes to dev experience, both have dev-tooling and editor integration. Though TS support for Vue was always lacking behind React. "Vetur" which is the VSCode/Editor extension to get good support for .vue files worked well enough until your project grew beyond mid to large in size at which point it slowed to a crawl for every dev on my team. Didn't have this problem with React. I think there is a new extension for Vue nowadays though.
Some of this is obvious a side-effect of there being many more devs working with React daily both in a hobby and professional capacity than Vue though.
Things are changing all the time. For example, the default state management solution just switched from Vuex to Pinia but a Vue 3 compatible version of Vuex still exist. Will it be the new default in one year? No one knows.
It's the same thing if you want to use things like SSR and not implement them yourself. You can either use Nuxt and continue to use Vue 2, or you can use the non-production-ready Nuxt 3 beta, which supports Vue 3. Both aren't great options.
Because of these issues, the strong community in the React camp really makes me consider switching to React for new projects.
FYI this part isn't true, both vue-router and vuex were updated in parallel and were ready for Vue 3's release.
For all of what facebook is worth, React has almost never broken backward compatibility, and the core idea has not changed much, while vue switched from 2 to 3 to adopt a more react like approach, go figure.
People generally understand Vue better because you can just push to an array and it reacts to it properly without having to commit to the React immutable data religion.
Basically if you were to competently build a framework you would have Vue, if you were trying to impress your colleagues and bring up bullshit comp sci principals so you can write 50x more lines of code while spending 100 hours trying to optimize a list re render, you would have React.
After using React professionally since 2015 I've come to the conclusion:
Only very few people at companies actually understand React beyond the surface layer. Everyone else just kind of gets by because on the surface it seems simple. It's actually really really hard to build performant React apps, but most developers are naive because they have $4000 mac book pros and Chrome cpu throttling isn't cutting it anymore. It's really an infection that has spread through our industry.
Vue has single file components with isolated CSS styles built in by default. I really don't like the CSS conventions in the React world. Seems everybody has settled on CSS modules, but I'd rather not have two files that represent a given component. You can of course inline styles and use alternative approaches, but none come close to ease of use and readability of Vue scoped styles, while preserving component level isolation. I know this because I've spent hours trying to replicate it in React. It's odd that mixing html components into JS via JSX (which I agree with) caught on, yet the same is often not done for CSS. Conceptually would like everything in one file, and with proper isolation (not affecting child components)
More subjectively, I feel React has a lower floor for writing poor quality/hard to reason about code.
Not a problem for personal projects, but at larger companies it's not as great. I'll have to spend some time thinking about and quantifying the specifics, but always seems to be that react projects end up being more difficult to decipher, all else equal. Not due to framework paradigms, just the collection of conventions and style that pushes you towards. One of the things is that in Vue there's a forced separation between markup and logic oriented code. This is best practice in react too, but easier to mix by mistake due to prevalence of JSX.
Also if/else statements in JSX being done via ternary reads very poorly in my opinion. I have seen third party components for this, but not sure why there's not a native implementation. Fragmenting your view code and assigning to variables/JS if else does not read well. Ordering of markup in Vue always matches ordering it will be evaluated in. Whereas in a react codebase there may be many variables or components declared within the same file and stitched together later, which requires the reader to reverse engineer what the evaluated code will look like.
React does have greater flexibility for mixing UI composition with scripting logic, which comes in handy for particularly complex use cases, but is often not needed. Of course you can use JSX with Vue as well, just not very conventional.
Finally, Vue is implementing all supporting major features from a first party perspective, whereas react projects tend to be more of a patchwork of open source components. E.g. static site generation, state management, cli, routing. I believe some packages like redux got formally adopted, but Vue is approaching from single implementation/first party first. Which leads to more consistency between projects in ecosystem.
The single-file components are really nice. You still have separation of concerns, but everything is organized in once place.
The config-style components might be something some devs don't like (boilerplate code), but I find it a lot easier to quickly scan a new component and understand what's going on. Easy to identify the component's private data, computed values, child components, etc. In React or Angular (or Vue 3's new syntax), these different types of data could be anywhere in the file.
Being able to choose TS or JS in a component file has saved me a lot of time. I can set very strict tsconfig rules for files that benefit from typing, and simply use JS when I'm prototyping a feature or I require some library that doesn't have good TS support.
And finally, the developer experience is top-notch. Excellent browser dev-tools extension, ESLint rules help avoid common problems and confusing code (and a lot of them are auto-fixable), and I've never had an easier time with hot reloading than with Vue (HMR still doesn't work out of the box in Angular 13, and apparently it was a major focus of the last release).
e.g. change the code in useMemo and forget to update the dependency, add a callback and forget useCallback results in re-render everytime. Those guarantees are opt-out instead of opt-in in vue by design.
You have to specifically call some api in vue to opt-out the guarantees if you really want to optimize it yourself. In other word, you are not going to get blazingly fast performance by default if you actually do nothing and use it like html, but you also won't get shit like performance if you use it like that. (Generally you get a decent performance that you won't want to open devtool to check "what the hell framework is this site use?", you are probably not even going to realize the site is using vue)
It is really clear that the changes in Vue 3 where implemented in a way where it is simply too much of a hassle to migrate for too many people - most of the ecosystem still does not work with Vue 3.
A new version breaking old code can be bulldozered into the world only by real godzilla projects like Python - and even there it triggers years of discussion and upgrade-resistence and lots of dead projects.
As a programmer of a small JS library you can learn from the fail of Evan: breaking backward compatiility is breaking your ecosystem - the most important resource you have. Disrespecting this resource will kill you.
The Vue project nowadays can be seen as dead - many projects got that "Angular-Burn" and will never upgrade, but switch to something else.
People still hanging on are the slow crowd that get things too late - we have many of these, but there is no creativity in these people, nothing to expect, just copypasta followers.
Hopefully other projects finally learn from this sad example.
Please do not break your ecosystem. Thanks.
Even if you don't like the exact setup , you can customize it to your liking (and there are a number of forks that do exactly that), but it puts together quite a few things that you often want as an "out of the box" experience.
All in all both frameworks aren't too great at sprinkling dynamic functionality on server-side rendered HTML.
Why do you think they are not great at this?
Vue-Petite is definitely interesting and I likely will use it in the future, but talking strictly about Vue 3 and React - they are more suitable to SPAs than to progressively enhance your HTML.
I am curious if anyone has as used the TypeScript class syntax with the decorators. Last time I tried to migrate it, there were a bunch of things that failed. Presently it looks like one other dependency I need hasn't been migrated to Vue 3, either.
just when you think you've learnt something, the rug gets pulled out from under you.