I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.
But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.
Svelte is a language.
Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?
A few projects that have answered this question:
(Idyll is an outlier as it's geared towards a specific use case, rather than general purpose app development, but I think it qualifies as an example.)
These projects are all very cool, but there's a reason they haven't hit mass adoption: they want to control the entire world. You can't adopt Elm or Imba incrementally, and they need dedicated tooling far beyond just the compiler itself (e.g. syntax highlighting, unless you like your code monochrome). In some cases (Elm stands out), interop with the JS ecosystem is less than seamless.
Beyond that, they have a steep learning curve, which is hard to justify when there are so many options that are more accessible.
What if we had a language that was designed for building reactive user interfaces, but that also worked with your existing tools? What if you didn't need you to discard your years of experience using HTML, CSS and JavaScript, because it extended those languages?
- It would extend HTML by adding JavaScript expressions in markup, directives for controlling behaviour and reacting to input, syntax for using conditions, loops and asynchronous values
 - It would extend CSS by adding a scoping mechanism that kept styles from clobbering each other
 - It would extend JavaScript by making reactivity a language primitive
 
How do we make reactivity a language primitive without introducing invalid syntax, or breaking the relationship with existing tooling (like TypeScript)? By hacking existing syntax:
- We instrument assignments to variables and properties
 - We add 
$:statements, using the little-known label construct, that run whenever their inputs change value - We tie it all together with an opinionated scheduler
 
This, to me, is the best of all possible worlds: we can lean on decades of accumulated wisdom by extending well-known languages, author components in a delightfully concise and expressive way, and yet still generate apps that are bleeding-edge in terms of performance and everything that goes with it.
I never looked at svelte until today. Interesting approach and ofc much respect to @Rich-Harris for pushing the boundaries of whats possible.
But, imho, SPAs are not the future. Not since datastar arrived on scene a few months back.
You can now get client-side reactivity more easily than ever with datastar
https://github.com/starfederation/datastar
"Getting started is as easy as adding a single 10.70 KiB script tag to your HTML."
That's it and you have no need for JSX, no need for Svelte, Angular, NextJs, React etc etc
Say goodbye to node_module hell and all the shitty frontend tooling that keeps on breaking day-in day-out.
Back to old skool server-rendered MPA with FULL reactivity in the client when you need it.
If you really wanted to do, you could still build a SPA with datastar, but you'd be coding yourself into hell. Just don't. Put each page on its own server-rendered route THE WAY THE WEB WAS MEANT TO BE!
Coupled with the WA API*, we have everything we need to build on the backend and have super-fast server-generated apps that feel like desktop apps.
*The Web Animations API allows for synchronizing and timing changes to the presentation of a Web page, ie animation of DOM elements.
Don't believe me? Here is something I'm building.
It is a full SPA SaaS rebuild with NO frontend spa frameworks. Typical SaaS CRUD to see if datastar if fit for purpose. Took me about 3 weeks to build this on my own from nothing ... whilst learning the "datastar way". Once your mind "flips off" the 15 year poison of SPA frameworks, trust me, you will enjoy building again. And move faster than ever.
I am still playing around, but here is my build, fully server-rendered, but using datastar where needed (only products and customer routes work for now). Follow me on youtube, or twitter, I'll be posting tutorials soon.
https://staging-floorbook-otii.encr.app/
(give it 30 secs to wake up, as it will be asleep)