Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Svelte’s characteristics that likely contribute most to improved performance

chuniversiteit.nl

Post reply on HN
Print view View original

171–180 of 205 posts

Re: Svelte’s characteristics that likely contribute most to improved performance

#171

Post by b_e_n_t_o_n »

array_key_first wrote: post #160
byearthithatius wrote: post #135

Earlier quoted context omitted.

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 l…

SSR can be a tactic to avoid complexity. Basically, let's not duplication state on the frontend and then create synchronization. Just say the backend owns it.

Yeah, but when it's used in conjunction with js frameworks it ends up being more complicated than pure SPA or SSR.

Re: Svelte’s characteristics that likely contribute most to improved performance

#172

Post by asa400 »

b_e_n_t_o_n wrote: post #166
asa400 wrote: post #150

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. Would love to hear other perspectives, though!

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 b…

Thanks for the detailed response.

Re: Svelte’s characteristics that likely contribute most to improved performance

#173

Post by b_e_n_t_o_n »

byearthithatius wrote: post #158
kaoD wrote: post #82

Earlier quoted context omitted.

Just to clarify: despite its name, React has no reactivity engine at all and re-renders unconditionally on any state changes or parent re-renders. You have to opt-in to prop-diffing conditional re-renders (which I wouldn't call a "reactivity engine" either) per component, via React.memo. And then you also have to opt-in to prop memoization for non-primitives for the prop-diffing not to be useless. These re-renders mi…

I am probably just misguided but multiple things you say you "wouldn't call a reactivity engine" only exist to support updating DOM (reactivity) efficiently. So what would you call them? They only exist to update the DOM, which is itself the reactivity we all want. Technically you could just getElementById and update it, but react has what I call a whole "reactivity engine" to do it for you.

It might be more useful to think of React as having a very simple reactivity system. In essence it just compares state values by referential equality (===) and if they're different, rerenders the component. And that includes children. In order to optimise, you need to both maintain referential equality of objects across renders (i.e. don't recreate them each render) and then tell React to compare the props passed into components by said referential equality before rendering.

Whereas other frameworks have a full blown reactivity system with signals (basically implicit observables), so your state values are not just regular javascript objects but either proxies or some other object which can be tracked by access in components to update things granularly, eg. setting an elements innerText but automatically.

Re: Svelte’s characteristics that likely contribute most to improved performance

#174

Post by b_e_n_t_o_n »

asa400 wrote: post #172
b_e_n_t_o_n wrote: post #166

Earlier quoted context omitted.

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 b…

Thanks for the detailed response.

Thanks for letting me nerd out a bit

Re: Svelte’s characteristics that likely contribute most to improved performance

#175

Post by katabasis »

byearthithatius wrote: post #26
SeanAnderson wrote: post #4

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.

I think Vue.js has done a great job of avoiding a lot of the churn while staying competitive with other projects in terms of features and performance.

The core library of React seems well managed, but the accompanying ecosystem of 3rd-party tools for styling, routing, state management, etc seem to be constantly changing.

Meanwhile in Vue land, the critical packages have remained fairly stable and are all maintained by the core team. You get support for styling and transitions out of the box; for most other things (routing, state management, etc) there is one well-maintained library (as opposed to a bunch of options of varying quality that you need to sift through).

I've been using Vue.js for 10 years at this point, and have been using the composition API for the last 5. The older options API is still viable as well.

Re: Svelte’s characteristics that likely contribute most to improved performance

#176

Post by cap11235 »

piskov wrote: post #117
stanac wrote: post #80

Earlier quoted context omitted.

> God I wish something like Silverlight returned in a way that is mobile battery friendly. Not exactly the same, but there is Blazor, it is using html instead of xaml. Also there are third party solutions (I have no experience with) like Uno and Avalonia, both are xaml-based. > mobile battery friendly Do you have some specific framework in mind that is not battery friendly? Probably anything is built on js/wasm isn't…

Battery and mobile performance is what killed flash and silverlight as an aftermath in the first place. See “Thoughts on Flash” by Steve Jobs https://web.archive.org/web/20170615060422/https://www.apple... — As for Blazor, we ain’t fools to rewrite the RIA app the fourth time. I just wish these “innovation” MF stopped reinventing the wheel. The code from 2008 was perfectly fine and should have worked in 2025 if all t…

I feel like flash could have been adapted to low battery quite easily (it isn't like JS has some super smart concurrency; it is literally the basic common denominator unless you are using a Z80). Rather, Macromedia was in the toilet, then purchased, and Youtube (and Vimeo and others) started to be useful, making a more appealing platform (and probably the first other than newgrounds) for animation. Having someone else host media was a big +++

Re: Svelte’s characteristics that likely contribute most to improved performance

#177

Post by digianarchist »

roblh wrote: post #162
sensanaty wrote: post #152

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 i…

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 wo…

I don't understand why frameworks that offer file based routing don't provide a way to define routes using either a configuration file or some library calls.

Re: Svelte’s characteristics that likely contribute most to improved performance

#178

Post by gitaarik »

codegeek wrote: post #15

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.

Svelte is pretty established and proven. But not as known as React / Vue / Angular

Re: Svelte’s characteristics that likely contribute most to improved performance

#179

Post by gitaarik »

dwaltrip wrote: post #67

So what’s the deal with svelte runes and maybe causing people to switch off of it?

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.

Re: Svelte’s characteristics that likely contribute most to improved performance

#180

Post by nwienert »

switz wrote: post #134
jchmbrln wrote: post #123

Earlier quoted context omitted.

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…

Except RSC doesn't solve for apps, it solves for websites, which means its server-first model leads you to slow feeling websites, or lots of glue code to compensate. That alongside the immensely complex restrictions leaves me wondering why it exists or has any traction, other than a sort of technical exercise and new thing for people to play with.

Meanwhile, sync engines seem to actually solve these problems - the distributed data syncing and the client-side needs like optimistic updates, while also letting you avoid the complexity. And, you can keep your server-first rendering.

To me it's a choice between lose-lose (complex, worse UX) and win-win (simpler, better UX) and the only reason I think anyone really likes RSC is because there is so much money behind it, and so little relatively in sync engines. That said, I don't blame people for not even mentioning them as they are newer. I've been working with one for the last year and it's an absolute delight, and probably the first genuine leap forward in frontend dev in the last decade, since React.

Post reply on HN