3 ms·

> There is no runtime and practically no framework As a fan of Svelte, I really wish people would stop repeating this. There _is_ a runtime in the form of repe

by lhorie 6y ago

> There is no runtime and practically no framework As a fan of Svelte, I really wish people would stop repeating this. There _is_ a runtime in the form of repeating patterns of code, which are objectively less ideal than the not-so-revolutionary approach of just having a runtime. Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf. On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers.

pier25 6y ago
> There _is_ a runtime in the form of repeating patterns of code Obviously there has to be some running code at the end, and technically you are right, but I think you're splitting hairs and for a brief introduction it makes more sense to say that there is no runtime. Also I think I implied your point with "Svelte is just a simple way for you to write vanilla instructions". > Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf I'm not sure about this point. I do agree Solid is currently faster than Svelte, at least on synthetic benchmarks. OTOH compilers can optimize hand written code which a runtime cannot do. We see this in assembly written by C compilers for example which have been optimized for decades and will beat the vast majority of hand written assembly. Svelte is very young and, while I could be wrong, I believe we will see performance improvements over the years. I also think this would be completely unnecessary. > On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers. If you're doing a SPA this can be solved with code splitting which is trivial to implement [1]. If not then Svelte will ship comparatively less JS than any other framework that needs a runtime[2]. BTW, big fan of Mithril here, are you still working on it? [1] https://github.com/PierBover/svelte-rollup-code-splitting-example https://github.com/PierBover/svelte-rollup-code-splitting-ex... [2] https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- lhorie 6y ago
  I'm mostly worried about the _optics_ of saying there's no runtime, because if people think "hey Svelte looks cool BUT I'm scared my bundle size will be humongous", then they won't convert. And Svelte sure could use some more adoption to get the adoption snowball going. That's all that it boils down to.
  - pier25 6y ago
    I could be wrong, but I don't think bundle size is the major concern people have over switching to Svelte. BTW adoption is growing nicely: https://npm-stat.com/charts.html?package=svelte&from=2016-05-10&to=2020-05-10 https://npm-stat.com/charts.html?package=svelte&from=2016-05... 2020 is close to the downloads of 2019 and it's only May.

by lhorie 6y ago

pier25 6y ago

> There _is_ a runtime in the form of repeating patterns of code Obviously there has to be some running code at the end, and technically you are right, but I think you're splitting hairs and for a brief introduction it makes more sense to say that there is no runtime. Also I think I implied your point with "Svelte is just a simple way for you to write vanilla instructions". > Newer libraries do have centralized runtimes (e.g. Solid.js) and perform better, so there's no real correlation between "no runtime" and having best-in-class perf I'm not sure about this point. I do agree Solid is currently faster than Svelte, at least on synthetic benchmarks. OTOH compilers can optimize hand written code which a runtime cannot do. We see this in assembly written by C compilers for example which have been optimized for decades and will beat the vast majority of hand written assembly. Svelte is very young and, while I could be wrong, I believe we will see performance improvements over the years. I also think this would be completely unnecessary. > On the other hand, the question of how the Svelte repetition scales as an app grows is a constant worry that drives away would-be newcomers. If you're doing a SPA this can be solved with code splitting which is trivial to implement [1]. If not then Svelte will ship comparatively less JS than any other framework that needs a runtime[2]. BTW, big fan of Mithril here, are you still working on it? [1] https://github.com/PierBover/svelte-rollup-code-splitting-example https://github.com/PierBover/svelte-rollup-code-splitting-ex... [2] https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...

lhorie 6y ago
I'm mostly worried about the _optics_ of saying there's no runtime, because if people think "hey Svelte looks cool BUT I'm scared my bundle size will be humongous", then they won't convert. And Svelte sure could use some more adoption to get the adoption snowball going. That's all that it boils down to.
- pier25 6y ago
  I could be wrong, but I don't think bundle size is the major concern people have over switching to Svelte. BTW adoption is growing nicely: https://npm-stat.com/charts.html?package=svelte&from=2016-05-10&to=2020-05-10 https://npm-stat.com/charts.html?package=svelte&from=2016-05... 2020 is close to the downloads of 2019 and it's only May.