VueJS turns 10 years old
twitter.com
twitter.com
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.
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.
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.
What problems did you have?
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.
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!
In most (all?) IDEs you can also tell the IDE to treat the file with a certain extension as written in any language
/ 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.
You can use .vue files, use JSX or write the h-function invocations by hand. Except for SFC-support, this also works without a build step: https://vuejs.org/guide/quick-start.html#using-vue-from-cdn
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)?
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.
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 switch between Python and TS regularly at work, Python type system is honestly kind of shite compared to TS.
- 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?
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
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.
A couple major version upgrades in a decade seems reasonable.
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.
Hide Show
```
$(".box").hide();
$(".box").show();
vs
document.querySelector(".box").style.display = "none";
document.querySelector(".box").style.display = "block";
``` Both work. The first is more clear
const $ = document.querySelector.bind(document);
$('.box').hidden = true;
$('.box').hidden = false;
```
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.
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.
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.
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.
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.
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.
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.
Like others have mentioned, the biggest fear was other libs we used. We are quite conservative with that though, so want a big deal.
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.