I like Vue a lot. It has a terrific documentation, good official—but mostly optional—tooling (Volar, Router, Pinia, Vite), built-in component-scoped styling, fine-grained updates (like signals, but already before it was cool), generates small bundles, their TypeScript support is great, their IDE support is great, single-file components are a blast to work with, and much more. What I also like is that their decisions are not rushed. They observe other frameworks and copy the best ideas from them but address the learnings and add even better versions of these features into Vue. They are rarely the first, but often (imho) the best.
This is an amazing project, it tells yet another story how one guy can start a project ended up challenging big companies like Google(Angular) and Meta(React).
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.
Svelte is not SSR first. Svelte has nothing to do with the server. There is no server related code in Svelte. Svelte is a UI library/framework/language w.e you want to call it.
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.
From what I recall, most of the early development was funded due to Patreon, and if you looked at the list of donors, something like 75% of the money came from a few large companies.
I've been in FAANG for a couple of years now and stuck in React world unfortunately. Prior to that I had to use Angular, which imo was even worse. I've had a couple of short opportunities to use Vue professionally in an enterprise application though and damn I loved every second of it. Vue is still my favorite by far. It's just so elegant with its simplicity, it allows me to actually focus on the app and not any bullshit cognitive overhead dealing with state or weird incoherent syntax (looking at you, Angular). I wish there was a larger adoption of Vue.
I really enjoyed vue for a large project back in the day. I seemed to have loved everything that everyone else here disliked... which is sometimes par for the course on HN.
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.
I think it's a shame the reactivity/signals system from Vue 3 wasn't broken out as a separate project under a different name. They had so much success with building Vite as a separate project, and the reactivity system they built for Vue 3 is so good it warrants the same attention.
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.
I agree and that's one reason I've stuck with MobX. Works with React, Vue, Solid, and even mixed solutions. Heck, I've bridged it with backbone codebases..
I dislike react and liked vue. However I’m on the svelte bandwagon now, which is similar to vue but improved. Basically sveltekit makes a lot of opinionated decisions for you but those are all good places to have opinions.
What i liked in things like vue, is that they get you to prototype things quickly with a thin layer of conventions that guide you softly and avoid creating a mess. Even if I stopped using vue (went to backend) I still appreciated the voyage / lesson.
+1 to Svelte. I used to work in Vue a lot but something about Svelte clicked so much better for me. It's so good that when new fancy reactive frameworks come around I don't even bother to get distracted - not even for a week (LOL) ;)
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 I love about Vue/Nuxt devs are not only the powerful tooling they create, but the way they build it so any framework can utilise it. Biggest examples are Vite, Unjs, Nitro. Plus I love the way they think about providing so much flexibility with deployments. Want to deploy your SSR Nuxt app to Cloudflare workers? It’s a 1 line config change in the Nitro config
I still don't understand why they had to introduce a proprietary file format. It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format. Unfortunately, developing those takes time – apparently more than 10 years: To this day (I set up a new Vue project just a few days ago) there are countless bugs in vue-tsc and Volar.
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!
> It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format.
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.
> What's worse, type checking was largely an afterthought in the development of Vue
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.
Couldn't agree more. We've been having good luck working with TSX-templated Vue components (using "render functions"[1]) after getting fed up with gaps in VTI back in the day – most of https://radiopaper.com is built in this way and we're closing in on it all being so. We haven't run into any issues with Vue's (alleged) lack of ability to optimize TSX templates in certain ways as opposed to traditional Vue templates – maybe comes down to the nature of our use cases – but our view is that this trades off against many other benefits:
- 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.
Does anyone know of a good open source syntax highlighting library for Vue SFC? That’s my biggest issue with the file format (I maintain a code review tool)
We have a large legacy PHP code base originally using "xajax" in many places for asynchronous parts of the UI. We've pretty much got somewhat of our own "framework" and any sort of re-write is absolutely out of the question. We have been slowing replacing xajax with VueJS via a script tag and it's been working great for us as a modern / supported alternative to xajax . There are certain VueJS niceties we can't take advantage of because of the script tag approach, but that hasn't been a big deal.
Similar story here, we have a fairly large code base which has been continually evolved since year ~2000, with our own legacy "framework" for much of the server-side structure. Back then the forms used to reload the whole page, keeping user input and adding error messages (fun times!), then some kind of AJAX was added, where the server would send actual JS back to the client for execution. Some older pages still use jQuery.
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.
I started using VueJS when I got thrown off the deprecation treadmill by Angular.
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.
As someone who started using Vue before 1.0, I find that characterization unfair. The overall API didn't change much from 1 to 2.
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 around for the first Angular deprecation treadmill, and it was jarring.
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.
We have a 100kloc codebase and migrated 2->3 + replaced our whole build stack (webpack -> vite) with a few dev days of effort (mostly on SSR stuff). It hasn't (at least not negatively) our general velocity at all.
A totally different thing than moving from Angular 1 -> 2 for example.
We transitioned from Vue v0.14 to v2 to v3 without all that much code churn. Most of the work was a couple third-party components that got abandoned in the 2 —> 3 switch.
A couple major version upgrades in a decade seems reasonable.
"Version 3 within 10 years" is, in this industry, glacial pace.
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.
It got so much right from the start, looking at Angular 2 just made me throw up my hands.
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.
uallo|2 years ago
Thanks to all contributors and happy birthday!
synergy20|2 years ago
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.
gherkinnn|2 years ago
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.
impulser_|2 years ago
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.
todd3834|2 years ago
bdcravens|2 years ago
y-c-o-m-b|2 years ago
code_runner|2 years ago
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.
samwillis|2 years ago
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...
Rapzid|2 years ago
monero-xmr|2 years ago
agumonkey|2 years ago
nlh|2 years ago
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.
notso411|2 years ago
[deleted]
timetraveller26|2 years ago
alexcroox|2 years ago
codethief|2 years ago
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!
uallo|2 years ago
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.
Hawxy|2 years ago
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.
evnp|2 years ago
- 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.
[1] https://vuejs.org/guide/extras/render-function.html
troupo|2 years ago
In most (all?) IDEs you can also tell the IDE to treat the file with a certain extension as written in any language
habosa|2 years ago
gilfoy|2 years ago
I switch between Python and TS regularly at work, Python type system is honestly kind of shite compared to TS.
bcaxis|2 years ago
jthemenace|2 years ago
downsplat|2 years ago
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.
tgsovlerkhgsel|2 years ago
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.
MatekCopatek|2 years ago
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.
PaulRobinson|2 years ago
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.
cjblomqvist|2 years ago
A totally different thing than moving from Angular 1 -> 2 for example.
ceejayoz|2 years ago
A couple major version upgrades in a decade seems reasonable.
DanHulton|2 years ago
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.
demondemidi|2 years ago
whimsicalism|2 years ago
huqedato|2 years ago
I switched to Svelte and more recently to Solid.
rpmisms|2 years ago
coding123|2 years ago
whizzter|2 years ago
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.
huskyr|2 years ago