The direction React/NextJS has taken modern web development is a modern day abomination. I say this as a passionate fullstack developer whos worked for YC startups and a fortune 10 company within the past decade. I appreciate Vercel as a company too; I have no hate towards them but the NextJS 13 release almost made me quit web development.
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 -_-.
So glad to see someone else say this. NextJS 13 was (is) a complete an utter disaster.
I took on a reasonable-size project around that time and the documentation was incomplete, no library worked on it. Mystery caching and fetch-call deduplication all over the place. It was horrific. I wonder if things have improved since.
The trick is to just stick to the Pages Router in Next. The app router and RSC is still too early to use, imo, and needs at least another version or two to gain some support.
React and NextJS, although technically part of the same sub ecosystem, have very different approaches to DX, backwards compatibility, marketing and commercialization...
I've been enjoying Astro+Svelte. I tried using Sveltekit and couldn't really get into it; I'm sure there are situations where it would be better than Astro + Svelte, but I don't know what they would be.
Now I know why I dislike Svelte so much, I don't believe in its principles. Which is perfectly fine, a framework can't please everyone.
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.
I'm not a big fan of HTML itself, but I do think svelte is right to focus on it for specifying UI.
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.
> I like explicit behavior and I think that is my problem with the whole wrap everything in observables approach. It's too magical
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.
You're just pointing out that svelte isn't 100% the same as HTML...
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.)
Sure... but there are degrees of closeness to HTML and the closer to HTML it is, the less translation you have to do and the easier it is to deal with.
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.)
I'm not buying it. Svelte's template language also has different syntax/semantics from HTML as well - arguably just as much. The JSX parts are character for character the same as HTML as well, except for the class/className distinction (which if you have used Preact it does not have that issue).
Svelte does not make any opinions about HTML attributes or tags, unlike JSX which contorts language standards such as `className` or disallowing style="..." without JS in CSS.
It's html plus adhoc behavior description language. Behavior does not belong in HTML. You shouldn't have full programming language in HTML. And if you do, at least use existing language not make your own.
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.
> HTML is the native language for describing UI in the browser
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.
That's not the same because the abstraction a mature computer language provides is nearly complete (not totally complete, of course, but the situations where you ought to go digging through machine code or lower are pretty rare).
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.)
Abstractions are great, as long as you understand their performance implications. Some are essentially free, some are surprisingly costly if you hold them wrong.
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.)
Open the browsers dev tools and you see HTML. Read MDN and you see HTML. Constantly translating back and forth between that and another language isn't worth it.
Though if there was a better language to describe the UI which is as performant, widely supported and documented as HTML, I can easily see people using it. Maybe someone will start that project today based on my comment, and a decade later browsers will integrate it natively because it's such a success and everyone is using it :).
I've found that web accessibility often calls for nice templates and abstraction, not less, because you often need to do some dynamic rewriting.
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.
problem is, the most important "abstractions" for describing the UI are not built "on top of" HTML, but along side it (CSS and to a limited degree JS). the relationship between contemporary "frameworks" and HTML is not like that of C and assembler or even Rust and assembler. It is more like that of a driver of a vehicle that has each of a gasoline, electric and steam powered motor, and must constantly pick which one to use for a given situation (sometimes two and occasionally all three).
> HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces.
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.
Also, these differences in syntax and opinion are why I vehemently support and work on web components. You shouldn't have to have two incompatible silos of UI building just because of some frankly minor differences in preferences.
Component authors and component users should be able to seamlessly interoperate which disagreeing about such trivial things.
I'd say that it's better to use real programming language, but you shouldn't use it in JSX beyond the simplest statements like ifs and loops.
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.
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.
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 agree - mileage definitely varies with people. Prefer markup languages over code for describing user-interfaces any day. Find myself quite comfortable with XAML and struggle with SwiftUI.
It depends on the markup format, language, and libraries of course. However in general I prefer code. Why? While it takes a bit longer to get started, you can factor patterns into reusable methods and before you know it are working at a higher level:
make_fancy_dialog(msg);
Html only recently got templates but I don’t believe they are that powerful.
I suspect that the dominance of HTML is largely due to it being the only browser native markup language. Crucially, the browsers' dev tools always show HTML and having an obvious mapping from there to your code is hard to beat.
I personally dislike HTML due to the verbosity. I prefer hyperscript.
> I disagree a lot on HTML here - it's a pretty fantastic way of describing a render and layout tree,
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.
Well, the constraint layout system that Apple introduced (sorry, I am drawing a blank on the name) is sufficiently different that I'd say that although technically you could call it a layout tree, that is really missing the point.
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.
I am not a svelte user, but I really like these principles.
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.
>HTML is not the mother language - It's actually pretty terrible for describing dynamic user interfaces.
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.
> There's literally nothing better than HTML for UI.
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.
I was responding to this: "There's literally nothing better than HTML for UI."
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.
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.
Even after all that, you still haven't made explicit the thing that needs to be explicit for any of this to make any sense:
".... for UI *IN A BROWSER*"
I know it's convenient to forget the millions of us who spent years and continue to spend hours implementing UIs outside of a browser context, but it certainly doesn't feel very polite.
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.
That said, there are examples of these being implemented in-browser. Not sure how any just use the canvas/webgl vs. the DOM (I know examples that do each).
I don't think anyone's trying to be impolite or diminish What Came Before, but HTML is used for lots more than websites and browsers. (Examples that come to mind are email, desktop and mobile apps, ebooks, and digital signage.)
Yes. Unfortunately we've not inly settled for one of the worst systems, but we additionally further settled for limited subsets of it as well (email, ebooks)
"There's literally nothing better than HTML for UI" and "There's literally nothing better than HTML for UI in my browser" are two different statements; anyway, until relatively recently there was XUL.
HTML was designed to describe single A4 page of single column text.
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.
Even some of the "proprietary nonsense" is better than HTML. Visual Basic let you just drag-and-drop controls onto a page, arranged in any way you liked! Now, it wasn't responsive, but we didn't have smartphones back then so nobody cared.
I feel like this phrase is causing confusion and the distinction the author is trying to make is clear in their mind but very unclear to read.
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.
I agree, I'm not going to learn yet another DSL for describing basic programming constructs when I can just...use a programming language itself. The lack of TypeScript and LSP support for quite a few of these DSLs is also very annoying, you're basically reinventing new tooling for every new framework.
No accounting for taste, I suppose. Writing JSX is a nightmare to me. It's like we've forgotten 20 years worth of hard-earned knowledge about the value of separation of concerns.
What is the value of separation of concerns when it comes to UI? Because I find not colocating the logic and styling for a component to be very annoying when it comes to looking for the right files.
The component DIR should have css, logic/js and template/markup. Seperation of concerns right down to component level. It really comes down to how organised the devs and their tools are.
Do a 5 why for separation of concern and you'll find JSX is more logical.
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.
I agree with you about separation of concerns, but I don't think JSX is the guilty party there, so much as the overarching frontend ethos that pushes the idea of "single file components" to extremes.
Yes, I also don't see the charm. JS/TS are more expressive, you can have composition and modular code natively. Also JSX is 99% HTML.
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.
> 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.
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!
> Instead of striving to be the fastest or smallest or whateverest, we explicitly aim to be the framework with the best 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.
> Except that svelte advertises itself constantly as being faster and with smaller bundle sizes.
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 gotta say, the “vibe” of the new $props syntax, to me, is awful.
I love that I can just use
export let prop;
because it’s just JavaScript.
The new runes syntax
let { prop } = $props
Is not. This just makes me incredibly sad.
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.
Because it’s introducing a magic global compiler directive - $props - that’s unique to Svelte.
Everyone knows what
export let prop = 10
means. But what’s $props? It’s a magical invocation (literally, a rune) of a compiler directive. So while it’s valid JS, it’s actually a signal to the compiler, with special behaviour. It’s something you need to learn and understand beyond just JavaScript.
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.
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.
work in any JS module? I thought it was quite standard. Maybe I'm mistaken, JS/TS is not my first language, but I think it's pretty obvious what it's doing.
In any case,
let { myProp = 10 } = $props
does not even remotely work like it would in JS. It's literally a compiler directive.
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?
What do you mean by "work"? You can export a mutable variable yes, but why would you? It makes no sense outside of Svelte and it doesn't relate to the rest of the code where you presumably use that variable as if it was set from the outside at the moment you were exporting it or something along those lines.
In the end it is also just a compiler directive for svelte, it doesn't end up in the code the svelte compiler outputs.
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.
> 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.
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.
Interesting, because now that I'm looking at them a little closer, it seems to me runes are reduction of magic objects in Svelte
> 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.
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.
I get that runes are in some sense a reduction of magic, I just don’t see the point. Svelte 4 feet, to me, incredibly natural to write, because the choice of idioms matched so closely with the behaviour I’d expect from JavaScript. Going into Svelte 5, I hoped to see fixes for the things that bit me - missing transitive reactivity in $:, for example. But not wholesale changes to the way you declare and use the framework.
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.
As someone used to doing everything with vanilla JS and having troubles with getting deep into any web frameworks (especially React), Svelte has been a godsend. I'm in love with the philosophy and approach and its natural combination of JS/CSS/HTML is, in my personal bubble, second to none. Most recent experiment was https://meoweler.com, but I'm now trying more complex projects and can't sing high enough praises. I sincerely hope the future of Svelte is bright.
Svelte and SvelteKit have earnt a place in my heart. They've allowed me to enjoy learning reactive- and component-based development. In comparison, React has always felt like a chore, and I avoid it as much as possible, despite it being the most popular framework.
(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.
Ha, did not expect this to be on the front page of HN today! Some quick context: in January I was in London for a few days, and while I was there we had a Svelte Society London event.
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.
Thank you for creating Svelte. I have basic web dev experience using no-framework. Is there any high level overview article explaining how Svelte compiler transpiles Svelte file into a series of html,css and javascript and wires them up together?
After several React projects, I recently went “back to the roots” and created an app with server-generated HTML using the ages-old Mustache templates.
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!
Chose Svelte for a client project 5 months ago, client loves the speed, I love developing with it. In general it's quite a nice tool, fast development, feels easy to learn. I do dislike server-less functions, which comes in pair with Svelte ability to do SSR, which doesn't have to do anything with Svelte tho.
Svelte to me is how objective progress in building the web looks like, much like React was just much better than Angular 10 years ago, Svelte just makes sense.
Whenever I've tried Svelte I've honestly had a horrible experience, which surprises me somehow. It definitely failed on the "magical, not magic" thing. The exact workings of $ is still extremely confusing
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
I believe this was likely referencing your topic of confusion there to at least some degree:
> 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.
I feel insane whenever the Svelte reactivity thing is touted to me as an improvement over React state. Surely it’s not so hard to internalise JS equality rules that such a huge break from convention is necessary?
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!
> We want Svelte to feel magical — we want you to feel like a wizard when you're writing Svelte code... 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 that. 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
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.
>What makes Vue "insanely" more productive than React ?
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.
Vue is a unified ecosystem of tools written by the same authors and designed to work with one another. React gives you way more rope to hang yourself. Good luck figuring out what the routing and state management flavor of the minute is.
Svelte 5 moves closer to React in quite a few ways. The single component per file is still a dealbreaker for me. React got it right with composition and being able to break a component out into its sub-components.
It's absolutely not. It works wonders for the community. Sorry for saying, but I am quite certain such a comment as yours is a rare sight in the svelte community.
Everything in svelte is around showing others how to do it. Most questions in the forum are solved with concrete examples despite its awesome documentation. People help each other. Good vibes ;).
That's a good thing, we should embrace it more — we should be more driven by gut feelings than "objective" bullshit, that's how you end up with nonsense like megabytes of JS going down the wire in the first place.
I halfway agree with the first part, and I like the statement by the maintainers.
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.
I started using Svelte a couple of years ago and I love it. Very quickly it became the only client side solution I want to use.
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).
It's severely lacking in the backend but I guess this is more of a general issue with all so called full stack JS frameworks.
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 wouldn't judge any JS framework like SvelteKit or Next.js on its lacking in the backend. They have a server to handle frontend problems, not solve your backend problems.
I think it’s wonderful that their official website doesn’t even work in iOS 14.3 Safari, which is only 3 years old (it crashes completely with “500 internal server error”). I encourage everyone who genuinely cares about the web to stop updating compulsively and just allow themselves to be gracefully excluded from this foolishness.
It's a set of performance tests built into the Chrome dev tools. It profiles your site on a variety of metrics and gives you a report. I'm not exactly sure what's wrong with it in the context of this post.
I've recently started using Lighthouse to test sites for accessibility compliance, and you can easily get a score of 100 without actually addressing all the accessibility issues a site might have. So, if you're not conscientious, you can just point at the score and say "all good" while your site might still have major issues.
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.
I like the general idea of Svelte, but last time I tried it, it required a lot of bloat (tens of files) for just a simple “hello world” project, which put me off.
I wasn't ever very tempted by React when it started getting hot because I had started using Rich's component library Ractive and it was so obviously better than React
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 -_-.