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

81–90 of 205 posts

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

#81

Post by jfengel »

its-summertime wrote: post #28
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.

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.

I concur about Javascript, but I don't think it's true for Typescript. Typescript is a remarkably powerful typing language.

It's still got some baggage left over from Javascript, to be sure. But the typing is genuinely very good, and more than sufficient for "basic comprehensive abstractions".

JSX is just Javascript with syntactic sugar for HTML. It's not really intended as a general-purpose language. TSX is a fine language, but I wouldn't use it for "basic comprehensive abstractions".

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

#82

Post by kaoD »

byearthithatius wrote: post #35
SeanAnderson wrote: post #34

Earlier quoted context omitted.

Didn't React 19 introduce a compiler in an attempt to provide auto-memoization? That feels pretty substantial.

The fact we got to a point of auto-memoization on every reactive function is crazy to me. How is that not prematurely optimizing? I already saw people doing useMemo on shit that shouldn't be getting called repeatedly with the same value. So maybe it is better to let a compiler decide, although I am curious how it knows. EDIT: if its pure (not reactive to any other variable but other variables may react to it) they wi…

Just to clarify: despite its name, React has no reactivity engine at all and re-renders unconditionally on any state changes or parent re-renders.

You have to opt-in to prop-diffing conditional re-renders (which I wouldn't call a "reactivity engine" either) per component, via React.memo.

And then you also have to opt-in to prop memoization for non-primitives for the prop-diffing not to be useless.

These re-renders might not result in any actual DOM changes since there is an additional vDOM diffing step from the resulting render (which, again, I wouldn't call a "reactivity engine").

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

#83

Post by Imustaskforhelp »

its-summertime wrote: post #28
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.

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.

Depends...

Like if you want to make a basic dashboard, things like alpine/htmx should make more sense to you and you should definitely go for it

But I have found that if you are writing ever so slightly complex code, you might be then forced to write js code (not sure about blazor but even that suffers a little in benchmarks but the fact that somebody can fully stop to never touch js sounds a bit intriguing even though it maybe slow but sure)

So when you are forced to use js to write complex software, frameworks especially frameworks like svelte / maybe solid could definitely help you out

Honestly, sveltekit is just html css js and some opinionated stuff and I kinda feel like that this might be the sane thing but maybe that's because I was there when svelte 3 was launched and I was 15 so svelte was something sooo interesting to me (still is! but golang is also love, man I know that svelte and go could be integrated and maybe I would), I never really went around learning pure js dom manipulation / ts / jsx if I am being honest so I am not that much of an expert

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

#84

Post by scrame »

habibur wrote: post #72
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.

> when I ask why they do SSR What are the reasons for not doing SSR?

want the whole point of Javascript to use client side manipulation? Is it's come back to SSR, then do we need all the JS baggage?

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

#85

Post by SeanAnderson »

mi_lk wrote: post #78
SeanAnderson wrote: post #47

Earlier quoted context omitted.

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

Vite is indeed awesome and a breath of fresh air after a decade of Webpack.

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

#86

Post by fakedang »

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

That seems to be the only big plus with NextJS and SSR. But a big reason behind that was how Vercel made NextJS accessible to so many newbie devs right during Covid season. I was one of those new learners picking up React through it. Out of all the frameworks, Next was the most well-documented and more straightforward. The extras such as the straightforward routing and the availability of templates by vercel made things all the more easier for many to pick up. Meanwhile React was languishing and most of the other alternatives were just all over the place.

That being said, I'm waiting in the back stage, like many other folks, for tanstack to get production-ready, because of the all the weird crap being pulled by Vercel on NextJS.

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

#87

Post by Imustaskforhelp »

pitaj wrote: post #18

I love Svelte. When I first used it, it was like using a framework for the first time: Wow, everything is namespaced to the component, even CSS! Wow, just putting $ in front makes it update automatically! etc, etc

Somethings have definitely changed but I've accepted that maybe this is what is best needed for having some fewer amount of bugs/headaches about software while making it more performant and I sort of trust the svelte team in whatever version they lead us to!

Afterall, what is fun in webdev if not for creating factions and I am part of the lovely sveltelandia! Proud to be a member of it and I have full trust on the team.

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

#88

Post by nixpulvis »

I've never used Svelte before, so maybe I'm misunderstanding what they mean by tracking dirty, but this bit confused me.

> This requires the framework to track which components are dirty. Vue does this at runtime, Svelte handles it at compile time.

How can it possibly track this at compile time? Best I could see if tracking where those bits could be set, but not actually setting them.

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

#89

Post by lukev »

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 substantive improvements in developer velocity or end user experience.

Any given "progress" looks reasonable for a moment but is ultimately circular. We've been playing rock/paper/scissors with "better" techniques for a long time now.

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

#90

Post by Buttons840 »

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…

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 pieces and try again. Maybe this next time we'll find a better way to fit them together.

Post reply on HN