The very first paragraph leads me to believe this is just a rewrite into svelte for the sake of it - I get it, Svelte is the new hotness on the FE-js-block, but this entire post stinks of "someone on the dev team advocated and fluffed enough figures to convince us. So now we're going to tell you why it was the right choice!" I say all this pretty confidently as someone currently maintaining a massive legacy vue2 app which we are currently rewriting into... *checks notes* React. Because we thoroughly vetted and PoC'd how we'd do it in Svelte and in Vue 3. The former is utterly untenable for an actual product-serving business - it is a pre-release, actively-developing product. Vue 3 is great, I highly recommend reacty-folks or frontend devs try it. We wanted the larger ecosystem (and boo to us for not being brave enough to support the growing vuecosystem).
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?
Excellent observation. This right here is what a senior frontend engineer, that has gone through a couple rewrites and hype cycles, looks like.
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.
Seems like a rewrite for the sake of a rewrite. New frameworks are exciting but if you're building a product you have to realize that's not important to your customers.
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.
> No stable and productive framework will ever be able to compete in hype and good PR than alpha-quality software.
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.
I get it. Yes, stable and productive frameworks would win out in a fair fight, but it isn't a fair fight. The warts in the stable, productive framework are known, and there's already mid-level devs with battle scars that are clamoring for something better than the stable, productive framework.
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.
I do not disagree. I meant that alpha software has fewer detractors, for the simple reason that few have actually used it for something serious and hit their head against all the bugs and shortcomings. On the hype metric alone, stable software just can't compete.
"There are only two kinds of languages^Hframeworks: the ones people complain about and the ones nobody uses."
In what way is being on Vue 2 painful? Using it in production, zero problems, everyone understands it, does everything we need.
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.
I've worked professionally in both Vue 2 and React. Even with class components and prop decorators you still have the annoying Vue template DSL where you don't get any TS support.
In comparison JSX will be checked by typescript, so in that regard JSX (and therefore React) is superior.
I really enjoyed using these tools, it felt idiomatic to have a class per component with props and data as fields on the class - but it seems like there's now no upgrade path for us folks in Vue 3 land.
Composition API has the best Typescript support available in Vue 2. It's supported out of the box in 2.7, and a plugin in previous versions. The decorator syntax is unsupported in Vue 3 and shouldn't be used.
- Nuxt only matter if you want to use it, is not Vues problem, because you talking about another software which addresses a different problem.
- Typescript support is only a problem if you want to use Typescript, imagine, there is also a world beyond TS.
- Performance, often a matter of design and understanding your framework
Note: used Vue 2 and 3 with JavaScript instead of TypeScript, so cannot comment on the latter.
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).
It certainly isn't bad and is my first choice. But, do you have a deep understanding of how React's rendering model works in all edge cases? Because that part really isn't heaven for me. Feels more like trying to navigate a minefield.
I don't and can see how in edge case scenario's one can run into discrepancies between Reacts typings and advanced edge case workarounds. Especially since React itself isn't written in TypeScript.
> In what way is being on Vue 2 painful? Using it in production, zero problems, everyone understands it, does everything we need.
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)
SvelteKit (a meta framework) is still not at 1.0, but Svelte itself is at 3.53 and mature and stable. We've used it production for several apps (moving from React). It's been a joy to work with.
SvelteKit isn't Svelte's UI framework. SvelteKit is a full web framework for serving Svelte apps. It's essentially Sapper + Svelte in a more harmonious combination.
I have no opinions about any of these libraries and frameworks for business applications.
SvelteKit is going ot be Django/Ruby on Rails of frontend frameworks. Due to integration and polish, it is so much easier to use than anything I have developed with on Angular, React and even older stacks like jQuery.
> SvelteKit is going ot be Django/Ruby on Rails of frontend frameworks.
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?
Typescript support in Svelte is one of the biggest problems with the framework I’ve encountered. We have a couple of production Svelte apps at my job and overall the frontend DX is excellent. However, not being able to use generically typed components is a big missing feature. We have a number of custom core components which work really well, but not being able to create a new component with something like MyTable = Table<User> feels like an oversight. Inside of the Table code we work around this shortcoming to appease tslint…
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.
I may be missing something (I haven't used Svelte, SvelteKit, or TypeScript much), this doesn't seem accurate. I was going to link to a direct example, but I'm not sure I understand exactly what you're looking for. More information here: https://github.com/ivanhofer/sveltekit-typescript-showcase
I added some more information in another reply, but Svelte has officially supported TypeScript for a couple years now. It provides some tooling to get started and there are also existing projects that may make certain things easier or more useful.
I'm not saying it's the same (like you said, Svelte isn't at 1.0) but don't you feel like there's at least a little irony in saying the post stinks of justifying someone just wanting to try out something different when you're currently chucking a Vue 2 app for React?
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.
Next.js is not a good general purpose React framework. It is good for static sites with sparse dynamic pages but nothing more complex. And the documentation is still woefully inadequate.
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.
Hey there, I'm on the Next.js team. Sorry about this experience. I would argue Next.js is a general purpose React framework – we enable you to take advantage of all the latest React features. Apologies if there was a gap in the documentation. Could you share more so we can improve? You can also email lee at vercel dot com.
You might be much more experienced than me so feel free to discard my suggestions if you objectively know you're right.
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.
Can I ask how long you ended up using Next for? Did you quit frontend dev after 2 weeks, or only after working through the challenges etc.?
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 designed and led that project for 3 years. The technology choice was mine, so it was a learning experience. Frontend was something I did alongside the rest of the stack, but I've seen so many terrible libraries by inexperienced developers come and go post jQuery, I actively avoid frontend-focused roles now.
> I've seen so many terrible libraries by inexperienced developers come and go post jQuery, I actively avoid frontend-focused roles now.
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.
I am still annoyed I took the time to learn Webpack and its overly complex configuration a few years back, and the world has already forgotten all about it. There definitely is the feeling that learning a new frontend library is a terrible use of your time.
> [svelte] is utterly untenable for an actual product-serving business
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.
In general agreement with one caveat; Svelte is hardly new. Rich Harris was using it at NYT 4 years (at least) ago, and it's been open source since. It's caught on because of; a pushback against React, the surging popularity of Vue, the sudden popularity of Rollup (which has been around just as long, but adoption in Snowpack/Astro and Vite was a game changer), Rich being hired by Vercel and more weight behind Svelte. All of those things have gelled to create a popularity surge in the framework. I'd shy away from calling it the "new hotness," and simply bear in mind that it's just trending lately.
> Vue 3 is great, I highly recommend reacty-folks or frontend devs try it. We wanted the larger ecosystem (and boo to us for not being brave enough to support the growing vuecosystem).
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.
Wowowow stop.. last time I seriously looked aeons ago (4 or 5 years? :D) there was Vue as the nice smaller thing as an alternative React.. besides some other few bigger names.
Noe Vue2, and Vue3? That didn't age well? And Svelte?
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.
Spotty support for C++17/C++20 is very annoying. Maybe if you stick to one platform and one language edition on one compiler you'll have a nice and stable C++ experience, but that's no different from Javascript. We adopt new things because we want better things, having some of those things fail or quickly deprecate is a risk that comes with that territory.
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
I think you probably can start using svelte/sveltekit for production development, depending on your timeline... the "svelte" part is mature, and sveltekit (the web app framework around svelte) is close to release according to their status report (feature complete, no more planned breaking changes)
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.
I migrated from vue 2 about 4 months ago seeking better typescript support and looking to move away from webpack. While I absolutely loved the simplicity and feel of svelte, I came to the same conclusion that it is not ready for a major production application yet. In a few years, I'm hoping vue setup scripts are as low friction as svelte or it may be time to switch over (they're close now, if you're using the latest macros, which may or may not be in beta still).
I've been writing operational apps with Svelte for over two years. I develop geospatial applications that make heavy use of WebGL. Haven't yet ran into any serious limitations. I keep things fairly simple and have been using tailwind the entire time. We had to fork a geospatial map framework (Cesium) to allow it to be loaded with Rollup.js as a simple javascript es6 module. But I wouldn't blame that on Svelte.
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 think Sate of JS is really useful, as long as you weight with User count, not just the percent of people that have liked the framework. Svelte is much too low in the actual usage for me personally to adopt.
> The former [svelte] is utterly untenable for an actual product-serving business - it is a pre-release, actively-developing product
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 was annoyed when I found out vuex4 was pinia. But I followed the guide and converted over and was suprised it works without any bugs. (Except for my typos during the migration) turned out great and I love the simplified api.
Some months ago I did the same thing as TFA - took a look at Vue3 and decided to change my main project's UI from Vue2 to svelte. So far I've been really happy with it.
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.
I’m kinda confused by this and your other replies in this thread. You seem to be defending Vue, specifically Vue 2, in almost a drive by fashion. You don’t seem to be considering any of the points actually being made. No bystander is interested in hearing the drive by argument of someone without an open mind.
I've got a couple of templates where I've aliased the value of a TypeScript enum into a local variable before using it in the template, so I'm pretty certain at that point I was unable to use the value of the enum directly (that's also how I remember it). However, I just tried it and...it seems to just work now. So thanks for making me revisit that :D.
<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.
It… does. Now I wonder if this was not in 3 from the beginning, or if I simply always assumed this behavior was the same after upgrading from Vue2. Wow. Thanks.
Svelte & SvelteKit has been wonderfully productive for me. It's a bit insane that I have adopted it across so many projects of mine despite the fact it is pre 1.0 (well that has more to do with me I guess), but I am just faster with it.
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.
Same. I normally prefer boring old tech, but I’ve migrated all my projects over to Sveltekit. Yep, breaking changes are annoying but it’s worth it. It’s got the point where you’d need to pay me lot to work on a Vue or (especially) React project.
- 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.
> 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).
Ditto. It's my go-to for all new web projects - we just move so much quicker in it, and don't usually spend a whole lot of time thinking about it - most of the time, it just doesn't get in the way at all.
JavaScript framework fence sitters who are planning to use Svelte for a component in your SSR application please note that that their Web Components support is very buggy and Svelte team has no intention to fix it, Because(In their own words)[1] -
"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].
> planning to use Svelte for a component in your SSR application please note that that their Web Components support
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.
> why you put SSR and web components in the same sentence
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.
> 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.
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
> 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
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.
> Bo idea why you put SSR and web components in the same sentence
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?
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]?
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...
Thanks for the resources, Wouldn't rehydrating the specific page which uses web component eliminate the need for explicit SSR support in the JS framework and thereby it comes down to whether the framework has good support web-components or not in the first place?
> Wouldn't rehydrating the specific page which uses web component eliminate the need for explicit SSR support in the JS framework
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]
Still don't understand why people prefer magic templated front-end frameworks. Reading non-standard HTML just sucks. What even is "$:" or why does Vue require non-standard javascript ref("") objects...
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.
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.
> 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.
If you want a serious answer: because frameworks do a lot of work for you.
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.
I think what snowl wanted to know was more technical than that - why such new syntax is necessary to achieve those things? Why exactly the same things cannot be achieved with existing syntax? For example, it's very understandable why JSX is preferable over vue's string syntax (<tr v-for="employee in employees" :key="employee.id">) in terms of "just use JS" argument. What exactly warrants this necessity for these weird looking and non-standard syntaxes and why it can't be done without them. Thank you.
With plain HTML+JS, it's very easy to get components to accidentally race each other when you have multiple inputs and outputs, like user interactions plus async API calls plus rerenders and UI state changes.
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.
Sure, you're right about that. It's just that everybody, for example, has the option to use React.createElement directly without JSX, as it's just a syntax sugar and people use it because they prefer it over the other option. Let's consider Vue's syntax:
Genuinely, do developers have the option to "just use JS" here (for looping and conditional)? I personally think this Vue example is very inferior to JS and I see it as an unnecessary complexity unless this "weird string magic" is what enables some nice-to-have feature which is not possible with plain JS.
I know you're probably asking it only rhetorically, but it's the way to mark something as reactive for the Svelte "compiler", cleverly using the existing JS label syntax.[1]
It's really not that bad. At least not in 2022. With the caveat that you can keep your UI (DOM manipulation) code from your business logic code. Which I'm sceptical of given the front-end code bases I've seen in the wild.
But no one writes blog posts about how Vanilla JS 2 is no longer supported so they had to migrate to Svelte :)
I see the point about abusing JS labels in Svelte being magic, but there's nothing magic or non-standard about Vue's ref(). It's just a reactive container, just plain JS.
All (widely used) modern frameworks have a degree of magic in them. Do you prefer not using any of them?
HTML and JS evolve very, very, very slowly compared to the needs of complex web apps.
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.
I'm not the one who wrote above but I see JSX as having fewer magic things than all other template languages I've seen. Take a look at Angular to see some complicated syntaxes examples. Vue and Svelte are better but, IMHO, not as easy as JSX.
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)
I find a lot of Svelte users are pretty religious and hysterically anti-React. When the first version of Svelte Query was announced, people were trashing the API because it looked like hooks and "you don't need those in Svelte", concluding the library must be useless. There's a lot of the "Svelte is the one true way" talk, similar to when Vue was the main alternative to React. The core team seem very reasonable but I think the community has some maturing to do.
I'd consider myself part of the community. I advocated for Svelte and lead two projects in my company, I spoke about Svelte at meet-ups and I did some mentoring around svelte and data visualisation.
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 was looking at the svelte-query PRs recently, and I didn't see anything that looked like "trashing".
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.
This could have been a year ago at this stage. It was on r/svelte, if I recall correctly. Svelte doesn't have idioms for reusable reactive logic. The $ sign is used to drive functionality in Svelte, so you can't use it to signify something observable like with RXJS. For Solid, they use createQuery because that is the convention in Solid. For Vue and Svelte, they stick with useQuery. I think the idea is that useX is just a shorthand for "here is some abstracted reactive functionality". Ultimately it has nothing to do with how the reactivity works, it just says, "this function will tie into your reactivity". They could have just called it query, but it seems arbitrary to change the name.
> so are less religious and more intentional about their tech choices.
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.
Personally, after going all in with Pinia, I went back to no store. I just use refs and computeds exported from files. I have a dummy pinia store loading all of them to provide a basic devtools ui.
Has anyone worked on a very large Svelte project yet? I work on a large React app in real life, but have been learning Svelte in my off time - there are some nice aspects like the out of the box state management, the syntax and structure is a bit easier to learn than React, but my intuition is a Svelte project would become unwieldy for a very complex app (React class components that are hundreds of lines long with dozens of props/local states are easy for me to read/digest but maybe I'm just used to it, it just doesn't feel to me like this would stay well organized in a .svelte file).
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.
We built Roomlio entirely with svelte. Large app and many components. Having used react and angular on production apps in the past, I much prefer svelte. That being said, I am sick of framework fatigue and going forward I would probably choose raw web components and a simple template literal based template library like lit-html (not lit element). Write all the other bits ourselves.
If you are sick of framework fatigue, why not sticking with the framework you know ?
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
Its a good question. I should have said I have "dependency fatigue". If we do stick with a framework, it would be Svelte, it has a great Dev UX. Over the years, I have came to the conclusion every dependency is a future problem, especially if pulled in w/o giving it much thought. It takes two hands to count the number of times we had to refactor an app because some client side router changed their API _again_. Writing a small client router that does only what we need is an event listener and switch statement. Javascript/CSS itself has came a long way in the last years as well. I have no plans of building yet-another-framework. Leverage what the browser gives us as much as possible, any annoying boiler plate can be a snippet or generator. Avoiding the complexity that a bundler adds is also a bonus. Tucking logic away in dependencies, whether written by ourselves or others can complicate things.
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.
> 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.
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).
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)
We rewrote our fairly large React app in Svelte and compared to React, Svelte is an absolute dream. Developers are no longer afraid to make changes to the UI. Making changes takes less time and it's easier to get them right first time resulting in fewer bugs.
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.
People seriously need to stop with this idea that small frameworks are only good for small projects.
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.
When will mithril.js get the hype it deserves, I'm a sucker for simple tiny libraries with no dependencies and no build steps that are mature as well (6 years). I guess it doesn't have a flashy community with talks and developer advocates :/. I feel the same about htmx, another simple tiny library with no deps and no build steps. Why don't people recognize the advantage in that.
Needing a separate build step is not the hindrance that you think it is. For most developers it's a "set up once and forget" thing, and there are many cases when you would need to transform code during build anyway.
Because bell curve. Mediocre developers are the curve and they evaluate tech differently. When most developers evaluate tech based on engineering metrics alone, we would make progress a lot faster. (The business benefit automatically comes with the curve).
As someone who has helped a few companies change frameworks I can say with confidence that it all boils down to developer adhesion within the product teams more than anything the frameworks have to offer. If a few people don't get over their own personal biases they are likely to drag development time down even unintentionally, and the performance of the application will suffer from more shortcuts being made. A well written Vue2 app can be much more performant than a poorly written Svelte app. That said, here are a few observations I have made.
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.
> 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.
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.
Solid JS is what I would have chosen. Not sure if they considered it. Best performance and dev experience with least 'magic' of all frameworks I've tried.
Solid does have state management. Its state management primitives can be used outside components and can even be used completely on their own, and its stores are fairly similar to Svelte stores.
They recently released a beta of SolidStart, their answer to Next.js/SvelteKit/Remix, etc, and I’ve been really liking it. A lot of good ideas pulled from the other frameworks. https://www.solidjs.com/blog/introducing-solidstart
wild west? as far as CSS is concerned the cascade should be well known and for scoping its (in order of preference):
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).
I’ve been so happy with Vue (2 or 3), I can’t think of a compelling reason to leave. The 2->3 migration is also trivial aside from any third party libs that don’t work. It’s really not a big lift. You can transition without going all-in on the composition API. The diff on a big project is very small.
Trivial is not the word I would use. My 2 -> 3 migration is a currently ongoing nightmare, even with the compat lib. I was using vue-class-component with typescript, which apparently... just doesn't work at all with Vue 3? And this isn't really documented, so I basically spent today digging around in Vue's guts with the debugger to prove there was no good way to salvage it for my code, I really just needed to rip it out to have a chance of running it at all. Hopefully that was the worst of it, but Vuex is still acting up. Thank god for VCS or this would be terrifying.
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.
I'm not going to rewrite everything to the composition API in the course of migrating. I want to get the app running, then start moving things over gradually. (I do like the look of it, FWIW. I'm hoping to use it to factor out some tricky UI stuff.)
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.
I was in a similar situation, heavy class component based TypeScript Vue 2 project. Vetur was still the default vscode extension and slow. It was either a big rewrite to Vue 3 or a big rewrite to React for me. I switched to React+MobX and have no regrets.
I mean, the class component thing was mostly syntactic, for what it's worth, once I figured out that was the only way. Drudgery, but not a real threat of failure.
As another comment mentioned, migrating from Vue 2 to Vue 3 is mostly trivial, so this is probably just a case of preferring the new shiny over the old formerly shiny now slightly tarnished...
React is almost 10 years old, if you used React in the last few years you haven't really been changing more than the average backend. The "frontend changes so often" meme made sense years ago but doesn't seem to be that different than backend nowadays. I mean in the last ~10 years we had the new hotness of moving from cloud hosted servers -> docker images -> kubernetes, C# made a massive move when going to .net core, Java actually updates frequently now, etc. Frontend moves a bit faster than backend but if you picked React/TypeScript 5 years ago, you're probably still using them.
Laughable, React is almost 10 years old but Hook is not yet a consensus of the best way to do state and effect. This is what people are actually talking about, they have constantly been in R&D mode while people shipping that codes to prod.
I see it as more a lack of developer discipline than a need—or, more charitably, developers choosing to prioritize things other than longevity. You can certainly choose to develop in a way that's more stable.
As a primarily backend person, it's always interesting to read about this sort of thing as an outsider with little appreciation for the nuances/challenges people face using these frameworks.
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
This is a common rebuttal against any dissent against the insane flux of the front end space and I genuinely don’t believe that anyone with significant experience in software actually believes it.
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.
Front end doesn't change that much from an implementation and coding perspective.
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.
If you’re working on a reasonably sized project “without a framework”, and haven’t effectively built your own, I’m very skeptical of the engineering practices at play.
Not using a framework doesn't automatically imply everything is built from scratch. Maybe I prefer calling libraries, instead of plugging my code into a framework. I could also implement patterns using the batteries included features of the platform. For example Web Components on the frontend, or a REST API on the backend built using the standard Go "net/http" package
Maybe Vue and Svelte are different. But something like react is "just a library", right? So they must be greenspunning their own framework as well, by their own admission.
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.
Since i first stumbled upon Quasar(built on vue 3) last year, i have never looked back. It is all that I ever wanted and could never find. And with pinia instead of vuex it's all even simpler. Vue isn't going anywhere and neither am i.
It has not. Elm just has relatively slow release schedule with the last release being three years ago and some people don't like that.
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 never like Vue2 extra verbose code, when I meet Svelte, I think: "This is it, just want I need" then realized Vue3 is an intended effort of Evan You (creator of Vue) to look like Svelte, I start to use Vue3 because all frameworks and libraries that exists in Vue, actually using Quasar ( excellent and full framework to use Vue2 and Vue3 )
I don't know if Svelte will ever get the same punch of Vue Libraries and frameworks that exists now.
As an outsider (I mainly develop backends), but occasionaly working on frontends, Svelte is the one I found easier to use, that is the most useful for me without having to learn too much above what I already know about html/js/css.
One huge thing that I feel nobody talks about about Svelte is that there is no easy way to pass components as props. Sure, there is slots and svelte:component but the ergonomics just don't match.
I see that as an advantage. Everytime I see components passed as props or a callback passed as child in react I regard it as a big red flag that something is wrong with the architecture of either the app or react itself.
It's funny; I often see it the opposite way. Passing components as props enables inversion of control and usually helps split responsibilities up more easily and generally avoids prop drilling or super components that do everything.
Yeah from a semantic standpoint it makes kind of sense sometimes but it just shows that jsx/xml is not the right abstraction level for the problem at hand.
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.
In most react codebases I've used, there's zero separation between business logic and code that touches react or redux. Meaning if you wanted to migrate, 95% of files would have to be re-written.
Do Vue codebases in the wild tend to be different? Or would this have been a massive undertaking as well?
> frameworks' retention ratios (would use again / (would use again)
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.
React may be "dominated by 1 person projects" but that's very misleading towards the number of big React projects; those dwarf the volume in other frameworks as well. All you're really saying is there are no 1 person Angular projects.
I learned React almost a decade ago and never looked back. Multiple SaaS apps and dozens of personal projects later, I feel no need to reach for anything else.
I like React and I'll admit that I resisted React at first, mainly due to JSX and workflow purposes. We had teams that could do CSS/HTML very well and those that were more capable in JS. There was a gap in skills. And taking the design files into HTML/CSS, testing the bulk of it and THEN adding dynamic functionality and JS was a good flow.
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.
Totally agree with you that now that React has matured, I have dealt with a ton of shitty React codebases because it really is more of a library that doesn't inform you how to architect your app and thus lots of folks went in completely different directions. Additionally because some of the pitfalls of React can be unintuitive, it is tough to unravel these in a larger codebase.
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.
This. For me product velocity and producing value fast for customers is always top priority. Migrating from state of the art framework #1 to state of the art framework #2 seems wild.
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.
It was kind of smooth. The biggest problem with Svelte was the lack of libraries and semi broken tooling. I am still not sold on this heavy JS/SPA approach (I am a mostly backend dev) and really hoping that HTMX or similar project takes off.
It’s odd, judging from a lot of the HN comments in the recent tailwind article, people find the lack of CSS inside react components (out of the box, I’m sure there’s ways of setting it up) enough of a hassle they want to style things in HTML - just to keep their styling in the same component. Something Vue and Svelte and others solve out of the box.
I question the project heads for deciding to migrate rather than build a new product UI side by side with the existing from scratch.
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.
> Besides, the latters share the same concepts of single file components: logic (JavaScript), structure (HTML), and style (CSS) in the same file.
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.
You are right, I prefer exactly this - to separate CSS, HTML, and JS/TS.
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.
It's one of the things I love about svelte. Obviously global styles live in a separate place, but having scoped JS/CSS alongside the HTML its related to is a godsend, especially as a project grows.
I'm missing the raw numbers. Increased performance? Faster code execution? By how much?
I'm sure Svelte is faster, but if we're talking 10% improvement it doesn't really matter.
i dont understand, you’d have to do the same in react?
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
It's 136.4kB minified (react+react-dom), for a zero app is crazy. The app size that will justify 136.4kB is probably 700kB which is 836.3kB total, is also crazy. So no hello world argument because it sucks (in engineering metrics) at all range of apps.
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.
Reading this thread I'm struck by how it's all about moving from this to that, or I use this framework because of these great components only available in X.
Isn't the problem that most of these frameworks or components result in an either/or choice and fragmentation?
As always, I find these ranking-based justifications for decisions just plain stupid and childish. Also with Vue 3 you won't have any issue and it is already out for a while, so what have you been doing anyways?
As someone who switched from Vue 2 to React around when hooks were introduced, can someone explain to me why they like non-React frameworks? Based on my experience, they all have some drawbacks:
- 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.
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
I'm primarily a React user and would generally agree with you, but I understand why people like Vue/Svelte.
- 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.
The churn back in the backbone.js/Ember/Knockout generation was much higher. Seems to have mostly stabilized on React, Angular, and Vue, all about 10+ years old now. Though major versions of these admittedly can add a lot of breakage. (Angular 1 to 2 was devastating for many people).
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).
I didn't see anything about type checking. We have a pretty sizeable Vue2 app written in TypeScript (well, mostly, because some devs...), and using Component/Prop/etc. decorators, it's very readable. The html template checker/compiler unfortunately doesn't see the data types, but apart from that, type checking is almost perfect within a component. That saves so much time. And it has optionally scoped styles too.
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/