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

111–120 of 205 posts

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

#111

Post by jslaby »

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…

Silverlight was awesome, too bad Microsoft abandoned it. You think they could've done something with it like decoupling from the browser, instead of making all these different UI frameworks that are fizzling out.

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

#112

Post by pverheggen »

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…

> Figure out what works and keep it, is that so hard?

Well, short answer is that it's been in the "figure out what works" phase for many years now. The developer experience has improved a lot over the years, but it's at the expense of constant breaking changes and dependency hell if you want to upgrade existing code.

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

#113

Post by lukev »

marcosdumay wrote: post #92
lukev wrote: post #89

As someone who has been doing frontend dev since "AJAX" was the hot new stuff... I am deeply, deeply disappointed in the field. It simultaneously has an extremely high rate of churn and an extremely low rate of actual innovation. After observing the discipline for nearly two decades, I am concluding that almost all the "progress" really starts to look like we're just rearranging the furniture endlessly without substa…

Things have been stable for a while now. We haven't had actual churn in years. But given that there has not actually been progress either, my guess is that this is a temporary situation. Either way, Svelte is one of those things that promise some real progress. Not one of the things that have the same amount of problems, but in a different configuration.

I guess you and I define "actual churn" differently.

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

#114

Post by nophunphil »

victorbjorklund wrote: post #41
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.

Nobody uses plain reactjs anymore.

Sure they do. I’ve used it multiple times for new (but small) projects in the last year. It’s straightforward with Vite and works fine.

I’ve also used Next for new projects in the last year - it just depends on the infra requirements.

Vercel’s position in the ecosystem is one we should question. Maybe it’s not good for innovation to use Next for every new project. The recent controversy with their CEO isn’t helping the situation either.

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

#116

Post by ozim »

fruit2020 wrote: post #76
torben-friis wrote: post #66

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

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

Reading comments here, Reddit or other places my guess is lots of people don’t know the difference between just a website and an app. Even ones that seem experienced.

Lots of newcomers are struggling and not understanding what are the options and which approach is best for their case.

Business people don’t help as they rightfully don’t care. But they want „do everything” - „pay once” approach so people bolt on static pages ona apps or other way around.

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

#117

Post by piskov »

stanac wrote: post #80
piskov wrote: post #58

Earlier quoted context omitted.

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 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 these guys stopped making web frameworks like hot cakes. Some of us with an actual job have products that last more than a couple years (15+ in my case)

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

#118

Post by sehugg »

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…

My VanillaTS project has been working well for the last six years. The most painful part was when I moved everything to esbuild w/ async imports (and ES2017 modules) but now I don't even think about it. npm audit gets kinda mad though.

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

#120

Post by YmiYugy »

some_guy_nobel wrote: post #38
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.

From what I recall, they nuked the ergonomics/what made Svelte great with the runes api (Svelte 4?) and most people begrudgingly switched over to React, because, why not at that point.

Runes got introduced with svelte 5 and they address some problems that really bite when your components become complex and just weren’t solvable in the old paradigm. I think svelte is still very ergonomic to use. Having to write $state() when declaring reactive variables is not a big deal and neither is writing $effect instead of $:. I think the real reason the hype has waned a little is a combination of time, LLMs really liking React and generally absorbing any spare attention.
Post reply on HN