- even better performance,
- a more granular reactivity system with runes,
- more expressive template syntax with snippets and event attributes,
- native TypeScript support,
- and backwards compatibility with the previous syntax!
I learned Svelte 3 over a year ago and I found it very pleasant. Unlike React, Svelte is an integrated framework, no "pick your router" nonsense, I don't want to be picking a router.
I like the direction Svelte going in, the old syntax was ok but not great.
I wonder how this new Svelte compares with some of the other new kids on the block like solid.js and alpine.js.
Writing code and writing literature are curiously similar. It begins with thinking, both structured and creatively. Breaking a story down into pieces while keeping the bigger picture, and making a plan for how to approach it. Then comes the difficult metamorphosis where abstract ideas/concepts are turned into concrete words/code.
Good literature/code is concise, expressive, even beautiful. It doesn't come about easily, but takes time. The author reshapes and refactors the text until it meets some standard that the author aspires to, often revisiting it days later to read it with fresh eyes. Then it's committed for review, and may still have to be reworked a bit.
I agree with those who say that coding is more art than engineering. At least if you're really good at it.
I love Svelte and use it for all my personal projects and all company projects (except strictly static sites are still built with just 11ty but I hate it and want to move off it).
But I'm going to wait a bit on v5 for the company, scanning all the issue headlines, it looks like there are a still a lot of unresolved edge cases: https://github.com/sveltejs/svelte/issues
As for my latest personal project, upgrading right now so I can help find more of those edge cases :D
Yes, yes and yes.
It kind of depends what your project uses under the hood and what it depends on, but Astro is quite flexible with the frameworks it supports and for many things there’s a first-class integration that lets you just install support for certain libraries and frameworks (for example Tailwind, React, Partytown, certain CMSes) with one command.
For DB and user logins, you might have to run in SSR mode to be able to do server-side stuff, but you can certainly build API routes, server middleware and interact with cookies for user token stuff.
For what it's worth, I've upgraded three pretty beefy projects to v5 over the past 6 months or so (making sure to stay on top of latest releases), and I haven't seen any weirdness. That being said, I'm not using any of the transition APIs and only one of the projects uses the "runes outside of a Svelte file" thing (i.e. svelte.js files), so YMMV. I was so excited about runes that I couldn't wait. The only thing that bit me initially was `$state` runes converting objects into Proxy instances, so if you want to send data using `postMessage` or IPC in Electron, you need to serialize it first. I really love the new APIs. The Svelte team did an awesome job of addressing most of the gripes I had with v4.
I adore 11ty. It’s not inherently component driven, but it’s super straightforward and endlessly customizable. It allows you to really experiment with organization, too. I like it a lot.
I've used 11ty on and off since pre-1.0. The documentation remains awfully confusing and doesn't cover common use-cases. The system has been pulled together but not thought out as a whole.
Lume (from Deno) is my preferred 11ty alternative.
From listening to webdev podcast #1, Syntax.fm, the gist I get is that a lot of what used to be invisible compiler magic is now more visible & explicit.
The compiler user to rewrite property access to make reactivity happen. Now you can kind of see yourself updating & reading/reacting as you sprinkle runes in. Implicit to explicit magic, with Runes as the headline demonstration of that. Other examples very welcome!
can I do async derived stores by default yet? It was kinda tricky to get working in svelte 4 and even Square/svelte-store wasn't super ergonomic. Would be super nice if it was built in
Exciting, I love Svelte! Does anybody have experience with both Vue and Svelte? It's been a while since I used Vue but it seems like both frameworks have converged quite a bit over the years. With this release I'm particularly curious now: why would somebody pick one over the other?
There is no way around trying yourself. Stop wasting time asking people for their opinions about frameworks and start building your own insights from first hand experience.
Its a valid question, esp if you haven't used a framework for years and want to get to know what other people think of the newer versions. Nobody has time to keep up with all the JS frameworks unless they are a youtuber who does framework comparison as their full time job. And even those youtubers fall behind in the JS world.
I've recently moved from Svelte (initially 4, then 5) to Vue 3, and much prefer it.
The big issue for me was the lack of support for nested observables in Svelte, which caused no end of trouble; plus a lack of portals (though maybe the new snippets fix that?).
Where would one even start learning more about front-end development in today's world? Ignoring the dizzying amount of frameworks, how could I become knowledgeable enough to connect my back-end experience to design the "full stack?"
Pick a stack and dive into it. If you find yourself getting analysis paralysis, just pick one arbitrarily; you're not getting married, you're just getting started. Make things and get feedback on them.
At the end of that process you'll have the background to reevaluate your decisions.
I think truly full stack is probably too much to ask: just accessibility is a huge area of knowledge, for example. I can fiddle around with back-ends, but I want someone more experienced to check my work or just directly help out with e.g. scaling or observability.
Also, ignore the dizzying amount of frameworks. Learn web technologies, and then React. There are millions of back-end tools as well, but in practice, you only use a limited set. Front-end is the same.
Play around with some stuff and see what works for you best. Personally, I didn’t get frontend at all before React came by, and then switched to Svelte because it fits my mental model exactly.
If you don’t like anything – no worries! Classic SSR with templates and stuff is a thing too, as another commenter pointed out.
Edit: no matter what, make sure you write good HTML first and foremost. Use proper semantic tags, don’t add dozens of nested divs, use native controls when possible etc. Make sure to check accessibility, but it should be OK if you don’t do any weird stuff. MDN is a great starting point.
The minimum to be a broadly employable frontend dev is to have knowledge HTML + CSS + JavaScript/TypeScript + React/Vue.
Svelte is pretty niche. I'm not saying you shouldn't learn it, but that you should focus on the common tools first. This is just like you might tell a friend learning programming to learn Java/Python/Go etc. before getting into Lisp/Haskell/Prolog.
All are useful and have their place, but one set of languages is definitely more likely to be used in a workplace (unless you're lucky!).
If you want my opinion on a cool/trendy framework to use, I really like Astro [0], but, again, I doubt anyone will hire you unless you also have experience in React/similar.
Would you use Astro for other type of sites apart from static ones?
I'm not sure if I understand well its use case. It's not for cases when there's complex backend logic, right? What other technologies can be replaced by Astro, to have an example?
Astro is _really_ great for static sites. It doesn't feel heavy like Gatsby and Hugo do. I understand what's going on and I get to write JSX that compiles to static HTML.
> What other technologies can be replaced by Astro, to have an example?
As I mentioned above, and you hit on this too, I think Astro can replace static site generators. It wouldn't replace React (or your favorite framework), but it would use those frameworks to reduce your overall reliance on JavaScript and let most of your site be static HTML.
Astro has "island" pattern which allows you to selectively use JS frameworks on portions of pages where interactivity is required. You can use React, Vue, Svelte, etc.
The big benefit of islands is that the majority of your site is static HTML and only the bits of each page that actually need JS rely on it vs React where your entire site would use JS.
I haven't used this feature but I have heard that people really like it.
I am an amateur but the reason I love React is because there is so much learning material. Robin Wieruch's The Road To Learn React book started with building a HN reader.
I think Claude/ChatGPT works exceptionally well with React code.
I tried to learn Svelte but React/Tailwind plus a language model is just incredible.
Much React hate I think is the way I view the band Metallica. They were way cooler in my head when they were not as popular.
The old way is a bit “magical” in a sense that it does some stuff under the hood to implement the intention behind your code, but it reads really straightforward:
let counter = 0;
// ...
<div>{counter}</div>
`let` in a .svelte compoment makes a variable reactive. If your state is outside a component, you use stores.
With the `$store` rune, the way you make reactive stores inside and outside components is the same, but it only works in .svelte.js/ts. The unification is great – but why not just use `let` in .svelte.js, too?
I understand it can be really tricky – e.g. you might want to use let for things that are not modified in runtime and do not need reactivity, but it should be possible to determine in compile time. (Actually after writing this all up I think I know why Svelte went with runes instead, haha!)
But again – really good work and I hope to try it out on my next project!
I don’t have a definite answer as I haven’t worked with Vue that much. Still, I like Svelte syntax a bit better (e.g. {#each x in xs} vs. v-for), and yeah, all the compile time reactivity stuff works out pretty well in terms of performance.
The runes are still optional, I think, and you can still use the old syntax. Not sure if that will be true in Svelte 6 though!
What's the preffered way to make simple SPAs using Svelte now? I'm using this +layout.ts with sveltekit:
> export const ssr = false;
export const prerender = false;
But it feels awkward for real SPAs - internal applications that have no need for server side rendering.
SSR is one missing pragma away from leaking api keys to clients.
SSR means your web server needs to scale with load on your front page, versus static bundles that can be served almost at infinite scale from a $15/month VPS.
Running a small Sveltekit app with SSR is the easiest yet most of the time good enough way.
However, when your app is larger or needs to be faster, you want a dedicated backend for your API. Then, you can choose a more secure and more scalable language like C#, Go or Kotlin.
Regarding performance, many SSR advocates (don't forget there's a huge business behind this stuff) don't do the math correctly. It's faster (or as fast) to host a SPA on a CDN and get the data from your backend close to your DB. Let me explain assuming the page containing personal data from the user:
1. The user never visited the site. Getting the SPA from the CDN is very fast. Even if you need to get the JS via a second round trip. Then to get the user data is a much slower second roundtrip to the backend server. With SSR, you also have a first much slower roundtrip to the backend to get your SSR site (maybe even another one for hydration!). Then there's a second slower roundtrip to the server to get the user data. This request is slower than getting the data from a fast API backend in the SPA case. So, if the user never visited the site, you need basically two requests anyway: One for the app another for the data. How else should the backend know, what data to return. With an SPA on a CDN the first request is much faster. I must mention that rendering the SPA is an issue on slow devices. But this is a much smaller problem with Svelte than with React. SEO is probably better with SSR, but no as much as the crawlers are nowadays fast to run the JS.
2. The user has visited the site: The SPA is cached in the browser. Or an eTag validation request goes to the CDN. Very fast. Then, the first relevant request with user auth token goes to the backend to get the user data. With SSR, you get everything with one request. No real world difference there. Both approaches one relevant request. One can argue: Rendering the JS on the client device vs on the Node server. C# or Go backend faster than Next or Sveltekit. But those are not the big numbers.
Now, the big disadvantages of SSR is that you need to run a comparatively slow and not very scalable Node backend. If your app is small, then go for Sveltekit or Next with SSR as the DX is awesome. There's no simpler way to create a fullstack app then Sveltekit. It you have a more complex scenario, most of the time SPA is the way to go.
You do realize that spa stands for single page application, right? That's just synonymous with virtual/JS based routing, which you're now equating with various other technological decisions.
I get that you've got opinions and like to voice them, but the parent comment didn't say they didn't want to use the node backend whatsoever initially. they only asked how to disable hydration.
IMHO, you'd be better of using Angular or plain svelte for this usecase, as almost all value you get from svelteKIT is the tight backend/frontend integration.
If you don't want that, you're using the wrong tool. But hey, the definition of a hacker is basically "a person that uses a tool for an unintended usecase" (literally: someone that uses an axe to build furniture), and this is called hackernews. To each their own.
I do have to ask - why don't you want to use SSR just because it's an internal application? For the new Svelte Society website we're SSR:ing everything (even the Admin dashboard). Being able to use form actions is a god send.
With that said, unfortunately when using Kit in "SPA mode" you're not getting the full experience, but it's still the best thing out there. You could try Routify as well.
There's a great talk from last years Svelte Summit that was about Svelte(Kit) in "SPA mode".
SvelteKit is a great way to build a SPA. I think just adding those two lines of config to your project once shouldn't be an issue. If there are any difficulties you'd like to share we'll try to fix them as part of SvelteKit 3. (e.g. this issue which I added to the 3.0 milestone: https://github.com/sveltejs/kit/issues/12580)
Also how can we hit back button and keep scroll position? I tend to write pages that scroll to top and make ajax calls. The Sveltekit site does it correctly.
Svelte 5 has been very nice to work with over the past few months. Yes, runes require you to think more carefully about lifecycles and updates. And you may end up writing a little more code initially than with svelte 4. But it serves you better in the long run with complex apps. I found a process for gradually turning a simple app into a more complex one that works for me. I iteratively move $state() runes out of .svelte files and into .svelte.ts files where I build a more abstract data-oriented structure for my app from a series of mutually linked classes. Then those runes can be re-imported into the .svelte files, or used and updated wherever you need. If you plan it right, I think it avoids the need for heavy redux-like state management. (at least I think so. I haven't worked with redux much myself)
Do you know of any large OSS software built with Svelte? I'd like to see how it turns out in the long run, because I'm reticent of all frontend frameworks nowadays through what I perceive as gateways to uncontrollable accidental complexity and abstractions.
Just my personal opinion: I love svelte for small projects but the whole runes rewrite just feels so much less ergonomic. A step in the direction away from the simplicity that drew me to svelte in the first place.
That said, there is backwards compatibility with the older syntax, so this isn’t a dealbreaker, and the team does a good job of explaining the reasons behind their selected design patterns.
(Interestingly, I’ve felt the opposite with react lately - they’ve been making the dx simpler).
This is more or less where I’ve landed lately. There are some things I really like in Svelte and Solid but not enough to overcome the massive ecosystem advantage React has.
I never understood the ecosystem argument as applied to Svelte. Vanilla js libraries integrate with it pretty much perfectly, meaning you don't need a Svelte port of a given library. The ecosystem is effectively huge.
There aren't very many good modern, maintained vanilla js libraries. But for just about anything I need in React I can find something polished and well supported that just works.
I'm not sure I understand. What types of libraries? When I think of libraries, I think of ExpressJS, lodash, JQuery, left-pad, etc. There are absolute tonnes of vanilla JS libraries.
I've rarely used React, are you talking about React-specific libraries? I find it hard to believe that there are more maintained React libraries than vanilla JS libraries.
I don't have a strong opinion on the whole, but as someone who's been building a diagramming app for 2+ years, I've found react-flow to be the most solid free & open-source node-based diagram component, by far. At least in terms of quantity/quality of features and UX/DX. Though admittedly I haven't thoroughly looked at alternatives in about a year.
It basically singlehandedly convinced me that the ecosystem was worth going with react when I started my project, despite really enjoying svelte.
All those libraries also work in React of course. The only vanilla js libraries that don't work well with React are UI libraries that assume they can control the DOM. But I can't think of many of those I'd prefer to the many excellent React UI libraries.
> I iteratively move $state() runes out of .svelte files and into .svelte.ts files where I build a more abstract data-oriented structure for my app from a series of mutually linked classes. Then those runes can be re-imported into the .svelte files, or used and updated wherever you need.
I don’t know exactly how you do this, but it sounds like you are dangling on the global state of the runes. This is DANGEROUS in Svelte and can definitely ruin your day.
Of course! I was very used to SPA, and the convenience of moving a rune/store to an external file meant it could be accessed anywhere (as the post said). With SSR however, if you’re not careful, you can easily leak data: https://github.com/sveltejs/kit/discussions/4339.
This really made my day. I decided to convert a pretty large project over to v5 a couple of months ago because the new APIs were so much nicer. I rolled the dice a bit because I wasn't sure if I was going to hit weird edge cases, but everything went smoothly. Congrats to the Svelte team and major kudos for coming up with runes!
Do they still operate with very little backwards compatibility policy? They killed the sapper project and replaced it with sveltekit. Is sveltekit still alive?
It's not a pessimistic statement. I'm just saying they did. There is no guarantee that they will not do the same in the sveltekit project :) I recommend people make smart decisions and use it.
I can wholeheartedly recommend Svelte. As someone who can only do vanilla HTML/CSS/JS, it lets me build projects quickly and efficiently without having to learn something complex like React. Case in point this silly side project made in Svelte over a weekend: https://meoweler.com
That website is actually a great way to compare options, thanks for sharing! I did find that it gives a 500 error for Birmingham, AL specifically, if you’re still working on it.
This is also why I chose SvelteKit as my first framework. I was actually pretty fluent in vanilla since my first real web project was a full stack chrome extension, but when it came time to choose a framework for my first true web app, I chose Svelte because it was the only framework I could immediately understand.
Svelte reminded me of how I got my start with coding. I love it. Refusing to learn React has cost me job opportunities but Svelte is just so much more pleasant to use and easy to grok.
I’m currently building a social network with SvelteKit and I couldn’t be happier. Excellent DX.
...but that's what Svelte is not. The techniques you adopt won't transfer over to vanilla HTML/CSS/JS without the magic Svelte compiler. These habits will become crutch when Svelte inevitably goes the way of every Javascript frontend framework.
> something complex like React
React is not that complex, certainly not more so than Svelte. It's hard to wrap your head around some behaviors, but at the end of the day, it is really just Javascript/Typescript. It is programming. As a programmer, I want to spend most of my time programming in a programming language, not so much of it configuring the Rube-Goldberg machine that is HTML/CSS. Your mileage may vary, of course.
> this silly side project made in Svelte over a weekend
As someone who had to work around the bugs and limitations of IE6 for years in the enterprise, popularity is not a measurement of how good a technology is.
The reason React is "embraced" by the industry is that it is widely used, not because it's the best choice. This lowers the risk for companies that can replace its developers with another easily. I'm not saying it's as bad as beeing stuck with a stale IE (yet), but there are surely good alternatives out there.
"Nobody has been fired for choosing IBM", was a saying that applies to React today
It has reached the "IBM" point where it's so widely used, that it has become the most rational choice for enterprise.
We have to wait for a few years while smaller businesses who don't have (or care about) the same risks uses better alternatives until they reach the point where you are not blamed for choosing something outside the box
> The reason React is "embraced" by the industry is that it is widely used
That looks like tautology to me. What point are you trying to make with this?
Comparing IE6 and React is _hardly_ a fair comparison. One was a Trojan horse injected by corporate policies and ACLs, while React gets explicitly chosen by teams. And... Yes, there _is_ a reason why nobody gets fired for choosing React: it's not a bad choice! Is Svelte a better choice? Not universally. Unfortunately—like with many things in our field—it comes with trade offs and the answer boils down to "it depends" again.
React has its quirks, but "hating" on a library because it was part of a dumpster fire project doesn't mean the library is bad, just that people using it weren't competent with it (not necessarily incompetent in general).
Vue, Svelte, Leptos, Solid, Elm. I've seen all of them used as dumpster fire fuel, and it was hardly the library's fault.
I do not hate React and am not the person who made the dumpster fire argument. The original person complained about React, and another person used popularity as a counter argument. That was what I replied to.
> That looks like tautology to me. What point are you trying to make with this?
React is in a place now, where it is the "safe" default choice for Enterprises. It's not necessarily a bad choice, but I argue that risk management is often an important part of deciding which tech to use.
It got to this point by being backed by Meta and was a genuinely good alternative to other frameworks at the time. But it is my view that enterprises prefer React not because it is the best, but because it is good enough and easy to find workers with experience. This is a self reinforcing feedback loop.
I worked in a sales driven startup some years ago and got to shape the technology as the first hire and only developer for a few months. I chose React because it was easier to recruit for and time to market was important. If I had already a team of developers with experience with another framework, I would have chosen that one even if it had been a less popular framework due. Time to market was our main focus.
More established companies don't have the same time constraints and are often more concerned about scaling up with multiple teams. A less popular framework is a bigger risk. It is "easy" to hire 10 people for any framework, but what about 100?
Vue? Lol. I've been using Vue full-time in multiple large corporate code bases for the past 3½ years and I'd exchange it for React in a heartbeat. Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily. …which is no surprise really if you introduce a new custom file format and make type checking an afterthought.
Meanwhile, React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
>Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily.
This seems like a setup issue.
Mine catches everything just fine. Both in-editor (I use neovim) and with a make step (just calls vue-tsc) + a precommit hook as a sanity check.
>React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
React is obscene. It always seemed to me the Java of the FE world, made worse in recent years. By that I mean grotesquely verbose and full of ceremonious value passing through multiple functions just for the tiniest of things. I've had to work with React codebases and these days I outright refuse to do that/turn down jobs with that requirement. I'd rather use angular.
Svelte and Vue are ergonomic and straightforward and they sanely default to SFCs instead of that woeful chimera of languages called JSX/TSX - you can still use it if you so desire though.
> As a programmer, I want to spend most of my time programming in a programming language
If your work requires you to use a web stack, this attitude will not serve you well in the long run. If you make the effort to learn these technologies, you'll soon find them to be simple and predictable, but admittedly not without some historical baggage. You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
> If your work requires you to use a web stack, this attitude will not serve you well in the long run
I disagree. A "web stack" is outdated quickly, but the language remains mostly the same, as does my data. React lets me express most things naturally as forward data transformations, without entangling me too much to peculiar toolchain that will become obsolete and break absolutely everything.
> You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
Sure, you'll have an easier time making decisions if someone else makes them for you.
Not sure about this. Most JS frameworks only last a few years before the next shiny is mass adopted. The churn in JS land is insane.
React is definitely one of the long beards though, and thats’s because declarative programming is a win for UIs IMO. So much so it had a massive knock on effect in popularizing this approach (what’s old is new again… and again) across languages and problem sets.
IMO we're long past the churn era - Svelte itself is 8 years old. There are occasional bursts of new frameworks and tools, but only when there is a new niche - the last one I remember was a few years ago when suddenly everyone wanted to do a static website generator. And that didn't make existing frameworks obsolete.
In my post I was actually speaking about learning CSS and HTML alongside the "real programming language" that is JS/TS.
> It's hard to wrap your head around some behaviors
I've got a React maintenance and development project coming up in a few weeks. I'd love if you'd expand a bit on these points and maybe point to some relevant docs. You could potentially save me days or more of tail chasing. Thanks.
Primarily the rules of hooks and what does and does not trigger a render or a unmount. If your project still uses class instead of function components, that's a potential target for refactoring.
The biggest thing most people don't understand is that React re-renders recursively by default, regardless of whether any particular child component's props actually changed or not. Most of its behavior patterns follow from that one.
I have an extensive post called "A (Mostly) Complete Guide to React Rendering Behavior) that covers the concepts and nuances in detail:
I swear every time I use React, every couple of years, I wind up thinking "okay fine, but... why?"
I love JSX. But the React API, for some areas, feels complex and boilerplatey. I dunno why you have to explicitly memoize some stuff. Svelte just magics that shit away.
> But the React API, for some areas, feels complex and boilerplatey
You may or may not have noticed this, but the React API is a bit counterintuitive to how JS or any other code you normally write would work because the component function gets invoked repeatedly so any code in the path of the functional component that's not externalized into a hook or memoized will be invoked again.
That's also why in local dev mode, you'll see the render cycle executed twice so that you can spot any undesired side effects due to this design choice.
So a lot of the complexity is to deal with this specific design choice to determine when code inside of the component function needs to be re-executed. In React, you need to explicitly opt-out of reactivity while in nearly every other framework, you are opting-in to reactivity.
For me, I've always seen this as the weirdest footgun because it's antithetical to the underlying language and runtime behavior so developers need to be explicitly aware of this behavior.
I went with Svelte when I built out the website for my canvas library a few years back[1]. It's proved to be easy to maintain the site, and I particularly like that it supported my vanilla JS library (which I use on the site's landing page) with minimal fuss.
At some point I want to update the site to use Sveltekit, which I'd been experimenting with in personal projects. But then the team announced Svelte 5 and these things called "runes" and ... I don't know. Having just passed my 60th birthday I'm getting to a stage in my life when keeping up with all the New Shiny makes me wonder if it's worth the effort, or if I should be doing more interesting stuff like creating new content for the site instead.
It's funny because very early on the key selling point of Svelte was that you just mutate objects and it compiles to the observable pattern, unlike React's clunky setState syntax. Now, somehow magic symbols in the code is supposed to be an improvement? It doesn't seem that different from React's magic hooks these days.
Is there some mysterious force of nature that binds front-end frameworks to bad decision making?
I haven’t had the chance to use Svelte in even a semi-serious project. From what I’ve tracked, Runes allow for better handling state complexity and allowing finer grained explicit control of reactivity.
Maybe you don’t need that. Seems like a bunch of the Svelte community did. I wouldn’t frame that as a bad decision.
There is probably a reason they did with a ground-up rebuild and partially this is because svelte 4 didn't enable universal reactivity and $ was more confusing than useful.
Furthermore <slot /> had limitations in terms of children which made it difficult to build UI libraries.
Svelte 5 now is actually simpler to learn for new comers despite higher verbosity.
Hope it starts to chip into React’s usershare and more companies adopt it, but I know that’s a slow process especially for the big companies.
I got out of front end development for most of the years Angular and React have dominated and it looked like a mess, but Svelte and even Astro make sense, maybe I’m just old school. I would totally go back to the frontend with these new frameworks.
If Vue hasn't made a dent, I don't ever expect Svelte to. Angular was the only high-level competitor and I haven't heard that one in a long time already.
For a framework to eat into React's usage, it needs a strong evangelist (like Facebook has been for React)
But didn’t Vue come before React? And it’s mostly the same from what I understand, it’s not totally different like Svelte. I think it can change, if more people put it on their resumes and LinkedIn and if those that know React say can do things in 1/3 the time with Svelte and mention that in interviews as well. That is a slow way of evangelism for Svelte that can spread.
No, react came first. And Vue is not the same. Vue 3 added reactivity via refs (which are essentially signals by today's terminology). They can be used outside of components, like Svelte's runes. Svelte 5 is very similar to Vue 3. So much so I jokingly called it "svuelte" when they first announced it.
Vue gets unfairly overlooked imo. I worked with it for 12 months and it was mostly a joy
Looking at the docs, Svelte is a mix of React and Vue, IMO.
They reverted from the `on` syntax while adding in signals like Vue's `ref`. The way the props pass down is more akin to React than Vue, but the overall reactivity system feels the same as Vue.
I'm not sure I'd pick it over either Vue or React.
I'm only familiar with Angular so far, but looking for a more enjoyable framework for personal projects.
I'm having a hard time deciding between Vue and Svelte.
Vue seems to be better supported by component vendors (PrimeVue, DevExtreme), but Svelte looks better from a framework perspective itself.
React has already been chosen. The familiar hammer. Face it, there is an entire workforce worth of devs who think web development is React (and now they are moving into management). The same way droves of people think Facebook is the internet.
I was very amused this summer, hearing a company that I had worked at six years ago is switching from React to Angular. I had thought angular was dead.
React is cargo cult at the moment and has been for years already. People will just use react because everybody is using react, no matter if it makes sense or not.
I gave React a handful of year to get popular and mature. I tried to approach it an immediately ran into basically endless arguments and bitching about how to manage state. There was no clear winner so I dropped it. Everywhere I landed trying to find advice or best practices just led to more questions. Like WTF?
Svelt, Vue3 or hell...Angular, and it's off to the races. I just need to know how to accomplish all the things being demanded by Product.
Prop drilling sucks and React has at least a handful of different philosophies when it comes to managing cross-cutting state (Redux, Jotai/Recoil, Zustand, Context, etc.).
I made my first website a few months ago (I'm an ML engineer). I tried in both Svelte and React.
I used Sonnet as a copilot the whole time and expected Svelte to be more difficult because there are orders of magnitude less training data on it.
To the contrary! The LLM tied itself in knots very quickly with React but mostly did ok with Svelte/Sveltekit. Also, the Svelte stuff it makes is usually snappier. However it does have a wider range of UI widgets it can grasp with React.
It seems that my opinion that React is horrendously and hideously overcomplicated is at least somewhat objective! Svelte has been quite pleasant.
To any devs out there that have to work with React, you have my sympathies. Compared to Svelte it's just flaming hot putrid garbage.
Strong words, I actually enjoy it quite a lot. For trivial stuff I can see how Svelte can seem simpler. But effects, JSX, and the React model tend to be incredible at composition at scale. And the close to the metal to JS nature is something I strongly prefer.
Now granted I’d never use a reducer, and imo a decent state library is the biggest win if you are using React.
Every time I try out something other than React (Vue, Svelte, etc), I have to learn some new syntax, understand the runtime magic, and add a syntax/LSP to my editor. But React is just JS/TS, which is straightforward.
Being disappointed by a library/framework because your LLM of choice can't produce decent code doesn't really tell me very much about the library, other than it's usage is varied.
The difficulty with react generally isn't the syntax. It's the constraints of hooks and reconciliation. Since mutation is always disallowed (but not by mechanical constraints) data changes are harder to express. You have to remember to keep your effect dependency list synchronized even though the linter can tell you when it's wrong. State continuity depends on the heuristics of the reconciler considering this component instance (and all its parents) to be some particular component instance from a previous render function output.
The syntax is maybe the only good part of react. And I still think the way it uses JSX is not great. Conditionals and .map seem... weird.
Someone on Twitter claimed that Svelte 5's runes are basically a nicer (custom) syntax for Solid.js -- is that true? I find the way Solid.js decouples signals from components to be a huge step up from React's state management in terms of abstraction capability and composability.
Hm i haven't checked the svelte 5 runes yet but last time I checked i also felt that solids reactivity concept is just beyond what svelte offers. If i wasn't that much in love with solidjs i'd probably pick svelte though. But i already see it coming that i won't be able to let it go until i checked the new runes now...
> Svelte 5's reactivity is powered by signals, which are essentially what Knockout was doing in 2010. More recently, signals have been popularised by Solid and adopted by a multitude of other frameworks.
> We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly.
Been using Svelte for about 8 months and have fallen in love with it, using it in production for both personal and company projects.
My only gripe is it doesn't support <template> tags or class list arrays out the box, meaning I've had to use preprocessors instead, the latter for me makes it far nicer to mentally visualise components when using dynamic tailwind classes.
253 comments
[ 2.8 ms ] story [ 251 ms ] threadThe new version brings:
Probably a better link for this post?
Edit: I'm not so sure that's up to date actually. Lots of "Coming soon" sections
I like the direction Svelte going in, the old syntax was ok but not great.
I wonder how this new Svelte compares with some of the other new kids on the block like solid.js and alpine.js.
You're talking about SvelteKit. Svelte does not have a router.
Lately I’ve also been wondering about the relationship and correlation between software writing skills and writing skills.
-- Edsger W.Dijkstra https://www.cs.utexas.edu/~EWD/transcriptions/EWD04xx/EWD498...
Writing code and writing literature are curiously similar. It begins with thinking, both structured and creatively. Breaking a story down into pieces while keeping the bigger picture, and making a plan for how to approach it. Then comes the difficult metamorphosis where abstract ideas/concepts are turned into concrete words/code.
Good literature/code is concise, expressive, even beautiful. It doesn't come about easily, but takes time. The author reshapes and refactors the text until it meets some standard that the author aspires to, often revisiting it days later to read it with fresh eyes. Then it's committed for review, and may still have to be reworked a bit.
I agree with those who say that coding is more art than engineering. At least if you're really good at it.
Runes are a pretty slick addition, as someone who comes from React, this feels like home.
https://x.com/Rich_Harris/status/1847682508822913359
But I'm going to wait a bit on v5 for the company, scanning all the issue headlines, it looks like there are a still a lot of unresolved edge cases: https://github.com/sveltejs/svelte/issues
As for my latest personal project, upgrading right now so I can help find more of those edge cases :D
For DB and user logins, you might have to run in SSR mode to be able to do server-side stuff, but you can certainly build API routes, server middleware and interact with cookies for user token stuff.
I saw they have Svelte 5 support, and maybe this would make runes a killer app if we can inject the runes into Astro, (or even React) components?!
Lume (from Deno) is my preferred 11ty alternative.
The compiler user to rewrite property access to make reactivity happen. Now you can kind of see yourself updating & reading/reacting as you sprinkle runes in. Implicit to explicit magic, with Runes as the headline demonstration of that. Other examples very welcome!
just came back to svelte after using version 3 previously, and I'm still finding my footing;
The big issue for me was the lack of support for nested observables in Svelte, which caused no end of trouble; plus a lack of portals (though maybe the new snippets fix that?).
At the end of that process you'll have the background to reevaluate your decisions.
That said, if you truly want to learn, MDN is the reference, and they have a pretty good curriculum too: https://developer.mozilla.org/en-US/curriculum/
Also, ignore the dizzying amount of frameworks. Learn web technologies, and then React. There are millions of back-end tools as well, but in practice, you only use a limited set. Front-end is the same.
If you don’t like anything – no worries! Classic SSR with templates and stuff is a thing too, as another commenter pointed out.
Edit: no matter what, make sure you write good HTML first and foremost. Use proper semantic tags, don’t add dozens of nested divs, use native controls when possible etc. Make sure to check accessibility, but it should be OK if you don’t do any weird stuff. MDN is a great starting point.
Svelte is pretty niche. I'm not saying you shouldn't learn it, but that you should focus on the common tools first. This is just like you might tell a friend learning programming to learn Java/Python/Go etc. before getting into Lisp/Haskell/Prolog.
All are useful and have their place, but one set of languages is definitely more likely to be used in a workplace (unless you're lucky!).
If you want my opinion on a cool/trendy framework to use, I really like Astro [0], but, again, I doubt anyone will hire you unless you also have experience in React/similar.
[0]: https://astro.build/
I'm not sure if I understand well its use case. It's not for cases when there's complex backend logic, right? What other technologies can be replaced by Astro, to have an example?
> What other technologies can be replaced by Astro, to have an example?
As I mentioned above, and you hit on this too, I think Astro can replace static site generators. It wouldn't replace React (or your favorite framework), but it would use those frameworks to reduce your overall reliance on JavaScript and let most of your site be static HTML.
Astro has "island" pattern which allows you to selectively use JS frameworks on portions of pages where interactivity is required. You can use React, Vue, Svelte, etc.
The big benefit of islands is that the majority of your site is static HTML and only the bits of each page that actually need JS rely on it vs React where your entire site would use JS.
I haven't used this feature but I have heard that people really like it.
https://docs.astro.build/en/concepts/islands/
I think Claude/ChatGPT works exceptionally well with React code.
I tried to learn Svelte but React/Tailwind plus a language model is just incredible.
Much React hate I think is the way I view the band Metallica. They were way cooler in my head when they were not as popular.
The old way is a bit “magical” in a sense that it does some stuff under the hood to implement the intention behind your code, but it reads really straightforward:
`let` in a .svelte compoment makes a variable reactive. If your state is outside a component, you use stores.With the `$store` rune, the way you make reactive stores inside and outside components is the same, but it only works in .svelte.js/ts. The unification is great – but why not just use `let` in .svelte.js, too?
I understand it can be really tricky – e.g. you might want to use let for things that are not modified in runtime and do not need reactivity, but it should be possible to determine in compile time. (Actually after writing this all up I think I know why Svelte went with runes instead, haha!)But again – really good work and I hope to try it out on my next project!
No shadow dom and a better template directives? Maybe, not sure.
The runes are still optional, I think, and you can still use the old syntax. Not sure if that will be true in Svelte 6 though!
Chef's kiss. I hate code that overcomplicates.
Blah blah 'making stuff explicit'... I don't think that it's impossible to make things explicit while also making it ergonomic, and humane to use.
Anyway, programming as a whole is an old paradigm, sigh, might as well make the new thing myself.
But it feels awkward for real SPAs - internal applications that have no need for server side rendering.
I get that hydrations value is mainly in SEO and a tiny improvement in initial draw speed, but why would you want it disabled, specifically?
It's pretty much what you already wrote though.
https://kit.svelte.dev/docs/single-page-apps
You'll only need the fallback page and can omit the +layout prerender configuration. It's documented on that page
https://kit.svelte.dev/docs/adapter-static
SSR means your web server needs to scale with load on your front page, versus static bundles that can be served almost at infinite scale from a $15/month VPS.
However, when your app is larger or needs to be faster, you want a dedicated backend for your API. Then, you can choose a more secure and more scalable language like C#, Go or Kotlin.
Regarding performance, many SSR advocates (don't forget there's a huge business behind this stuff) don't do the math correctly. It's faster (or as fast) to host a SPA on a CDN and get the data from your backend close to your DB. Let me explain assuming the page containing personal data from the user:
1. The user never visited the site. Getting the SPA from the CDN is very fast. Even if you need to get the JS via a second round trip. Then to get the user data is a much slower second roundtrip to the backend server. With SSR, you also have a first much slower roundtrip to the backend to get your SSR site (maybe even another one for hydration!). Then there's a second slower roundtrip to the server to get the user data. This request is slower than getting the data from a fast API backend in the SPA case. So, if the user never visited the site, you need basically two requests anyway: One for the app another for the data. How else should the backend know, what data to return. With an SPA on a CDN the first request is much faster. I must mention that rendering the SPA is an issue on slow devices. But this is a much smaller problem with Svelte than with React. SEO is probably better with SSR, but no as much as the crawlers are nowadays fast to run the JS.
2. The user has visited the site: The SPA is cached in the browser. Or an eTag validation request goes to the CDN. Very fast. Then, the first relevant request with user auth token goes to the backend to get the user data. With SSR, you get everything with one request. No real world difference there. Both approaches one relevant request. One can argue: Rendering the JS on the client device vs on the Node server. C# or Go backend faster than Next or Sveltekit. But those are not the big numbers.
Now, the big disadvantages of SSR is that you need to run a comparatively slow and not very scalable Node backend. If your app is small, then go for Sveltekit or Next with SSR as the DX is awesome. There's no simpler way to create a fullstack app then Sveltekit. It you have a more complex scenario, most of the time SPA is the way to go.
I get that you've got opinions and like to voice them, but the parent comment didn't say they didn't want to use the node backend whatsoever initially. they only asked how to disable hydration.
IMHO, you'd be better of using Angular or plain svelte for this usecase, as almost all value you get from svelteKIT is the tight backend/frontend integration.
If you don't want that, you're using the wrong tool. But hey, the definition of a hacker is basically "a person that uses a tool for an unintended usecase" (literally: someone that uses an axe to build furniture), and this is called hackernews. To each their own.
With that said, unfortunately when using Kit in "SPA mode" you're not getting the full experience, but it's still the best thing out there. You could try Routify as well.
There's a great talk from last years Svelte Summit that was about Svelte(Kit) in "SPA mode".
https://www.youtube.com/watch?v=uIZOeBS-3cI
TL;DR: Lean into load functions and monkey-patch fetch (if possible)
huggingface https://huggingface.co/pydio https://huggingface.co/docs/chat-ui Ollma webui https://github.com/open-webui
These are just a few of them that I quickly search and look at their popularity .
I’ve used it as a reference for a NestJS+SvelteKit app in the past, they did a pretty good job.
Gradio: https://github.com/gradio-app/gradio
EDIT: Also, not OSS, but https://search.brave.com seems to be built with Svelte
Another notable example is Yahoo Finance, which is written in Svelte
https://finance.yahoo.com/
Ollama's OpenWebUI https://github.com/open-webui/open-webui
Cannot edit my previous answer i mentioned wrong page. , updated proper links
That said, there is backwards compatibility with the older syntax, so this isn’t a dealbreaker, and the team does a good job of explaining the reasons behind their selected design patterns.
(Interestingly, I’ve felt the opposite with react lately - they’ve been making the dx simpler).
I've rarely used React, are you talking about React-specific libraries? I find it hard to believe that there are more maintained React libraries than vanilla JS libraries.
It basically singlehandedly convinced me that the ecosystem was worth going with react when I started my project, despite really enjoying svelte.
I don’t know exactly how you do this, but it sounds like you are dangling on the global state of the runes. This is DANGEROUS in Svelte and can definitely ruin your day.
CLI tool: https://github.com/sveltejs/cli
Edit: added the link to the CLI tool
Why makes you think SvelteKit could be dead? What a weird a pessimistic phrasing.
This is also why I chose SvelteKit as my first framework. I was actually pretty fluent in vanilla since my first real web project was a full stack chrome extension, but when it came time to choose a framework for my first true web app, I chose Svelte because it was the only framework I could immediately understand.
Svelte reminded me of how I got my start with coding. I love it. Refusing to learn React has cost me job opportunities but Svelte is just so much more pleasant to use and easy to grok.
I’m currently building a social network with SvelteKit and I couldn’t be happier. Excellent DX.
> easy to grok got me :)
...but that's what Svelte is not. The techniques you adopt won't transfer over to vanilla HTML/CSS/JS without the magic Svelte compiler. These habits will become crutch when Svelte inevitably goes the way of every Javascript frontend framework.
> something complex like React
React is not that complex, certainly not more so than Svelte. It's hard to wrap your head around some behaviors, but at the end of the day, it is really just Javascript/Typescript. It is programming. As a programmer, I want to spend most of my time programming in a programming language, not so much of it configuring the Rube-Goldberg machine that is HTML/CSS. Your mileage may vary, of course.
> this silly side project made in Svelte over a weekend
I will admit, that's what Svelte excels at.
The reason React is "embraced" by the industry is that it is widely used, not because it's the best choice. This lowers the risk for companies that can replace its developers with another easily. I'm not saying it's as bad as beeing stuck with a stale IE (yet), but there are surely good alternatives out there.
"Nobody has been fired for choosing IBM", was a saying that applies to React today
It has reached the "IBM" point where it's so widely used, that it has become the most rational choice for enterprise.
We have to wait for a few years while smaller businesses who don't have (or care about) the same risks uses better alternatives until they reach the point where you are not blamed for choosing something outside the box
That looks like tautology to me. What point are you trying to make with this?
Comparing IE6 and React is _hardly_ a fair comparison. One was a Trojan horse injected by corporate policies and ACLs, while React gets explicitly chosen by teams. And... Yes, there _is_ a reason why nobody gets fired for choosing React: it's not a bad choice! Is Svelte a better choice? Not universally. Unfortunately—like with many things in our field—it comes with trade offs and the answer boils down to "it depends" again.
React has its quirks, but "hating" on a library because it was part of a dumpster fire project doesn't mean the library is bad, just that people using it weren't competent with it (not necessarily incompetent in general).
Vue, Svelte, Leptos, Solid, Elm. I've seen all of them used as dumpster fire fuel, and it was hardly the library's fault.
> That looks like tautology to me. What point are you trying to make with this?
React is in a place now, where it is the "safe" default choice for Enterprises. It's not necessarily a bad choice, but I argue that risk management is often an important part of deciding which tech to use.
It got to this point by being backed by Meta and was a genuinely good alternative to other frameworks at the time. But it is my view that enterprises prefer React not because it is the best, but because it is good enough and easy to find workers with experience. This is a self reinforcing feedback loop.
I worked in a sales driven startup some years ago and got to shape the technology as the first hire and only developer for a few months. I chose React because it was easier to recruit for and time to market was important. If I had already a team of developers with experience with another framework, I would have chosen that one even if it had been a less popular framework due. Time to market was our main focus.
More established companies don't have the same time constraints and are often more concerned about scaling up with multiple teams. A less popular framework is a bigger risk. It is "easy" to hire 10 people for any framework, but what about 100?
Meanwhile, React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
>Its type checker and build toolchain are so abysmally bad and bug-riddled that I run into new bugs and limitations on the daily.
This seems like a setup issue.
Mine catches everything just fine. Both in-editor (I use neovim) and with a make step (just calls vue-tsc) + a precommit hook as a sanity check.
>React is basically pure TS and the only bugs I run into are the occasional limitations of TSC.
React is obscene. It always seemed to me the Java of the FE world, made worse in recent years. By that I mean grotesquely verbose and full of ceremonious value passing through multiple functions just for the tiniest of things. I've had to work with React codebases and these days I outright refuse to do that/turn down jobs with that requirement. I'd rather use angular.
Svelte and Vue are ergonomic and straightforward and they sanely default to SFCs instead of that woeful chimera of languages called JSX/TSX - you can still use it if you so desire though.
If your work requires you to use a web stack, this attitude will not serve you well in the long run. If you make the effort to learn these technologies, you'll soon find them to be simple and predictable, but admittedly not without some historical baggage. You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
Interestingly, people chose React over Angular, because it gave you the freedom to not use anything.
I disagree. A "web stack" is outdated quickly, but the language remains mostly the same, as does my data. React lets me express most things naturally as forward data transformations, without entangling me too much to peculiar toolchain that will become obsolete and break absolutely everything.
> You may even have an easier time with Svelte, since it has everything working out of the box, unlike React, which requires you to figure out a build toolchain and a separate solution for styling.
Sure, you'll have an easier time making decisions if someone else makes them for you.
You're comparing two tools that are both at the top of a very tall stack of pre-made decisions.
React is definitely one of the long beards though, and thats’s because declarative programming is a win for UIs IMO. So much so it had a massive knock on effect in popularizing this approach (what’s old is new again… and again) across languages and problem sets.
In my post I was actually speaking about learning CSS and HTML alongside the "real programming language" that is JS/TS.
I've got a React maintenance and development project coming up in a few weeks. I'd love if you'd expand a bit on these points and maybe point to some relevant docs. You could potentially save me days or more of tail chasing. Thanks.
> some relevant docs
Read the docs. All of them. React isn't that big.
I have an extensive post called "A (Mostly) Complete Guide to React Rendering Behavior) that covers the concepts and nuances in detail:
- https://blog.isquaredsoftware.com/2020/05/blogged-answers-a-...
I swear every time I use React, every couple of years, I wind up thinking "okay fine, but... why?"
I love JSX. But the React API, for some areas, feels complex and boilerplatey. I dunno why you have to explicitly memoize some stuff. Svelte just magics that shit away.
That's also why in local dev mode, you'll see the render cycle executed twice so that you can spot any undesired side effects due to this design choice.
So a lot of the complexity is to deal with this specific design choice to determine when code inside of the component function needs to be re-executed. In React, you need to explicitly opt-out of reactivity while in nearly every other framework, you are opting-in to reactivity.
For me, I've always seen this as the weirdest footgun because it's antithetical to the underlying language and runtime behavior so developers need to be explicitly aware of this behavior.
At some point I want to update the site to use Sveltekit, which I'd been experimenting with in personal projects. But then the team announced Svelte 5 and these things called "runes" and ... I don't know. Having just passed my 60th birthday I'm getting to a stage in my life when keeping up with all the New Shiny makes me wonder if it's worth the effort, or if I should be doing more interesting stuff like creating new content for the site instead.
[1] - https://scrawl-v8.rikweb.org.uk/
Is there some mysterious force of nature that binds front-end frameworks to bad decision making?
Maybe you don’t need that. Seems like a bunch of the Svelte community did. I wouldn’t frame that as a bad decision.
Furthermore <slot /> had limitations in terms of children which made it difficult to build UI libraries.
Svelte 5 now is actually simpler to learn for new comers despite higher verbosity.
I love it!
(edit) Sorry, for previous users the preview site might be better: https://svelte-5-preview.vercel.app/docs/introduction
Any idea of when the new tutorial will be complete? I might go back and refresh some stuff.
I got out of front end development for most of the years Angular and React have dominated and it looked like a mess, but Svelte and even Astro make sense, maybe I’m just old school. I would totally go back to the frontend with these new frameworks.
For a framework to eat into React's usage, it needs a strong evangelist (like Facebook has been for React)
Vue gets unfairly overlooked imo. I worked with it for 12 months and it was mostly a joy
They reverted from the `on` syntax while adding in signals like Vue's `ref`. The way the props pass down is more akin to React than Vue, but the overall reactivity system feels the same as Vue.
I'm not sure I'd pick it over either Vue or React.
Svelt, Vue3 or hell...Angular, and it's off to the races. I just need to know how to accomplish all the things being demanded by Product.
I made my first website a few months ago (I'm an ML engineer). I tried in both Svelte and React.
I used Sonnet as a copilot the whole time and expected Svelte to be more difficult because there are orders of magnitude less training data on it.
To the contrary! The LLM tied itself in knots very quickly with React but mostly did ok with Svelte/Sveltekit. Also, the Svelte stuff it makes is usually snappier. However it does have a wider range of UI widgets it can grasp with React.
It seems that my opinion that React is horrendously and hideously overcomplicated is at least somewhat objective! Svelte has been quite pleasant.
To any devs out there that have to work with React, you have my sympathies. Compared to Svelte it's just flaming hot putrid garbage.
Now granted I’d never use a reducer, and imo a decent state library is the biggest win if you are using React.
Every time I try out something other than React (Vue, Svelte, etc), I have to learn some new syntax, understand the runtime magic, and add a syntax/LSP to my editor. But React is just JS/TS, which is straightforward.
Being disappointed by a library/framework because your LLM of choice can't produce decent code doesn't really tell me very much about the library, other than it's usage is varied.
The syntax is maybe the only good part of react. And I still think the way it uses JSX is not great. Conditionals and .map seem... weird.
But yes, judged from syntax only, react is ok.
> Svelte 5's reactivity is powered by signals, which are essentially what Knockout was doing in 2010. More recently, signals have been popularised by Solid and adopted by a multitude of other frameworks.
> We're doing things a bit differently though. In Svelte 5, signals are an under-the-hood implementation detail rather than something you interact with directly.
My only gripe is it doesn't support <template> tags or class list arrays out the box, meaning I've had to use preprocessors instead, the latter for me makes it far nicer to mentally visualise components when using dynamic tailwind classes.