3 ms·

Once you're building custom components in JS files, aren't you basically writing your own microframework? Sure you don't need bundlers and compilers (such as T

Once you're building custom components in JS files, aren't you basically writing your own microframework? Sure you don't need bundlers and compilers (such as TS to JS), but at some point you might need async updates on `fetch()` of components that also share state with other components. At this point you're into framework territory, whether using your own or someone else's. Producing a framework with those features that still fits in a single small size JS file would be great, especially if it can do component updates to shared state (without updating the DOM each turn, hence shadow DOM).

oxcabe 1y ago
Just checked what's there for libs implementing local state management + server-side sync in vanilla JS. The best options I found were `@tanstack/query-core`[1] and `@signaldb/core`[2]. The former packs no dependencies, with a total size of 89.18 kB if you were to put all the module JS code together, unminified, on a single file. Which could be even smaller with an optimising bundler that tree-shakes and minifies the build. [1]: https://www.npmjs.com/package/@tanstack/query-core https://www.npmjs.com/package/@tanstack/query-core [2]: https://www.npmjs.com/package/@signaldb/core https://www.npmjs.com/package/@signaldb/core
WorldMaker 1y ago
That's why there are an increasing number of "microframeworks" for Web Components such as Lit and FAST. (My own Butterfloat I think works very nicely in Web Components, too, though some would quibble that it isn't a "microframework" because its one and only dependency is RxJS, which isn't as bloated as people remember it being, but has that reputation.) > (without updating the DOM each turn, hence shadow DOM). Uh, Shadow DOM doesn't help with DOM performance and can make some things worse. If your Web Component has terrible DOM performance in the Shadow DOM that can still noticeably degrade DOM performance of the entire DOM. I'm of the growing opinion that the Shadow DOM is over-complicated for what it tries to do and most Web Components don't actually need the Shadow DOM and would be better without it and would have a better idea of their own performance (issues) without it. Hot take: The Shadow DOM is built for advertisers that want beefier iframes, not for building good performance.

oxcabe 1y ago

Just checked what's there for libs implementing local state management + server-side sync in vanilla JS. The best options I found were `@tanstack/query-core`[1] and `@signaldb/core`[2]. The former packs no dependencies, with a total size of 89.18 kB if you were to put all the module JS code together, unminified, on a single file. Which could be even smaller with an optimising bundler that tree-shakes and minifies the build. [1]: https://www.npmjs.com/package/@tanstack/query-core https://www.npmjs.com/package/@tanstack/query-core [2]: https://www.npmjs.com/package/@signaldb/core https://www.npmjs.com/package/@signaldb/core

WorldMaker 1y ago

That's why there are an increasing number of "microframeworks" for Web Components such as Lit and FAST. (My own Butterfloat I think works very nicely in Web Components, too, though some would quibble that it isn't a "microframework" because its one and only dependency is RxJS, which isn't as bloated as people remember it being, but has that reputation.) > (without updating the DOM each turn, hence shadow DOM). Uh, Shadow DOM doesn't help with DOM performance and can make some things worse. If your Web Component has terrible DOM performance in the Shadow DOM that can still noticeably degrade DOM performance of the entire DOM. I'm of the growing opinion that the Shadow DOM is over-complicated for what it tries to do and most Web Components don't actually need the Shadow DOM and would be better without it and would have a better idea of their own performance (issues) without it. Hot take: The Shadow DOM is built for advertisers that want beefier iframes, not for building good performance.