HTML Web Components

That's exactly what React is though?

Rendering react on the server isn't some magical hip technology. It's just a different template framework. I'm not pretending this is anything special or fancy.

I am more a fan of the augmented style because it doesn't entrap you in dev lock-in to platforms.

The problem with frameworks, especially web frameworks, is they reimplement many items that are standard now (shadowdom, components, storage, templating, base libraries, class/async, network/realtime etc).

DOM rendering speeds have been improved due to virtualdom but is no longer needed with shadowdom.

The web standards of today are amazing and take away the need for frameworks today: from templating to html templates [1], vanilla javascript with classes [2] and async [3] and better api access like fetch [4] and browser support for vdom with shadow dom [5], components with WebComponents [6][7], css now with lots of additions like variables [8] transitions[9]/animations[10], flex and media queries, canvas/svg/etc for interactivity, and so much more. There is little need to use frameworks except to sell books and conferences and keep developers locked in.

React for instance jumped ahead and front ran WebComponents and ShadowDOM, those are both part of the browser and standards now. The killer feature phase of React is over.

If you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice. [11]

Google Lit is like a combination of HTML Web Components and React/Vue style components. The great part is it is build on Web Components underneath.

[1] https://caniuse.com/template

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[3] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[4] https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...

[5] https://caniuse.com/shadowdomv1

[6] https://caniuse.com/custom-elementsv1

[7] https://developer.mozilla.org/en-US/docs/Web/Web_Components

[8] https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_c...

[9] https://developer.mozilla.org/en-US/docs/Web/CSS/transition

[10] https://developer.mozilla.org/en-US/docs/Web/CSS/animation

[11] https://lit.dev/

I'm not sure I buy the "React is replacement, not augmentation" argument. At the end of the day/render, React still renders HTML elements... with javascript event handlers. Wrapping an '' in a React component doesn't mean I've taken away any functionality of 'img'. I just add to it -- augmentation.

Maybe the author has worked in different React codebases than I have, but in my experience, we use built-in browser functionality unless we have a reason not to. Maybe I've just been lucky?

Staying closer to web standards is always best for maintainability and portability. I personally like custom direct standards but that doesn't always work in a team for some reason today. There will always be less dependencies in a straight standards solution, that makes for better maintainability and opsec. I also think it is better for web developers to know standards over just abstractions, it makes for better developers.

Additionally, web standards like Web Components/templates/custom elements will always be faster at browser level.

The article from OP mentions this:

> But the unique power of web components (in the browser) is that they can render before JavaScript. React components cannot do this — full stop.

There are other reasons as well but these are the best reasons.

I think using a framework for a team isn't a bad idea, but for products and personal projects I like going custom or newer framework like Lit simply because of the web standards being less abstracted away and due to that, less need to constantly update on others schedules due to dev lock-in. There is less weight in straight standards.

If you remember React/Vue originally won due to virtualdom and being small parts that work into an existing web, but recently they have been very monolithic in that they take over the entire project. The web is more about augmentation as the article mentions and I agree, those items will be easier to maintain.

I'm a backend php dev who is hopelessly behind on the frontend literature, so here's pseudocode for how I would like web components (dynamic tag definitions) to work:

  
    
      
        
          alert($message);
          setTimeout(function () { alert("Boop!"); }, 10000);
        
        
        
$message
      
    
    
    
      
      
      
      
    
  

By default, the browser would allow setTimeout(), so the user would see alerts showing after 10 seconds. But there should be a custom script.js that works like stylesheet.css that the user can set for the browser. It could have a line like quitTimeout() which would disable setTimeout() for all pages. And something like setScriptLifetime(5000) which would run Javascript for 5 seconds in this case, preventing the alerts, then only allow new scripts to run upon user action. Or even have an option like setScriptLifetime(5000, 0) where the second argument sets a lifetime for new scripts, in this case preventing all future scripts from starting.

That right there would make browsers run about 1000 times faster regardless of how many tabs are open, as well as stop most of the slowdown from ads.

Maybe should be to make it inline. Or so as to not confuse new tag definitions with existing tags. As they say, the devil is in the details. But I think it makes sense to nest the tag definition in case or tags are needed, which would maybe get installed in the parent page. And there are endless use cases for passing variables to/from tags which are beyond the scope of this comment. Probably that would happen through data tags, passing JSON or raw Javascript like for onclick="alert('Hello')" where myTag.data = 1 + 1 would be like re-rendering with .

But if we had something like that, frontend code would end up several orders of magnitude smaller, because we'd get back to declarative interfaces with progressive enhancement, more like what Htmx is working towards.

Keep in mind that I thought of this in 1995 when I very first saw NCSA Mosaic, and was flabbergasted that html tags weren't dynamically defined this way. When Netscape copied Mosaic but failed to fix even the slightest oversights like this, I knew that the future of the web was in perile and that we'd end up with the imperative stateful mess we live with today.