observable VS vanilla-todo

> especially since Observables have been widely available and actively worked on for a long time, without seeing wide adoption

Take a look at "Userland libraries" section [0] of the proposal (almost certainly written by Ben). He argues that observables get reinvented in the userland in various libraries over and over again. It is a primitive, like a Promise, only better.

[0] - https://github.com/WICG/observable?tab=readme-ov-file#userla...

Perhaps this falls into the repetitive boilerplate category you referred to, but if you want framework-agnostic domain objects that still work well with Svelte, create your own using the observer pattern.

Create an object with a subscribe method and whatever other methods make sense for updating its state. Svelte will treat it like one of its stores, and it will work with the $ syntax. It can be used with React via its `useSyncExternalStore` hook. It can be used with SolidJS via its `from` utility.

If you don't want to handle the set-up boilerplate, you could use another library like Effector or RxJS, but of course, that means another dependency. There is a gradual move to make something like this a part of the platform[1], but who knows when or if it will land.

[1] https://github.com/domfarolino/observable

Thanks for this, gives my intuition some words to back it up!

I find especially compelling how the author separates concrete problems like reconciliation (hard to argue against) from the abstract principle of "everything should be a component" (can be argued more easily IMO).

Shamelessly plugging https://github.com/morris/vanilla-todo here; in this try-hard-to-stay-vanilla case study there are similar conclusions: Reconciliation is hard, CSS global namespace is problematic, etc. - I also did not use web components, but could not explain/justify that decision well (until now!).

A few years back I stumbled into something a bit more complex, still done in pure js, just for the hell of it: https://github.com/morris/vanilla-todo

And then wrote my own version, with code a lot closer to modern react, with undo/redo and other niceties - https://github.com/ivank/vanilla-teuxdeux

And what I leaned is that is astonishingly easy to write code that would be understandable to people coming from the redux crowd. Maybe that’s because redux is just such a simple concept in and off itself - a glorified switch on a big object. And it’s also quite easy to hack a simple version of vdom to make it all work.

What’s missing from all those vanilla js efforts though turned out to be testability. There is a ton of code in the modern js world just to allow you to mock/test your components, and thats for me the real tragedy of vanilla js.

I have no idea why W3C crowd have not invested into standardizing js tests in all these years…