Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
The truth about Svelte

I've been deceiving you all. I had you believe that Svelte was a UI framework — unlike React and Vue etc, because it shifts work out of the client and into the compiler, but a framework nonetheless.

But that's not exactly accurate. In my defense, I didn't realise it myself until very recently. But with Svelte 3 around the corner, it's time to come clean about what Svelte really is.

Svelte is a language.

Specifically, Svelte is an attempt to answer a question that many people have asked, and a few have answered: what would it look like if we had a language for describing reactive user interfaces?

A few projects that have answered this question:

(Idyll is an outlier as it's geared towards a specific use case, rather than general purpose app development, but I think it qualifies as an example.)

These projects are all very cool, but there's a reason they haven't hit mass adoption: they want to control the entire world. You can't adopt Elm or Imba incrementally, and they need dedicated tooling far beyond just the compiler itself (e.g. syntax highlighting, unless you like your code monochrome). In some cases (Elm stands out), interop with the JS ecosystem is less than seamless.

Beyond that, they have a steep learning curve, which is hard to justify when there are so many options that are more accessible.

Thinking inside the box

What if we had a language that was designed for building reactive user interfaces, but that also worked with your existing tools? What if you didn't need you to discard your years of experience using HTML, CSS and JavaScript, because it extended those languages?

  • It would extend HTML by adding JavaScript expressions in markup, directives for controlling behaviour and reacting to input, syntax for using conditions, loops and asynchronous values
  • It would extend CSS by adding a scoping mechanism that kept styles from clobbering each other
  • It would extend JavaScript by making reactivity a language primitive

How do we make reactivity a language primitive without introducing invalid syntax, or breaking the relationship with existing tooling (like TypeScript)? By hacking existing syntax:

This, to me, is the best of all possible worlds: we can lean on decades of accumulated wisdom by extending well-known languages, author components in a delightfully concise and expressive way, and yet still generate apps that are bleeding-edge in terms of performance and everything that goes with it.

@SheenHealth

This comment has been minimized.

Copy link

SheenHealth commented Feb 22, 2019

Rich,

That is helpful, thanks.

However, it brings new questions:

  • Is Svelte a competitor to TypeScript? I have been using JavaScript with Vue. Vue also works with TypeScript. Should I move to Vue + TypeScript (get type safety) or Svelte + Sapper? Why?
  • On the server side, Deno (deno.land) may be a meaningful step forward for Node: More secure, TypeScript-friendly, no package manager, etc. Is Node + Svelte + Sapper a competing vision, or can I move to Deno + Sapper + Svelte (and ditch Node)?

Thanks,

Aneesh

@omgoshjosh

This comment has been minimized.

Copy link

omgoshjosh commented Apr 25, 2019

Yo that link to "instrument assignments" is dead. Looks like you merged a PR to master and the dead branch killed the link. This link seems like the right one:

https://github.com/sveltejs/rfcs/blob/master/text/0001-reactive-assignments.md

(difference is just changing blob/reactive-assignments to blob/master.

keep up the great work!

@sigi

This comment has been minimized.

Copy link

sigi commented May 20, 2019

Curiously, when listing the various reactive UI languages, you've skipped over QML (from the Qt project), which predates all of the others, and probably inspired a lot of them. It's not a targetting the Web, of course (rather, native GUI applications).

@sigi

This comment has been minimized.

Copy link

sigi commented May 20, 2019

Commenting on the main points of the article:

Staying as close to plain {HTML,CSS,JS} as possible is laudable, but as I see it, the only upsides are being able to use existing syntax highlighters (and related lexical editor tooling such as auto-complete), and increased familiarity for new users.

However, what if I do not want to use HTML, CSS or JS? Because, I really don't. HTML is painfully redundant and noisy, I want to use Pug instead. CSS is, again, painfully redundant (due to lack of nesting) and lacks important features like mix-ins; it's also noisy. I want to use Stylus instead. JavaScript is meh; I think it's bearable, but I want to use CoffeeScript instead.

The decision to stick with plain HTML and CSS makes it possible the re-use existing tools, but it comes with the problem that one has to use, well, HTML and CSS; and those are awful languages (and so is JavaScript, but at least there it's usually possible to transpile from something else if you want to).

A framework like Vue.js allows me to pick my preferred tools, because I can instruct Webpack to transform my languages-of-choice into HTML-CSS-JS, and Vue doesn't care. Is that possible with Svelte 3, or would it be possible with an additional transformation step that is not too difficult to implement?

Having said that, if one is ready to bear with HTML and CSS (in my book that borders on masochism, given the alternatives), the approach in Svelte 3 is great. Hijacking labeled statements in this way is a great idea (unless you want to use CoffeeScript, or any other language that compiles to JS, because then you can't output labelled statements in a controlled way, or not at all...).

The low-boilerplate approach is great.

@ryanatkn

This comment has been minimized.

Copy link

ryanatkn commented May 20, 2019

@sigi see kaisermann/svelte-preprocess and other svelte-*-preprocess/svelte-preprocess-* projects for language support like SCSS and CoffeeScript and integrations with Webpack and Rollup. Labels may trip up certain JS transpilers but I find the reactive syntax to be wonderful.

Along similar lines but going further with compiler flexibility, you might be interested in Svelte Native and sveltejs/gl. ( (the latter is currently experimental)

@sigi

This comment has been minimized.

Copy link

sigi commented May 20, 2019

@ryanatkn Thanks for the pointers. I've actually discovered svelte-preprocess in the meantime, and it seems to be exactly what Svelte needs in that area.

Labels, and the idiosyncracies around export, are the main problem when using CoffeeScript as far as I can see. CoffeeScript doesn't allow you to use "blank" export statements, but one can always do export foo = undefined, or provide a default value in the first place (which is good practice when specifying props anyway).

Labels are trickier, because CoffeeScript simply cannot output them (the same is probably true for most other transpiled languages that are not very close derivatives of JS). So there would need to be a Svelte compiler plugin/preprocessor that can transform comments into labels (e.g. /*$*/ would serve as the $: label).

@ryanatkn

This comment has been minimized.

Copy link

ryanatkn commented May 20, 2019

@sigi I'm a former CoffeeScript/LiveScript user and I can feel some of that pain. The special Svelte stuff (including the $store piece) unfortunately also makes it so languages like ReasonML might never be supported.

FWIW, after ES6 (which seems to owe a lot to CoffeeScript), I find TypeScript to be a joy - terse, unambiguous, excellent for refactoring and fast iteration. Svelte has plans to support it (with few or no significant caveats, AFAICT), and it points to a future where other languages could introduce great features and be able to target "SvelteScript" as an intermediary. I really do miss the existential operator ? and pipeline operator |> but we may get both of those standardized in ES before long.

Svelte's language extensions - export prop, $: reactive, and $store - are just so terse and powerful and feel natural now that I've gotten used to them. Writing fast code with high intrinsic complexity is easy. Whatever can pull me away from them is going to be even more awesome, and I suspect Svelte's approach has helped light a fire under a lot of language and framework devs.

@swiesend

This comment has been minimized.

Copy link

swiesend commented May 21, 2019

Hey @Rich-Harris can you point out little more, why its possible to adopt svelte gradually, but imba not? And are there internally big differences in the approach of both?

@sigi

This comment has been minimized.

Copy link

sigi commented May 21, 2019

@ryanatkn

I find TypeScript to be a joy - terse, unambiguous, excellent for refactoring and fast iteration

Well, TypeScript is an improvement, but it's a shame that it's basically the same syntax as JavaScript. In order to get typing (and excellent tooling), I'd rather switch to Kotlin (for JS), which can use TypeScript definitions out of the box. Kotlin is actually a well designed language, and easy to learn, and it can also target Android and the JVM.

The reason why I love CoffeeScript are the whitespace sensitivity, writing -> instead of function, and the simple object literal notation; everything else is just (plenty of) gravy on top of that. Just those three things already make the code so much more compact and readable, compared to JS.

Some people say that language syntax doesn't matter that much, but they are mistaken. It really does matter a lot.

Svelte's language extensions - export prop, $: reactive, and $store - are just so terse and powerful and feel natural now that I've gotten used to them.

Yeah, those are just amazing ideas. I'm really close to switching my current project from Vue.js to Svelte (it's not that much code yet, so it might be worth doing it now).

@wolfadex

This comment has been minimized.

Copy link

wolfadex commented May 22, 2019

You say "You can't adopt Elm [...] incrementally" but you can. See https://www.oreilly.com/library/view/why-elm/9781491990728/ch04.html, specifically the section labeled Adopting Elm Incrementally.

Separately you suggest that learning a new markup syntax is easier than learning a new language or tool, but that seems quite subjective.

@sigi

This comment has been minimized.

Copy link

sigi commented May 22, 2019

@wolfadex The Elm language and paradigm is very different from JS + web technologies. Unless you already have a strong background in platforms like Haskell or Clojure, this will definitely be harder to pick up than, say, React (or Svelte) for a JS front-end developer.

The main issue I see right now with Elm is that interoperating with existing JS libraries and frameworks is not straightforward, and there is not much of an ecosystem or prior art that you can use -- so you have to do a lot of work yourself. I'm thinking about scenarios like integrating PouchDB or Firebase. Depending how much of the target API you need exposed, you'll have to write a lot of code in an unfamiliar language. That's probably not an option for somebody who needs to Get The Work Done, now.

Plus it's also a lot more difficult to find developers if you need to grow your team or project.

That says nothing against Elm as a technology; it's really a very good design and platform.

@wolfadex

This comment has been minimized.

Copy link

wolfadex commented May 22, 2019

@sigi as someone with 8+ years of javascript/front end experience and I've only written Hello World in both Haskell and Lisps, I found Elm to be easier to learn than React, and React easier to learn than Angular, ExtJS, jQuery, and ember. All of which I've used professionally. That is why I said difficulty is subjective.

I personally have encountered too many projects in the last 8+ years where someone had wanted to "get work done" and they ended up creating a mess of code that 2-ish years later was unmaintainable and bug ridden. This isn't to say for example that React equals bad code, but maybe Get The Work Done is a poor approach? That's a whole other topic though.

None of this is an attack on Svelte either. I'm very happy for Svelte and want to see it succeed. I think it is a positive influence on the community.

@sigi

This comment has been minimized.

Copy link

sigi commented May 23, 2019

@wolfadex The fact that you have even heard of Haskell, let alone wrote a "hello world" in it, sets you apart from the majority of JS developers out there (probably 99%, quite literally). So it does not surprise me that it was reasonably easy for you to pick up Elm (and appreciate its qualities). You are probably smarter, more open-minded and flexible than the vast majority of people doing JS work. And it is precisely the point you were making when you said "subjective".

Having said that, I still think your argument of "it's a subjective experience anyway" is a cop-out, because on average, option X will always be objectively (!) more/less approachable than option Y -- and the average case is mainly driven by a large amount of web-hipsters and brogrammers without a degree. This might sound elitist, but it is just the truth. It is not very relevant how subjectively easy it is FOR US to learn something like Elm. The vast majority of developers use the one language they happened to run into first, or that promised them their first good job, for the rest of their lifes (usually that is one of C++/C#/Java/JavaScript). These people are not going to touch Elm with a ten-foot pole, at least not on their own. However, we need a certain mass appeal for a healthy ecosystem to even exist.

The only way I could see a large number of people picking up things like Elm, Clojure(Script) or other "exotic" languages would be a "Ruby on Rails Event"; but I don't see that coming. Rails filled a huge vacuum, making Ruby popular for a while, however the situation is different now. There is no such vacuum in the JS world at the moment. (BTW I think Ruby is amazing and would have deserved the attention on its own, but it would never have gotten it, without Rails -- for the reasons mentioned above.)

Also, look at what made Node.js popular: "Hiya folks, now you can do JS on the server too!! No need to learn anything new!" And people loved that. I was using Ruby at the time and just could not understand why anybody would go out of their way to use JavaScript (of all things) on the server, instead of e.g. Ruby or Python. And you are waiting for the Elm uptake (a purely functional language with completely unfamiliar syntax), because it is "not that hard to pick up"? Not realistic. (I might be putting words into your mouth here, I am aware.)

The reason why you found so much bad code in the past 8 years is because most people just suck at our craft, and often just do not care (corollary of the above). They are not going to make better code in Elm.

@donnisnoni95

This comment has been minimized.

Copy link

donnisnoni95 commented Jul 27, 2019

Elm is very good ... simple and powerful, but for me its take me a long time...and the problem is what if someone is a developer who has learned all the languages ​​of web technology, then they learn another technology that is not too familiar with what they have learned so far, surely they need a long time to master it.

And I think for now, Svelte has made it very easy for web developers to develop web applications so that development is rather faster and also produces small but efficient code. I really hope Svelte continues to grow and become a good tool for the future.

@donnisnoni95

This comment has been minimized.

Copy link

donnisnoni95 commented Jul 27, 2019

@sigi I agree with you

@agraves

This comment has been minimized.

Copy link

agraves commented Sep 4, 2019

Neat idea. The one place where I think it differs from a language is that it seems to be domain-specific. Wish I could think of a short, catchy name for such a concept, feels like it really might catch on.

@farhan2106

This comment has been minimized.

Copy link

farhan2106 commented Sep 5, 2019

Love from Malaysia. We been using it in one of our small mapping project as a trial and I personally love it. 💃

We have been using it with typescript integration.

The gziped bundle size itself is only 30kb! 💯 (...but with polyfill + css it is 220kb++). Polyfill is to support IE11

Here is the performance. The slowdown is due to loading the map data into canvas.

Hopefully we can get svelte 3 hot reload working soon.

DESKTOP
desktop

MOBILE
mobile

@MehdiRaash

This comment has been minimized.

Copy link

MehdiRaash commented Sep 24, 2019

I just got to know Svelte today by watching the creator's nice talk, I just feel this thing is like a new platform(or as he said a new language as well), At first it's a bit scary, because you should be using its offered tools like $, and this is a total shift in crafting web apps.
So I just feel unsecure now to pick it up, however very curious to research and work with it a lot.

@Genenenenaam

This comment has been minimized.

Copy link

Genenenenaam commented Sep 30, 2019

Thank you for your work !!

HTML is the language is which we should be building our applications. HTML is the language of the web.
We just need to enrich it with the missing pieces to make it a dynamic data driven language, rather then the opposite approach…
of thinking that Javascript is the language of the web, and we should be putting all of our logic inside of javascript alongside with
all of our markup, styles, etc…

The closer a tool can stay to the three fundaments of the web, being HTML, CSS & JS, the better for our knowledge/growth as developers.

A good tool makes your work easier and faster with lots of features and build in shortcuts (Like react etc...)
A great tool makes you walk away as a better developer once it has become obsolete!

@xCyborg

This comment has been minimized.

Copy link

xCyborg commented Oct 9, 2019

Blazor for Javascript, nice to see this.

@limitlessloop

This comment has been minimized.

Copy link

limitlessloop commented Oct 17, 2019

If components were automatically registered that could improve adoption. I don't want to have to worry about where the component is and what page it's being used on.

@loganpowell

This comment has been minimized.

Copy link

loganpowell commented Oct 21, 2019

TBH, I'm having a hard time with all the new syntax that I have to learn to use Svelte. I really love the ideas and apparent performance, but I worry that - by getting good at Svelte - I'd be actually getting worse at JS. Forgive me if I'm spouting nonsense. Just a first impression sorta thing.

@nilskp

This comment has been minimized.

Copy link

nilskp commented Oct 22, 2019

@sigi, sorry if I'm late to this, and this is recent change, but Coffeescript doesn't seem to have a problem with the reactive syntax.

This:

$: foo = 'bar'

Is transpiled to this:

var foo;

({
  $: foo = 'bar'
});
@MehdiRaash

This comment has been minimized.

Copy link

MehdiRaash commented Oct 23, 2019

@loganpowell you are kind of right, Svelte(based on creators saying: is a language) brings a new environment.
We can craft a performant app using it, BUT we developers should be capped by architectural limitations. for example having two-way binding is great at first glance, but it complicates our app when it gets bigger hence React's opinion for me worked better.

@loganpowell

This comment has been minimized.

Copy link

loganpowell commented Oct 23, 2019

@medhiraash, seems like it's a tradeoff between magic-via-syntax or magic-via-vdom/hooks. I prefer Svelte's magic to React's in that you can always inspect the compiled code to see what that magic is doing under the hood. I just worry about developing habits that I can't take with me when the next best thing comes along... React also uses JSX, so... I guess it's a matter of taste.

@wolfadex

This comment has been minimized.

Copy link

wolfadex commented Oct 24, 2019

If you're writing in any language, you can look at it as "magic-via-syntax" because at some point the code you write is getting transformed into another language you're most likely not familiar with. "Magic-via-vdom" is just using data structures. For me HTML is more magic than vdom because it's handled by the browser. Conversely I can more easily comprehend how a, relatively simple, trie (vdom) works.

@sigi

This comment has been minimized.

Copy link

sigi commented Oct 25, 2019

@nilskp

sorry if I'm late to this, and this is recent change, but Coffeescript doesn't seem to have a problem with the reactive syntax.

The example you've provided displays exactly why it does not work with Svelte, because Svelte expects a JavaScript label, but CoffeeScript outputs an object literal (with '$' being the property name).

What's needed would be a way to output a JS statement label (a.k.a. "goto label") from CoffeeScript, which is not possible at all (unless one uses literal backtick-based JS interpolation, which is not acceptable to me).

@nilskp

This comment has been minimized.

Copy link

nilskp commented Oct 25, 2019

@sigi
You're right. Somehow I read it as scope brackets, not as an object.

Of course, simply adding back-ticks around such statements would solve the issue, and given it's a "magic" syntax anyway, it doesn't feel too weird.

@sigi

This comment has been minimized.

Copy link

sigi commented Oct 27, 2019

Of course, simply adding back-ticks around such statements would solve the issue

Escaping CoffeeScript into JS in order to make it play with Svelte is absurd, let me explain why.

Svelte uses JS syntax for non-standard behaviour, in order to increase community uptake and to make editors behave. Outside of that there is absolutely no technical reason for the abuse of the goto label and export statements (if the target language was non-shitty, you could write macros or just use normal syntax in order to avoid boilerplate).

Since I use a non-standard, non-shitty, language anyway (CoffeeScript), and I have to transpile it, it makes no sense to me to somehow shoehorn its output into something usable by Svelte.

The actual solution would be to enhance the CoffeeScript transpiler, so it could target Svelte directly. In that case one would also not have to "re-use" things like gotos and exports. You could either use standard CoffeeScript syntax, which is often feasible because it is actually non-shitty, or extend the grammar for the reactivity stuff.

I will probably be writing Vue.js or just switch to ClojureScript, however.

In any case I love the Svelte approach, in a pure JS web-hipster world it's really pretty close to perfect for a reactive framework.

@wolfadex

This comment has been minimized.

Copy link

wolfadex commented Oct 30, 2019

@randompixels as someone who doesn't even use Svelte or consider themselves part of the Svelte community, I find comments like this to completely inappropriate. I sincerely hope you delete this comment and refrain from speaking this way about others and their work in the future.

@loganpowell

This comment has been minimized.

Copy link

loganpowell commented Oct 30, 2019

dudes, chill...

@Rich-Harris

This comment has been minimized.

Copy link
Owner Author

Rich-Harris commented Oct 30, 2019

@randompixels normally I'm very chill about people expressing their opinions about the work done by me and my fellow maintainers, and given away freely for the benefit of the web community, but then you went and said this...

You have absolutely no place to decide what I can or cannot say. You know, free speech and all. It's my opinion and I own it, including the consequences. Feel free to ignore my opinion, but you are not allowed to tell me to remove it

...which I found very funny. Because I can tell you to remove it, because this is my gist. 'Free speech' just means the government can't prevent you from saying things, it's not a license to be a dick. Your comments have been deleted, and your future comments will also be deleted. Bye!

@MehdiRaash

This comment has been minimized.

Copy link

MehdiRaash commented Oct 31, 2019

From React doc

Additionally, React has been out for about five years, and we want to make sure it stays relevant in the next five years. As Svelte, Angular, Glimmer, and others show, ahead-of-time compilation of components has a lot of future potential. Especially if it’s not limited to templates. Recently, we’ve been experimenting with component folding using Prepack...

I've seen from react team that they pronounce Svelte quite often as a successful ahead-of-time library, as you can see they started Prepack, but a bit later they somehow leave the project.

Maybe this is a question that I must asked there also.

What do you think was the reason behind stopping such an idea(prepack I mean)? do you think that was related to Svelte or so?

@Rich-Harris

This comment has been minimized.

Copy link
Owner Author

Rich-Harris commented Oct 31, 2019

As I understand it (from conversations — I don't have any real inside knowledge) it was mostly about code size. Prepack was capable of creating code that executed very fast, but that was many times larger than the input.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.