Live data from Hacker News

Svelte’s characteristics that likely contribute most to improved performance

chuniversiteit.nl

121–130 of 205 posts

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

#121

I'm on a project now that requires using Svelte in an enterprise setting. I've used all the big 3 (Angular, React, Vue) and then some (Ember, AngularJS) and I can say without a doubt, Svelte is my least favorite of them all by far. To say it has encouraged designing an unreadable mess in the code-base is an understatement. It seems to have taken the worst aspects of the big 3 and ran with it. I'm utterly confused why…

If using Svelte hinders the creation of “enterprise web applications” then it sounds like exactly what we need.

The web is supposed to be made by tinkerers and hobbyists.

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

#122

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…

He also chose a Vue version that came out in 2020.

Vue 3.4 (2023) rewrote their template rendering engine to be 2x as fast as well.

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

#123

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…

The reason the web changes so fast, and there are so many rewrites, is the same reason a puzzle whose pieces don't fit together keeps getting shifted around and restarted. People are looking for a satisfying non-leaky abstraction to build upon and they don't find it with web technologies. They get close, but those last few pieces never quite fit, and we lack the power to reshape the pieces, so we tear out all the pie…

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 people complaining that apps on top of hypertext is a fundamental mistake and so we can't expect it to ever really work, but the way you put it really made it click for me. The problem isn't that we haven't solved the puzzle, it's that the pieces don't actually fit together. Thank you.

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

#124
post #122

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…

He also chose a Vue version that came out in 2020. Vue 3.4 (2023) rewrote their template rendering engine to be 2x as fast as well.

[deleted]

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

#125

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.

This is probably the best answer to my confusion. Not too negative or overly optimistic. We are just still fleshing out how we want to do this and there are a lot of cooks in the kitchen finding various ways to make the same dish.

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

#126

I'm on a project now that requires using Svelte in an enterprise setting. I've used all the big 3 (Angular, React, Vue) and then some (Ember, AngularJS) and I can say without a doubt, Svelte is my least favorite of them all by far. To say it has encouraged designing an unreadable mess in the code-base is an understatement. It seems to have taken the worst aspects of the big 3 and ran with it. I'm utterly confused why…

lol, I love this take! I honestly have never used Svelt but you hear so much fanboi love for it I assumed it actually was awesome! If Svelt is a hipster scam, that would be hilarious. Anyone else able to corroborate or refute this claim? I personally like React with just React Router 7 in framework mode (Remix). So simple, so intuitive, just works, paper thing abstractions over stuff everyone already knows how to do.…

I went from react to next and back to react+tanstack (with vite), best setup I've used thus far (having tried angular a while ago when it was contender and vue more recently)

React is where industry mind share and energy is today, regardless of developer opinions

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

#127
post #116

Earlier quoted context omitted.

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…

I have over ten years experience and the distinction isn't always clear to me.

Example: This logistics SPA I was building I realized could just be single pages with some data for most of the stuff (tracking, inventory, etc...) but for admins they wanted a whole dashboard. This was a conditional on some value of the stored session user. So it ended up being kinda a website for parts of it and an SPA admin panel if the user conditionally matched some privileges. Probably should have been separate stacks but they used the same data so early on they made it the same Next app.

I don't think the whole website vs app thing is always as simple as static blog pages vs full fledged JS-heavy app. There is a spectrum and overlap even within a single "application" because of various requirements.

Your last sentence is the most accurate. I don't think its primarily ignorance, its just trying to meet all the requirements while retaining some level of organization in the codebase.

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

#128

Earlier quoted context omitted.

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

YMMV, but I don't agree. I was building very complicated UI's with Svelte before runes (multiple layers of state, complex d3 + webgl visuals in the UI, etc.) and loved Svelte. Runes completely nuked the vanilla feel of Svelte, so I determined I may as well just use React. I know other people did the same (just look at the evolution of dev tools for Anthropic's research post-runes, or popular news rooms that once used Svelte but now don't).

The main issue I had with Svelte was building real full-stack applications, where Sveltekit itself certainly felt behind its peers, but that's unrelated to runes/signals.

It's certainly not a rare viewpoint, just click on any link about "svelte runes" to see people upset.

- https://www.reddit.com/r/sveltejs/comments/1crpj0r/svelte_5_... - https://www.reddit.com/r/sveltejs/comments/1htup7k/ive_been_...

You do raise a good point that LLMs make React much easier to adopt these days. Again, in my case the switch happened before I found LLMs effective for the sort of work I was doing, (but now it's a no-brainer to default to react).

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

#129
post #102

Earlier quoted context omitted.

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

Sadly, yes. Fortunately, most of them are developers’ toys, but not all.

I mean the docs of most of the frameworks are written in that framework even though its just static pages. Didn't even need the framework but not using your own framework for docs feels ... bad I guess?

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

#130
post #111
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…

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.

The whole reason was working in the browser.

WPF was great for desktop, albeit Windows only.

So that was wrecked after .net framework became .net core (and thus needed crossplatform).

Then some shitheads at Microsoft got the “release new UI framework to get a promotion” annual bug: winui, maui, etc.

All that instead of making WPF crossplatform.

That’s why C# succumbed to server API only (and games of course, but those blokes suffer as most great C# features are not supported in Unity).

That was the grandeur of Windows Vista: not the OS but completely new dev stack (wpf, linq, wcf, etc.) that was feature rich for a few decades to come. And they fucked most of it up instead of building further on the same foundation.

And after you keep abandoning the technologies devs will say FU and go to something more stable to build a business.

Even now, .net is keep getting rewritten (meaning existing features being abandoned) because board wants those sweet-sweet money from the cloud functions and what have you instead of you being self-hosted and not vendor-locked

Post reply on HN