Svelte wasnt fast before 5.x
Svelte’s characteristics that likely contribute most to improved performance
131–140 of 205 posts
Re: Svelte’s characteristics that likely contribute most to improved performance
#132I've never used Svelte before, so maybe I'm misunderstanding what they mean by tracking dirty, but this bit confused me. > 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.
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.
Re: Svelte’s characteristics that likely contribute most to improved performance
#133Earlier quoted context omitted.
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 pie…
This is insightful. I remember thinking after the first generation of SPA frameworks like Backbone and Ember and—somewhat later—AngularJS that maybe the second generation (React, Vue, etc.) would get it all sorted out and we'd arrive at stability and consensus. But that hasn't happened. The next generation was better in some ways, worse in a few, and still not quite right in many others. Of course I hear plenty of pe…
Resolution is in design not engineering. Instead of trying to tireless work around the web as a sort of “broken mobile”, design with its strengths instead.
The difficulty is finding designers who understand web fundamentals.
Re: Svelte’s characteristics that likely contribute most to improved performance
#134Earlier quoted context omitted.
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 pie…
This is insightful. I remember thinking after the first generation of SPA frameworks like Backbone and Ember and—somewhat later—AngularJS that maybe the second generation (React, Vue, etc.) would get it all sorted out and we'd arrive at stability and consensus. But that hasn't happened. The next generation was better in some ways, worse in a few, and still not quite right in many others. Of course I hear plenty of pe…
Frontend web development is effectively distributed systems built on top of markup languages and backwards compatible scripting languages.
We are running code on servers and clients, communicating between the two (crossing the network boundary), while our code often runs on millions of distributed hostile clients that we don't control.
It's inherently complex, and inherently hostile.
From my view, RSC's are the first solution to acknowledge these complexities and redesign the paradigms closer to first principles. That comes with a tougher mental model, because the problem-space is inherently complex. Every prior or parallel solution attempts to paper over that complexity with an over-simplified abstraction.
HTMX (and rails, php, etc.) leans too heavily on the server, client-only-libraries give you no accessibility to the server, and traditional JS SSR frameworks attempt to treat the server as just another client. Astro works because it drives you towards building largely static sites (leaning on build-time and server-side routing aggressively).
RSCs balance most of these incentives, gives you the power to access each of them at build-time and at run-time (at the page level or even the component level!). It makes each environment fully powerful (server, client, and both). And manages to solve streaming (suspense and complex serialization) and diffing (navigating client-side and maintaining state or UI).
But people would rather lean on lazy tropes as if they only exist to sell server-cycles or to further frontend complexity. No! They're just the first solution to accept that complexity and give developers the power to wield them. Long-term, I think people will come to learn their mental model and understand why they exist. As some react core team members have said, this is kind of the way we should have always built websites-once you return to first principles, you end up with something that looks similar to RSCs[0]. I think others will solve these problems with simpler mental models in the future, but it's a damn good start and doesn't deserve the vitriol it gets.
Re: Svelte’s characteristics that likely contribute most to improved performance
#135Earlier quoted context omitted.
But how many use _just_ React now? There is a whole stack that 90% of YC companies use: Node, pnpm, Next, React, doing SSR by default. Idk about it all. Most of the time when I ask why they do SSR they can't tell me a valid reason. Their bundle sizes are so big for what the apps do.
> when I ask why they do SSR What are the reasons for not doing SSR?
Why is it the default for you? You are worrying about hydration complexity and all that when you introduce it, so it better have some benefits.
My default is a small page that client then fetches any additional data it needs. If its long load time skeleton UI it. I also have not seen the SEO benefits at all.
So again _why would I_ unless I needed to do stuff on the server to make the client bundle, which I don't.
A lot of these YC companies doing this could literally just be using a fetch because their backend is dead simple REST.
Re: Svelte’s characteristics that likely contribute most to improved performance
#136What is react doing that appears to make it so much slower? Where does it spend its time?
Re: Svelte’s characteristics that likely contribute most to improved performance
#137Earlier quoted context omitted.
want the whole point of Javascript to use client side manipulation? Is it's come back to SSR, then do we need all the JS baggage?
Its a division of responsibilities thing isnt it? "Proper coders" in python or whatever provide up to an API. Past that its basically the web devs domain and they live in JS land
Agree, that is why I am confused by his question to me. Like SSR should be the default. Why does your server by default "hydrate" the client bundle. Why can't the client bundle request data as it needs it (then we can only request what the user needs). Skeleton UI it while you fetch. Then you have great page load time because you just return a static HTML+JS bundle that was non-conditionally built. In SSR it talks to the DB before it even constructs the bundle, that is oof right? So you are faster because you don't even gen the HTML until you talked to the DB? I give the user plain HTML instantly and talk to the DB while I give them a UI indicating its loading. SSR just moved the load time to before initial render. Stupid IMO.
Re: Svelte’s characteristics that likely contribute most to improved performance
#138Earlier quoted context omitted.
>Most of the time when I ask why they do SSR they can't tell me a valid reason. Isn't it mainly about playing nice with crawlers? SEO and the like? (that was my understanding but I'm a backend dev).
Yes but they obsess over making everything perfectly ssr to the point of both delivering slow and half the time making client side navigations slow as hell after the user is already past the pay walled/marketing material part of your app. Honestly except for the marketing page and blogs and stuff, most apps are fine without server rendering. In fact I'd say many that avoid server rendering actually feel better simply…
Some site have dual pages these days. I guess I should explain… they have a large footprint seo and those pages are static… unless you are logged in, then they are completely different!
I see this happening in finance data sites. Say a page about Apple, has stock price, etc. when logged in, same stuff but 10x data so they layout and everything is different.
Re: Svelte’s characteristics that likely contribute most to improved performance
#139Re: Svelte’s characteristics that likely contribute most to improved performance
#140I've never used Svelte before, so maybe I'm misunderstanding what they mean by tracking dirty, but this bit confused me. > 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.
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.