It doesn't give you absolute flexibility like React + JSX does, but it solves your most common problems much more pragmatically.
See this for example: https://stackoverflow.com/questions/60934557/how-to-bind-eve...
Please explain these efficiency benefits. VDOM architecture can't be faster than native javascript updating the DOM because at the end of the day you still have to to use native javascript to update the DOM.
> Also React, Angular or Ember does not add a lots of code to the project.
They do to small apps. I tend to embed small svelte apps inside of a larger multi page apps to handle more complex UIs. In that use case the much smaller overhead helps tremendously.
VDOM is an optimization that allowed react to be fast enough to work, it can never be faster than direct dom manipulation.
But mutating the data directly is always going to be faster.
If you want to operate at a level of abstraction where you can ignore mutability and say rerender an entire huge ul every-time a single li changes, then using a VDOM to calculate the diff so you can only replace the single li is going to be faster than replacing the entire ul directly in the DOM. In many cases this is fast enough and so you get to program at a that higher level of abstraction.
However, if you have code that just directly replaces the innerHTML in the single li that changed, the VDOM can never be faster than that. Because it has to do that as well as calculate the diff to find which li it should change.
In essence Svelte just runs more of its abstraction optimization techniques at compile time instead of at runtime.
> The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too high for any company to include it as part of an SDK.
Svelte is just a simple way for you to write vanilla instructions. There is no runtime and practically no framework.
Other than React he is criticising problems which have better solutions than the ones he is proposing.
For example the bundle splitting problem can be solved by a smart browser refresh at the appropriate time.
The SSR problems he mentions are non existent with Svelte as the JS needed for an SSRd page is probably less than 5kB and since those are so small you can preload all JS files on the first user visit. He also mentions authentication problems which are non existent if your SSR app talks to the database and uses some KV cache for sessions. It's also certainly possible to cache the HTML, not only in the server but in the browser too using service workers.
As for his critique of APIs I don't agree. He also states that "GraphQL application will suffer under the N+1 query problem" which is true on the most simplistic implementations. Hasura, Fauna DB, and other GraphQL servers don't suffer from this problem at all.
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.
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-ex...
[2] https://krausest.github.io/js-framework-benchmark/current.ht...
BTW adoption is growing nicely:
https://npm-stat.com/charts.html?package=svelte&from=2016-05...
2020 is close to the downloads of 2019 and it's only May.
Why is this a good thing? Surely most developers want a framework?
Svelte does not make the problem dissapear. Svelte does not provide a solution. Svelte has exactly the same problem like React.