Tenets(github.com) |
Tenets(github.com) |
nuff said
Wat.
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.
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.
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.
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.
(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.
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.
I bet someone could have added the functionality but it just didn’t matter when all screens were squareish.
make_fancy_dialog(msg);
But, I think other libraries have done this too. React is a great example. It prioritized making the reactivity model really strong, and everything else is less important. (Like performance or bundle size.) To the extent that the official solution to performance issues is writing a compiler for the library to auto-optimize everything, because they don’t want to compromise on the reactivity model itself.
To me, that feels like a subjective choice, going more off vibes than certain metrics. (Not making a value judgement, just explaining what I’ve heard at conferences.)
In other words, I don’t think “objective BS” got us into this place. Shops which care a lot about performance will have “performance budgets” for things like TTFB or time to reactive. It’s a more objective approach that tries to minimize lots of MB going over the wire.
It's a unified ecosystem of tools written by people closely related and désigned to work with one another.
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.
Also, the render tree concept doesn't exist in the internals of GTK (at least; I could speculate about Qt but will not). Rendering is done by invalidating rectangles and then finding intersections with widgets; since there is no z-axis stacking, there's only ever 1 widget to be drawn at a given pixel coordinate.
That is true... but of course, if you wanted 100% HTML, you aren't looking for a framework at all.
The approach in svelte is that you write the HTML parts of your app in HTML. It sounds almost silly to say -- that should almost be a silly circular statement -- but with some popular frameworks you write the HMTL for your app in something sorta like HTML but with various syntactic and semantic differences.
(You also write most of your UI logic in Javascript or typescript. The amount of syntax that is svelte-specific is pretty small, though semantically, the Javascript you write for the UI is built on the svelte concepts.)
That is, the closer to HTML the better.
Plain javascript is a crappy way to represent HTML because both the syntax and semantics are different (and sometimes there are conflicts, like with "class").
JSX is better than plain javascript because the syntax is closer, but the semantics are still Javascript, and there are still a number of differences you need to work through.
svelte is even better, because the HTML parts are strictly character-by-character the same as HTML, but you still need to know the syntax of a few escape mechanisms.
If there were a way to improve significantly on svelte then I'd be all for it. (Maybe HTMX? I'm skeptical of the approach of putting a network round-trip into every UI interaction, but they sure have nailed down the HTML aspect of it.)
Since all of this is client side (and display: none; is the best you can do in terms of not revealing everything to the user anyways) you don't even need any behavior language in HTML. Just set classes to elements and manipulate them with the framework from outside.
Everyone knows what
export let prop = 10
Also, to your point, it’s not actually destructuring. This statement is declaring “prop” as a new property.
And finally, this statement actually does export “prop” to a user of the component. But that’s no longer explicit.
> export let prop = 10
> means.
What? I mean that's technically syntactically correct JavaScript but it makes no sense outside of Svelte, and if the prop is not literally named prop like in your example here, it's much harder to understand what this is doing compared to taking a prop value out of a $props object (or rune or whatever), like you would in many other frameworks.
I'm just a bit surprised because while I like Svelte I feel like all of is like this, it's all technically JavaScript syntax but all of it is magic that only works through the Svelte compiler, and this new syntax actually looks slightly less so to me, although I wouldn't say I prefer it.
export let myProp = 10
In any case,
let { myProp = 10 } = $props
That is, $props is not an object. The string "$props" is a compile-time directive that declares myProp to be a prop. It's not destructuring $props, it's declaring myProp. "$props" is a magic incantation defined within the Svelte compiler.
I mean, this is my point really. It's using JS syntax but it's no longer obvious what it's doing.
To your point, given that Svelte compiles the code anyway, I don't understand why they couldn't have kept the existing syntax ("vibe") and just changed the semantics. Why come up with some brand new, syntactically-compatible- but semantically-incompatible-with-JS, syntax?
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.)
Think, how often do you write a javascript code and think to yourself to debug it by understanding the underlying assembler code. I'd guess it's nil.
But abstractions to html leaks a lot.
Leaky abstractions are never good as now you have to think about your cool framework and the underlying library.
For example, in a world where components are embedded into different places on a website and where users might submit rich text content, you have to rewrite their headers (h1...h6) to fit with accessibility guidelines.
In general that is false statement. In particular, when it relates to browsers, HTML is the local minimum of what can be done to describe the "UI".
Because HTML (well, DOM) is the only thing to describe the UI in the browser, and it's abhorrently awful. It can barely describe a page with static text and some images (and even then tools like Lighthouse will warn you that "you have too many elements on the page" if you dare go beyond 100 or so paragraphs). For the actual UI (yes, UI: complex layouts, interactions, dynamic parts, states, hundreds of complex interactable objects) HTML is unbelievably incredibly bad. Unfortunately that's the only thing you have running in the browser [1]
[1] Well, there's canvas (Google Docs switched to canvas because of limitations of the DOM etc.) and WebGL (pretty much every in-browser graphics program out there). But they suffer from having to implement literally everything from scratch.
Edit.
Just to show how inane "HTML is superior to everything is", here it is barfing at my static web site that only contains text and images (and a total of 9 Youtube and maps embeds): https://pbs.twimg.com/media/GF__tHjXgAAZGUA?format=jpg&name=...
Yes. It chokes on the insane number of .... 943 elements with a maximum depth of 8.
Apropos of nothing, here's a screenshot of a highly dynamic interface like Ableton Live with hundreds of dynamic elements https://cdm.link/app/uploads/2023/11/CleanShot-2023-11-15-at... that the "technical superior" HTML would not even be able to represent, much less render.
In reality it's very hard to find anything that is inferior to HTML when it comes to representing and rendering UIs.
".... for UI *IN A BROWSER*"
- But HTML is lingua franca!
- There’s no alternative, that means it’s perfect
- You don’t need js/json/etc, just use HTML
- HTML is not that bad
- You can choose JSX, but it’s mostly HTML
In the end it is also just a compiler directive for svelte, it doesn't end up in the code the svelte compiler outputs.
Look at this example:
https://svelte.dev/repl/c450c88a415a435485729f4ba88069f1?ver...
If you check the JavaScript output tab on right, this prop declaration in Child.svelte
> export let count = 0;
Has become
> let { count = 0 } = $$props;
Which looks a lot closer to this new rune syntax, so
> does not even remotely work like it would in JS.
Is not true at all, it works a lot like this in JS, or at least a lot more than the "export let" syntax.
Edit:
I want to add to your point here:
> That is, $props is not an object. The string "$props" is a compile-time directive that declares myProp to be a prop. It's not destructuring $props, it's declaring myProp. "$props" is a magic incantation defined within the Svelte compiler.
I get you on this! I wasn't aware it worked like this and replaces the $$Props interface [1] which I am using to declare component props at the moment. I understand your point and I agree that parsing required props and such out of this destructuring assignment is a bit magical, but to be honest in my view not significantly more magical than the rest of Svelte.
[1] https://svelte-5-preview.vercel.app/docs/runes#$props-what-t...
I think this is the only place we really disagree. To me, the export syntax is obvious and consistent, even if under the covers the behaviour is magical.
On the other hand, the $props syntax is not obvious; for a putative assignment to result in a declaration has no basis in my previous experience. Both the syntax and the behaviour is magical.
If Svelte is about the vibe, Svelte 4 was perfect for me - it’s why I moved from Vue, which I found had too many magic objects, and then doubled down on it with Vue 3 (I think) and refs. With Svelte 5, I feel it’s making the same mistake - the vibe no longer gels with me, and I gotta say, in addition, that pushing reactive behaviour into pure JS feels like a huge mistake to me. Sadly, I think I’ll be getting off this particular train.
Edit: I think my reaction to this is because $props - and the other runes - are effectively svelte-specific keywords added to JavaScript. I'm sure the Svelte folks have their reasons for this; but I hate it. They could have just introduced a new actual keyword, like "prop myProp = 5". I honestly can't see myself ever adopting Svelte 5.
> At first glance, this might seem like a step back — perhaps even un-Svelte-like. Isn't it better if let count is reactive by default?
> Well, no. The reality is that as applications grow in complexity, figuring out which values are reactive and which aren't can get tricky. And the heuristic only works for let declarations at the top level of a component, which can cause confusion. Having code behave one way inside .svelte files and another inside .js can make it hard to refactor code, for example if you need to turn something into a store so that you can use it in multiple places.
(https://svelte.dev/blog/runes)
If the vibes are subjectively off for you with the new syntax that's fair, I just can't get it to align with what you are saying because at the end of the day, they are removing some Svelte magic and replacing it with regular JavaScript, apparently even the "$" label dependency tracking stuff, which I find to currently be the most magical thing in Svelte
To me that looks like a step to making Svelte more easy to reason with, but vibes are subjective in the end.
Anyway I certainly agree that the vibe is subjective, but I for one am bitterly disappointed by Svelte 5. It’s yet another framework that can’t make up its mind, and stick to it.
2. Even in the browser it's the worst possible system
3. The original comment I was replying to didn't make any references to "in the browser", and explicitly talked about things like QML and XIB which are very much not in the browser.
Needless to say I agree with everything you've written, and also appreciate the use of a DAW screenshot to make the point.