Tenets

[Rich-Harris]

This is an attempt to articulate the Svelte philosophy — our bedrock principles, that guide our design decisions.

Edit: for visitors from Hacker News, and anyone else who is curious, here is the video that this list came out of

The web matters

We work on Svelte because we believe that the web is a critically important technology, and that its continued survival is not guaranteed.

Optimise for vibes

People use Svelte because they like Svelte. They like it because it aligns with their aesthetic sensibilities.

Instead of striving to be the fastest or smallest or whateverest, we explicitly aim to be the framework with the best vibes.

Don't optimise for adoption

We're not trying to be the most popular framework, we're trying to be the best framework. Sometimes that means making choices that we believe in but that go against the grain of web development trends.

HTML, The Mother Language

HTML is a really good language for describing UI. Svelte augments HTML in a way that makes it a really good language for describing interactive UI.

Most frameworks are JS-centric, because JS is the most powerful language. But then they find themselves jumping through hoops to make it feel like you're writing HTML. We think both options are valid, but the HTML-first approach ends up feeling more natural.

Embrace progress

There is a tendency in the web developer community towards a harmful form of pessimistic nostalgia — the idea that things were better in the prelapsarian age before bundlers, TypeScript, client-side routing and other trappings of modernity.

This is nonsense. As a community our default position is one of optimism about technology — the platform is getting better, our tools are getting better, our devices are getting better, and if we embrace that fact we can make better stuff.

And when other frameworks introduce new ideas like signals or server components, we look at them with interest and jealousy, and try to work out how we can incorporate good ideas, instead of resting on our laurels. There is always room for improvement.

Numbers lie

Lighthouse has broken the brains of a generation of web developers. We have replaced good judgment with subservience to metrics that were only ever intended to be used as a diagnostic tool.

Goodhart's Law states that

When a measure becomes a target, it ceases to be a good measure

and this is very true in web development. Numerical rigour is good, and we pay attention to the various numbers, but when designing Svelte we think qualitatively, not quantitatively.

Magical, not magic

There's a subtle line between something feeling magical, and something feeling like magic. We want Svelte to feel magical — we want you to feel like a wizard when you're writing Svelte code. Historically I think Svelte went too far into magic territory, where it's not 100% clear why things work a certain way, and that's something that we're rectifying with Svelte 5.

Dream big

'Choose the right tool for the job' is sensible but boring advice.

It makes us small in our ambitions. I want us to dream bigger. I don't want to feel like my tools can't handle evolving requirements, or that if I want to dabble in a new field I need to learn an entirely new way of working first.

Even if it turns out to be unachievable, I find it valuable to ask the question 'what would it take for SvelteKit to be the best framework for any app?', whether it's purely static content, or a realtime multiplayer app, or an offline-first productivity app, or even something built for an augmented reality headset.

No-one cares

Most people do not care about frameworks. They just want to build something cool, and Svelte is for those people too.

So when we design things we need to think about the people who haven't read the docs in a while, if at all, and don't care about things like fine-grained rendering or configuring their build tool. This means that things need to be intuitive, that we shouldn't need to worry about manual optimisations like memoisation, that we should have as few APIs as possible, and that things need to be discoverable — for example you should be able to hover over a rune and get a link to comprehensive documentation.

This also informs our approach to documentation and tutorials — it should be possible to build what you want by just learning the concepts that you need, and worrying about the other stuff for another day.

Design by consensus

Svelte is a community-driven and consensus-led project. It's important that the community — that's you — has a stake in the project's future. Many of Svelte's best ideas originated outside the core team.

When we introduce new plans, we want to communicate them openly and provide everyone with good opportunities to offer their feedback.

Those of us who work on the project every day have a vision for what kind of thing we want it to be, but we don't want to foist that vision on people against their will. And so while we can't get unanimous agreement on every change, we can at least say that dissenting voices have been heard and considered.

[Indyandie]

@Rich-Harris How do you imagen sveltekit will embrace the no-one cares tenet? I dream of a world where we don't have to think of package managers as much.

[codymikol]

Check out Nix 🤠

[tausifcreates]

Oh, you moved from 'optimise for vibes' when you decided to deprecate export let in future version

[eddiemcconkie]

@AlanBreck sure! Here's a REPL with a couple examples.
If you want every component to accept a baseline of props, you can define an interface with TypeScript, and then extend that interface within each component. In the example, the circle and rectangle components both have color and stroke props, but the circle also has a radius and the rectangle also has width and height.
A really handy use case, though, is if you want to extend the functionality of an existing HTML element, like a button, you can extend the HTMLButtonAttributes type provided by Svelte. This is much easier to do in Svelte 5, compared to Svelte 4.

[AlanBreck]

Thank you! What about from a runtime perspective? Will the $props rune help determine what props are available for a component during runtime, though?

[eddiemcconkie]

Not totally sure on that one! Someone from the core team could probably give a good answer, but I'm guessing the compiled code gets optimized based on which props you destructure from $props()

[Pierstoval]

I think that's it @eddiemcconkie, that's the argument that can convince me 👌 As a typescript fan, I can definitely see the advantage of being able to just define the types myself, it's probably even easier to generally document 👍

[Pierstoval]

Addition to my big comment above: I'm still not a hype fan of Runes, but now I just don't like them when outside Svelte files.
If everything stays in the Svelte file, all is good 👌 And Runes are actually interesting.
I'm almost convinced.
It just took time.
I'm still into this "separation of concerns" thing: Svelte code in Svelte files, JS/TS code in JS/TS files.
I would still dislike very much the obligation to compile JS/TS code with Svelte outside of Svelte components, because IMO that's completely different.
I really like Svelte also because it's more okay to use it as a frontend templating engine, or as plug-and-play JS components (just like Web components).

(sorry for all the fuss)

[codenoid]

the first time I use Svelte & Kit I feel the same joy as I feel when the first time learning web development in 2015

I don't know how I can be thankful enough

[amr3k]

I also started in the web track back in 2016 and I wasn't fond of frontend, but came back to it in 2020 because I heard the word svelte on reddit and watched a crash course from traversy media, and quickly fall in love with svelte & frontend.

[codymikol]

I love the "Vibe Based Optimization" philosophy

[FlexWilliams]

cosign, i'm here for the aesthetic ;)

[jycouet]

no-one cares, that's the best vibe 🎉

[softwarecurator]

RICH FOR PRESIDENT

[dragosstancu]

Harris for president :)

[gevera]

With enthusiasm and community like ours, I feel like SvelteKit in five years from now will able to do this:

• +page.server.go (adapter/go)
• +page.server.py (adapter/python)
• +page.server.rs (adapter/rust)
• +page.server.rb (adapter/ruby)
• +page.server.ex (adapter/elixir)
• +page.server.php (adapter/php)

Enjoyed The Tenets

[SikandarJODD]

it would be crazy if would be able to add python to it...and integrate with ai models in seconds......or simple python integration in seconds

[Antonio-Bennett]

My guess is with Bun this will be possible since they make it easy to import files if they have a good C FFI. We've already seen Rust and C++ being imported easily into Bun. The only thing I'm not sure about is svelte/kit's tight coupling to vite since I assume Bun would need to do all the bundling and etc

[didier]

That's actually a great idea.

[jubbs]

Yes please

[ConProgramming]

https://github.com/semicognitive/sveltekit-modal

[kirso]

I gave up on learning webdev some time ago. Svelte brought me back last year! I wish there was a bit more in the philosophy of going from 0 - 1 given a lot of docs and resources cater for other web framework converts.

Great tenets and can't wait whats ahead!

[gterras]

Beautifully said for the most part!

[MichaelDimmitt]

HTML, The Mother Language !

[samal-rasmussen]

I've just realized that with Tailwind you put css in html, and with htmx you put js in html. It is wild how powerful just html can be. I've personally been fully converted to the church of html first 😅 I reeeally like how Svelte is html first, but then also gives you all of css and js right there in <style> and <script> tags if you need them.

[sharu725]

But then they find themselves jumping through hoops to make it feel like you're writing HTML. We think both options are valid, but the HTML-first approach ends up feeling more natural.

This is the biggest reason for me to use Svelte.

[DipandaAser]

it should be possible to build what you want by just learning the concepts that you need, and worrying about the other stuff for another day.

As a backend dev trying to do frontend stuff sometimes for side projects this statement is the best thing i ever read.

[nguyenbn7]

I love svelte and kit. Even I am just a regular developer but I really enjoy what svelte has reached so far and use svelte and kit as my main tool. I used to learn React, I do not like it because the virtual DOM and advertising that virtual DOM beat DOM, I learn Angular, I feel it too heavy and uncessary thing to configure and pain in ass like layout and router. I wish Svelte still enjoyable to make web because right now there is no a single framework can do it like Svelte and I love the no one cares and numbers lie philosophy because I am tired of those, just look at React has to change to compiler, it's funny 😂

[rgeditz]

No mention of cybernetics?

[dragosstancu]

My hate for JSX alone would push me toward Svelte :)
I mean, returning a tag?! Accepted by the same people shitting on PHP for mangling code with templating.

[malgor]

Regarding "Don't optimise for adoption", if the other tenets are done well adoption rates will increase. So perhaps adoption rates can be a measure of how well other things are being done. I actually think adoption rates are important because when choosing a development environment one of the considerations is how many people can be employed with the necessary experience.

[ThePaSch]

I've written this out elsewhere, but thought I'd repost it - and significantly elaborate on it - here, because it feels relevant, specifically to the "No one cares" point:

I'm really not a fan of how much "background knowledge" is now necessary in many Svelte 5 workflows in general. The introduction of proxied state may have opened up new possibilities and quality of life, but it's also brought many a potential pitfall and footgun with it, and it seems like there are too many stopgap measures and bandaid fixes to issues it's brought up that essentially boil down to "this thing that was previously possible and intuitive with little headache now requires this very specific workflow that you'll always have to keep in mind if you don't want to run into issues".

In short, when previously, you could write code that looks like it should work, and it worked as you expected - I'd reckon this aspect of Svelte was the main reason for why it was the king of DX - now, you constantly need to worry about how Svelte achieves what it achieves in the background.

For instance, you need to remember to $state.snapshot when you send state to an outside consumer because the state is proxied - but you have to know that state is proxied in order to know do this, and if you don't, stuff might break in unexpected and obscure ways.

Or, you need to use $state.is to compare a value to reactive state, which means there is now a distinction between the two where there didn't use to be - and if you don't know that, then you're going to wonder why your comparisons seem so wonky.

Or, you now need to use specific Svelte-only Maps and Sets and Dates and somesuch if you want them to be reactive, which reduces framework agnosticity of all affected code - and you need to know about their existence in order to not be confused when, suddenly, you can no longer use the "vanilla" versions of them in your code and have them be reactive.

Or - as an extension of this - you have to know that state is proxied and that proxying any arbitrary object is a bad idea in order to understand why non-POJOs will just blanket refuse to become reactive in Svelte 5 now, requiring you to either write cumbersome boilerplate to make it work or tie all of your application's code to Svelte inextricably by adding runes all over it.

Every one of these examples is going to need a mention somewhere in the docs, adding sizeable API surface, and will add something you will need to mentally make a note of and keep in the back of your mind whenever you write Svelte code. It feels very un-Svelte-like, and I wouldn't be surprised to see many issues related to all of the above pop up once Svelte 5 is out and about.

To circle back to the tenets: I agree that "no one cares", and previously, no one had to care. You wrote code that looked like it should work, and it worked. Therein lay the magic of Svelte. Now, you do have to care in what feels like far too many cases, and if you don't, then the code you wrote, the code that looks like it should work... just won't work. And you'll have no idea why, because broadly, this stuff just isn't intuitive to anyone who doesn't know about how Svelte works behind the curtains.

[7nik]

Those are fair points, and longstanding odd quirks of Svelte 3/4, but I'd argue they had a much smaller impact on DX than the potential pitfalls with proxies might have

You literally say, "I learned the Svelte 3/4 quirks the hard way (the only way to learn it is to step on and debug for hours only to find out that it is Svelte's unfixable bug) and got used to them", which, in fact, isn't good DX at all.

I believe you think about states too much. Unless a function stores somewhere the passed arguments, it's ok to pass in a proxied state.

[ThePaSch]

You literally say, "I learned the Svelte 3/4 quirks the hard way (the only way to learn it is to step on and debug for hours only to find out that it is Svelte's unfixable bug) and got used to them", which, in fact, isn't good DX at all.

When do I literally say that? I don't remember saying anything of the sort. The Svelte 4 docs, as well as the tutorial, outline that reactivity is triggered by assignment to the reactive variable, and Svelte 4's behavior largely follows this rule. I doubt many people lost hours in the debugger for this issue that's very prominently pointed out pretty much anywhere that the docs teach you how reactivity works in the first place.

Unless a function stores somewhere the passed arguments, it's ok to pass in a proxied state.

Right, but the issue is that it's impossible to tell at a glance whether the argument you're receiving (or passing, for that matter) is proxied state, particularly when you're dealing with code that lives somewhere other than where said state is declared. Even if you meticulously keep mental track of where exactly every argument you're receiving comes from while you write it, good luck remembering that a few months down the line when you have to touch that code again while refactoring some other feature.

[7nik]

I probably misunderstood your words about Svelte quirks, sorry.

Svlete 3/4 has many undocumented quirks of the reactivity: canges made inside reactive blocks can be ignored; $: blocks can be reordered which isn't obvious; $: blocks are executed at the end of initialization, but it isn't obvious; ambiguous $: a = b + 2; invalidating "unrelated" variables; reactivity can be lost in deeply nested slots; beforeUpdate called twice when bind:this used; etc (I have found 54 issues about reactivity, though some repeats). Roughly half of them are caused by the reactivity implementation, and the other half - by the reactivity design (syntax + rules).

Almost all of them are undocumented, and you encounter many of them when writing more or less complex apps. It's awful to spend hours debugging the app only to find out that it is Svelte's unfixable bug.

I hope Svelte 5 will properly document the edge cases of the runes so we can write apps without unexpected surprises.

the issue is that it's impossible to tell at a glance whether the argument you're receiving (or passing, for that matter) is proxied state

I haven't written big apps with Svelte 5, but I don't notice complaints about it from people who have. So, I believe that either you overestimate the problem, or your personal code style doesn't go well with runes (or kinda both).

[Pierstoval]

Regarding adding reactivity to "Array.push()" and other stuff, I personally wouldn't have minded a few Svelte-specific data structures. I mean, doing something like const myData = new ReactiveArray(); in order for myData.push(someData) to call reactivity, that would have been great, because it's only a data structure, and the implementation behind is clear: when internal array is modified, reactivity is triggered.

For the rest, I still think having a mix of too complex&generic structure (like proxies) is both nice and bad. It's generic enough so it's good for many purposes, but it comes with other quirks (and we already have enough quirks everywhere).
To me, the issues @7nik pointed that Svelte has in v3 and v4 are maybe fixed, but when I look at how it works, it's more like "Fixed with another hack, but instead of a syntax hack, it's now a generic-data-structure-based hack".

I hope I will be convinced once I use Svelte 5 every day 😕

[flevi29]

"Fixed with another hack, but instead of a syntax hack, it's now a generic-data-structure-based hack"

I felt that. Some degree of "generic-data-structure-based hack" is acceptable but right now it just doesn't feel right. Way overcomplicated for what it's worth. Not going to replace stores as it is currently, not with this many gotchas and conditions.

EDIT: It's actually fine.

[justDeeevin]

I've gotta say, runes ruin the vibes

[mindplay-dk]

I will just say, that's how I felt initially, when it was announced. I always thought of Svelte as the one where you didn't have to think of this - where reactivity "just happened" and "just worked". In hind sight, this feels reactive. Having seen Rich talk about runes more recently, and then deciding to try it, I gotta say, I get it now. It's still declarative, but the runes are not just annoying boilerplate, they're useful to the reader because you don't have to figure out what's reactive or not. I changed my mind. Maybe you can too? 🙃

[taishi55]

Please revert the changes made in Svelte 5

[didier]

😂😂😂