Svelte’s Characteristics That Likely Contribute Most to Improved Performance

For writing a web server library, like oak or flask or etc etc:

First, resources own the methods, methods don't own the resources, so the path comes first, easy enough, its just a string with potentially placeholders whose values need to be shunted down the line

Next is the method, for some reason a lot of libraries like to hardcode these? Immediately jumping away from comprehensive, unless you have a language that makes identifier-like things possible, e.g. symbols in ruby, or `__getattr__` in python, or proxies in javascript, of the 3, proxies are probably the most cumbersome in implementation.

then the request handling, that is fine for all languages

Templating is more of a bother: Either you use JSX, which in most cases is not XML, but instead DOM, subtle but a pain, additionally requires a compilation step before you can run the code, and also requires a DOM or DOM-lite library. Or you do chained calls with an ending call, e.g. https://sonnet.js.org/, or you do something like lit-html which is quite practical. You can't do something like title("hi") vs title({attr:123}, "hi"), as everything is an object and {} are objects, so you need to have fixed function signatures unless you want to have a lot of bother in implementing things. This is all less of a problem in other languages (e.g. Python, Ruby, Raku)

In short, Javascript does not flex when you push on it, that is great for a lot of tasks, but not so much for building frameworks where instead of having systematic ways of extending the language, either tricks are used which break other things down the line ( https://news.ycombinator.com/item?id=45472119 ), or you have opinionated narrow frameworks, which results in more churn as instead of frameworks, its more, frame-specific-use-cases.

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)

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

And, yes, Google has internal JS frameworks, but I am not aware that GoogleDocs is based on one.

I know svelte/sveltekit and would want to contribute to svelte apps (a good reminder that I should)

But there are some projects that I really really want to contribute to / heck even port to sveltekit like cinny and hedgedoc and the likes and so I almost feel pressured by the system to learn react so that I can finally feel confident enough to understand their repositories as they scare me right now...

Cinny:https://github.com/cinnyapp/cinny Hedgedoc:https://github.com/hedgedoc/hedgedoc

I don’t even want to talk to somebody that defines themselves as a “React” developer. Let alone work with them.

If you know any of these frameworks, and the basics of web development you can work in any of them.

So the hiring part is not an excuse for this.

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.

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.

My default is a small page that client then fetches any additional data it needs. If its long load time skeleton UI it. I also have not seen the SEO benefits at all.

So again _why would I_ unless I needed to do stuff on the server to make the client bundle, which I don't.

A lot of these YC companies doing this could literally just be using a fetch because their backend is dead simple REST.

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

Meanwhile, sync engines seem to actually solve these problems - the distributed data syncing and the client-side needs like optimistic updates, while also letting you avoid the complexity. And, you can keep your server-first rendering.

To me it's a choice between lose-lose (complex, worse UX) and win-win (simpler, better UX) and the only reason I think anyone really likes RSC is because there is so much money behind it, and so little relatively in sync engines. That said, I don't blame people for not even mentioning them as they are newer. I've been working with one for the last year and it's an absolute delight, and probably the first genuine leap forward in frontend dev in the last decade, since React.

This is all specific to frontend stuff, i.e. how do you build an application that mostly lives on the client. Generally, the answer to that seems to be signals* and your choice of templating system — unless you're using React, then the answer is pure render functions and additional mechanisms to attach state to that.

Where there's more exploration right now is how you build an application that spans multiple computers. This is generally hard — I don't think anyone has demonstrated an obvious way of doing this yet. In the old days, we had fully client-side applications, but syncing files was always done manually. Then we had applications that lived on external servers, but this meant that you needed a network round-trip to do anything meaningful. Then we moved the rendering back to the client which meant that the client could make some of its own decisions, and reduced the number of round trips needed, but this bloats the client, and makes it useless if the network goes down.

The challenge right now, then, is trying to figure out how to share code between client and server in such a way that

    (a) the client doesn't have to do more than it needs to do (no need to contain the logic for rendering an entire application just to handle some fancy tabs).
    (b) the client can still do lots of things that are useful (optimistic updates, frontend validation, etc
    (c) both client and server can be modelled as a single application as opposed to two different ones, potentially with different tooling, languages, and teams
    (d) the volatility of the network is always accounted for and does not break the application

And importantly here, I don't think anyone has solved these issues yet, even in older models of software. The reason this development is ongoing has nothing to do with the web platform (which is an incredible resource in many ways: a sandboxed mini-OS with incredibly powerful primitives), it's because it's a very old problem and we still need to figure out what to do about it.

* Or some other reactivity primitive or eventing system, but mostly signals.