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

71–80 of 205 posts

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

#71

Post by yurishimo »

IshKebab wrote: post #39
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…

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?

Arent buggy? React had to introduce a compiler because the masses only write buggy code. The reason they likely waited so long to do it is because they felt like it was a waste to write software to fix something that theoretically has “no flaws” because it’s “just JavaScript”.

Literally every other JS framework figured this out years and years ago and some over a decade ago. Compilers help to raise the floor for everyone so we don’t need to worry about making a dumb mistake and drastically slowing down our programs. Compilers are the evolution of software.

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

#72

Post by habibur »

byearthithatius wrote: post #33
icemelt8 wrote: post #29

Earlier quoted context omitted.

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

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?

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

#73

Post by Jcampuzano2 »

torben-friis wrote: post #66
byearthithatius wrote: post #33

Earlier 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.

>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 because next.js makes it really easy to screw up your performance doing it.

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

#74

Post by dyauspitr »

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…

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.

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

#75

Post by christophilus »

byearthithatius wrote: post #53
thousand_nights wrote: post #46

Earlier quoted context omitted.

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.

Main React has been pretty stable for a few years but the ecosystem to serve React bundles has not been.

Yes, but it’s gone from a few, slow, clunky build tools. To things like Bun or Vite which are excellent. So, bring on the change, if that’s the kind of change we’re talking about.

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

#76

Post by fruit2020 »

torben-friis wrote: post #66
byearthithatius wrote: post #33

Earlier 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.

>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).

Do people really build SPAs that are just websites and not ‘apps’?

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

#77

Post by Imustaskforhelp »

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.

To be really honest. AI / LLM's can write svelte 5 runes code but Its a really really mixed bag and most of them probably write svelte 4 code

Like, here's the thing, sure it can create the code but LLM's stop so early in things like svelte atleast that's my opinion. I never really learnt react and didn't ever use react with any LLM

fun fact: Chatgpt 3 could write perfectly well sveltekit, that's how I "vibecoded" in the start

Like, sure I would copy paste but deep down I just felt like most of this is just plain html css js and nothing too much to worry about and that soothed me that sure this may be vibe coded but I was a real noob of svelte but the vibe coding was a bit of a successful :p

I have stopped it / atleast reminded myself 100 times to stop it because I want to feel even more confident with svelte and really learn it even more to the point that I can be 100% confident to write complex software in svelte myself and well only using AI for the boilerplate part or the tedious parts I am not sure, there is a lure to ask LLM's more and more and to depend on them more or maybe its just me I am not sure.

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

#78

Post by mi_lk »

SeanAnderson wrote: post #47
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.

not an FE but it seems the only thing stands out from that survey is Vite

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

#80

Post by stanac »

piskov wrote: post #58
byearthithatius wrote: post #26

Earlier quoted context omitted.

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.

My nation-wide C# Silverlight app lasted almost 12 years. And it had grid, animations, what have you in 2010 better than most html5 in 2018. Not to mention tooling. And you know what? No matter the browser, no matter the OS it all worked and rendered the same. Probably Adobe Flash was like that also. First app we rewrote to AngularJS. You know what happened to it. So then we rewrote it to Vue. The same effing app jus…

> 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 friendly.

Post reply on HN