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

41–50 of 205 posts

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

#41

Post by victorbjorklund »

icemelt8 wrote: post #29
byearthithatius wrote: post #21

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…

ReactJS is pretty consistent since last 5 years and probably won't be changing for next 5 years.

Nobody uses plain reactjs anymore.

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

#42

Post by weinzierl »

cheema33 wrote: post #31
andrewmcwatters wrote: post #13

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, w…

"For example, try building Google Docs without a frontend library. You will struggle [..]"

Except that Google Docs is not built with a framework. At least not a generic one and being generic is kind of the hallmark of framework.

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

#43

Post by smj-edison »

herrkanin wrote: post #12

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

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.

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

#44

Post by andrewmcwatters »

cheema33 wrote: post #31
andrewmcwatters wrote: post #13

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, w…

We build large apps at my company without this and it reduces our dependency management overhead.

Most software doesn't require large teams, ones with large enough structure to utilize cross-functional teams are siloed enough that it also still doesn't matter and the most standardization that's effectively useful is the company's specific UI library for their corporate branding.

At that point you're really using the company's library, and less of the underlying framework anyway. Uber, AAA, American Express, etc. All of them do basically this.

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

#45

Post by thedelanyo »

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.

About 90% of stuffs, svelte's ecosystem is the same as the whole js ecosystem.

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

#46

Post by thousand_nights »

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.

React has been pretty stable for many years now and is almost ubiquitous.

Also, I'm not a huge fan of synthetic benchmarks like in the article such as "render a static list of 25000 elements". This never happens in the real world, you would use some implementation of a virtual list instead.

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

#47

Post by SeanAnderson »

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.

Short answer: no.

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.

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

#48

Post by Ameo »

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.

[1] https://svelte.carbondesignsystem.com/

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

#49

Post by Menu_Overview »

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.

Yea, the version of Angular is from 2020. I don't think there is much to be gleamed from this study.

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

#50

Post by pmarreck »

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)

Post reply on HN