Obviously Svelte can't do nothing about the misuse of Svelte (which is one the major points of the article) but:
> 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.
> 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.
> 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?
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.
Svelte is a compiler, and yeah you have to structure your code to fit certain patterns, but there is no framework in the end result as you would expect from React/etc.
Real World application written in Svelte requires a lots more libraries and code to supplement parts Svelte does not provide. So in the end you still have a big chunk of data.
Svelte does not make the problem dissapear. Svelte does not provide a solution. Svelte has exactly the same problem like React.
> 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.