Right, but you do avoid worries like "will I have to update this dependency every week and deal with breaking changes?" or "will the author be compromised in a supply-chain attack, or do a deliberate protestware attack?" etc. As for performance, a lot of npm packages don't have proper tree-shaking, so you might be taking on extra bloat (or installation cost). Your point is well-taken, though.

You can avoid all those worries by vendoring the code anyway. you only 'need' to update it if you are pulling it in as a separate dependency.

> you do avoid worries like "will I have to update this dependency every week and deal with breaking changes?

This is not a worry with NPM. You can just specify a specific version of a dependency in your package.json, and it'll never be updated ever.

I have noticed for years that the JS community is obsessed with updating every package to the latest version no matter what. It's maddening. If it's not broke, don't fix it!

As someone who has actually worked on JavaScript frameworks, I think Marko is criminally underrated. The compile-time optimizations are extremely impressive: https://markojs.com/docs/explanation/fine-grained-bundling

I was not surprised for example that Marko came out very well in this performance comparison: https://www.lorenstew.art/blog/10-kanban-boards

I remain convinced that RSC and the SSR craze was a result of someone (or multiple) people needing a raise and their friends wanting to start a company selling abstract compute. Statically hydrated, minimal React was pretty great when served over good CDN infrastructure. Then I watched the bundle sizes and lock-in balloon. That second article is a dragon slayer. It really lays out the problem with React. In marrying itself to Next.js and embracing the server, it's betrayed the platform. Meanwhile, the platform itself has matured. React practically built my career, and I just don't have a reason to choose it anymore.

SSR isn’t a craze. Web applications have been served that way for literal decades now.

Read it in context. There's nothing wrong with SSR.

I agree, if there is a death of React it will be killed by Next/Vercel.

I probably shouldn’t care. I’m just not looking forward to the chaos of another full “turn” in JavaScript, akin to query->backbone or backbone->react.

Maybe I shouldn’t fear it. I’ve just yet to see an idea that feels valuable enough to move an entire ecosystem. Svelte, HTMX, etc… where is the “disruptive” idea that could compel everyone to leave React?

That’s interesting. I’ve always held SvelteKit in high regard for greenfield projects because it balances capability, developer experience, and performance, but I’ll have to give Marko a look. I’d love to see a similar deep dive into Electron style desktop frameworks since that space still feels underexplored compared to mobile. I honestly wouldn’t know where to start for a video game interface, and that bothers me.

Author here. I actually did some research on CSS selector performance: https://nolanlawson.com/2023/01/17/my-talk-on-css-runtime-pe...

The TL;DW is: yes, class selectors are slightly more performant than attribute selectors, mostly because only the attribute _names_ are indexed, not the values. But 99% of the time, it's not a big enough deal to justify the premature optimization. I'd recommend measuring your selector performance first: https://developer.chrome.com/docs/devtools/performance/selec...

I use shadow DOM every day, but yes, it is often the part of WCs that baffles people – probably because they don't need it.

Alternative approaches that may work for your use case:

- "HTML web components" [1] - light DOM only, SSR-first, good as a replacement for "jQuery sprinkles"

- "Shadow gristle" [2] - use as little shadow DOM as possible. If you need styling or composition, put it in the light DOM!

[1]: https://adactio.com/journal/20618

[2]: https://glazkov.com/2023/03/02/shadow-gristle/

I cover this in another post [1], but broadly:

- Not every web app is perf-sensitive to every extra kB (eCommerce is, productivity tools typically aren't)

- Plenty of frameworks have tiny runtimes, e.g. Svelte is 2.7kB [2]

- I wouldn't advocate for 100 different frameworks on the page, but let's say 5-6 would be fine IMO

No one is arguing that this is ideal, but sometimes this model can help, e.g. for gradual migrations or micro-frontends.

BTW React 17 actually introduced a feature where you could do exactly this: have multiple versions of React on the same page [3].

[1]: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp...

[2]: https://bundlephobia.com/package/[email protected]

[3]: https://legacy.reactjs.org/blog/2020/10/20/react-v17.html

Author here. I cover this in another post [1], but basically the interop benefits you get on the client just aren't there (yet) on the server. My north star:

> Maybe in the future, when you can render 3 different web component frameworks on the server, and they compose together and hydrate nicely, then I’ll consider this solved.

[1]: https://nolanlawson.com/2023/08/23/use-web-components-for-wh...

Thanks a lot! I was just trying to highlight the cool work that browsers do under the hood, but which wasn't very well-known. So I'm really glad that folks enjoyed the talk. :)

Author here! I struggled with the word "modern" – I could have said "current gen" or "post-React" or even "Solid-inspired" frankly, but I thought "modern" was succinct with the right amount of punchiness.

Obviously a lot of these techniques are pretty novel, and maybe they won't stand the test of time. Or maybe a new browser standard will make them obsolete eventually. But for now these seem to be the current wave anyway.

Perhaps you could have said that it is built using more modern JS APIs - template literals instead of string manipulation, Proxy(), queueMicrotask etc.

Author here. Thanks for the thoughtful reply!

I did indeed mix up `useMemo` and `React.memo` – fixed it in the post.

You're right, I am skipping a lot of details (hence "to grossly oversimplify"). I know that React doesn't invalidate the whole tree, but it does in the worst case. Maybe I should add a note about that.

Svelte not being truly reactive makes perfect sense, but in Svelte v5 my understanding is that "runes mode" does exactly that. This is what I mean by "moving in that direction."

Hard to ride the line between clear, concise explanation and perfect technical correctness; I thought you picked good tradeoffs in your article.

Appreciate the response! You're right on Svelte v5; I just confirmed that Svelte's new runes are indeed reactive:

    let count = $state(0);
    
    function increment() {
      count += 1;
      console.log(count + " + 1 = " + countPlusOne);  // prints "1 + 1 = 2"
     }

    let countPlusOne = $derived(count + 1);

could you explain why this demonstrates svelte is reactive?

What's the definition of reactive is I think my question and having a clear demo is useful - if I understood it it looks a useful piece code

I never used svelte, so it’s probably a weird question, but how is increment() called?

The calling location has been omitted from the snippet. You don't need to do anything special to call it, just `increment()` wherever it's in scope.

`<button on:click={() => increment()}>+</button>`

> I know that React doesn't invalidate the whole tree, but it does in the worst case

You mean *invalidate the whole subtree, right?

Thanks for the shout-out! I think I mention this in the talk, but note that YMMV. I designed that benchmark as a kind of "worst-case scenario" where shadow DOM / scoped styles really show a benefit. Depending on your CSS rules, DOM size, and amount of thrashing, the perf benefit could be small to large.

Also, it's still possible to shoot yourself in the foot, especially if you have a large/complex stylesheet repeated across multiple shadow roots. (Not because of the repetition – that's optimized in browsers [1] – but rather because of the number of DOM nodes affected.)

That said, I still think the perf benefits of shadow DOM have been undersung. And Declarative Shadow DOM makes it way more useful.

[1]: https://github.com/whatwg/dom/issues/831#issuecomment-585489...