Svelte.dev's Approach to Runtime Libraries

This is my short take on the Svelte 3 author's presentation, given comments that the Svelte compile-time code is "not really Javascript," ...

Any non-ECMA-native templating, the use of decorators, and Typescript, etc. require a x-pilation step. But what's the benefit from it?

The approach that React/ Vue/ Hyperapp/ Choo/ lit-html/ etc. take is that:

1. you write x-pile-time code
2. your (1.) is parsed by an x-piler to run-time code
3. your x-piled run-time code calls a run-time library
3b. with some frameworks, you may also write (1.) which does not need an x-piler to convert DSLs to JS... but that JS remains subject to the API of (3.)...

Whereas the approach taken by Svelte is that:

1. you write x-pile-time code
2. your (1.) is parsed by an x-piler to run-time code
3. there is no run-time library **
3b. there is thus never an API limiting the run-time code ****

** You could feasibly argue that Svelte reifies the library code and puts it into the x-piled JS. But we can only discuss the value of this, if discussants all do homework and read the pre-x-piled/post-x-piled code for all the frameworks under discussion :P

**** Subject to ** above.

All in, instead of x-piling moderately complex x-pile-time code to moderately complex run-time code... Svete tries to x-pile relatively simple x-pile-time code to much more complex run-time code, WITH BETTER PERFORMANCE... and since this generally how code x-pilation has worked in computing prior to the web... I'm going to go out on a limb with my limited experience and say that I welcome Svelte's approach.

Caveat: I'm a bit out of date with these things, and I may have misunderstood a lot of things which I referred to.