Svelte is a language
gist.github.com> Svelte is a language.
All Javascript frameworks may become implementations of SAT solvers, where rendering and state are scheduled constraints, i.e. tiny operating systems.
NPM uses CSS as a query language - https://news.ycombinator.com/item?id=33136843 - 9 months ago
Then apps may be instantiations of the framework.
They should be SAT solvers, but people also want them to be vague and super flexible. Many people I know responded to Apple UI constraints (what was the name again?) with ‘what am I, a math professor?’. People want throw poop against a wall and smear it around and when they are happy with their work, they want to press a button and get the absolute optimal result that fits their broadest use case.
No different from what most non-frontend developers want by the way.
Problem is; that is not yet possible at all, because ‘the spec’ is too vague and strictness generated from vagueness will either be just vagueness (cannot find any constraints to throw into a solver so just leave it) or too strict (where many cases simply are suddenly forbidden that were actually feasible cases by the author).
The really exciting thing about svelte is getting rid of the virtual Dom. Having everything just be explicit JavaScript code that modifies the Dom manually makes for really readable code. If you have not tried it, got to the svelte tutorial and look at the output code. It's awesome.
I don’t follow… in what sense is this JavaScript?
Specifically, what is on:click? It doesn’t look like JavaScript, and it doesn’t look like the DOM. It looks like a new language which is specific to Svelte.<button on:click={incrementCount}>Or what about this… is this JavaScript?
Or…$: doubled = count * 2;
Or…{#if user.loggedIn} <button on:click={toggle}> Log out </button> {/if}
I am willing to believe that all of that is ergonomic in some way, but it doesn’t appear to me at first blush as very JavaScript-y, or explicit. I see a lot of black box stuff controlled by a declarative API.<button on:click|once={handleClick}> Click me </button>> I don’t follow… in what sense is this JavaScript? > <button on:click={incrementCount}>
it's not. it's html. incrementCount is a pointer to a javascript function.
> Or what about this… is this JavaScript? > $: doubled = count * 2;
Yes. $: is a javascript label. We use it to indicate that a function should be reactive - if the count variable changes, the right hand will be rerun and double updated.
> <button on:click|once={handleClick}> Click me </button>
html again. the |once is a modifier to click which detaches the handler after a single use. It's a directive in the html markup (still valid html) which the compiler picks up and converts into node.removeEventHandler.
While this is all technically true, I don't think it's all that helpful a thought process to have when approaching Svelte. Yes, Svelte files are syntactically valid HTML, Javascript, etc, but they have very different semantics.
Take the ability to reference functions in HTML - this is simply not possible in normal HTML, where inline event handlers instead are passed Javascript expressions to evaluate. It's definitely a useful feature, but it's very clearly outside of the normal realm of HTML.
This goes further with Javascript: here the semantics differ considerably, with labels in normal Javascript doing nothing except when dealing with loops, and labels in Svelte are a form of reactivity. You've also got things like dollar signs interacting with stores, and other semantic differences.
As Rich Harris says, Svelte is a language.
<div onclick="handleClick">Click me</div>
100% valid HTML and within "the normal realm of HTML". The event is passed as a parameter to the function. Has been available since the introduction of JavaScript. Predates addEventListener(…) and its ilk by a few years.
Yes, "$:" as a labeled break exists outside JavaScript proper. That said, given the rare cases where anyone uses a labeled break and how unlikely that labeled break would be named "$", it seems a pretty safe extension to the language to allow such powerful behavior.
Both "$:" and "$store" are not magical; they are quite deterministic and serve to substantially reduce the total amount of boilerplate. Seems a fair tradeoff, but you are correct, it's a superset of the JavaScript language.
Now let's discuss the "naturalness" of useState, useMemo, and their ilk. I'll take Svelte's minimal "magic" over the verbose, repetitive, and error-prone library API logic, thank you very much.
> 100% valid HTML and within "the normal realm of HTML". The event is passed as a parameter to the function. Has been available since the introduction of JavaScript. Predates addEventListener(…) and its ilk by a few years.
Like I said, it's valid HTML, but it doesn't do what you're describing (and you can try it out fairly easily in your browser). The "onclick" handler executes the code string that it's given, working essentially the same way as `eval` or the `new Function("...")` syntax. It does not take a function pointer.
So in this case, the only thing it executes is a variable pointing to a function, which doesn't do anything because the function isn't being executed. You would need to add the function brackets to get any sort of effect.
This is the crux of the issue: Svelte is an additional language that happens to use the same syntax as HTML and JS, just with different (in some cases very different) meanings. You are not just writing "explicit Javascript code", you're writing Svelte code (which in most cases is probably very easy to pick up if you know Javascript, but it's still a different language).
Compare and contrast with, say, Typescript, which is syntactically different from Javascript, but semantically identical - just remove the types, and you have normal Javascript. (In fairness, with old decorators and enums, this isn't quite true, but it holds in general.)
To be clear, I don't think that's saying that one thing is better than the other, or that Svelte is bad because it's a new language or something. I think reactive primitives in Javascript are important, and adding them directly into the syntax of the language is a really clever way of solving a lot of problems in this space. I'm not sure if it's the solution I like the best (I've really enjoyed working with SolidJS signals recently, which provide some of the same ideas with a more typically Javascript-like API), but it's good to see experimentation here.
> which the compiler picks up
I think this is the crux of the gp's question. The browser doesn't support explicit behaviours for "on:click" or "|once" (the "$" label is a cool trick I'd forgive the gp for not recognising as native JS) - it may be "valid" HTML but it's not "just HTML" (nor just JS), it's a DSL.
It does support onclick though. This isn't a far off derivation. Also "|once" is a whole lot cleaner and more terse than the "once" variant of addEventListener, to be sure.
Anyone who already knows HTML and native event handling could pick this up in less than 5 minutes. Good enough.
Author means explicit after compiling.
Reminds me of Angular
Angular template syntax is correct HTML syntax. It's nothing like the examples abovd.
https://angular.io/guide/binding-overview
Haven't looked at angular since 2015 to be honest, but it still seems like they do weird html stuff to me, such as:
<ul> <li *ngFor="let customer of customers">{{customer.name}}</li> </ul> or <label>Type something: <input #customerInput>{{customerInput.value}} </label>
Angular will soon be migrating to the Svelte style of conditional flow control. https://github.com/angular/angular/discussions/50719
I agree with you, it looks weird, but my point was that it's correct HTML syntax, even though you cannot expect it to work if you open an Angular template in a browser, but an HTML parser can tell you it's syntactically correct.
> HTML parser can tell you it's syntactically correct
Which is completely useless because your website doesn't work anyway
This is true of Svelte's syntax as well, is it not?
Not really on:click is not valid HTML
Oh, that makes sense, I get you now.
You're telling me on:click={toggle} is nothing like (click)="toggle()"?
it's not. `toggle` is a pointer to a function name and "toggle()" appears to be an expression which is parsed and then executed (scary).
you can on on:click={() => toggle()} in svelte which is more similar, but it isn't parsed and executed, it is a pointer to an anonymous function which is directly executed.
on:click={toggle()} in svelte would run the function immediately (probably not what you want) and return the result as the handler for the on:click
so quite different, really.
Not a pointer to a function. In JS, functions are first class objects. You might as well say toggle() is an invocation of a pointer to a function.
<div onclick="toggle"> has existed since the dawn of JavaScript in Netscape Navigator 2.0 Beta Gold. Your complaint about the syntax is in fact baked into the foundations of the web.
One is syntactically correct HTML, and the other is not. That's was the only point of my comment
I haven't used Svelte beyond a couple toy tutorials, but, for me, the infrastructure adapters [1] are the most exciting thing. I love the idea of being able to build using Svelte and auto-magically deploy to something like Cloudflare Pages without completely giving up the potential to deploy somewhere else.
I've got mixed feelings about this and I'm sure I'm in the minority. Those adapters are usually supported by the commercial company that wants you to use them. But, for example, the static or node adapters often don't work great with the important parts of svelte kit like SSR, and feel like second class citizens.
I love svelte but I'm having a hard time getting the same development ergonomics out of svelte kit. It's probably just me.
adapter-static is meant for generating fully static sites. It's fundamentally not aiming to and cannot support SSR in that context. However, SSR is fully supported in adapter-node, which is well maintained.
Infrastructure adapters are becoming table stakes for frontend frameworks.
Which other frameworks have them out of interest? Sounds like a great feature. AFAIK Next doesn’t and it’ll be interesting to see if it gets them given it’s from Vercel. When I tried Remix you had to choose your deployment when initialising a project and it didn’t look trivial to change it, but that was a while ago.
Solid & Astro.
First we were excited for the virtual DOM which is good for batching updates, flexibility, efficiency, etc. But now the cool thing is to get rid of it?
Never been excited in the least by it. Being too clever imho. Problem is: I don’t often get to dictate what we use so there I am, caught in the web.
not everybody was excited about the virtual dom. people who looked closely at it weren't particularly excited.
Browsers are not the same as they were ten years ago.
> Having everything just be explicit JavaScript code
This is funny because it's exactly the reason I prefer react
Agreed, I want markup in my logic — not logic in my markup
CSS and HTML in JS was always a bad idea. HTML can live on its own. JS is a dependent technology, on the same level as CSS. The HTML was always the foundational technology.
Centering JS has always been like putting the cart before the horse.
This seems intuitively right but doesn't really result in good outcomes in practice (I'm curious if you have any concrete reasons to justify saying it "was always a bad idea").
In practice what I've found is that HTML is fine/optimal for event-driven interactions layered onto entirely static content, but for inherently interactive UIs, what ends up happening is you get one of two systems:
1. If you start from a HTML-forward standpoint, you can go a certain distance separating your concerns entirely, but at scale the drawback is maintaining disparate references, negatively impacting code colocality: having to edit a reference in three separate files in a repo is incredibly bad for DX and readability. To overcome this, a common approach is to make the JS side generic by embedding DSL with dynamic functionality into your HTML: the worst of both worlds, creating both a Frankenstein HTML+weird-extras language and still needing to bundle JS with it.
2. If you're starting a greenfield project with the early intent of having a fully interactive UI, instead of growing into it, you can avoid the above mess and architect your project from the offset with good code colocality by embedding templates for highly dynamic/transient UI components into the imperative part of your application logic (i.e. the JS).
Svelte is neither a Frankenstein nor incredibly bad. In implementation, the compiler is JavaScript and there is JS bundled in the output. However, the developer experience is comparatively indistinguishable from plain old HTML, CSS, and JS in a substantially similar form to a static HTML page to the point where vanilla JS libraries can bind to HTML elements without modification. This is in fact how I develop for Svelte: I start with a static page, put in some elements and CSS to look like my design target, drop them into Svelte largely unmodified, and add if/each/await control flow.
I have yet to find a greenfield React project with more than a few developers over a few years that didn't turn into a big ball of mud that only the original developers could understand (at best). State management alone on React is an utter, total, and indisputable shitshow. Codebases with a mixture of classes and functional Hooks are far from ideal for developer experience.
Svelte code by comparison is a breath of fresh air both to develop as well as maintain. Whether Svelte wins or something inspired by Svelte does not matter as much to me as something that takes away the inverted JSX model, the virtual DOM, and allows the use of vanilla libraries without React wrappers interfacing with other React wrappers.
> Svelte is neither a Frankenstein nor incredibly bad.
"bad" is subjective I guess but "Frankenstein" can equally be applied to ".svelte" & ".jsx" - both are non-standard amalgamations of imperatives with markup. In my mind the qualitative differences here end up being in parser support (jsx as a js language extension, svelte as... I'm not sure... not quite a HTML extension but closer to it I guess) and output consistency: this is either dynamic output by the node server in Svelte's case, or perhaps a multifile static bundle with Sapper/SvelteKit; that bundle taking various forms depending on your bundler chunking plugin configs, etc. JSX in contrast is a line-by-line one-to-one simply defined translating to basic native JS render calls: it's eminently auditable and will work with an infinity of preexisting testing/parsing tools that support basic JS.
> I have yet to find a greenfield React project with more than a few developers over a few years that didn't turn into a big ball of mud that only the original developers could understand (at best).
I've seen this with Svelte and React in relatively similar measure (I've seen hundreds of large React projects, some elegantly structured but most a mess. I've seen <20 large Svelte projects, all much much younger, all but 1 a complete mess). All in all this is a problem with the development/developer landscape and not either individual project dependency. Contributor scale is a hard problem.
very interesting, i wonder what's your opinion on tools like htmx which work on the exact opposite basis
this!
Using the label and block syntax for this was a stroke of genius.
Two great things about this "thinking inside the box" approach are:
1. You're encouraged to use native APIs because they're highly unlikely to clash with the framework.
2. You can a legible stack trace. After all, the only thing the compiler does to your JavaScript is add some instrumentation here and there.
Svelte Kit is great for static is "classic"-like websites.
I've converted my company website to svelte-kit from first Angular, then Vue.
But for SPA it's bad. If you use oidc auth. There's only Auth.JS and it's a confidential client, for Svelte Kit.
If you're not using svelte-kit you can use vite to create a Svelte SPA. There you can use your PCKE client as usual and burden the load on the client.
I have yet to experiment with how well it works with a graphql client. Apollo has its own cache but I'm not sure there is a svelte version of it. There is for Vue. Does it even need one? The default is for React. Is Apollo even needed? Questions over questions.
Why Svelte? Performance. Performance matters, a lot.
Svelte being a "language". First time using a template system? I have to wonder.
SevelteKit has some rough corners. The debugging is not as smooth especially because these frontend frameworks needlessly insists on being server side framework first for no reason specifically because server side frameworks have very strong, battle tested options ranging from Django, Flask, echo, Rails, sinatra and what not.
This makes tooling complicated and a debugging that works out of the box for both server and client side is non existent even in SvelteKit 4.
When I'm picking up SvelteKit, it's only for its routing which isn't so great either with file based arrangements, things get out of and pretty fast.
you can still use your own backend for all of the business logic which is maybe easier than doing it in svelte directly.
Svelte is a major improvement on vuejs. It is a pleasure to work with. I can’t stand react / JSX. Highly recommend anyone who preferred vue over react to give svelte a try.
I disagree. But I am someone who deals with frontend tech sporadically as opposed to spending all/most of my time working on UI.
I was excited about svelte, but have found that coming back to my svelte project after a month or two of not using it was arduous because of all the myriad language level things. There are just too many little svelte specific things to keep track of in head.
In contrast coming back to a react/vue project is much easier for me, because even if I forget something at the end of the day any vue-directive or react hook is just another js/ts api I can easily lookup.
In particular, I find the DX that volar+vscode offer in a project with vue3, composition API & pug templates to be better than anything else I have seen in the FE ecosystem in last 5 years.
I also don't find the enhancements for local reactivity to be major value additions because most of the times my state resides in a shared store. I find the vue reactivity model to be simpler to deal with because I can create shared stores which can be (deep) mutated from any component and it all just works seamlessly.
I've done a lot of contracting jobs and I get to see a lot of codebases and had the exact opposite experience, Whenever I see react or vue code, and in particular react, I feel like I have to relearn everything because the combination of external state libraries and to top it with translation specific code and libraries makes it such that each code base is very different from the other. It almost feels like you are learning a new framework altogether. The other issue is not directly related but because there are so many external dependencies, there is this constant slog work to keep everything updated due to constant vulnerabilities that keep popping in our CI tool.
Familiarity wise Angular has been probably the easiest to jump into and maintain long term, but it is a pain to work with due to the amount of ceremony involved to do even the simplest of things.
Svelte codebases due to the very nature of Svelte are simpler and very straightforward to get into, there are some svelte specific things but they aren't too many of them and are simpler to reason about when compared to codebases built on hooks, and even worse are hooks in combination with junior Devs. It is very very easy to write bad react code and you see this way way too often. Most react code out in the wild is badly written, you don't see problems because the browsers and modern computers are performant enough to hide them away but you do notice as the codebase grows and you realize it too late that the very foundation was wrong.
I don't mind Vue and just see svelte as a nicer DSL over it.
You can create a shared store and mutate it from any component, not sure what’s missing there.
I was primarily saying that I find the DX of vue's reactivity to be more intuitive in the context of my application. I didn't intend to say there was something that was possible with vue which wasn't with svelte.
Last I checked (and things may have changed since) is that svelte didn't support transparent reactivity for deeply nested objects. So something like `$myStore.foo.bar = "baz"` wouldn't trigger a component update, you need to remember to use .set, .update etc. You could assign to local reactive variables but you couldn't assign to stores.
I am sure the library authors made these trade offs thoughtfully, I was just disagreeing with the blanket statement that Svelte is generally a major improvement over Vuejs.
This is true and is a fair point.
Or use a module context depending on your scoping needs. Agreed, not sure what the GP is talking about.
I preferred Vue over Angular. I certainly feel attracted to Svelte.
I'm currently finally doing a big React project, and boy, the complexity is spiraling a bit out of control. It's certainly not DRY.
Big ball of mud. The muddiness is always exacerbated when increasing the number of developers, especially when they disagree on Hooks.
Specifics needed (please)
One thing is that sveltekit is a “batteries included” opinionated framework. Everything you need is there, the docs are excellent, you don’t need to make any decisions to get the fundamentals of routing, stores, directory structure, and other basic things working. This is the opposite of the traditional nodejs / JavaScript ecosystem of selecting a hodge podge of libs to get even a minimal thing going.
I love the idea of "thinking inside the box". It's a great encapsulation of the hacker mindset. A fun talk about it in another context (impro theater): https://www.youtube.com/watch?v=bz9mo4qW9bc
Give a quick glance to Svelte. Help me understand, how this syntax {#if expression}...{:else if expression}...{/if} can be seriously invented in our... more civilized age?
It’s not the most pretty syntax, but it’s wayyy better than React’s terrible (expression ? … : …) or (expression && …)
react didn't invent that syntax. This is a standard piece of C like syntax that most (but not all) languages with curly braces share. JSX/TSX used in react don't make this choice for you, you can use any javascript syntax which can be used when passing a value (eg in a function invocation, or variable declaration). If you don't like it, you are perfectly free to declare a variable and set its value using a regular if / else block and use it directly from the template.
My point is this is not a syntax decision that React made, but svelte's syntax was (as far as I can tell) a decision.
I mean, yeah, the ternary operator is part of JS syntax. But it WAS React’s choice to not include any alternative way to if/else add an element (there is an if/else but only for the entire component, not just for conditionally adding one element within a component). So indirectly this is React’s syntax decision.
Because React is JS and Svelte isn't
React is JSX*
Nothing preventing them from making an <If condition={…}>…<Else>… component
And this is typically how conditionals work in SolidJS, which also uses JSX but adds extra core components to handle conditionals and iteration. In fairness, this is largely because they can better support the reactivity model that SolidJS uses, but it's a convenient side effect.
There is nothing holding anyone back from using (expression ? val1 : val2) in svelte though. So, we're not missing anything that JSX/react has got. The {#if} thingy is just a bonus which is welcome in my opinion.
you're equating it to string interpolation. It isn't. It's a compiler directive which disappears when compiled, which is why it is expressed as a brace expression rather than a tag.
How would you do it?
I don't know should I stick to mustaches (it can be dictated by other reasons), but if I should: {#if expr} {#elseif expr} {#endif}
These sigils seem to exist to make it easier to balance the expressions. I personally find {#if} … {/if} much more intuitive. {:else} is an unfortunate compromise necessitated by the fact that elseif is ugly in most imperative languages.
I much prefer keeping everything XML-ish:
Great insight. It feels like at some point reactivity as a language primitive should be built into js. Most frameworks start with this and then build out into a opinionated implementation, dissolving the ecosystem into framework fragments. Any known reasons why this is / was never implemented?
Or maybe one day people will realize render functions explicitly listening to event emitters is actually a better pattern than implicit reactivity.
I think it is a shame that the Observable proposal [1] still seems somewhat stuck in Stage 1. It's a better idea than just raw event emitters because of composability (if no other reason). Making Observables "first class" could go a long way to unifying a lot of reactivity patterns in various frameworks, in theory at least.
To be fair, Observables and especially Observable composition has a rough learning curve and many frameworks like Svelte intentionally prefer implict reactivity and avoiding things like explicit Observables because they are seen as too complex/"too hard" for the average developer.
(Then you get awful worst of both worlds frameworks like Angular that sort of rely on Observables but yet also don't trust teaching Observables and wind up with code that isn't properly Observable and so also has all the code for implicit reactivity and is full of nasty escape hatches that cause all sorts of composition problems and unnecessary side effects.)
I really, really love Observables as an imperfect solution in an imperfect world, but I don't think they will solve reactivity.
The main issue is, that it becomes a nightmare to transmit and compose meta-information. An example would be the fetchStatus of ReactQuery [1].
I way too often end up in situations like this:
I wonder if it is possible to create a mixture between React hooks and async/await. Since you tend to work in one big scope, you could ignore the meta-info until you need it..map { unwrapMetaData ... rewrapMetaData } ... .map { unwrapMetaData ... rewrapMetaData } .switchMap { // unwrap metadata and wrap it in an observable combineLatest(...) // have fun juggling an array of nested monads :) }
[1]: https://tanstack.com/query/v4/docs/react/guides/queries#fetc...async live function() { const { value, meta } = observe getValue(...) // suspends when loading, throws on error // work with values const multipleValues = observe Observe.all(...map(i => ...)) // more work // evaluateMetadata }You can already combine hooks with something like Rx using the useSyncExternalStore hook.
I’ve worked on very complex Rx code bases. I like Rx, but it gets it be a huge pain the debug when you have very complicated chains. I haven’t used hooks too much, but from what I’ve seen the default behavior is to “do the wrong thing” which makes them very annoying to work with. The implementation of hooks is also very hacky. Like you can’t create a hook inside an if statement. That’s crazy.
I've had some success with writing Async Generator functions in mixed RxJS/IxJS pipelines.
(I've done similar things in C#, as well, with its Rx/Ix pair.)async *function someMapOperation() { const { value, meta } = await getValue(…) doSomething(meta) yield value for await (const { value, meta } of AsyncIterableX.from(mergeAll(…).pipe(takeUntil(…)))) { doSomething(meta) yield value } // … }You are right, there are still good cases where being able to write the "state machine" of a complex flow as an async (generator) function makes it a lot easier to reason with. The nice thing is that Observables work well with AsyncIterables and a pipeline doesn't have to be just one or the other.
Svelte Stores: observables without all the boilerplate. If you want to do manual subscribing and unsubscribing, you can of course. Stores really are quite flexible if you really want to dive deep into them.
Certainly I've had a lot of fun with wiring mobx up to various things that provide render functions (react with mobx viewstate classes is way nicer than hooks to me).
Svelte I've never quite got the hang of to the point where I feel comfortable expressing an opinion about it (and I haven't spent enough time experimenting to claim my not having got the hang of it yet means anything either).
Mobx as your ViewModel/Model selector implementation is precisely where it belongs in your stack. You just need to be disciplined and not build your whole state/update loop on it. Sadly, I'm stuck on v4.5.x at work, and my big complaint is arrays not being a first-class observable.
> You just need to be disciplined and not build your whole state/update loop on it.
If you have a minute, I'd love you to expand on that. I have some thoughts along those lines myself but I suspect you've spent more time with mobx than I have and would rather hear yours from cold.
(I also keep looking at mobx-state-tree and wondering if that would work for me, I'm not sure I know enough to judge what the trade-offs involved are particularly well)
Event emitters/listeners are entirely too magical and borderline impossible to write automated tests for imo.
I don't think that's a good direction to go.
You can pretty much do it with proxys.
(2019), since there is a reference to "Svelte 3 around the corner" that is confusing otherwise.
Omg I was confused because the Gist also said “Last active 23 minutes ago” which I thought was the last edited/created time
I wish people stopped calling websites as applications and I wish web site developers spent more time learning how the world has been building great desktop apps for years. It’s just beneficial to get out of the bubble once in awhile to validate certain ideas
If you want a good language that turns into Javascript I recommend PureScript
True, but PS is general purpose while Svelte is a DSL. They did a good job at creating a non-invasive DSL that JS developers can use without much learning
I did a stint of Elm and it taught me a lot. But I found I prefer dirtier languages like elixir and typescript. I would not recommend the pure languages for anything other than learning FP.
(2018)