Migrating from Vue 2 to Svelte
escape.tech
escape.tech
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/
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.
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.
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."
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.
- 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.
FWIW, Nuxt 3 was released in November. https://nuxt.com/v3
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.
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.
> 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.
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)
I have no opinions about any of these libraries and frameworks for business applications.
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?
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.
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.
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.
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.
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 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)
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.
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
Trust me, the grass ain't greener on the other side.
Just a note: Svelte is 6 years old, only 2 years younger than Vue. Both are definitely "old" on JS-framework timescales.
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.
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:
I'll guess Vuex -> Pinia is more work.
In my case the big motivator was that with Vue, whenever I worked on my UI code I found I spent most of my time thinking about Vue and not about the UI. I think the key issue was that Vue seems to offer several different abstractions for each of the things it does, so there's generally lots of different ways you could architect any one thing - e.g. how to make a piece of state inside one component accessible from another. Then when I saw Vue3 was adding a new, apparently separate way of doing things (the composition API), but also not deprecating any current abstractions, that was what specifically made me start looking for alternatives.
In contrast I've found svelte less mature (and I've had to work around some bugs), but it's been infinitely easier to work with. Svelte basically just has One Magical Thing, and otherwise everything is plain JS (or at least looks like plain JS). So there's nothing to re-learn when I come back to the UI after not touching it for a month, and I don't really find myself thinking about any svelte-specific details when deciding how to architect each component or piece of state.
I'm only using a small subset of each library (e.g. I don't use routing or SSR), so YMMV. But so far I'm really happy I switched, and my UI code has gotten smaller and cleaner.
> e.g. how to make a piece of state inside one component accessible from another.
That is logically the same with every component framework, there is only one correct way to design it, flowing inside data are props, outgoing data are events. Was always the same.
> Then when I saw Vue3 was adding a new, apparently separate way of
> doing things (the composition API), but also not deprecating any
> current abstractions, that was what specifically made me start
> looking for alternatives.
How does this makes any sense? There is no need to deprecate the component declaration cause of the way it works. Instead of exporting a native JS Object you just use defineComponent({...}) to get type annotations, that it.
Re global enums - I'm not sure what the author means about global enums - anything imported into your Vue file can be used in the `<template>`.
Re styles - Style is automatically scoped in Vue SFC files, too - I believe it was the first component framework to do this.
This article and migration seems not very thoroughly researched - seems the author just wants a reason to rewrite the front-end.
<style> is global, <style scoped> is scoped. But comparing frameworks based on having to write at most one extra scoped property in each file, or having to wrap HTML template in a <template> is laughable. You get a hundred times the time back the first time you need a library not available in the smaller ecosystem.
-----
I agree with the rest, but how do you use imported TS enums in your template? Something like this being impossible is regularly a pain point for me:
slotProps.data.type === ArticleTypes.SomeTypeOtherwise you also need to return it in the setup function (composition) or store a local copy of it in the data field (options)
I have used a lot of frontend frameworks over the years, and before SvelteKit Vue & Nuxt were what I was warming up to.
The article really focused on measurable things like type checking and surveys (not sure exactly how much that's relevant to a single team), but if I tried to quantify:
- Svelte/Kit is conceptually small - Svelte/Kit's diversions from common practice are disruptive at first but quite productive if you really let them sink in (ex. path based naming, +page.svelte/+page.server.ts/+server.ts) - Svelte's ability to run in various different modes (SSR/node/vercel/etc) is awesome
At this point Vue3 & Nuxt3, Remix, etc have caught up in many ways but I really really love using Svelte/SvelteKit. I recommend trying it at least once.
- Angular introduces structure, people realize that Directives are awesome but dirty checking is bad.
- React re-focused frontend on components (to be fair Backbone/Marionette and some MVVM stuff was going this way already but whatever), people realize they really mostly just want big hierarchies of components and to minimize everything else. The Flux data flow pattern is alluring too but kind of unnecessary.
- Vue cloned react but improved on it by introducing the data object via automatic tracking and radically simpler APIs. I read up and was productive with Vue in like... 1 day of reading docs.
- Svelte builds on all of that, moves more magic into the compiler and introduces weird syntax but thoroughly consistent ergonomics and lower complexity.
- Everyone goes SSR
For people who want jobs, React is still king and probably will be for a very very long time. But you can pry SvelteKit from my cold dead hands.
What a long strange trip it's been
It feels like it was
Plain JS -> jQuuuuuuuuuuuuueeeeeeeeerry -> Angular -> React -> Vue -> Svelte
Until Svelte and Kit becomes difficult, slow, or hard to use, I'll keep using it. No need to switch to another at this point.
I'm even using Kit to build out simple REST API endpoints, it's so simple.
YUP. SvelteKit is one of the things that made me throw out my 3 tier (3 repo) project boilerplate. I mean I always knew I was slowing myself down (I'd look out the window and see all the Rails kids frolicking wild and free, not a care in the world), but I just didn't feel like I could trust my API code to Nuxt for some reason. I don't know what it was. Nuxt 3 is much better since they explicitly call out API routes but...
SvelteKit properly making space for API endpoints and being so light that I felt I could just pop a few endpoints in there and it absolutely broke that barrier for me. Now I quite often mix back and frontend, and even streaming endpoints are fine too (they added support for streaming responses).
Even after this many years on HN…
"Nobody on the core maintainers team is particularly fond of Web Components"
Yet,Their official doc includes support for Custom Elements; I found that svelte is not the right JS framework for building specific components in a SSR app while trying to use it for feature in my Go application[2].
[1] https://github.com/sveltejs/svelte/issues/6481
[2] https://abishekmuthian.com/javascript-framework-fence-sitter...
No idea why you put SSR and web components in the same sentence, and in a way that presumes that web components are required for that, or at all.
1. web components are literally incompatible with SSR and all SSR solutions for them are ugly hacks.
2. It's not just personal "fondness" that prevents Svelte from doing more about web components. There are multiple documented downsides, including by Rich Harris, the author of Svelte
3. As long as you pretend you need web components for SSR, no framework will be right for you, including web components themselves. Meanwhile every single framework is several light years ahead of anything web-component-related for SSR. Especially Svelte whose authors and contributors have thought really hard about SSR.
Web components are a browser standard; so anyone thinking about the long haul for their web product would be well advised to think about web components as well.
> web components are literally incompatible with SSR
Declarative shadow DOM is an emerging browser standard that is literally compatible with SSR, and is already supported by Blink-based browsers.
It doesn't make it
1. a good standard,
2. a requirement, and
3. a viable standard to support
There are countless issues with web components none of which are on any path to solution, they keep valiantly solving issues that only arise from introducing web components in the first place, and there are multiple well-documented and discussed reasons why the absolute vast majority of frameworks (including the new ones) don't use them as their foundation.
> Declarative shadow DOM is an emerging browser standard that is literally compatible with SSR
1. It's only "emerging"
2. As far as I understand, there are still multiple unresolved issues
3. The fact that it's available in Chrome (don't insult us by using the vague Blink-based browsers) means literally nothing. Because Chrome are well known for shipping half-baked Chrome-only non-standards just because they feel like it
(Don't also forget how horrendously bad the whole API is https://twitter.com/WebReflection/status/1526186094232064000)
Great example is Custom Elements V0: they shipped it, forced a Youtube re-write in it (well, in Polymer), literally no one else implemented it, they had to wait ~7 years to remove it from the browser because they had to wait for Youtube to re-write everything again in V1.
Great standards, and a bet on the future, I'm sure.
A typical JS framework fence sitter would build SSR first applications and might likely think about using a light weight framework like Svelte for a client rendered 'feature (or) two' like I did.
> There are multiple documented downsides, including by Rich Harris, the author of Svelte
In link [2] of my parent comment I've mentioned those, I've no technical contention on his PoV but that 'Custom Element' feature is buggy, Is not made clear upfront and that there's no intention to fix it.
> As long as you pretend you need web components for SSR, no framework will be right for you, including web components themselves.
What about web components first framework like Lit[1]? I'm not stating it as a fact, But asking?
[1] https://lit.dev/
Rich Harris called this "transitional apps" :) See this excellent talk: https://www.youtube.com/watch?v=860d8usGC0o
There's now active work to finally let you build whatever you need from a single code: be it MPA SPA, or anything in between, seamlessly. Including things like "everything is SSR'ed except this specific part of the page". Svelte, Solid.js, Astro are all rapidly moving the state of the art towards that goal.
> Is not made clear upfront and that there's no intention to fix it.
IIRC the idea is to remove web components from the core eventually, and have them as a third/first-party add-on. Can't find the relevant tweets right now, so don't quote me on that :D
> What about web components first framework like Lit[1]?
Their SSR support is listed as experimental: https://lit.dev/docs/ssr/overview/ with multiple issues (see the end of the page).
There's a reason for that: web components in general cannot be SSR'ed. That is, you cannot take a random web component and have it SSRed. You have to do very specific manual hacks or very library/framework-specific/bundler hacks to make them work. See this excellent article for details: https://css-tricks.com/using-web-components-with-next-or-any...
Erm.... No. If you don't have SSR then it doesn't matter if it's web components or not: they will be instantiated at runtime.
> it comes down to whether the framework has good support web-components or not in the first place?
All of them have decent support for web components (at least for "consumption").
The reasons they don't support them as a foundation (and at most emit web components if you tell them to) is that they don't want to deal with all the stuff like no SSR support, the need to still have all the layers above for things like lazy loading, progressive enhancement and a whole laundry of issues that none of the non-web-component frameworks have: [1][2]
[1] Why I don't use web components https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
[2] https://twitter.com/Rich_Harris/status/1198332398561353728, explanation on SVG: https://twitter.com/Rich_Harris/status/1198339672361119745
<h1>{name}</h1>
clearly state that you want name inside h1, it's colocated and faster to write than
const h1=document.querySelector("h1"); h1.innerText=name;
As for why we need $ or reactive is because JavaScript does not comes with a way to express reactivity. In the case of svelte this means having to come up with a syntax for the compiled language, for Vue means that you need to wrap your normal object in a proxy to let Vue know when you are accessing or setting a variable.
> it's much more readable
I guess this is just a difference in opinion then, haha. Not so different from Python vs Ruby.
If we talk about bundle size, then there might be more interesting discussion. Svelte claims to be pretty small - I wonder how that pans out compared to an "equivalent" app in Vue or even vanilla JS.
I don't have helpful benchmarks here, but can anecdotally confirm that the compiling and bundling magic that svelte does is... magical. They do some really smart tree-related things at build which are (imo) a major feature leading to this quick-and-small packaging of an app.
For example, they will keep state synchronised between your data model and components (and with some handy plugins, your server).
They allow encapsulation and reuse through a well thought out set of abstractions.
They provide functionality like routing and app-wide data stores with transactions.
If you’re just building a webpage no problem, use raw JS. But if you’re building a complex app, let a framework take care of as much incidental work as possible.
Same as with all (good) frameworks and libraries, they boost your productivity.
The syntactical sugar is often masking a lot of complexity behind the scenes, and the very idea of (say) React's props propagation within a component tree is an abstraction over having to write a bunch of separate event handlers and figuring out a way to manually share state between them.
If that is a problem you run into in your app, you can of course write your own system. But that's all these frameworks are... someone else had that same problem, decided to formally tackle it and make it a well-supported & documented system so that others facing the same problem can use that as a solution too. Over time the industry converges on a few (React, Vue, Svelte these days, Angular in the past). If you don't like any of them, well, that's how a new framework is made...
Vanilla HTML doesn't even have loops and conditionals, the basic features of any templating language from 10-20 years ago. It's glorified Gopher with JS shimmed in because Netscape was afraid of losing dominance. It was never intended to become the de facto language of software app distribution... the whole reliance on a "document" model is a poor fit for an entire class of web apps (like Google Maps or Gmail or Spotify or Netflix or Figma or Photopea).
IMO the better question in my mind is not "why do new JS frameworks and templates keep popping up?" (because HTML+JS sucks), but rather "why haven't native HTML+JS continued to evolve, creating a native solution for common pain points that the frameworks address -- like state, component trees, etc.?"
For what it's worth, at least the Web won, instead of (say) ActiveX or .NET or Flash or the Metaverse or whatever alternate ecosystem companies have tried. The JS frameworks offer some of the devex benefits of those other richer languages while still being able to compile down to HTML+JS for delivery to the enduser -- a huge benefit over a "cleaner" ecosystem that would require the enduser to install additional software. The ugliness of modern JS is because it's no longer trying to just handle basic documents, but trying to replace desktop apps altogether. And for many people, it already has.
<template v-for="todo in todos">
<li v-if="!todo.isComplete">
{{ todo.name }}
</li>
</template>
[1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
But no one writes blog posts about how Vanilla JS 2 is no longer supported so they had to migrate to Svelte :)
All (widely used) modern frameworks have a degree of magic in them. Do you prefer not using any of them?
If you're just building a simple page, sure, don't use a framework. But once you get into the realm of multi-screen async state sharing across components, a framework makes that a LOT easier to read and maintain.
At the end of the day the minor syntactic changes aren't much more complex than say, Markdown... they just facilitate component composition. The actual business logic is usually still written in plain JS. The templating language doesn't really matter all that much in the end, whether it's JSX or a Vue thing or a Shopify Liquid template or whatever.
HTML + JS isn't some golden standard that markup should aspire to... it is literally the lowest common denominator. It's historical baggage that everyone's forced to compile down to, and there's nothing magical or special about either writing in a framework or in pure HTML. Users don't care. Just make it work, and make it work within resource constraints. The latter is usually what drives framework usage... most teams don't have infinite time to reinvent everything in their own proprietary framework.
createElement(
"div", {
className: ["recipeTile", { lastRow: options.lastRow, lastColumn: options.lastColumn }],
onclick: function () { showHideRecipe(recipe.name) }
}, [
createElement("img", { src: "./static/images/" + recipe.name + ".jpg" }),
createElement("div", { className: "details" }, [
createElement("div", { className: "name" }, capitalize(recipe.name)),
createElement("div", { className: "ingredients", }, Object.keys(recipe.ingredients).map(function(ingredientName) {
return capitalize(ingredientName);
}).join(", "))
])
]
);
function createElement(type, attributes, children) {
var element = document.createElement(type);
Object.keys(attributes).forEach(function(key) {
if (key === "className") {
classNames(attributes[key]).forEach(function (className) {
element.classList.add(className);
});
} else if (key.indexOf("on") === 0) {
element.addEventListener(key.replace("on", ""), attributes[key], false);
} else {
element.setAttribute(key, attributes[key]);
}
});
if (Array.isArray(children)) {
children.forEach(function(child) {
child && element.appendChild(child);
});
} else if (typeof children === "string") {
element.textContent = children;
} else if (children) {
element.appendChild(children);
}
return element;
}
But these must be maintained now
Very few sites need to be applications
people always call out the small community to be a downside, so a few of us started Svelte Society to fix that (very humble numbers compared to react, Rethinking Reactivity is probably the best starting point for most https://youtu.be/AdNJ3fydeao). i actually think theres a “be careful what you wish for” aspect to this, svelte’s community is super enjoyable now BECAUSE it is small and many come to it as a second framework; so are less religious and more intentional about their tech choices.
notable companies now using svelte not just for internal apps but customer facing, critical stuff: huggingface (for everything, including gradio), alaska airlines (entire customer flow), razorpay (payment dialogs), schneider electric (many things), ikea (ecomm experience), riot games (league of legends client), Brave (search page), Square (developer portal), several YC startups, and basically every notable data journalism outlet on the planet (Bloomberg, the Economist, Reuters, Les Echos, german and japanese publications, pudding.cool, and of course the NYT) https://twitter.com/sveltesociety/status/1260209026563858432
sveltekit 1.0 is also frequently called out as an adoption barrier but.. well.. stay tuned (on the order of weeks not years)
And I agree with you. Rich has strong opinions and he likes to stir some discussion. And that's fine, he always responds with nuance and mutual respect. Problem is when community parrots his one liners. If I had a nickel for everytime I got yelled with "vdom is pure overhead!" or "jsx is an abomination, my templates are pure html".
In the end I'm not even sure if it is something specific about Svelte, or just any non-react solution has to bash React loudly.
I agree that if you want to keep the patterns that make React-query so amazing, but apply them in Svelte, you should use idioms that make sense in Svelte. The exact syntax (`useQuery` and friends) isn't the point, and the `use[A-Z].*` naming convention actually communicates that you're hooking into the React lifecycle... which obviously doesn't make sense in Svelte.
The problem with "useX" isn't an anti-react one, it's that "use" is an actual thing in Svelte, it's called an action! https://svelte.dev/docs#template-syntax-element-directives-u... :)
yes this does happen too, i do acknowledge that. just making very subjective generalizations based on my exp
The sentence I would use is "less pragmatic and more interested in hacking than being productive".
I know people like to dump React devs for being fanatics and I have encountered some of those people... Like, 2 maybe. The rest of us use React because we want a battle tested framework with a huge community.
I don't want to hack around with the cool new framework. I don't find frameworks exciting. I want to build stuff that I do find exciting and I want the framework to be in the background supporting that. I want to be able to find support when I need it and high quality prebuilt extensions for as much of the functionality my app needs as possible so that I'm not spending my days rebuilding basic components. That's why I choose React.
- Typed component emits: https://vuejs.org/guide/typescript/composition-api.html#typi...
- Typing event handlers: https://vuejs.org/guide/typescript/composition-api.html#typi...
Our documentation is all Svelte and dogfoods our own UI components. We've got dozens of pages and components here. Scale is from small to large. All open source so give it a go.
I come from a background in Angular over the last 10 years. Built several large SaaS apps and admin systems. I'd have no hesitation using Svelte in it's stead. In fact I'd probably get it done in half the time and half the code.
It seems to me that using raw web components you would end up writing your own custom framework, which would be yet another framework but with probably less support
I am a founder first, and a developer second. My biggest goal is to build products that solve problems and load extremely fast and are as lightweight as possible. The less tech involved the better.
Lastly, this is just one person's opinion, and I am often wrong.
Come on, why even ask this, you already know the answer.
Writing frameworks (or text editors, or...) is fun, and the original dev will be long gone when the warts of the framework become obvious and drag down the project (5+ years from the initial launch date).
We are hosting ~2.5 million pages.
You can find the code here: https://github.com/tradingstrategy-ai/frontend/
One one the latest additions for making managing large applications easier is folder based pages, with +page.ts and +page.svelte and all of their children compnents in the same folder.
Generally, folder based routing makes code much more manageable than React routing solutions, as React has too many solutions and is not enough opinionated for large projetcs.
The counterintuitive reality is that the best tool for big project is a small framework.
The bigger your project is, the more likely that framework will be getting in your way. The more likely that complexity of the project will be multiplied by complexity of the framework and result in an unmaintainable mess.
Mithril's hyperscript like syntax hinders its adoption. And now, with newer tools like solid and svelte, the ship has sailed.
Vue2/3/Svelte is the easier frameworks for the widest range of developers to use and maintain apps for. This is because of their approach to templating VS that of React for instance, not to mention how they handle styling though Vue2/3 is even a rung above that of Svelte when it comes to CSS.
React is great if you want to convince the money people because they are more likely to have heard about it and how everyone is using it.
Svelte has a lot of odd bugs and associated hacks you have to figure out, such as looping over a list may sometimes not work at all and you need to place it within {# key} hack, this re-renders everything within the block though so it kills performance.
SvelteKit is unusable at this point, the routing system has undergone several major changes for example but there are constantly several breaking changes, DO NOT USE.
Vue3 typescript support is near perfect, I have had more problems getting full typescript support in Svelte and React.
They state sveltekit is feature complete and there are no more planned breaking changes before 1.0. I think you can use it now, with relatively low risk.
still doesnt have scoped styles, animation, state mgmt, head management, etc out of the box, all minimum things i look for to be productive
Err, I'd have a hard time not to see that as a major benefit first of all?
1. user 2. client 3. document
and within document its in "components", but those are unknown from the start so we defer the details (which must not but can lead to "wild west"). programming is hard, thought. would love to have that holy grail solved, too (apart from the famous three column layout).
And as the latest and greatest omnipotent entry in it, so my guess would be theirs authors were aware of it.
/edit: thanks for pointing me to solid, it shined a lot of light to me in context of the article.
I was using this but immediately saw the writing on the wall as soon as the Composition API came out with its far superior typescript support. Converted our greenfield Vue 2 app over to the new API within a few weeks which turned out to be the correct decision.
Unfortunately, unless you were following Vue development very closely this would've slid by.
Are you sure vue-class-component 8.0.0 RC1 doesn't work? I see it was in development for v3 before being discontinued.
On a distinct but similar note, I don't want to pull an "RC" into my migration, let alone one with no prospects of being maintained. I was already seeing scuttlebutt about deprecating it entirely. Removing it entirely had a much clearer and lower-risk path before it, if not a fun one.
Of course old technology exists. You could still make your frontends in Jquery if you'd like.
I keep hoping things will settle a bit more so that I can someday pick one to learn in depth without worrying about it being replaced by the next hotness.
Am I right in thinking the state of major players is roughly:
React - incumbent, slow, vast, but widely used Vue - main challenger to React, aimed to fix many issues, but 2->3 migration tricky Svelte - lighter compiled alternative for smaller projects, faster, but more niche Solid - even faster, more similar to React, but too new/small for bigger projects
You are in the wrong industry, to think this will happen any time soon.
Change has been fast in computing, for decades. Stand still, and you are overrun and eventually your knowledge moves towards irrelevance.
Doctors need to keep up to date with new medical information, new drugs, new warnings about drugs, new techniques.
Lawyers need to read caselaw, keep up to date on new legislation.
Both are arduous tasks for those professions.
Yet there is more to keep up to date in computing, in a year, than any doctor or lawyer must keep pace with in their lifetime.
So either dive in and learn, learn, learn! Learn for the joy of it, for the fun!
Because there is nothing to wait for.
Because change will never stop here.
The front end space is really quite unique in its fragmentation and pace of change. Things are…maybe starting to cool down a touch, but not really. We can talk til the cows come home about how this or that have caused things to be how they are, but simply chalking this up to “things change fast in tech” - beyond just being a thought-terminating ‘shrug your shoulders’ platitude that I’d probably hear from a non-tech family member over Christmas lunch - is really missing most of what’s going on here.
To that I mean, if you could code 5 years ago, and deploy a front end of any sort 5 years ago, you won't have many issues today.
People still use redis/memcached, mysql, php, apache2, with laravel for example.
And solutions such as docker, with unvetted builds snagged from random people, are no different, functionally, than a VM or even a bare metal cluster.
I will agree that the absurd node ecosystem, with its unsecure, unauditable packages, composer and its insane web of just stupid dependancies are ridiculous.
But that's not rapid change of method or coding language, just because behind the scenes it's all just language such as php.
So sure, the cruft is just that, but the meat is what drives change, and a lot of it.
Last time there was a meaningful major improvement is when React devs came up with practical implementation of view=f(model) idea.
> someday pick one to learn in depth without worrying about it being replaced by the next hotness
So maybe the trick is to not use a framework. Like, I don't need a "framework" for backend dev, just a toolbox of good libraries.
The tooling around TypeScript is similar to a backend language like Go, a very different experience from writing JavaScript a decade ago
So then ask yourself the question - which underlying tech of your in house framework is going to be more stable, supported, have better tooling, and be easier to reason about. I'd pick the DOM every time.
Also the developer has requested that forks are not be called Elm to avoid confusion which some people consider "hostile against forks". There are some projects that have forked Elm.
I don't know if Svelte will ever get the same punch of Vue Libraries and frameworks that exists now.
Let see what happens.
Meanwhile I stayed with Vue3
Cheers!!!
I wish it had something like vuetify though.
If you compare xml style syntax to s-expressions there is a clear distinction between child nodes and attributes (a "bi-partite tree", not sure if the term exists). For markup like html where the child-data is the content and the attributes are meta-level annotations this makes sense. Even when looking at guidelikes for "how to design an xml schema/doctype" the responses are often like "use child elements for alle business data and attributes only for technical meta-data".
So from syntactical perspective there is a clear distinction between attributes and child elements. The main one I would say is that attributes are limited in the sub-structure they can contain (only primitive types or space separated lists).
The way react adopted the html/xml like syntax for the creation of javascript objects to allow the declaration of DOM nodes in a nicer way. On top of that react allows the creation of custom elements as functions and allows their usage via the same xml-like syntax.
But now as soon as these custom components have more complicated dependencies between each other the xml syntax gets (imo) misused as a poor dependency-injection layer. It's only possible because JSX allows for non-primitive attribute values and it sticks out like like a sore thumb because the semantics do not match the syntax (like defining a "+" operator that is not commutative).
In my opinion a better way would be curry the component creation or to introduce a real DI-layer for component configuration that is then used to load fully configured components that can then simply be composed in jsx.
Do Vue codebases in the wild tend to be different? Or would this have been a massive undertaking as well?
This "metric" and the results leading towards are so misleading. What is their setting? Their context?
> The number of developers: Two front-end developers worked full-time for two weeks alongside another developer who worked full-time for one week, so that's three developers involved
Ok, a fairly small team with a small app.
It is ok for me, if business allows for this migration. Small team, needs fun. The write-up is ok.
However, as a general reminder: take context into account. These comparisons never include teams size.
React is dominated by 1 person projects, if you follow the tutorials. I work in enterprise context, where I am leading 100+ devs and would always, always opt for Angular, since it is opinionated.
https://insights.stackoverflow.com/trends?tags=reactjs%2Cvue...
This was also many years ago, where we had - let's build apps mainly with HTML/CSS and sprinkle in some JS framework sugar and dynamic capability on the client side. Ok, Angular/Ember and then Vue worked VERY well. We made a hop from jQuery to more sophistication but still easy to read and develop compelling and maintainable, interactive frontends. Then we did SPAs which worked well for a few things but were vastly oversold.
React came along which was nice, but early on, it was not needed for many projects even though many devs started implementing it.
We had a demand for more rich web apps and they got MORE complex and dynamic. We decided, maybe we shouldn't sprinkle in all these sugary JS framework tags and corresponding logic in our HTML.
Then we had a ton more university-educated programmers entering the frontend scene that used to just be comprised of a megaton of jQuery heroes (no offense, they got shit done and went out to lunch most days while the more sophisticated frontend devs went hardcore on semantic HTML/CSS, VanillaJS, spending countless hours on browser bugs and QA cycles and using divs to render tabular data for fun/ego?).
We also got more interest in React from non full-time frontend devs (ex: fullstack and even backend devs) that were like, hey building frontend doesn't suck like it used to in VanillaJS! Count me in!
Coupled with the Stackoverflow copy-paste dev era and the nightmarish third party library upgrade scenarios... now we have a TON of shitty React codebases and people have, and will, migrate away from them. This cycle I'm describing gives rise to challengers like Svelte.
I like React (and React Native), but the many codebases I've inherited have not been good. In fact, I've probably inherited as many decent React codebases as decent jQuery codebases but what does that say? Not much because I haven't inherited many good examples of either.
I'll still choose inheriting a shitty React project over a shitty jQuery project any day. Great progress has been made (although you could argue much of the progress was in cross-browser standards and advancements in browser technology).
But I still feel like the truth that everything that is old becomes new again cannot be avoided.
And in that - it's web components and/or more HTML sprinkled JS frameworks for the win to me. I haven't used Svelte, although some on my team like it, but it looks like a return to a get-shit-done dynamic websites/apps framework.
And I'll likely still continue using React for larger, more rich and dynamic apps that require a larger dev team.
However, I will say it has been much easier to make updates to bad React codebases than a bad jQuery codebase. The way React works tend to make it less difficult to reason about even if the app is poorly built.
So a rewrite in less than two years? And Vue 3 was announced over two years ago: https://blog.vuejs.org/posts/vue-3-one-piece.html
The original decision, to me, feels like the wrong one and with no long-term thinking considered. They are now making another poor choice based on framework-hype.
I don't see much difference between the two. So why not go with the largest community?
Since 2014, we have done this several times
UI+backend went from [Cruddy coffeescript + Node.js] to [Jquery + django] to [React 15 + django] to [React 17 + django] and after we were acquired [AngularJS + django] is ongoing.
Backend has been python since the beggining.
Public API server went from python to golang.
Compute and Infra went from private baremetal to k8s.
At no point was there ever any already running code being refactored or framework updated.
We build an improved clone of what exists and plug it in after its been used by enough people in beta. We dont throw the old stuff away until new deployments are working on client premises under high loads and extreme usage.
We dont force clients to upgrade unless serious bug fixes exist.
We never change UI in a way that older customers have to do anything different - unless its a major feature upgrade.
I have written a post clarifying them: https://blog.vuejs.org/posts/on-migration.html
After 25+ years of HTML, JS, CSS, the switch to TS, WebComponent(lit) and Tailwind in Vite is like sci-fi for me.
But let's discuss this again when escapy.js the library, that does not exist yet, will replace svelte in 5 years
Personally, I hate this.
I currently work on a large Angular 14 (now 15) application that separates the view (HTML) from the logic (TS) and the styling (CSS). So you have essentially 3 files for a component.
I don't understand why some developers love cramming this stuff into the same file. Angular's default style encapsulation prevents component styles from affecting other components.
To each their own, I guess.
IIRC, Vue allows you to move link to a separate html,css and js file from vue sfc file should you want it
I know that “smaller components are better”, I agree with this rule, but I prefer to draw the boundaries myself, not forced by the capabilities of my code editor.
Additionally...
{@html
Prism.highlight(code, Prism.languages[lang], lang)
}
mostly this code injection comes from trusted sources like your CMS. if you’re displaying arbitrary user input then yeah better sanitize it but thats a problem common to all frameworks react included
as for perf i mean the main thing is “are you downloading 100kb just for the framework” whereas many svelte apps come in under 10kb. beyond that agree it doesnt really matter
According to https://web.dev/optimizing-content-efficiency-javascript-sta... the js size budget is about 800kB minified (1s to parse/compile). So if an app max out the budget, the framework part is considerably 17.05%.
Not bad, but if the median of react app is around 300kB which means the framework part is 45.4%. This is bad!
I'm writing a dashboard UI for a project as well as the marketing site, both in SvelteKit. It's so easy to write semantic HTML and I'm not forced to see divs everywhere (this has apparently been fixed in React). The reactivity bits are great. It's also lightweight.
I've already seen comments here basically saying, "Yeah cool, React is here to stay" and that's fine. Y'all use that.
Svelte is easy to pick up and a joy to use.
Isn't the problem that most of these frameworks or components result in an either/or choice and fragmentation?
They’re literally going:
- we picked svelte
- we got these benefits from it
I don’t agree with everything they’re wrote but it was interesting to see they’re happy with it.
> All in all, the aforementioned benefits and gains make our developer experience much more enjoyable
Good for them. Glad it worked out.
I will not be doing the same. I do not presume my experience would be the same.
> I find these ranking-based justifications for decisions just plain stupid and childish
Is no one allowed to have an opinion if it doesn’t match up with yours?
It’s just stupid to make a decision, do a thing, then blog about why you did it how it worked out for you?
Pretty harsh.
- Template languages instead of JS. If I want to perform some operation, I have to use their if and for constructs in their unique template language. In React I can just write JS.
- Due to the above, TypeScript support is often lacking or outright poor. IDE support also usually is less than React. The maintainers of the IDE plug-ins simply don't have as much bandwidth as those of React, likely due to lack of man power.
- Vue has a weird plugin architecture, I remember that I couldn't simply import a library as in regular JS or React, I had to register it as a plugin for some reason. Not sure if the situation changed since Vue 2.
- Vue also has a weird way of writing out the code, it had to be done inside an object in the script part of the single file component.
- Speaking of SFCs, cool concept but again depends on IDE support. I'd much rather have a folder for each component and colocate my CSS and JS files there as in React, or use a CSS in JS solution.
- Signals and two way data binding are not as good as people think. When you have a big enough project, you'll understand, as changing one thing can change something else completely separately and debugging is like untangling spaghetti. I actually had to do this for a big Vue 2 project and it just put me off from the concept. There's a reason why React has explicit one way binding, even if it's more code to write and wire up.
- Hooks are incredible. For people who don't get it, they should actually read this GitHub issue about adding something similar to Flutter, the author Remi Rousselet is a well known library author and shows the value of hooks in any declarative UI framework. He explains how, much as functions encapsulate state, hooks encapsulate life cycles, and how mixins fundamentally cannot work the same way in a class based architecture with component life cycle methods. https://github.com/flutter/flutter/issues/51752
- Even if everything all else was equal, everything above was fixed, the main difference for switching is that library support is vastly, vastly lacking for non React libraries. The community assumes React first over anything else, and the quality of React libraries vs non React ones are night and day. Take react-three-fiber or Framer Motion for example, no way there's something of that quality in non React ecosystems
- I even got annoyed by the lack of library support and being treated like a second class user and switched to React. The network effect is real.
-templating language:
First, Jsx is also a templating language. Second, Vue & svelte templates are html super set. So you can leverage your existing html skills. Vue allows you to use pug (and any other html compilation language). Templates also enable performance optimisations while jsx don’t. Jsx is more powerful construct, hence Vue supports it.
- weird plugin architecture. All plugin architecture are weird. You can choose to not use plugins or write one. But they exist so for convenience of users
- weird way of writing code. An object inside script of sfc. And SFCs
Your mileage may vary. I prefer vue sfc. Especially because it is html like syntax and makes sense to me. If you prefer separate files, you can split html/js/css to separate files and link via src attribute
- signals and two way data binding
Vue has unidirectional flow. And two way binding is just syntax sugar for form inputs. And it is very good, if you have used react form, then you know what I am talking about
- network effect is real
It is real. And nothing can be done about it. :(
- Templating languages have been around for years, and for many, they feel like the right way to write markup. If someone has used Handlebars in the past, the templating constructs feel familiar. There is also the idea of keeping logic out of your views with the restricted feature set of your templating language. Finally, conditional logic is simply easier in a templating language vs JSX. This will be true until we get pattern matching or the do expression, ternaries, and boolean expressions are clunky. Solid added constructs for conditions and looping to JSX, mainly for performance, but it's much more ergonomic.
- People like the SFC pattern precisely because everything is separate. Your logic is separate from your markup, which is separate from your styling. For me, it feels like a throwback to the times of MVC when it was good and proper to separate your concerns that way. Some reject React out of hand because "there's no default solution for styling".
- The composition API in Vue 3 and Svelte's stores provide the same abstraction potential as hooks. Their reactive primitives aren't tied to the component lifecycle, which is a really nice benefit. It avoids a lot of the context performance pain that people can end up in.
Overall, I'm not really sold on SFCs. They inherently limit you to one component per file, a tradeoff I don't like. There are also the type and IDE support issues which will always be an uphill battle. Template languages are at least better than lashing everything in template strings which is becoming a thing now.
All jokes aside, its hilarious how fast frameworks become obsolete in JS.
Wrote some tools in the last 4 years in the new fancy js ecosystem, and have to update them them permanently, migrate to new version, and and and.
I am sure, i did something right in the past, but i don't now what ;-)
Of the alternatives, Svelte may be the biggest, and is 6 years old.
Web Components are also a decade old concept (implemented to some degree for several years).
Only single brackets are necessary in Svelte
//Svelte
{fullName}
//Vue
{{fullName}}