Thanks to all contributors and happy birthday!
While React is adding all those complexity by SSR and server component etc these days, Vuejs separates them wisely, if you need just the original SPA, use vuejs as-is, if you want SSR, add Nuxt.
I am moving back from React to Vuejs after realizing how heavily React is nowadays affected by VC company Vercel, which has its own agenda of SSR-first(Next.js) and make React even further complicated, Vercel hijacked React in my opinion and made it no longer a "neutral" OSS project, so long, thanks for all the fish.
On the same note, Vercel also bought up Svelte and made it SSR first.
If you just need SPA and has no need for SSR, which made frontend even more complex, go with Vuejs.
Vercel pushing Next's terrible app router has a VC stink to it. That's the only way I can explain their downright awful solutions.
SvelteKit can be bundled with server code, but it's just as easy to bundle it without any server code. SvelteKit is essentially just a Vite plugin.
You can add adapter-static and have to bundled as an SPA and not change anything with you code as long as your not using .server.js files which are files meant to protect server code from not being bundled with the client.
The same thing is happening with deno as well: most active dev is with deno deploy.
VC has infiltrated open source development and is driving how features are built. Not saying it’s necessarily bad but it does change the incentive structure.
I spent two months with SvelteKit for a SPA project,it did not fly, the SSR-first (e.g. documentation etc) made CSR-SPA a second class citizen plus added unnecessary burden for those who does not need SSR, no it's not as easy as just "setting this flag you will be golden for CSR".
If I need SSR sometime, I might as well just do Django, Rails, Laravel etc which are solid. Please give me a true SPA as it used to be, and make SSR optional instead of the default.
My project pre-dated the composition API and some other bells and whistles that I've never looked into since leaving FE projects... but IMO, a really good framework with a good community and lots of resources to learn.
It can, and is, used outside of Vue, see Alpine.js, but it's adoption would be so much greater if it was packaged under its own name.
There is this project that even combines it with react: https://github.com/antfu/reactivue.
I wish we had slightly looser compiling between templating and reactivity systems...
I'm curious to see how Svelte v5 takes hold. I get the motivation behind why it's been created, but it does dramatically change the syntax to make things feel less "Svelty".
It's an interesting side-effect of a maturing project. A lot of the things that make Svelte <=4 enjoyable is how approachable and logical it is. I understand how more complex projects need more ability to split up large components, etc., so Svelte 5 logically makes sense, but it loses some of the charm and simplicity of the original.
What's worse, type checking was largely an afterthought in the development of Vue. Can we, as an industry, please finally agree that languages & frameworks with proper (tools for) static type checking are infinitely better than those without, instead of having to painfully re-learn that lesson time and again? Heck, even Python devs are using type hints these days!
React has (but does not require) JSX. It introduced a new file format: jsx or tsx. JSX is not valid JavaScript syntax. Hence, tooling needs explicit support for JSX. For an editor/IDE, that means it needs to add a relatively easy new syntax and a couple of custom React attributes. Obviously, there is a little more to add React support to an IDE, but this is the very first step.
Vue has (but does not require) single-file components. It introduced a new file format: vue. Vue files are already valid HTML syntax. For an editor/IDE, that means it does not need new syntax but only a couple of custom Vue attributes. Obviously, there is a little more to add Vue support to an IDE, but this is the very first step.
PS: Vue 3 has great TypeScript support.
I'm not sure what you mean. For Vue 3 it was a priority and extensive work went into exposing types that would make it easier for IDE tooling to integrate. Features like the `defineProps` macro are specifically designed to make TS development easier.
> For Vue 3 it was a priority
Right, for version 3. And type checking & IDE support still don't work glitch-free.
> Features like the `defineProps` macro are specifically designed to make TS development easier.
As you say, in more recent Vue versions, defineProps is a compiler macro, no longer something you `import […] from 'vue'`. So IDE developers had to put in effort to support it.
- File extensions are all .tsx, and thus work with bog-standard editor tooling and syntax highlighting
- We're more confident about typechecking in templates, because template code is 1 minor transformation away from raw typescript, and basic `tsc` has understood TSX well for years now. Up and down the component stack, it feels like we understand typings better without "gaps" at each template layer.
- Scoping of values in templates is easier to understand. Everything you write is what it says it is, it's just whatever's in the same scope as the template. There are no transformations, no omissions of various words, no magic.
- It's easier to compose templates from small easy-to-understand parts in the same file, without fragmenting code across many small components. Not everything needs to live in a `<template>` tag separate from your `<script>` tag.
- When React folks have joined the team they've had no problem ramping up.
- By the way, in Vue TSX you just say "class" not "className" which is refreshing.
Feel free to email me at evan at radiopaper dot com if any of this interests you – we're currently working on expanding the team and looking for like-minded people interested in contributing.
I'd also be interested in how you write (S)CSS for your components – do you use some form of CSS-in-JS?
In most (all?) IDEs you can also tell the IDE to treat the file with a certain extension as written in any language
I switch between Python and TS regularly at work, Python type system is honestly kind of shite compared to TS.
A couple of years ago we needed to choose a way forward for new front-end dev, and we chose Vue just as Vue 3 was maturing. I didn't know much about reactive frameworks back then, so it was a bit of a hunch, but I'm very happy with how Vue3 has worked so far.
We did however do the effort of adding a build step. The site is basically multi-page, with small SPAs sitting at their own URLs for individual jobs. So we wrote a Rollup config to bundle each of the mini-SPAs into its own file, and modified the framework to add a way to configure "this page wants Vue3 and this is the path to its bundled JS". We load the main Vue script as a <script> tag of its own, instead of adding it to all the bundles, for better caching. But as far as I can tell, in this way we can use all the Vue3 niceties, including Single-File Components.
Regardless of whether something is a hobby project that you want to only touch a couple times a year or a big project with dozens of developers, having your platform deprecated under your feet and being forced to do migration work sucks.
Vue is now on version 3 within 10 years. That means anyone who relied on v1 has had their work churned away under their feet, twice.
3 was initially going to be a big change, but after a lot of community resistance, they decided to make the reworked API entirely optional so people wouldn't be forced to make changes. AFAIK this is still the case and the classic variant (Options API) is still fully supported.
I was thinking about doing some stuff for a hobby project recently and as a mostly back-end engineer, I am very out of date for most front-end code. I did a scout around, and didn't feel too impressed.
Finally last week I was thinking "I wonder what happened to jQuery", and there it was. Just as it ever was. Updated, freshened up, but completely recognisable and completely usable.
Is it new and shiny and full of awesome features? No. Do I understand it? Yes. Are there plugins for most things I need? Sure.
I feel old, but I'd rather make progress with something unfashionable than have to deal with deprecation and learning curves with something fashionable.
For development, browsers and version managers/containers are stable enough that you won't be on a deprecation treadmill. Any pressure would come from including other people on the project, which you'd get even more of with jQuery.
I appreciate the 'do what works' mindset quite a bit but I hope you'll give a modern reactive framework or library a try; I'm glad I made the change.
A totally different thing than moving from Angular 1 -> 2 for example.
One of our issues is that we've used some component frameworks that also need to be migrated.
A couple major version upgrades in a decade seems reasonable.
And also, the work required to do those upgrades has always been relatively minimal, with a backwards path for stuff you're not ready to convert yet, but real tangible benefits for the stuff you are. I still have a few projects that are a mix of Vue 2/3 - new stuff written in 3 because it's nicer, older components not rewritten yet because they haven't needed to be touched and just still work.
I switched to Svelte and more recently to Solid.
But saying "just" is unfair to Vue, it's a big upgrade thanks to the internal mechanics as it solved a lot of brittle and error prone ceremony associated with writing Angular that just went away with the same elegant style of templating.
