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.
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.
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.
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...
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.
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'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.
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.
<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.
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...
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]
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.
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?
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.
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 :)
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.
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.
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.
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’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 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.
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.
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.
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).
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.
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.
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.
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
> 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).
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.
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.
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.
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)
> 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.
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 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.
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.
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.
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'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.
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.
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.
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?
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.
- 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
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.
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.
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.
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)
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.
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.
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.
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.
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.
> 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?
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.
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
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.
> 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."
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.
> 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.
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.
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.
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.
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.
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.
> [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.
> 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:
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.
288 comments
[ 3.9 ms ] story [ 290 ms ] threadThis 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.
https://insights.stackoverflow.com/trends?tags=reactjs%2Cvue...
https://npmtrends.com/react-vs-svelte-vs-vue
- Typed component emits: https://vuejs.org/guide/typescript/composition-api.html#typi...
- Typing event handlers: https://vuejs.org/guide/typescript/composition-api.html#typi...
Of course old technology exists. You could still make your frontends in Jquery if you'd like.
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.
-----
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:
Otherwise you also need to return it in the setup function (composition) or store a local copy of it in the data field (options)
<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.
[1]https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
<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.
All (widely used) modern frameworks have a degree of magic in them. Do you prefer not using any of them?
But no one writes blog posts about how Vanilla JS 2 is no longer supported so they had to migrate to Svelte :)
But these must be maintained now
Very few sites need to be applications
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.
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 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.
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.
still doesnt have scoped styles, animation, state mgmt, head management, etc out of the box, all minimum things i look for to be productive
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).
Err, I'd have a hard time not to see that as a major benefit first of all?
https://www.solidjs.com/docs/latest/api#stores
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
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).
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.
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.
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.
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)
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.
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
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.
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.
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.
Additionally...
looks very unsafe to me. (Vue example has the exact same problem)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 wish it had something like vuetify though.
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.
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/
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.
> 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.
- 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.
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.
FWIW, Nuxt 3 was released in November. https://nuxt.com/v3
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.
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)
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.
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.
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.
I have no opinions about any of these libraries and frameworks for business applications.
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.
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?
I'll guess Vuex -> Pinia is more work.
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.
Trust me, the grass ain't greener on the other side.
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
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.
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."
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.
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.
1. https://www.tldraw.dev/
2. https://reactflow.dev/
3. https://atlaskit.atlassian.com/ (seriously, table handling in the RTE is excellent)
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.
Just a note: Svelte is 6 years old, only 2 years younger than Vue. Both are definitely "old" on JS-framework timescales.
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 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:
https://github.com/neurosnap/neovimcraft/pull/201
I don't see much difference between the two. So why not go with the largest community?
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