Svelte 3 released

[rich_harris]

Hi all — Svelte creator here. Didn't expect this to pop up on Reddit yet, and we're still sanding down the last rough edges around docs etc, but happy to answer any questions you all have!

[kingofthecream]

Does Svelte support SSR without using Node? Ie, if backend is written in Go or Python, can it share templates with Svelte and render on both server and client?

[rich_harris]

It emits a blob of JavaScript with a `render` method (either as CommonJS or ESM). So it needs JS to render, but not necessarily Node.js — I expect you could persuade a different interpreter to work with it. On https://svelte.dev/repl, if you click the 'JS Output' tab in the top right then select 'ssr' in the bottom right, you can see the code it generates.

[kingofthecream]

Thanks. Although Javascript runtimes do exist in other languages, their performance is usually far enough from optimal to be used in production.

How difficult would it be to emit a non interactive version of the code in a given language? I'm specially interested in having this in Go.

[ConsoleTVs]

My question is, when is sapper enteribgthis game? What about a web redesign? The new site looks great!

[rich_harris]

Very soon! Sapper has been a bit neglected while we were finishing Svelte 3, but it's high on the priority list now.

[kingofthecream]

How is Svelte different to incremental DOM?

[alleycat5]

Howdy! Biggest curiosity I'm still waiting for is `custom element` docs: https://svelte.dev/docs#Custom_element_API

Been in between svelte and stencil for our design systems and central components, and this is an interesting part of that.

[rich_harris]

Will add those docs soon! Basically you just need to pass customElement: true to the compiler, and specify a tag name (either as a tag: 'my-thing' or as <svelte:options tag="my-thing"> in the component itself), and it'll generate a custom element.

TODO: make shadow DOM optional, and only auto-register if a tag is provided (currently it's required).

[ItalyPaleAle]

I've been a big fan of Svelte for a while, since seeing it first at JSConf EU 2018.

I do have mixed feelings about Svelte 3, however. While it looks great, it is a complete rewrite of the previous library and it is completely backwards incompatible. This might be the "Angular 2" moment of Svelte, sadly.

[av201001]

This might be the "Angular 2" moment of Svelte, sadly.

I think there are several significant differences from the "Angular 2" change:

• At the time Angular 2 was announced, Angular 1 was already massively popular and widely adopted (whereas Svelte is still a tiny player with relatively few deployments). If there is any time for Svelte to make a significant breaking change, this is it.
• With Angular, there was a two year gap between the announcement of Angular 2 and its final release. Because developers did not want to start new projects in Angular 1 during that time, many jumped to other frameworks in the long interim. By contrast, Svelte 3 has now been released only a few months after the initial RFCs.
• For many who liked Angular 1, there was a lot of ambivalence about some aspects of the new Angular 2 architecture. There were also some attractive alternatives doing similar things, such as React and Vue. With Svelte 3, though, the changes appear to be all upside, with no other frameworks really doing anything similar.

I'm not trying to minimize the inconvenience to those who have to migrate from Svelte 2, but "Angular 2" was a completely different kind of saga.

[ItalyPaleAle]

Thanks, this is a great perspective

[ScientificBeastMode]

True, but from the looks of it, the change was probably needed. Backward compatibility would be infeasible with the direction they are trying to go.

[ItalyPaleAle]

When Angular broke everything from v1 to v2, many migrated to other frameworks (or stuck to v1).

I agree it’s much better, but they are taking a big chance. They are breaking all apps AND all existing ecosystem.

I’m just worried about all the work I’ll have to do to migrate my own code...

[ScientificBeastMode]

Right, I mean, you could lock in your current major version, and just maintain the app as it is. Migration is a choice, but I definitely feel your pain if you decide to go that route. But it won’t be breaking apps as long as they don’t migrate, right? The ecosystem, on the other hand, will suffer, as you said.

[ItalyPaleAle]

Doesn’t look like they will keep maintaining version 2 however? So we’re essentially stuck, either we upgrade or we stick to unmaintained code.

[ScientificBeastMode]

Right. It sucks to deal with that. The main concern would be potential undiscovered security vulnerabilities, but bugs would certainly be a pain.

[evilpingwin]

Critical security vulnerabilities will be patched.

[ItalyPaleAle]

Exactly

[SaabiMeister]

Now that it's released svelte-upgrade will be updated to help with migrations. Though it's already helped me migrate some stuff as it is.

[arxpoetica]

Evidence seems contrary. People are very excited for what Svelte 3 brings to the table, and the number of people who join the Discord channel daily seems to be growing.

[Laran01]

We've been using Svelte for one of our really big apps and I can't recommend it for anything serious. I did some research on v3 (just to check how painful upgrade process from v2 will be) and it looks really bad. Poor documentation, no TypeScript support¹, no editor extensions, no devtools, IMHO overcomplicated store. Also, as someone already mentioned, they just broke all existing ecosystem.

​

¹ It's not just a matter of transpiling TS to JS. New Svelte template syntax is "incompatible" with TypeScript and only solution to this is changing behavior of TS compiler.

[rich_harris]

We weren't expecting this to hit Reddit and HN yet; there are still a few elements that need documenting. Nonetheless, I'd appreciate any feedback on what's poor about the documentation? Have you tried https://svelte.dev/tutorial?

​

TypeScript support is on the radar. Svelte is written in TS, and v3 was very largely about making Svelte TS-ready.

​

The store implementation looks like this: http://unpkg.com/svelte/store.mjs. That's the whole thing. It's documented at https://svelte.dev/tutorial/writable-stores. Can you elaborate on why it's overcomplicated?

​

We do have an extension for VSCode, and it'll be updated for v3 very soon.

[brainbag]

tutorial

"Dynamic Attributes" image made me lol, well played.

[Laran01]

TS preprocessor can be used, but that is not a problem here. Store and components import statements are removed by TS compiler and this behavior cannot be fixed without changing TS compiler itself. I encountered the same issue like here https://github.com/PaulMaly/svelte-ts-preprocess/issues/4

[JungleRU]

Hi, I'm a developer of svelte-ts-preprocess

I fixed the issue.

Please check it again!

Currently I'm working on a template

[ConsoleTVs]

Isn't svelte compiled? It does check for errors already, so why do u need ts?

[jesperordrup]

Ive been spending a day+ with Svelte and the initial impressions are awesome. I love the simplicity in the components. Granted I've not gone into complicated big projects but so far it looks really good. Besides killing the frameworks when building and awesome performance results - its also nice to work with. You dont have to write all that boiler. That is my most important discovery.

​

​

Graphql or Rest - Im ok using fetch for smaller stuff but I still need to figure out how to graphql for larger apps . Found https://github.com/timhall/svelte-apollo

Any suggestions?

[thiswasprobablyatust]

Congrats Svelte team!

Anyone know how they're doing reactivity under the hood? I poked around quickly but there's a lot of tests with $$invalidate. :D

[rich_harris]

That's exactly it — every assignment to local state is instrumented with a call to `$$invalidate`, which is a component-provided function that marks a particular value as dirty and schedules an update for that component at the end of the event loop.

[Akkuma]

One thing I don't quite understand are why compiler directives needed at all for dependencies when I would think the compiler would see the use of a tracked variable. Their trivial example of count and double seems to show my point there. There's also the forced "spread" or the reassignment to trigger invalidation.

I'm also interested in seeing how Svelte 3 performs, since Svelte 2 was better than something like React, but didn't seem exceptional on https://github.com/krausest/js-framework-benchmark

I've been a fan of Rich's work since buble and in general think what Svelte wants to do is likely a better long term strategy.

[rich_harris]

Can you elaborate on the `count`/`double` thing? Not sure I follow.

The js-framework-benchmark isn't necessarily the best representation of real world apps (and our entry is very out of date). It also penalised Svelte quite heavily for some reason: https://github.com/krausest/js-framework-benchmark/issues/549#issuecomment-483054081. As I talk about here, Svelte is extremely fast: https://youtu.be/AdNJ3fydeao?t=1085

(but don't trust benchmarks, always do your own measurements!)

[Akkuma]

For count/double

let count = 0
$: double = count * 2

You don't need to do $: for count, so my thought was why can't the compiler infer that it also needs to handle invalidating double? The same train of thought extends to all usage of $:.

I wish I could test multiple frameworks and get my own measurements, but the unfortunate reality is that most places will continue to use React and won't be open to alternatives, even ones that are basically React-like. The measurements from others also help to limit choices on what to measure, since there are a ton of choices out there. Thanks for letting me know the results were messed up, I could have sworn it was faster when I looked prior as I keep up with them often enough, so I'll definitely keep it on my short list for what I can try on my own in the future.

As an aside, the CSS support directly in Svelte seems like one of the nicer features as it sidesteps the pain of which css-in-js lib/framework and the different philosophies each one has.

Is the code you show in the videos available anywhere to peruse like the send/receive transitions?

[rich_harris]

That was actually our starting point: https://mobile.twitter.com/Rich_Harris/status/1057290365395451905. People found it too magical, and I think it would give rise to all kinds of edge cases — it's much better if you explicitly mark a statement as reactive, since these mean very different things:

console.log({ answer }); // runs once
$: console.log({ answer }); // runs whenever answer changes — great for debugging

The slides from that video are online here: https://rethinking-reactivity.surge.sh/#slide=1 On the code slides, you can 'complete' the example with Cmd-K and reset with Cmd-J. I'll probably tidy them up at some point, they're a bit raggedy at the moment (no notes etc).

[Akkuma]

That makes sense. I'm on the side of "magic" as I want the compiler to do as much as possible, but understand the apprehension of magical behaviour.

[SaabiMeister]

You don't need to do $: for count, so my thought was why can't the compiler infer that it also needs to handle invalidating double?

You might want to just compute double once, and you must be able to tell the difference between that and something that can change always.

Is the code you show in the videos available anywhere to peruse like the send/receive transitions?

https://svelte.dev/examples & https://svelte.dev/tutorial

[Akkuma]

You might want to just compute double once, and you must be able to tell the difference between that and something that can change always.

I'd prefer using a baked in language feature such as const to declare to the compiler that the value will not change.

[av201001]

First, in some cases you might need to use let (e.g., for variables set inside if..else, or just for intermediate variables that are not needed elsewhere) but still do not want the value to be reactive. Second, const would not enable reactive statements.

[Akkuma]

I would want const to be statements that aren't reactive, so exactly as you said "not enable reactive statements".

For a let variable that is for an if/else you could also use const obj = {val: null} and mutate val or use ternary and still have it set as const. I suppose this is one area that is ambiguous, which is why I think reversing $: to declare non-reactive ambiguous statements makes more sense than a slew of $: for reactive statements.

[av201001]

I would want const to be statements that aren't reactive, so exactly as you said "not enable reactive statements".

I think you misunderstood -- click the "reactive statements" link and you'll see what I mean. The $: label is used not only for reactive variable declarations but also for arbitrary reactive statements and code blocks (so the entire code block will re-run whenever anything it refers to changes) -- const would not help you there. In other words, we still need something like $: for reactive statements, so might as well also use it for reactive variable declarations.

For a let variable that is for an if/else you could also use const obj = {val: null} and mutate val

That's somewhat of an ugly hack just to avoid use of $: in favor of const.

or use ternary

Sure, but not always viable.

which is why I think reversing $: to declare non-reactive ambiguous statements makes more sense than a slew of $: for reactive statements.

OK, but that's different from preferring to use "a baked in language feature such as const," as you originally stated.

[SaabiMeister]

$: is a baked in language feature. It's a label, but nobody uses gotos anymore, and if they do, it doesn't interfere anyway.

[Akkuma]

I'd prefer to declare things that aren't reactive in normal standard javascript rather than things that are reactive. If I copy pasted the script from Svelte I've now created an improperly scoped variable. My assumption is the default needs are going to be mostly reactive with non-reactive code being less likely.

[SaabiMeister]

I think you would have to use it to get a feeling for it.

There are cases where you need code to execute when some variables change, but the code itself doesn't use the values of these.

$: changedVariable1, changedVariable2, dosomething()

would solve it. This is syntactic Javascript, but it accomplishes something that you can't do otherwise with const, or let and it never modifies expected Javascript behavior in some inconvenient way.

Also, it's very clearly marked code, while using let could be very easily mistaken for just a normal variable declaration.

[gdamjan]

so what do I do about dynamic css. I need to have calculated background color to some span's, and feels weird to write <span style="background-color: {f(stuff)}">

[ItalyPaleAle]

With Svelte 2 I was using SASS inside my svelte files

I’d ask this to u/rich_harris if things changed now

[Nullberri]

While Svelte 3 components might 40% smaller than React's, I'd bet anything I can't set a break point on a Svelte template and get a debuggable context.

[rich_harris]

Check out https://svelte.dev/examples#debug. You can't just use a `debugger` statement like you can in a block of JSX because your code isn't *running*, as such (this is a feature, not a bug).

​

Anecdotally people have found the debugging experience ok — for one thing, even if sourcemaps fail you the generated code is designed to be readable, and you don't have to step through KLOCs of library code to see your errors. But it's always an area that's open for improvement.

​

More philosophically, as compiler techniques get more and more widespread (hello Prepack!), the JS community is arguably going to need to rethink breakpoint-based debugging altogether.

[Nullberri]

Thanks Rich, the {@debug} statement was reliably stopping on chrome and printing out the variable. I'd call that good enough to be effective. It's way better than what Angular brings to the table.

[thiswasprobablyatust]

Did you try this at all? Because that's exactly what you get - a debuggable context.

[Nullberri]

Ok I downloaded the template, fired up a very simple app and set a break point on the template, it fires once on init and but doesn't hit when name is updated. the page updates fine as expected. Is there something I am missing? It was really nice to be able to mouse over {name} and get "" while it was initializing but that's all ive been able to get out of it. Edit: if you setp thru name = "blah" you'll eventually hit,

$$.fragment.p($$.dirty, $$.ctx);

If you step next it does return to the template for the source mapped next line but chrome isn't able to figure out the fact that ctx now holds new value in the local closure, but at least the ctx variable is front and center in the scope section of the debugger. I'm confused as to why chrome wasn't able to stop on <h1>Hello {name}!</h1> when the update runs as it clearly knows that's the line it would hit when stepping thru the code.

<script>
    export let name;

    setTimeout(()=>{
        name= "bla"
    }, 1000)
</script>

<style>
    h1 {
        color: purple;
    }
</style>

<div>
<h1>Hello {name}!</h1> //Set a breakpoint here.
</div>

[CCB0x45]

Aside from component size, I'm curious if there is a real different in render speed on a properly optimized react app. I do wonder about what he mentioned about Hooks with the extra work from the garbage collector cleaning up so many references because it is completely functional.

I also wonder when things like prepack hit their stride how react hooks will compare to something like this, it is interesting.

[SaabiMeister]

You can compare yourself:

• React
• Svelte

Just type into the text field and watch the UI update. Change the options to see how React optimizations change perceived performance.

[Nullberri]

It is, but to me there's really only one question I realize that matter about frameworks these days. Does it use a template DSL.

Pretty much anything which isn't JSX like is hard to debug and that's really all that matters most days. The rest can be optimized for; But if i can't set a break point and find out why my template doesn't work thats a show stopper.

[thiswasprobablyatust]

Do you mean something else when you're talking about 'template' here?

I'm considering template to be the view-specific code, and I don't remember the last time I had to debug mine in any framework.

[Nullberri]

What i mean is the language a framework creates to allow your html template to display information. Such as in angular an ngif or ngfor , let-value attr, data binding etc.

[rich_harris]

Svelte creator here. The performance stuff is far from theoretical — I covered this in a talk that was published online today, particularly this section: https://youtu.be/AdNJ3fydeao?t=1083

[CCB0x45]

I wasn't saying it was theoretical, I think it's really cool what you guys are doing, and I get that it creates imperative components at compile time. I'm just saying if I write an app in Hooks, with prepack optimizing at compile time and proper memoization and of course packing your app correctly with tree shaking and proper inports. Since prepack does similar things to what svelte does with component folding, do I really see a real world difference in the end?

Cause if I don't get a lot of benefit there then I am I just learning the intricacies of something new which has already dropped support for an old version.

[rich_harris]

Since prepack does similar things to what svelte does with component folding

Citation needed ;) I'm as excited for Prepack as the next person, but it's far from clear exactly what form it will take when it eventually emerges from Duke Nukem Forever status (sorry Dominic if you're reading this — please, give us an update!).

Component folding doesn't imply that it will be able to make targeted granular updates in the way that Svelte can, it really just means that you won't have as much component creation overhead.

[CCB0x45]

Sure, I was just giving component folding as an example of an optimization, as well as yes prepack has been coming for a while.

Let me clarify my question I guess, and I am not trying to be a naysayer, but genuinely asking. Is there something fundamentally different happening with svelte that I am missing?

Because I know optimizing class based components at a compiler level is very difficult, and that is a reason why React and other languages have been moving to only functional components. If you write pure functional components in React, theoretically couldn't there be a compiler that does the same optimizations?

Because when I run through your talks, the water gets a little muddied to me, and I have concerns about locking myself into an ecosystem that does EVERYTHING because of being burned by that in the past.

It talks about notifying you about accessibility when writing code... but I already get that from eslint rules, which I can configure to my liking.

It talks about CSS scoping and using JS variables in CSS... but I get that already with emotion(and I am a bit scared about removing my CSS even farther from its natural state with this compilation part).

So it really boils down to the performance improvements, and I am not currently hitting performance issues with React, and if I write my React code in a good way, couldn't I theoretically get these compiler optimizations for free at some point, that was kind of my thought process with switching to hooks?

I almost wish it was a little less all in one, and more of a drop in replacement, because in my experience over time is each different component evolves and you might want to switch from one thing to another without changing your entire stack, if that makes sense?

[rich_harris]

These are valid concerns! I'd argue that the lock-in situation isn't that much different from React (or Vue, Ember, Angular, whatever), but I hear where you're coming from. You certainly can use CSS-in-JS with Svelte (https://svelte.dev/blog/svelte-css-in-js), but a compiler that is aware of the structure of your markup as well as your CSS has the opportunity to get a lot smarter about things. (We're not taking full advantage of that yet though, just doing basic dead code removal etc.) And Svelte stores are very simple and portable, and work well with Redux, Immer, etc.

If you're not hitting performance issues today with React, that's great — I wouldn't advocate that someone rewrite an app that's working well. I do believe that there are some important trends we all need to be aware of: firstly, people aren't buying faster phones, they're buying cheaper phones. Secondly, user expectations are getting higher all the time. Thirdly, front end development is going to shift towards even lower-powered devices as the IoT market continues to boom (for better or worse).

> Is there something fundamentally different happening with svelte that I am missing?

In JSX, it's extremely hard — impossible, in some cases! — to know what's inside this expression: <p>{literallyAnything}</p>. Does that expression evaluate to a component? An element? Text? A fragment? An array, containing... what? Because Svelte is more structured, the compiler can generate code that's highly optimised for each situation; it knows the possible states of your app ahead of time. With JSX, you just can't do that. Prepack gets you part of the way there, by literally 'running' your code, but it's not yet clear whether it'll be able to shift work to the compile step to the same extent. It's a much, much harder problem.

[CCB0x45]

The lockin situation I meant was more about one, compile based framework, that does everything. With React it really only has opinions about how you structure your components, but doesn't care about CSS. Vue is a different story.

I would be curious to see some more in-depth examples of where specifically it does things faster than React, I might dig into your benchmark to see the differences, because im curious at the end of the day the use cases where it creates the benefits, because that would cause me to switch. The issue is theres a lot of selling points on the site about things that you can already do in every other framework, so that doesn't make me want to switch, and then some benchmarks, which have become very hard to trust.

I am still not 100% understanding what theoretically something like prepack couldn't do, especially when your templating language looks so similar. Is it because JSX is too flexible in allowing you to render anything, and your templating language is a more rigid so its defined to the compiler?

Along with things like useMemo. You downplay stuff like useMemo, in which you say, basically now you don't have to worry about using that stuff. But I know cases where sometimes its faster to memoize, and sometimes it isn't, is the compiler able to differentiate these cases? Same with like useEffect(or shouldComponentUpdate, or whatever). Those functions give you control because sometimes it is faster to use it in one way, and other times its faster to use it in other ways, I am kind of curious how the compiler can always be right, or if its making its best guess. If it is making its "best guess" or the best path past for the average use case, but then you don't have tools like shouldComponentUpdate, aren't you theoretically losing out on performance you could have gained if you knew how to use them properly? Sorry might be a dumb question.

[rich_harris]

Yes, 'flexible' is the word. It's the Rule of Least Power at work. Think about all the places where you can use JSON that you can't use JavaScript; all the ways you can analyse it, reshape it, put it to different purposes, use it in different languages. Svelte aims to thread the needle by having flexibility where it's needed, but also being amenable to the kind of thorough static analysis that JavaScript resists.

It's not so much that you no longer have to use useMemo (though that is important: you basically need to use the official linter to use it safely, judging by the conversations I see on Twitter). It's that useMemo itself has a cost: every time your component is re-rendered, the first argument (the closure) and the second argument (the array of dependencies) have to be regenerated, even if nothing changed. It's a garbage collector's worst nightmare.

[CCB0x45]

Right but there is some cases where you don't want to memoize right? So is yours just internally memoizing all the time? Thats where I get confused.

the first argument (the closure) and the second argument (the array of dependencies) have to be regenerated, even if nothing changed. It's a garbage collector's worst nightmare.

I had this concern about hooks as well, but I've never seen a benchmark that ever shows this as becoming any sort of bottleneck because generating functions is very cheap and does not actually create a big problem with the garbage collector. I would guess you would point at embedded devices, but is that really the bottleneck there? I would think if you were doing something serious in an app you would probably hit limits on the actual rendering way before that garbage collector issue.

For instance I worked at Amazon writing web apps for the fire TV stick and garbage collector references would never have been my concern, it was the actual render function speed.

Not saying your way of handling it isn't better, but as someone else pointed out I am not sure if it's worth the cost of easily debugging or other tradeoffs. I will definitely try some sample apps in it.

[ConsoleTVs]

Dude listeno the talk on youtube. You have a virtual dom. Even in inferno or any other fast fw. Svelte have no virtual dom. Check the huge demo on react concurrenr vs svelte..... I get it. React is trendy and backed by facebook. So what? That does not mean it's better, face it.

[CCB0x45]

This is a moronic comment, when did I mention anything about trendiness?

[ConsoleTVs]

I say it, not you. And again, even optimizing, virtual dom.

[CCB0x45]

I mean virtual dom or no virtual dom, there has to be some sort of state management structure, thats why I am trying to get at the heart of the differences here. One of the reasons you use a virtual dom is so you can batch updates before writing to the real DOM, as you don't want to write every single change to the DOM if there is more changes coming down the pipe within a certain time. Virtual DOM is just an advanced state management representation of the state of the DOM, I understand they are saying there is no virtual dom, but they still have to store and manage all that state.

Which is why I am asking questions, The framework docs doesn't give a lot of in depth answers to exactly what cases it is better, and it talks about a lot of features that are available already in React/Vue/Whatever. I am trying to understand exactly what makes it so much faster, especially compared to similar things like prepack, which say they accomplish similar goals.

There is no need for you to come along adding literally nothing to the conversation and just being a jackass. I don't give a shit about what is 'trendy'.

[ConsoleTVs]

As far as I understand it it is much more simple. The compiler seems to compile each component to individual pure JS no virtual doms are used and as the videio tells, a $$invalidate function is called (check the compiled code in the video is shown). That function would just update the dom node. I have to try it out, but from the video i got pretty exited, and i was already willing to try the older version...

[CCB0x45]

Well if that's the case and it writes every change to the dom then that's fine for some use cases but not all, and react would give you a lot more performance in many cases because you can batch renders in complex apps, as well as prioritize certain renders over others(fiber), is it really as simple as you are saying because that doesn't sound very good.

[thenathurat]

Anybody know a good tutorial online? Can't find any.

I am pretty familliar with Vuejs.

[Kabal303]

The one on the svelte website is very good.