It seems like both Mithril and Imba do some form of DOM diffing. It’s easy because you just tell it to update the DOM using the latest state. Imba in particular says it has a really fast way to do that. But isn’t it that case that no matter how fast they can make it, it is still doing way more work than an approach that can determine what parts of the DOM need to be updated without DOM diffing?
The key is that when you update a Svelte store you must return a new value. It's enough to just return the value you updated. You see that happening here on lines 16 and 21.
I take your point that this is not as transparent as when using observables. But at least you can use classes that have relationships and call methods that modify the objects when those objects are in Svelte stores.
<div>
Hello, {$person.name} at {$person.zip}!
</div>
Of course if person is only used inside this component, you would not use a store. If it is used in other components, you would typically define and export the store in another .js file and import it everywhere it is needed.
My point is that this is a very simple way to share state between components and nowhere near as complex as the page you shared might indicate. That's because you do not need to use derived stores or custom stores. The simple writable store works in most cases.
Yes, but it is so much easier to implement Svelte components than components in Angular, React, or Vue. So much less code to write. No need to write classes, just plain functions, so no need for "this". Automatically scoped CSS. Very easy state management, both inside components and shared between components. And Sapper adds even more cool things like server-side rendering and code splitting with no configuration required.
A Svelte store can hold a deeply nested object. It's up to you how fine-grained you want the stores to be, anywhere from one store per value to one store for the entire application. I think a middle ground is best.
If you are referring to my article, "small footprint" is not the main point for me. The main point is ease development due to features like easier component state management, app state management with stores and sharing data between components with context.
You said "My personal view is that the 'what' in frontend development generally isn't super interesting and most web frontends are very similar." I think if you take a serious look at Svelte you will see that it is much simpler than the current popular web frameworks.
If your most pressing issue is making managing state easier, you should run to Svelte! Take a look at how Svelte supports "stores", "context", and state within a component. Those are so good that I predict nobody will ever feel the need to write a state management library for Svelte. It's already very easy!
Not true. That section mentions several other "Whys" including this: "Svelte dramatically simplifies component and application state management. Contributing features include context, stores, and module context, each of which is covered in detail later."