The fact this is already outdated by more recent Svelte releases which changed things drastically is exactly my problem with the modern JS space. So fast moving and most of it is still doing JQuery like reactivity.
I am probably just not smart enough to get it, but it reminds me of the constant seemingly pointless rewrites I see in companies. Figure out what works and keep it, is that so hard? Why can other languages do that. Is this just the nature of web dev?
The reason the web changes so fast, and there are so many rewrites, is the same reason a puzzle whose pieces don't fit together keeps getting shifted around and restarted.
People are looking for a satisfying non-leaky abstraction to build upon and they don't find it with web technologies. They get close, but those last few pieces never quite fit, and we lack the power to reshape the pieces, so we tear out all the pieces and try again. Maybe this next time we'll find a better way to fit them together.
Svelte was pretty much stable between 2019-2024, of all the frameworks it probably changed the least. It's only with the recently released Svelte 5 version that things changed a bit.
You have a point but you're giving Svelte unfair criticism here.
> Figure out what works and keep it, is that so hard?
Well, short answer is that it's been in the "figure out what works" phase for many years now. The developer experience has improved a lot over the years, but it's at the expense of constant breaking changes and dependency hell if you want to upgrade existing code.
The core technology behind Svelte remains the same, and the performance results are still valid. There is no code or feature comparison happening here, so I don't see how this is relevant to the article. Before Svelte 5, it has been by far the most stable framework of the big four.
If you write your stuff in a web framework, the rewrites aren't pointless. Well, they are, of course, but you can't really avoid them, because the old stuff stops getting updates within a year, so you either rewrite or can't update the framework, security updates included.
Made me just give up on web development.
I think React has an at least somewhat reasonable track record in terms of backwards compatibility? Still not perfect but much better than all the other frameworks.
Speed of development and community support is a much better experience in the web space which I think coincides with why there's enough free time and resources around to generate "n new JS frameworks a week". compose and swiftUI, for instance, emerged with component based architecture patterns much later than what was already considered standard in modern web dev.
Tbf, the versions used in this are all roughly 5 yrs old.
And svelte was pretty new at that time, hence it would make sense that it was figuring stuff out, I think.
Though angular has gone through multiple concepts during this time between version 11 (as used in this article) and the current 20 - and especially signals and zoneless would have also massively impacted performance.
> Figure out what works and keep it, is that so hard?
Yes, very. Perfect design upfront can eliminate the need to change it later, but you never get it perfect, so you continue to "figure it out" for many years with many failed attempts in the process.
My VanillaTS project has been working well for the last six years. The most painful part was when I moved everything to esbuild w/ async imports (and ES2017 modules) but now I don't even think about it. npm audit gets kinda mad though.
Yeah they all do exactly the same thing just packaged differently. All of web dev was essentially a solved problem probably as far as a decade or two back.
Svelte is definitely still my favorite way to build web apps in 2025.
I wasn't (and still am not) the biggest fan of the new Runes syntax, but I've gotten used to it, and it doesn't really hurt my productivity or get in my way that much.
There's definitely an ecosystem gap compared to React, but there are still lots of really good components and frameworks out there. For example, there's a native Svelte version of IBM's Carbon Design[1] which I've used and found to be very high-quality.
And as for arguments that React will keep winning due to LLMs not having enough corpus to learn less-popular frameworks, I've anecdotally had good success with using LLMs to edit and generate Svelte code. There are occasionally some issues (like it generating pre-runes syntax or using deprecated stuff like stores) but it works well enough to be useful, and definitely better than I expected.
You might be happy to hear that we're releasing a new version of the Svelte Society website to make it easier to find packages and other resources. We're currently migrating data and fixing bugs but if you want to give it a whirl you can find it here https://prod.sveltesociety.dev until we switch it over to the root domain.
It's worth pointing out this article is discussing Svelte 3.x when the current version is Svelte 5.x and has some significant departures from previous versions (i.e. the introduction of runes)
I haven't finished reading the article yet. I am a fan of Svelte, though, and have switched to using it by default for new projects - coming from a React background.
Things change so fast in web dev. Is it so hard to find a pattern that works and stick to it? I think the constant rewrites are honestly _worse_ for dev experience and security. Nobody knows whats standard and docs become outdated so quick a lot of frameworks just have outdated docs or multiple versions that contradict eachother.
> Because WebAssembly modules lack direct access to the DOM, they rely on an additional JavaScript interoperability layer, which can introduce extra overhead.
I still like Svelte, but to me SvelteKit has taken up too much of its mind/devshare. Svelte itself is fantastic, especially as a Vue guy I love the "new" reactivity system/runes, but SvelteKit for me is horrible. It's just a hodgepodge of over engineered crap to cater to React/Next devs, and the Svelte team has also been hell bent on horrible decisions like the abomination that is routing[1] in SvelteKit.
To me Kit is the antithesis of what made Svelte so attractive to me originally. Svelte was dead simple and intuitive to use, Kit is anything but.
The router is really baffling, agreed. Magic file names make me so frustrated, and even more so when they all start with the same prefix so all my editor tabs look the same. I wish they’d just make a simple single file router that works the same as every other one. There are a lot of things that aren’t perfect in Vue, which I primarily work on, but the router isn’t one of the things that bothers me. It mostly just works.
I love Svelte. When I first used it, it was like using a framework for the first time: Wow, everything is namespaced to the component, even CSS! Wow, just putting $ in front makes it update automatically! etc, etc
Somethings have definitely changed but I've accepted that maybe this is what is best needed for having some fewer amount of bugs/headaches about software while making it more performant and I sort of trust the svelte team in whatever version they lead us to!
Afterall, what is fun in webdev if not for creating factions and I am part of the lovely sveltelandia! Proud to be a member of it and I have full trust on the team.
Many .net devs knowing c# in the enterprise. The same way that got angularjs and later vue popular — typescript + mvvm pattern more closely resemble normal c# code
Svelte version 3 used to statically analyze at compile time which things could change which things and it would build a "direct" reactivity system from that. So kinda both compile time and runtime.
But Svelte 5 changed to use a signals based approach just like Vue and Solidjs, which is runtime based and more flexible. Svelte chose to add some compile time syntax sprinkles on top that they call "runes", because they like a simpler syntax. But signals are fundamentally a runtime concept.
I was struggling with this too - maybe it means that at compile time, it just flags those nodes in the tree that might become dirty due to state changes, and ignores the rest.
Did Svelte gain the adoption like React and Vue ? I am not sure how mature the ecosystem is. I am always wary of using things in production that have not gained significant adoption.
It shares a space with React and Vue in terms of positive opinions. Opinions are worse since v5 due to the perceived increase in complexity of using the Runes system.
It is the fourth most used JS framework behind React, Vue, and Angular.
At least anecdotally I see job listings mostly for React, with some for Vue and Angular, with almost no Svelte. I think I did see one company mention Svelte, so at least someone is building on it, but to a much lesser degree than any of the major players.
From what I recall, they nuked the ergonomics/what made Svelte great with the runes api (Svelte 4?) and most people begrudgingly switched over to React, because, why not at that point.
Serious question: is rendering throughput as much of an issue today as it used to be?
I feel like CPUs have gotten a ton faster while bundle sizes have gotten larger and mobile networks still have a ton of latency, so network matters more in the scheme of things.
Hmmm, it's kind of complicated. A lot of the innovation in JS frameworks has been at the meta framework level, because the client-side framework itself can't really control how data is loaded or how the app is bundled. A lot of work has been done to begin data fetching as quickly and in parallel as possible, like you said because network latency is a big factor for performance. And there is a focus on bringing down bundle sizes. I think Svelte 5 is only a few kb, same with Solid.js. The meta frameworks bring some added weight because they contain the routing and data loading logic.
But especially on mobile, rendering throughput as you put it is still relevant. Especially in response to interactions which cause significant changes to the UI. The "issue" with React is that it's all done at runtime, which does bring significant benefits but loses out on opportunities to optimise things which is what stuff like Solid, Svelte, and Vue's in-development Vapor mode take advantage of via static analysis. The benefit is performance, but you lose out on the dynamic nature of React. That is a tradeoff you need to choose when picking a framework.
Solid and Svelte are so close to vanilla JS levels of performance that you start thinking about how to optimise as if you were directly manipulating the DOM itself. Which is cool, in comparison with React you end up trying to optimise for React instead of the DOM. You still need virtualisation in a lot of cases regardless if you use React or Svelte.
I think the bigger attraction with Svelte and Solid, as well as Vue et al. is the signals / reactivity aspect. You can still tie yourself up in issues with that but it's a better mental model for a lot of developers compared to the pseudo-pure functional approach React takes. React's model can be a pain when you do need to escape-hatch to the dom itself, like you often do with complex animations, or interactions like drag-and-drop. If you can stick to pure React it can often be pretty clean.
React's compiler is designed to minimise redundant rerenders and object instantiation. It seems to help if you look at benchmarks. Still not nearly as quick as the static analysis approach because it doesn't change the underlying semantics (it's just doing stuff you would otherwise do manually for the most part).
So I would say it's still an issue, but so is latency and bundle sizes and that's also seen a lot of innovation and improvements.
It's just a new way of using reactive vars, which you have to get used to a bit, and which people that don't like change are annoyed about. But it's ultimately a more consistent and flexible way which actually makes a lot of sense once you're used to it.
It's that fast because it uses a declarative model and this ends up being very efficient for a variety of use-cases
(I say this speaking from a NixOS laptop; Nix operations are invariably much faster than alternatives, like Docker, assuming you have the technical chops to get them to work)
React also uses a declarative model, in fact React might be more declarative because it's still declarative at runtime, whereas Svelte et al. do a lot of static analysis to turn declarative UI into imperative targeted dom updates.
I grew tired of Svelte after it introduced too much "magic". Svelte used to be simple, now it's Vue that feels simple (and yet powerful), and Vue has a much bigger ecosystem in terms of plugins, etc.
What magic does Svelte have that Vue doesn't have? I like both - they seem so very comparable to me. Only fundamental differences I see are matters of syntax, which are very much a matter of taste.
The article is a bit old but I don't think that it was AI, like, no offense but like before AI mania no one would have ever thought that calling blazor js framework would've discredited everything the author wrote by three words
Is this AI?
Fun fact just asked chatgpt, and even chatgpt says that blazor is not js framework, so the fact that author did say makes it prove that it was just a mistake and not some AI thing but you can't always be sure of these things
It said to my question, is blazor a js framework?
Good question — no, Blazor is not a JavaScript framework.
Here’s a clear breakdown
What Blazor Actually Is
Blazor is a .NET-based web framework created by Microsoft that lets you build client-side and server-side web apps using C# and Razor, instead of JavaScript.
It runs on top of .NET runtime — not on a JavaScript engine like React, Angular, or Vue do.
Offtopic but why is my chatgpt being so sycophantic, I thought that they had reverted out the update which was causing the sycophancy but I am tired of this dumb LLM praising me, I am starting to dread the first sentence of chatgpt because of it saying good point or anything bruh.
I'm on a project now that requires using Svelte in an enterprise setting. I've used all the big 3 (Angular, React, Vue) and then some (Ember, AngularJS) and I can say without a doubt, Svelte is my least favorite of them all by far. To say it has encouraged designing an unreadable mess in the code-base is an understatement. It seems to have taken the worst aspects of the big 3 and ran with it. I'm utterly confused why people enjoy this wild west hodgepodge of framework mistakes. I'd argue the improved speed is not worth sacrificing readability and lower cognitive load. This is designed for tinkerers and hobbyists. I say this with confidence of nearly 20 years experience building enterprise web applications (including in FAANG): Svelte is another fad library that has no place in a professional setting.
I have long time experience building huge web applications in both Angular, React, and Svelte, and my experience exactly the opposite. Anecdote meet anecdote. You really have to be more specific.
lol, I love this take! I honestly have never used Svelt but you hear so much fanboi love for it I assumed it actually was awesome! If Svelt is a hipster scam, that would be hilarious. Anyone else able to corroborate or refute this claim?
I personally like React with just React Router 7 in framework mode (Remix). So simple, so intuitive, just works, paper thing abstractions over stuff everyone already knows how to do. (Next.js OTOH I do not love)
Every Svelte enthusiast I have spoken to tends to lean towards the esoteric Elm and other such technologies.
They don’t really understand that software isn’t about “my framework can render 1000 elements 500ms faster” but rather my organization of hundreds or thousands of front end engineers (mix of employees and contractors both of whom usually don’t give a fuck) across the WORLD need to be able to work together on a significant product and ship constantly without breaking things.
And customers don’t give a fuck otherwise they wouldn’t be paying six figures or more for literally shit software.
That said I have tried it a couple times over the years. Not sure I like the latest direction they’ve gone though.
As someone who has been doing frontend dev since "AJAX" was the hot new stuff...
I am deeply, deeply disappointed in the field. It simultaneously has an extremely high rate of churn and an extremely low rate of actual innovation.
After observing the discipline for nearly two decades, I am concluding that almost all the "progress" really starts to look like we're just rearranging the furniture endlessly without substantive improvements in developer velocity or end user experience.
Any given "progress" looks reasonable for a moment but is ultimately circular. We've been playing rock/paper/scissors with "better" techniques for a long time now.
Things have been stable for a while now. We haven't had actual churn in years.
But given that there has not actually been progress either, my guess is that this is a temporary situation.
Either way, Svelte is one of those things that promise some real progress. Not one of the things that have the same amount of problems, but in a different configuration.
It is not that popular anymore, tho. At least there is no hype, it is just a bureaucratic soulless tool used by many. The posts about the new React Foundation have almost no engagement here in HN. 5 years ago it would be a huge discussion. Now nobody cares.
I'm no longer a fan of using any front-end libraries at all en lieu of just using standard event listeners and web components, but in their defense, by the time that you're creating or updating that many elements, most developers are backing out of the framework anyway.
It's the primary reason virtual table libraries exist.
> I'm no longer a fan of using any front-end libraries at all en lieu of just using standard event listeners and web components
You can get away without using frontend frameworks for small and simple projects. However, for large and complex projects you will struggle. For example, try building Google Docs without a frontend library. You will struggle even if you have an army of developers at your disposal. In fact, with a larger team, a library/framework helps standardize things.
I'm so sick of these performance benchmarks. I understand it's easy to spin them up to show that one framework is faster than another, but in general all these frameworks are fast enough for 99.9% of use cases.
Where frameworks lack today, in my opinion, are in providing the right tools further optimize the UX of interacting with web sites. It's a constant struggle of loading spinners and flicker and loss of scroll positions.
The only framework I see that actually tries to resolve these very hard problems is React, through their work on new asynchronous primitives like startTransition. Yes, they are currently hard to understand how to properly use, but I so wish the discourse would be around how to best resolve these actual UX issues than who can create 50M divs the fastest.
IMO, we desperately need standards or tooling to make frameworks easier to swap out and interoperate. Web Components was supposed to be this, but it's not quite there yet and requires awkward wrappers around everything.
No framework will stand the test of time. I encourage everyone to, at the very least, own your state and router libraries, as you'll be able to extend them when you want to jump ship in a more incremental fashion. Going all in on a single framework's state, router, and view libraries will create a ton of inertia...
To me the only framework that has really pulled this off is Phoenix live view and spinoffs, because they solve the fundamental problem: pipelined latency. The frontend has to request object A, wait for the result, then it has to request object B, then wait, etc, etc. There's too many combinations of objects, so it would be impossible to have an endpoint per specific request (I suppose graphql has sort of done this, but it's still not flexible enough for complicated transforms). Live view solves this problem by not really solving the problem, but moving everything server-side so pipelined latency is dramatically lower.
Yeah I agree, these benchmarks are basically meaningless. E.g. they acclaim Vue's binding based approach as being faster, but it also leads to spaghetti code. React was specifically designed to avoid that so you can build big apps that aren't buggy.
Also isn't Preact meant to be a faster option if you really need performance?
> I'm so sick of these performance benchmarks. I understand it's easy to spin them up to show that one framework is faster than another, but in general all these frameworks are fast enough for 99.9% of use cases.
Yes, any framework is fast enough. At this point, everybody probably knows already. Nobody would ever say React is not appropriate because it's slower than Svelte. No sane person would ever argue for a migration from React to Svelte based on this benchmark.
But being against the performance benchmark is such a weird take. It's so strange that many times there are hidden agendas.
Many times because a person advocates for X over Y at Company Z. Then, there's some random benchmark saying Y is faster. Now the person needs some way to cope. The best way is to refute the benchmark in some ways, but this would take a huge amount of time and effort. The second best way is to simply say "it doesn't matter. I hate this useless benchmark. There are more important problems to solve!"... as if everyone on the planet has to always solve the most important problem first ... only one problem and no more. Haha
Most of that latency is coming from back ends across most major sites, anyway, so it's the wrong place to test.
As an addition to the general commentary here, "The Toilet Paper" is an unfortunate choice of label for this article, and maybe also indicative of the quality of the writing.
byearthithatius|4 months ago
I am probably just not smart enough to get it, but it reminds me of the constant seemingly pointless rewrites I see in companies. Figure out what works and keep it, is that so hard? Why can other languages do that. Is this just the nature of web dev?
Buttons840|4 months ago
People are looking for a satisfying non-leaky abstraction to build upon and they don't find it with web technologies. They get close, but those last few pieces never quite fit, and we lack the power to reshape the pieces, so we tear out all the pieces and try again. Maybe this next time we'll find a better way to fit them together.
kevinak|4 months ago
You have a point but you're giving Svelte unfair criticism here.
pverheggen|4 months ago
Well, short answer is that it's been in the "figure out what works" phase for many years now. The developer experience has improved a lot over the years, but it's at the expense of constant breaking changes and dependency hell if you want to upgrade existing code.
icemelt8|4 months ago
andai|4 months ago
ricardobeat|4 months ago
tgsovlerkhgsel|4 months ago
Made me just give up on web development.
I think React has an at least somewhat reasonable track record in terms of backwards compatibility? Still not perfect but much better than all the other frameworks.
wahlr|4 months ago
ffsm8|4 months ago
And svelte was pretty new at that time, hence it would make sense that it was figuring stuff out, I think.
Though angular has gone through multiple concepts during this time between version 11 (as used in this article) and the current 20 - and especially signals and zoneless would have also massively impacted performance.
eviks|4 months ago
Yes, very. Perfect design upfront can eliminate the need to change it later, but you never get it perfect, so you continue to "figure it out" for many years with many failed attempts in the process.
sehugg|4 months ago
dyauspitr|4 months ago
dmix|4 months ago
Vue 3.4 (2023) rewrote their template rendering engine to be 2x as fast as well.
Ameo|4 months ago
I wasn't (and still am not) the biggest fan of the new Runes syntax, but I've gotten used to it, and it doesn't really hurt my productivity or get in my way that much.
There's definitely an ecosystem gap compared to React, but there are still lots of really good components and frameworks out there. For example, there's a native Svelte version of IBM's Carbon Design[1] which I've used and found to be very high-quality.
And as for arguments that React will keep winning due to LLMs not having enough corpus to learn less-popular frameworks, I've anecdotally had good success with using LLMs to edit and generate Svelte code. There are occasionally some issues (like it generating pre-runes syntax or using deprecated stuff like stores) but it works well enough to be useful, and definitely better than I expected.
[1] https://svelte.carbondesignsystem.com/
SeanAnderson|4 months ago
Making my LLM aware of these documents significantly mitigated issues I had with adopting Svelte 5 syntax.
kevinak|4 months ago
SeanAnderson|4 months ago
I haven't finished reading the article yet. I am a fan of Svelte, though, and have switched to using it by default for new projects - coming from a React background.
byearthithatius|4 months ago
Menu_Overview|4 months ago
Evan-Almloff|4 months ago
Blazor is slow for other reasons. You can make wasm web frameworks fast (see leptos and dioxus). It can be as fast as vanilla js. Sledgehammer on this benchmark is wasm: https://krausest.github.io/js-framework-benchmark/2023/table...
sensanaty|4 months ago
To me Kit is the antithesis of what made Svelte so attractive to me originally. Svelte was dead simple and intuitive to use, Kit is anything but.
[1] https://svelte.dev/docs/kit/routing
roblh|4 months ago
pitaj|4 months ago
Imustaskforhelp|4 months ago
Afterall, what is fun in webdev if not for creating factions and I am part of the lovely sveltelandia! Proud to be a member of it and I have full trust on the team.
pier25|4 months ago
Also the article is commenting on this other article from 2022 which is severely outdated by now.
https://journals.riverpublishers.com/index.php/JWE/article/v...
piskov|4 months ago
nixpulvis|4 months ago
> This requires the framework to track which components are dirty. Vue does this at runtime, Svelte handles it at compile time.
How can it possibly track this at compile time? Best I could see if tracking where those bits could be set, but not actually setting them.
Sammi|4 months ago
But Svelte 5 changed to use a signals based approach just like Vue and Solidjs, which is runtime based and more flexible. Svelte chose to add some compile time syntax sprinkles on top that they call "runes", because they like a simpler syntax. But signals are fundamentally a runtime concept.
duderific|4 months ago
codegeek|4 months ago
SeanAnderson|4 months ago
Long answer: https://2024.stateofjs.com/en-US/libraries/#tools_arrows
It shares a space with React and Vue in terms of positive opinions. Opinions are worse since v5 due to the perceived increase in complexity of using the Runes system.
It is the fourth most used JS framework behind React, Vue, and Angular.
Hamuko|4 months ago
gitaarik|4 months ago
thedelanyo|4 months ago
some_guy_nobel|4 months ago
ChrisArchitect|4 months ago
(2022 paper https://helda.helsinki.fi/server/api/core/bitstreams/a301a02...)
Sammi|4 months ago
maz1b|4 months ago
EMM_386|4 months ago
Angular has OnPush change detection strategy and can even be free of zone.js now, so this isn't necessarily true.
asa400|4 months ago
I feel like CPUs have gotten a ton faster while bundle sizes have gotten larger and mobile networks still have a ton of latency, so network matters more in the scheme of things.
Would love to hear other perspectives, though!
b_e_n_t_o_n|4 months ago
But especially on mobile, rendering throughput as you put it is still relevant. Especially in response to interactions which cause significant changes to the UI. The "issue" with React is that it's all done at runtime, which does bring significant benefits but loses out on opportunities to optimise things which is what stuff like Solid, Svelte, and Vue's in-development Vapor mode take advantage of via static analysis. The benefit is performance, but you lose out on the dynamic nature of React. That is a tradeoff you need to choose when picking a framework.
Solid and Svelte are so close to vanilla JS levels of performance that you start thinking about how to optimise as if you were directly manipulating the DOM itself. Which is cool, in comparison with React you end up trying to optimise for React instead of the DOM. You still need virtualisation in a lot of cases regardless if you use React or Svelte.
I think the bigger attraction with Svelte and Solid, as well as Vue et al. is the signals / reactivity aspect. You can still tie yourself up in issues with that but it's a better mental model for a lot of developers compared to the pseudo-pure functional approach React takes. React's model can be a pain when you do need to escape-hatch to the dom itself, like you often do with complex animations, or interactions like drag-and-drop. If you can stick to pure React it can often be pretty clean.
React's compiler is designed to minimise redundant rerenders and object instantiation. It seems to help if you look at benchmarks. Still not nearly as quick as the static analysis approach because it doesn't change the underlying semantics (it's just doing stuff you would otherwise do manually for the most part).
So I would say it's still an issue, but so is latency and bundle sizes and that's also seen a lot of innovation and improvements.
iammrpayments|4 months ago
wartijn_|4 months ago
SeanAnderson|4 months ago
PKop|4 months ago
dwaltrip|4 months ago
gitaarik|4 months ago
pmarreck|4 months ago
(I say this speaking from a NixOS laptop; Nix operations are invariably much faster than alternatives, like Docker, assuming you have the technical chops to get them to work)
b_e_n_t_o_n|4 months ago
kode95|4 months ago
Sammi|4 months ago
unknown|4 months ago
[deleted]
clickety_clack|4 months ago
nasso_dev|4 months ago
billrobertson42|4 months ago
b_e_n_t_o_n|4 months ago
EugeneOZ|4 months ago
b_e_n_t_o_n|4 months ago
Also no Solid.js?
Imustaskforhelp|4 months ago
Is this AI?
Fun fact just asked chatgpt, and even chatgpt says that blazor is not js framework, so the fact that author did say makes it prove that it was just a mistake and not some AI thing but you can't always be sure of these things
It said to my question, is blazor a js framework?
Good question — no, Blazor is not a JavaScript framework.
Here’s a clear breakdown
What Blazor Actually Is
Blazor is a .NET-based web framework created by Microsoft that lets you build client-side and server-side web apps using C# and Razor, instead of JavaScript.
It runs on top of .NET runtime — not on a JavaScript engine like React, Angular, or Vue do.
Pasting the link to it here https://chatgpt.com/c/68e6d1ed-9030-8322-82fa-84267f8d20c5
Offtopic but why is my chatgpt being so sycophantic, I thought that they had reverted out the update which was causing the sycophancy but I am tired of this dumb LLM praising me, I am starting to dread the first sentence of chatgpt because of it saying good point or anything bruh.
y-c-o-m-b|4 months ago
barnabee|4 months ago
The web is supposed to be made by tinkerers and hobbyists.
Sammi|4 months ago
SeanAnderson|4 months ago
eagsalazar2|4 months ago
I personally like React with just React Router 7 in framework mode (Remix). So simple, so intuitive, just works, paper thing abstractions over stuff everyone already knows how to do. (Next.js OTOH I do not love)
moomoo11|4 months ago
They don’t really understand that software isn’t about “my framework can render 1000 elements 500ms faster” but rather my organization of hundreds or thousands of front end engineers (mix of employees and contractors both of whom usually don’t give a fuck) across the WORLD need to be able to work together on a significant product and ship constantly without breaking things.
And customers don’t give a fuck otherwise they wouldn’t be paying six figures or more for literally shit software.
That said I have tried it a couple times over the years. Not sure I like the latest direction they’ve gone though.
dzonga|4 months ago
if they had stayed on their origin basis of making web apps fast with interop n ease of use the you wouldn't have the rune nonsense.
lukev|4 months ago
I am deeply, deeply disappointed in the field. It simultaneously has an extremely high rate of churn and an extremely low rate of actual innovation.
After observing the discipline for nearly two decades, I am concluding that almost all the "progress" really starts to look like we're just rearranging the furniture endlessly without substantive improvements in developer velocity or end user experience.
Any given "progress" looks reasonable for a moment but is ultimately circular. We've been playing rock/paper/scissors with "better" techniques for a long time now.
marcosdumay|4 months ago
But given that there has not actually been progress either, my guess is that this is a temporary situation.
Either way, Svelte is one of those things that promise some real progress. Not one of the things that have the same amount of problems, but in a different configuration.
leeoniya|4 months ago
timeon|4 months ago
Obligatory: sad state of web where React is so popular.
brazukadev|4 months ago
unknown|4 months ago
[deleted]
andrewmcwatters|4 months ago
It's the primary reason virtual table libraries exist.
cheema33|4 months ago
You can get away without using frontend frameworks for small and simple projects. However, for large and complex projects you will struggle. For example, try building Google Docs without a frontend library. You will struggle even if you have an army of developers at your disposal. In fact, with a larger team, a library/framework helps standardize things.
herrkanin|4 months ago
Where frameworks lack today, in my opinion, are in providing the right tools further optimize the UX of interacting with web sites. It's a constant struggle of loading spinners and flicker and loss of scroll positions.
The only framework I see that actually tries to resolve these very hard problems is React, through their work on new asynchronous primitives like startTransition. Yes, they are currently hard to understand how to properly use, but I so wish the discourse would be around how to best resolve these actual UX issues than who can create 50M divs the fastest.
candiddevmike|4 months ago
No framework will stand the test of time. I encourage everyone to, at the very least, own your state and router libraries, as you'll be able to extend them when you want to jump ship in a more incremental fashion. Going all in on a single framework's state, router, and view libraries will create a ton of inertia...
smj-edison|4 months ago
bpicolo|4 months ago
IshKebab|4 months ago
Also isn't Preact meant to be a faster option if you really need performance?
ergocoder|4 months ago
Yes, any framework is fast enough. At this point, everybody probably knows already. Nobody would ever say React is not appropriate because it's slower than Svelte. No sane person would ever argue for a migration from React to Svelte based on this benchmark.
But being against the performance benchmark is such a weird take. It's so strange that many times there are hidden agendas.
Many times because a person advocates for X over Y at Company Z. Then, there's some random benchmark saying Y is faster. Now the person needs some way to cope. The best way is to refute the benchmark in some ways, but this would take a huge amount of time and effort. The second best way is to simply say "it doesn't matter. I hate this useless benchmark. There are more important problems to solve!"... as if everyone on the planet has to always solve the most important problem first ... only one problem and no more. Haha
andrewmcwatters|4 months ago
As an addition to the general commentary here, "The Toilet Paper" is an unfortunate choice of label for this article, and maybe also indicative of the quality of the writing.