Svelte is an absolute love language to the web and a direction for healing the damage caused by modern "web frameworks". It's the absolute direction we need to head in.
Here's something beautiful. I'm teaching my brother-in-law programming to get a job when he's out of the military. He's learning JS/CSS/HTML and doing quite well. With about a 2 minute tutorial of how Svelte works; he was able to start creating some pretty impressive projects. A day later because he already knew the basics of how the web works, he was in Sveltekit building fullstack apps -_-.
HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces. This is why JS solutions are so appealing. If HTML is so magical why do they need a fancy template language?
Magical, not magic - I really don't want it to feel magical either. I like explicit behavior and I think that is my problem with the whole wrap everything in observables approach. It's too magical.
No one cares - The countless blogs, posts, and communication around frameworks implies that yes, developers do indeed care. Details are important. You can't waive away concepts like memoization because they need to be used in the right context. There's no one size fits all solution to caching.
That's because HTML is the native language for describing UI in the browser.
No matter what you use to specify UI, you have to understand how it translates to HTML to use it in the browser (and how HTML translates back, for debugging). The further your UI specification language deviates from HTML the harder that it.
Of course, there are plenty of people using various frameworks that don't really understand HTML or how the code they write translates to it. But they end up with crappy web sites and bugs they don't know how to fix and various other compromises and frustrations.
99.9% of people using React have no clue how the reconciler works, how hooks are implemented, how context works, what useEffect does, yet none of that is considered “magic” somehow.
{#if answer === 42} <p>what was the question?</p> {/if}
In the same way that assembler is the native language for giving instructions to the CPU. In practice, it is of zero importance, because there are powerful abstractions built on top of it, with wonderful benefits once you’re building anything more complicated than one-page documents.
Outside of games, almost all the frameworks people use don't try to do that -- you are essentially trying to write HTML, but using the syntax of a different language, or each HTML thing in a thing from a different language. (Flutter is the exception -- it really does try to provide a complete abstraction, though it's certainly not without its tradeoffs.)
Sadly, there's no way around understanding HTML and CSS when you need to troubleshoot what a high-level framework built for you. (Or maybe there is! Render everything using WebGL, the way Flutter does, and Flash did before it. But it's a different kettle of fish.)
I disagree a lot on HTML here - it's a pretty fantastic way of describing a render and layout tree, so much so that people are embedding HTML-like syntax in programming languages because the syntax is better than what the language already has to offer.
To paraphrase something I've heard: JSX proves that HTML actually won.
And you can see this because even in a language with concise object literals like JS, a markup based syntax is nicer. There are template systems where you write objects, and I find them cumbersome and they're not very popular.
But markup is king, whether it's in JS like JSX or Lit-like tagged template literals, or in an HTML-like file like Angular, Vue, or Svelte. They all share a markup-based syntax.
> If HTML is so magical why do they need a fancy template language?
Note that Rich doesn't say that HTML is magical. He says it's good, which it undeniably is. It describes elements with attributes and children, which happens to be exactly the structure you need for the vast majority of UI widget concepts.
The reason you need a fancier template syntax is that while HTML is good it isn't perfect. HTML doesn't have a dynamic binding syntax (though standards is working on that with Template Instantiation) or conditionals, and attributes are underpowered.
So template systems generally add those things. Whether it's JSX, Svelte, lit-html, Angular, etc... they share those common enhancements.
The only real big disagreement is whether you embed the logic in HTML or the HTML in JS. It's not even that fundamental of a difference.
I prefer HTML-in-JS myself (note: I'm on the Lit team) because JS already has binding syntax, expressions, control flow; because the data is already available in JS; and because JS has a module system and you can do all the things without forking a language or a build step.
But having been on the Polymer side too, which is logic-in-HTML, I know that a lot of people prefer HTML syntax and that to some it's more clear how it maps to the DOM created on the page, simply due to syntax similarity. That's fine. But it's really all variants of HTML in the end.
Component authors and component users should be able to seamlessly interoperate which disagreeing about such trivial things.
While I think that might be true, similarly, JSX proves that for the dynamic parts of the template, you want a real programming language.
Mixing any logic beyond that with HTML makes a mess of both.
I'm personally a fan of minimalist templating engines that provide only simple loops and conditionals so that template has to receive prepared data tree which is created by the actual programming language first and passed into the template.
And you can see this because even in a language with concise object literals like JS, a markup based syntax is nicer. There are template systems where you write objects, and I find them cumbersome and they're not very popular.
That’s completely an opinion, and I have another one. Html sucks at reading and writing, it is cumbersome (and also non-typed, and non-structured), and js structs/calls are much better for creating these trees.
Jsx proves nothing but that react team had to make a decision about format and they decided to not experiment with formats due to drop-in compatibility. That’s it.
I personally dislike HTML due to the verbosity. I prefer hyperscript.
In the context of the discussion, that would imply that "a render and layout tree" is a good way to describe a UI. That too is subject to serious questions.
I feel very different than you, but I am sincerely glad you have clarity and that you better understand what YOU are looking for :) having said that, we'll likely end up happily working on different things in different pastures
GUIs are essentially 2d scene graphs. Basically you need to describe a tree of hierarchical relationships.
I agree HTML is not great for the dynamic part and the reacitivity but it's the lingua franca of the web. Why reinvent some new DSL when you already have one that was already designed to represent a scene graph.
Personally I just don't like when people go too much into "<lang> in <lang>" mentality. HTML is decent at describing what's there. CSS is sort of fine at describing how it looks. And JS is ok for describing what should happen.
My second guiding principle is that everything should be split into composable components, without anything being privileged. So I don't like page components being special in any way.
I can excuse some violations of the first principle in the service of the second one like putting a bit of HTML into JS file instead of keeping separate HTML template file for each component. But I don't really like any CSS in JS. The only connection surface between CSS and JS (and HTML) should be selectors that say what is addressed. CSS classes should identify elements. If you want some classes that describe groups of styles (like tailwind) you can have them but don't cram them directly into HTML. Include them in styles for given element using SASS (or LESS) include functionality. HTML (or JS) shouldn't describe how things look.
Also all the frameworks that claim to be almost pure HTML but they cram the adhoc behavior description into fake HTML attributes rub me the wrong way. They remind me of what was there 20 years ago.
And any reactive bindings between arbitrary stuff is just ordering whole bowl of old time spaghetti, after Redux (and React) shown that it doesn't have to be like that anymore.
I agree that additional challenge of keeping the flow of state centralized and unidirectional might feel unnecessary for simple projects, but it's worth it if the project survives more than few years and grows.
Compared to... what? XML? QML? XIB?
There's literally nothing better than HTML for UI. Anything else is either buried in a mountain of proprietary nonsense, is platform specific, or is far inferior technically.
Except... Literally everything else. Imperative Delphi code from early 2000s or indeed Turbo Pascal code from 1995 will run circles around HTML any day of the week and twice on Sundays.
The fact that people started building apps with is was miraculous persistence. HTML acquire some functionalities that supported such advanced things as multiple columns or fairly recently some automatic layouts not directly stemming from its text displaying roots. But in terms of flexibility and ease of use they are still behind layouts of Delphi from 20 years ago.
I bet someone could have added the functionality but it just didn’t matter when all screens were squareish.
The problem with magical is that bugs and performance issues will make you feel like you're dealing with a bad spell and there's no logical solution.
I'm not sure but I think the distinction being made is "not magic" means you're expected to be able to understand how and why something works. And "magical" means it should be surprisingly easy to do what you want.
You don't need js to create a website, you only need HTML.
For dynamic UI you need a server, not javascript. Your server can render html, it doesn't have to serve json.
Svelte is by far my favorite framework of the lot. It’s also the most productive for me.
You want things edited together to be closer in code also. A single file or couple of files next to each other that decide structure, behaviour and view of a component is better than few CSS/JS for whole site.
No. We haven't. Because there's a different separation of concerns: https://twitter.com/simonswiss/status/1664736786671869952
With HTML first solutions, we sprinkle it with some # language which is neither simpler nor as expressive. It looks simple in toy examples, but for large projects you end up with worse structure.
Don't worry - they hint that they're gonna change it again in Svelte 5 anyway, so the suckers using it can throw away their code and start again with slightly less magic ...but hey, vibes!
Except that svelte advertises itself constantly as being faster and with smaller bundle sizes. Which is a good thing. I don't buy that it priortizes 'good vibes' at the cost of those other things. If it's saying it prioritizes 'good vibes' and everything else, then that's pretty meaningless - they might as well say they're good at everything.
Would also help to actually define what 'good vibes' are because I think every tool tries to make DX as nice as possible.
I honestly dislike fluff like this because it conveys nothing and gives fodder for people to ignore practical evidence in favor of biased advertising i.e. someone's going to make a bullet point list about things they dislike, and someone will just point to this and say "nuh uh, you're wrong, they care about being user-friendly, it says so right here".
Since we're talking about front-end frameworks, I still maintain that vue has some of the best documentation. I fell in love with vue 2 because the documentation did a great balancing act between being brief, simple, and somehow dense at the same time. In particular, I remember a page about it's comparisons to other frameworks that in a few paragraphs, gave a history lesson, simplified differences to barebones, explained the practical implications all in a way that put vue in a good light. It was much better than the angular and react docs at the time.
Maybe this is a subtle difference, but I understood it as Svelte still caring about and prioritizing speed and bundle size, but not necessarily as the primary focus with the goal of being the smallest or the fastest.
I love that I can just use
export let prop;
The new runes syntax
let { prop } = $props
Like all things, everyone is going to switch to the new syntax because it’s shiny, even though it objectively has a greater cognitive load (and IMO, looks ugly). My components are going to start looking like Svelte, rather than JavaScript.
The reason I prefer svelte over Vue is because there’s less to remember. Looks like I’ll be looking for a new framework after Svelte 5. Just like I did after Vue 3.
Also,
> Snippets are more powerful and flexible, and as such slots are deprecated in Svelte 5.
Removing slots, which feel really natural in HTML, with snippets - that are expressed as JavaScript values passed to a component - honestly, I don’t see the prioritisation of vibe, here.
These changes are going to make it so, so much harder to teach Svelte that I honestly feel despondent. I feel like svelte 5 has just totally forgotten that Svelte is supposed to feel like JavaScript. Super sad.
I believe the vibes thing refers to the DX, not the engine itself.
(Side note: I rate Vue as well, though I prefer SvelteKit over it these days)
Rich Harris and the Svelte family have always been pragmatically minded, and there's value in expounding one's development philosophy, but I've gained no insights with this list. Perhaps it's the language used, rather than the tenets themselves.
This document is a text version of a talk I gave there, which expands on some of these ideas: https://www.youtube.com/watch?v=eswNQiq4T2w&t=5211s
It's deliberately brief and vague in parts, because it's designed to spur conversation. It's not set in stone, nor is it an Official Statement on behalf of the Svelte team — it's an attempt to articulate the way that the maintainers tend to find ourselves thinking about some of these topics, as viewed through my personal lens. If it helps explain why you like Svelte, great! If it helps explain why you hate it, that's great too — that's the whole point. Have fun with it, and if there are parts you disagree with then your homework is to think through what kind of tenets would describe your ideal framework.
Also, it's Saturday — get off Hacker News :)
For interactivity, I added a bit of HTMX, and to have beautiful forms, I added the web components from Shoelace, all wrapped up in a Vite build.
And I must say that this was a relaxing experience: No complicated React stuff anymore, and the Typescript-based server components on AWS Lambda render the pages within 30 msecs each. AWS DynamoDB powers the data layer.
Feels like 1997 again, but I am Happy with the new stack!
It's funny, a lot of the Svelte fans made me think that it would be very simple and nice, and that React was much clunkier, confusing, and implicit, but my experience was the total opposite
> 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.
Svelte 5 uses a different approach to reactivity using runes: https://svelte.dev/blog/runes
PS. I looked up the reactivity token docs on the Svelte website to make sure I was remembering correctly, but it repeatedly crashes the latest version of Safari on iOS. Oops!
Amen. After being forced into working on a large Vue project as a React dev who had sworn it off, I've slowly come around to falling in love with it. Once you get over the "black magic" of it all, the productivity is insane. For people who just need to get things done, and couldn't care less about millisecond level rendering benchmarks, I would easily suggest it over React at this point.
React is a fantastic rendering library but there are no great React frameworks. Next is ok, but it's a beast that most people don't need. The beauty of something like Vue is having your batteries included in a standardized way that you don't have to worry about when upgrading, while also still being fairly lightweight. The average React app becomes a hodgepodge of dependencies that get frozen in time due to the fragile nature of NPM. Versus having a known and documented upgrade path for your router, state, styling, etc.
I quite love this.
Then again, svelte has a great developer experience, so I would say he's delivering on this.
Can't say the same about SvelteKit though. I've tried it a couple of times and it's just not fot me. It's really a tool built around a client side library and it shows (instead of being a backend framework).
Specifically with SvelteKit the big deal breaker is routing. I also find the whole +page.svelte stuff to be a usability nightmare since I barely use the file explorer to move around a project and instead use fuzzy search. Unfortunately SvelteKit is pretty unflexible so you either love it or hate it.
It's really weird that I agree 100% with all the decisions regarding Svelte itself and how it's evolving (runes etc) but SvelteKit is just a big nope from me.
I assume the same is true of the other checks Lighthouse does for performance, best practices, etc.
Lighthouse and other such tools are a good starting point, and using them is better than doing nothing, but a thorough understanding of accessibility etc is necessary to create truly accessible and performant sites.
> the first time I use Svelte & Kit I feel the same joy as I feel when the first time learning web development in 2015
That sounds pretty awesome. If you have experience with Svelte and this resonates with you, could you explain why?
Like, Svelte isn't better than any alternative in a meaningful way, he's just doing it because he wants to.
Svelte was then like Ractive++ as well
one of the upvoted comments says 'Rich for president'
If one is being super pedantic, tenets and principles aren't the same thing, but they're very close in meaning to each other.
The linked page contains examples of both tenets and principles, and uses the terms interchangeably in the title/intro.
Tenets are positions/beliefs/qualitative statements presented without proof. "The web matters", "No one cares" are examples from the OP.
Principles are related, but more like guidelines or instructions. "Optimise for vibes" is an example.
I still use them. Defining the DNA of your project in this way aids in decision making.
nuff said
Wat.