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.
You haven’t described anything different from what the OP is saying: the main dev behind svelte now works for a company that wants you to use SSR for all your projects. That absolutely impacts feature development to favor sveltekit. The same thing is happening with react.
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.
Svelte has no routing for client-rendering, and itself recommends everyone to just use SvelteKit as boilerplate, which is SSR-first.
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.
We use SvelteKit for a internal application that we embed into a Go binary. It as simple as adding adapter-static as the adapter and not using .server files.
You can use SvelteKit the exact same way as the API for server and client are nearly the same. Load function on the server work the same as the Load function on the client expect for where they are called.
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.
Sure but that is as helpful as saying a Word document (.docx) is a valid ZIP file. The tags in Vue files are merely containers of the actually interesting stuff.
What matters for most (all?) tools is that the file is a valid HTML syntax. Most (all?) tools don’t care if the document it self is valid HTML. I don’t think I’ve used a single developer tool which stops working if I remove the <title> tag, nest <a> elements or even insert a self closing <div /> tag.
Vue uses @:[]. in their attributes and these are valid HTML attribute syntax. HTML attribute syntax only disallows SPACE"'>/= and some specific code points. Everything else is valid syntax.
> 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.
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.
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.
Hi Evan! That sounds really interesting! Would you have a short code example for me, demonstrating what your typical Vue component looks like? Is it similar to the examples at the end of https://vuejs.org/guide/extras/render-function.html ?
I'd also be interested in how you write (S)CSS for your components – do you use some form of CSS-in-JS?
CSS-in-JS has been a challenge – we're currently using https://github.com/astroturfcss/astroturf which seemed the simplest zero-runtime-cost option back when we were looking, but the library is starting to feel a bit under-maintained (if the author of Astroturf reads this, we love your work and will do whatever we can to support you in it!). But it's worked well for us over the last 2 years.
Happy to share a component example. We also use a small library for managing CSS classes in a typed fashion, which can also be used by our UI test code to target various elements. So that does add a bit of cryptic boilerplate, but the repo README has an example component with syntax highlighting:
https://github.com/evnp/namespace.style#usage
You still need a full JS(x) parser (and lexer) though since / symbols are contextual (as are < in JSX).
/ and < in operator positions becomes operators, whilst / in plain JS in a value position becomes the start of an reg-exp and < becomes the start of an JSX tag, so to handle it there needs to be a full parser (with a pull-lexer to correctly handle the contextual part) as you cannot just do a textual replacement due to ambiguity.
Typescript supports JSX out of the box. It was once true you need custom tools for React, but JSX has proven useful enough that support is provided almost anywhere you need it. Also, as someone else mentioned, JSX is really just syntactic sugar around vanilla JS, so supporting it is much easier.
You don't, because JSX is not required for react. This isn't even just a theoretical point, but something I've actually done in the past several times; it's very convenient to just try something out by throwing react into a script tag and then just writing a small prototype or something without utilizing JSX and thus avoiding the need to set up a build system and everything else. I would still use JSX for larger projects, of course, but it is mostly just a small quality-of-life improvement, and I'd be using react even if JSX didn't exist, as the actually important parts of the library are not about JSX.
> You don't, because JSX is not required for react.
And what does this have to do with the fact that the absolute vast majority of react code is written with JSX and that you need special tools in IDEs to deal with React code (because regular JS tools would break)?
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)
I moved away from JetBrains to VSCode a while ago because of bugs related to Vue. Now, a week ago, I moved back to JetBrains because of a bug in Volar. Sigh.
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.
They did drop class components though which I had heavily used for both professional and personal projects. I still haven’t gone through the process of upgrading one of those but I’ve written a new project in vue 3 with the composition API and I like it overall I just hate that I have to switch from class components
I fell for a feint though. Reading their docs it seemed like they were going to go in the direction of class components with attributes (class decorators). So we built our app for that, thinking we'd be future proof, but alas the community went 180 degrees the other way, and our Vue 2 app became super hard to upgrade to Vue 3.
Without more context can't comment on your upgrade process. But as others stated above, there's not much difference betweeb 2 and 3, except you do not get composition api on a v2 project, while you can use composables but can't go full composition api and have to stick to options api. Other than that most of v2 code would work on v3.
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.
I'm genuinely curious - what features does jQuery have that make it better than modern vanilla JS? Back in the day the vanilla DOM APIs were bad, so jQuery was great, but I haven't felt the need to reach for it in ages.
jQuery is designed not to fail. So if there's no `.box` on the page, jQuery will not do anything.
`querySelector` may return null, so `$('.box').hidden` will hard break your page if you're not careful enough
2. `$('.box').hide()` is just one such example.
The hilarious https://youmightnotneedjquery.com/ shows that jQuery remains more consistent, concise, and composable than most things in modern browser APIs
Also, do you know if there is a jQuery-like that actually throws exceptions? Having `$('.box').hide()` tell me there is no `.box` would be pretty useful.
I would look around more. You might like one of the small reactive frameworks if you find the large ecosystem of React and Vue off-putting. My last jQuery app was several years ago, when I realized I was just maintaining a slower reimplementation of a reactive framework. These are mature technologies now that quickly save time and prevent headaches down the road. jQuery's best lessons have been absorbed into both the reactive frameworks and native JS and you can alias the handful of selectors you're used to.
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.
Vue with Vite (the builder/runner) is a stable, open source option. It is really a lightweight start where you're mostly writing HTML with interpolated data, and Vue is updating values correctly and performantly. Just build your reactive HTML app in one file and break into separate components as you're feeling the spirit. https://vuejs.org/guide/quick-start
Mithril if you just want to drop in want a tiny, complete reactive library that doesn't require a build step--this one is most like what you might end up creating in a large jQuery app. You can understand everything from the homepage. https://mithril.js.org/
HTMX if you really like HTML conventions. This doesn't feel jQuery-like and depends on your approach to your server app. https://htmx.org/
If you were to pick just one, I think Vue would be the most rewarding.
It certainly does but only for very flat designs. I was in jQuery camp for a solid 15 years (2000~2015) but once you get a taste of reactive design, it physically hurts to go back to jQuery. For me, that is.
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.
Was an Angular 1 -> 2 even possible? If I remember correctly, they were one of the first big open source projects to go all in on Typescript and even the fundamental way that the rerender and state changes were tracked were completely different. I worked on an app on AngularJS and when asked for an assessment on a migration, it felt clear to me that it would require a complete rewrite. Even the tooling was totally different
That opening is what react used to become what it is today. With the 1 -> 2 no upgrade path it forced a rewrite and many left to react and never came back.
We're about to need to do the same thing with similarly sized codebase. Would love to hear your story. Did you find any migration tooling to help? Would be happy to DM to chat as well.
One of our issues is that we've used some component frameworks that also need to be migrated.
I did it to a similarly sized codebase too. Vue itself was painless.
I also migrated our component framework, from Buefy to Oruga. Some string replacement to change component prefixes, then Typescript to help catch incorrect properties. I might have fixed several bugs in the process thanks to Typescript working better with Oruga. The only real tricky part was converting customized CSS, which was A LOT in our case, but Oruga provides a better way of overriding CSS, so it was worth the time.
Took about 2 days of me doing pure coding with a blocked calendar, plus a third day for testing and code reviews by the rest of the team.
With the caveat that I don't do software engineering professionally, I recently migrated a personal Vue 1/JavaScript project to Vue 3/TypeScript, and it was mostly painless. There's a migration guide¹, and Phind and Copilot were helpful.
Basically, see other comments. We simply followed the migration guide. Very painless. We use few external libs, så that helped a lot. You can find me on LinkedIn with the same username as here for DM.
Going through the same migration from nuxt 2 to nuxt 3. Can you share more details? Did you also move from vuex to pinia ? If so, how did you manage the API change (dispatch, commit) scattered through the codebase. I'd love to learn more
I’d love to hear if anyone has done this migrating from vue 2 with class components. There doesn’t seem to be as nice of an upgrade path from what I can tell.
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.
Thanks to all contributors and happy birthday!