Plan to migrate to Vue 3 for the nice to haves and to keep up to date, but Vue 2 is not painful at all.
Considered React but I think Vue will be more productive for the team as a whole in the long term. Vue is more intuitive, better designed, and structured. But totally understand React has a larger ecosystem - we’ll just be building more stuff in house so understanding our own code will be more important than having a larger choice of dependencies.
Did take a look at Svelte, agree with you.
> After using Vue 2 as our front-end framework for almost two years, it was announced that this support would no longer be maintained,
Eg. some teams don't want their development to happen on a framework with no support from the devs that wrote it.
- Very poor typescript support.
- Poor performance (compared to Vue 3).
- Ecosystem has already started lagging behind (e.g. Vue Testing Library for v2 has out of date dependencies, and no one is actively maintaining it)
- Nuxt 2 hasn't made any releases in ages.
If you use class components and prop decorators, the TS support is actually pretty nice. Kinda boilerplate heavy, but nice.
In comparison JSX will be checked by typescript, so in that regard JSX (and therefore React) is superior.
FWIW, Nuxt 3 was released in November. https://nuxt.com/v3
Personally, I rather enjoy the <script setup> syntax in Vue 3 which makes using the Composition API more pleasant and makes it feel more like React, instead of something more boilerplate heavy: https://vuejs.org/api/sfc-script-setup.html
Of course, Composition API itself is also available in Vue 2 (at least the newer versions) as a plugin, but personally I didn't see anyone using it in the older version. Either way, it can make code easier to write!
Furthermore, starting out new projects, regardless of which version you use, Pinia is a great option, which you won't see in many of the older Vue 2 projects (but could use if you started a new one with Vue 2, although that's not a good option because of EOL): https://pinia.vuejs.org/
Aside from that, Vue 3 still lacks some component library support in some cases, last I checked so perhaps that's an argument in Vue 2's favor (until everything is updated): https://news.ycombinator.com/item?id=32916677
React feels good in some cases, for example thanks to new solutions like https://react-query-v3.tanstack.com/ but at the same time seems to be getting more overcomplicated as time goes on (Vue feels like it does hooks in a more clean way, you don't need to deal with the complexity of Redux either).
The last React + TypeScript codebase that I looked at felt like it's just going to slow down anyone who works with it, which seemed to be true, judging on how fast people iterated with it vs a Vue project. Note: that's an anecdote.
Then again, the only good front end technology with TypeScript that I've used was Angular, even though it crumbled under its weight otherwise sometimes (once again, in regards to iteration speed in particular).
I agree that that combination it is very ceremonial.
We now doing new projects in Elm as the JS/TS ecosystem simply does not cut it for me.
I think others have offered sufficient/agreeable takes on this, but as the OP, I'll firstly point the pain finger at our own development and blame far too much state/ui/biz logic existing in the web in very tangled and inappropriate ways (part of the nightmare I inherited). Beyond that, the actual vue2-related pain points are typically ecosystem-related support (packages, etc.), and specifically being able to adapt to typescript (this project was initially done in early vue 2.x with just javascript, and attempting to reimplement in typescript to address some of our pain was not fun)
Reading your post it doesn't sound like you're fully onboard with that jump anyway? (Maybe I'm reading too far with this though).
There's still a new JS framework everyday but if you ignore all that noise and for production-quality software just have a look at React and the most popular meta framework on it, Next.js, you'll be more than alright.
Don't be like me, choosing to build an entire app on Next.js and hating every moment of it after the honeymoon period ended 2 weeks in. Live and learn.
My Next honeymoon has been going on for a couple years now, and I think it's an AMAZING developer experience compared to anything I've worked with before (Perl/PHP/Laravel/Symfony/Angular/jQuery/React)... it's the framework that made me choose to specialize in frontend because it was so nice. What didn't work for you?
I don't blame you, heh. Every year I feel like the fragmentation is getting worse, not better. It's fun for a while, but makes it really hard to plan for long-term stability and maintainability. It's likely anything I write today will be unusable in 2 years.
However, I would strongly disagree with you on the part about it not being suitable for complex applications.
If you feel that way, you can choose to have a decoupled backend (which is what I do with Django) or go all in with full-stack integrations (tRPC in conjunction with edge functions) on top of Next.js.
I have seen great apps built with both of those ideologies.
I have no opinions about any of these libraries and frameworks for business applications.
Overall though regular .ts code works well. We use it for all our API definitions and networking layer, and it’s been 1000x better than our former version built with jinja/jQuery.
Announcement (some things have changed, surely): https://svelte.dev/blog/svelte-and-typescript
More info in the GitHub repo I linked to elsewhere.
I use it for my production app, so I'm a big supporter, but I don't think this is true. It's an extremely light framework that doesn't offer anywhere close to the feature support of Django or Rails, and as far as I'm aware it doesn't have any intention of doing so. Perhaps I'm mistaken?
I'll guess Vuex -> Pinia is more work.
Omg, doing (because I need to) C or C++ stuff, where you have (or lets say you are bound to for several reasons, compatibility, regulations,..) C++11.. or even C99 .. man I feel so old and slow as I potentially am, lol.
Trust me, the grass ain't greener on the other side.
BTW just a snarky aside, but I've never seen any of the Javascript frameworks make as bad design decisions as the C++11/C++14 standards committees have. At least when you use a one-day-fly JS framework you'll use something that was actually designed with a grain of intelligence.
Vue 3 was a big shift, like react hooks. It will take some time for community to stop whining about it, and accept old version is legacy like react classes
The fact that they used a popularity contest as justification is laughable: if you have more than 3 years in the field you have experienced the pattern that the new kid on the block, often untested and with smaller mind share, jumps to the top of any "which framework would you like to try next?" surveys, while the tried and tested one move towards the bottom.
https://emtemp.gcom.cloud/ngw/globalassets/en/research/image...
No stable and productive framework will ever be able to compete in hype and good PR than alpha-quality software.
Huh? Stable and productive tools will let developers ship features while hyped frameworks come and go. Whatever survives and is in good shape after multiple hype cycles is surely a winner.
The alpha-quality software is all new shininess, sometimes with explicit promises of solving the warts of [STABLE FRAMEWORK]. Plus everybody seems to think that new shininess looks better on a resume.
"There are only two kinds of languages^Hframeworks: the ones people complain about and the ones nobody uses."
Sure if you were on PHP, a rewrite to a JS framework would be worth it, because you could deliver features to your customers faster, less bugs, etc. But once you're in the JS ecosystem, it gets much harder to justify a lateral migration like that. Like what features have they actually picked up as a result of the migration? Or are they just doing it so they can work on flashy new framework? I'm going to guess the latter.
That sounds just as much like a cargo cult thing and not actually making sense.
I enjoy Vue 3 and I don't enjoy React, but like you this is the reason I keep heading back to React.
From tldraw [1] to react-flow [2] to the superb AtlasKit [3] to form builders & validators, the React ecosystem contains great stuff that isn't available off-the-shelf for other frameworks.
3. https://atlaskit.atlassian.com/ (seriously, table handling in the RTE is excellent)
It's a little risky, but not particularly so.
But I agree that vue3 is usually a much better migration path from vue2. Also, it seems outright bonkers to me to give major weight to the "State of JS" survey, and doubly so since the delta is small.
2) we REALLY need a sort of "reference implementation" website that does the typical things a website needs to provide comparisons of approaches (hm, and performance benchmarks) to things like templating / html generation / data binding / etc.
Just a note: Svelte is 6 years old, only 2 years younger than Vue. Both are definitely "old" on JS-framework timescales.
This is an overstatement. Use what you want and what works for you, but we've been using Svelte in production for years and overall are extremely happy with it.
I agree with this point. I also think that in terms of svelte-kit, the use-cases are pretty specific. I originally built https://neovimcraft.com using svelte-kit in an effort to learn the framework and see how useful it is.
I eventually ripped it out because all I needed was a static site generator and the framework felt like overkill and in some cases too magical:
The framework is so new, trying to justify your decision based on State of JS surveys over the last three years is asinine at best - svelte's own UI framework[1] is not even at 1.0 (has only recently been renamed to sveltekit).
Furthermore, there's a literal migration guide[2] to bring your app from vue 2 to 3. It's not easy. It's not painless. But being on vue 2 is equally painful. I'm also not sure what documentation or development this person is referring to because "restricted global access" is just patently false for both vue 2 and 3 - I don't even know what to cite here because it boggles my mind so thoroughly that I can't even conceive where you would come up with that "fact." Is this someone who's never opened their root app file? The place where one can pipe anything from decorators (and yes, enums???) to entire packages globally?
[1] https://kit.svelte.dev [2] https://v3-migration.vuejs.org/