Not all of them. Without the overhead of rendering everything to a virtual DOM and then doing a diff, performance can get pretty close to native javascript--the sweet spot the author mentions gets bigger. Plus since the framework is mostly just a compiler, the bundle issue is less of a big deal.
Virtual DOM actually has some efficiency benefits. So it is not as easy as no Vdom = better. Also React, Angular or Ember does not add a lots of code to the project. I am 100% sure real world app written in each of major frameworks including Svelte has almost exactly the same size. Svelte has the same problems like React or any othe framework.
>Virtual DOM actually has some efficiency benefits.
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.
You don't need a VDOM to use a buffer to batch changes. A VDOM is a buffer that comes with a huge amount of overhead vs an ordinary sequential buffer of DOM manipulation commands.
VDOM is an optimization that allowed react to be fast enough to work, it can never be faster than direct dom manipulation.
VDOM isn't useless. It's basically an optimized immutability helper. React wouldn't have been feasible without it.
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.
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.
