Live data from Hacker News

Svelte’s characteristics that likely contribute most to improved performance

chuniversiteit.nl

21–30 of 205 posts

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

#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 do that. Is this just the nature of web dev?

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

#22

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…

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

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

#24
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.

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

#25

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…

I think it's a combination of boredom and job security.

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

#26

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.

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

#27
post #25

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…

I think it's a combination of boredom and job security.

I agree with that. I'm sure they do find genuine improvements, but they are often just trade-offs.

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

#28

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.

Javascript is not a language that is good for making basic comprehensive abstractions in.

Typescript is not a language that is good for making basic comprehensive abstractions in.

JSX is not a language that is good for making basic comprehensive abstractions in.

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

#29

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.

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

#30

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…

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.

It really isn't - a ui framework should be able to properly handle backend latency and provide a great experience while waiting for a backend response with no flicker while not locking the entire ui. It's just way harder to set up good benchmarks for this.
Post reply on HN