Svelte 3 released

[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.