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.