Also read these articles for more on the idea of "HTML Web Components":
https://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - "So there you have it: a few thousand words on my journey through coming to understand and work with these fully-Light-DOM web components, otherwise known as custom elements. Now all they need is a catchy name, so we can draw more people to the Light Side of the Web."
I just don't get the point. They are cumbersome to use, so now you need a lightweight framework on top of the built in framework such as Lit (which btw is larger than Preact). Then they solve none of the real problems like state management, routing, etc... so you'll likely need to pull in more.
Sure you can get re-usable components. But are you going to pull in a re-usable web component that might use say Vue underneath when you use React? It just doesn't make any sense.
I think there's a lot of value for classic server-side web applications rather than SPAs. That handles routing, state, etc. I'm personally a fan and hope that the server-based application renaissance happens as some predict.
Most people using react aren't building SPAs. Vue/React can be used the same way as jquery, which is to add enhanced UI functionality that server-side HTML views simply can't offer.
For example, on my company website there's a timezone select box with 151 options. Asking a user to scroll through 100+ options is a big ask vs typing a few characters and hitting enter. There really is no static server-side way to solve this problem (I tried hard to think of one)... without creating a multi-page Wizard for what should be a single field on a larger form.
If you're building a SaaS product there are many UI requirements that demand high-interactivity and and there's really no better mainstream solution atm than static-first sites with small "islands" of React/Vue/etc components (ideally with hydration).
People still abuse React/Vue of course and the trend is 100% moving back to "mostly static" rather than slow SPAs but IMO JS-powered components are not never going away unless browsers start offering a broad selection of built-in complex web components like comboboxes, datepickers, tooltips, etc.
The <datalist> element with a text input field is an HTML native typeahead, which works great with SSR or you could wire up the datalist client side with an XHR creating the datalist.
You maybe don't get full control over the rendering style of it, but it's a still significantly more usable than the Angular Material autocompletes.
> Recommended values in types text, search, url, tel, email and number, are displayed in a drop-down menu when user clicks or double-clicks on the control.
On paper, <datalist> is great but as implemented (or not) in all browsers, it has issues. This post walks through an example of using the element but also summarizes issues (as of June 2023): Under-Engineered Comboboxen?
> People still abuse React/Vue of course and the trend is 100% moving back to "mostly static" rather than slow SPAs
I'm not seeing this at all, in fact I can't remember the last React project I worked on that wasn't a full blown SPA. I don't see anyone starting or advocating for static sites with islands unless they're using a framework like Astro or something.
Do you have any example sites or codebases using this approach?
Web components are only useful IMO in the case of a large enterprise which wants to systematically and consistently style a large number of applications written by different divisions in different frameworks in different languages targeting different clients.
I'd add longevity. If your company works for a product where you'll have to maintain the code you write now for the next decades, you don't want to deal with then-ancient abstractions. The JavaScript of a well-written web component should be as valid now as it will be in 10 years, as you're just using the platform.
This year I pulled class-based React component into a greenfield React project. Worked without a hitch, even though its a 10-year difference between approaches.
Meanwhile, "use the platform":
- all form components written before form participation landed in browsers are broken
- all web components written before cross-root ARIA (not even a spec yet) are potentially broken due to shadow DOM
- ... you may continue this list at your own leisure ...
Yeah I don't get the comments either. React has been there for a decade now, is pretty stable and very backwards compatible. You can't really go wrong with it and it's a super lightweight "framework" (I know, it's not a framework, maybe a library would be a better term) all things considered.
The issue is just some sort of "front end bad" feeling at this point, imo. It's like some people think web components are the answer to the popular perception of the frontend being a mess of yearly novelties. When again, you can just use react and could have done so for a decade now.
I think the criticisms of not solving state management and routing are well taken. I've tried to create a minimal sub-300 line, sub 3KB-compressed micro base class for using custom elements that reduces their cumbersomeness!
I wonder what minimal solutions to state management and routing might look like in Hyphen: https://github.com/00000o1/-
I really appreciate there being some concerted advocacy for shadowless web components!
So much of the beauty & elegance of the web was how declarative everything is, as that grants such observability & malleability. Shadow dom felt such an enterprise desire, to build much higher encapsulation walls, to layer in so much certainty, and that never felt like a goal I shared.
This article shows how light dom work can compose. I want to see light dom advocacy go further. It always seemed clear to me a web component/custom element could and should just self-modify the dom inside of it, move children around, build new content. Another example in the comments talks about maybe the user avatar element adding a div with the users name... Maybe the page or framework adds the icon, and the custom element then inserts that name, or that name and some aesthetic embellishment.
I guess my one concern with light dom / html web components is it seems like there have been - in some cases - some good performance wins from shadow dom. This wouldn't change what I go for unless I was desperate, but as a dev, in my head I see how shadow dom can scope down and reduce the number of elements that have to be traversed for a css specifier. and I want that win to be available somehow to me.
Really elating to see a lighter take on custom elements / web components. Thanks for the great links Simon!
I just think SSR is kind of missing it because web components allow a static frontend bundle to have a power that was previously reserved for SSR or HTML-only apps.
Moving the render off the client is nice, but removing the prerender altogether is something much cooler.
If you have a static frontend bundle, isn't that just SSG (static site generation)? And if you can generate the site at build time, what's the fundamental difference between any of the non-web component SSG solutions and a web component SSG solution? Sure, you can pretend like there will be "no build step". But only if you're fine with "no proper cache headers" (and a long tail of other things). So in practice - hopefully there _will_ be a build step anyhow.
Or You could instead use this magic thing that has been around for decades, has massive tooling and most importantly, doesn't lock you into one specific ecosystem of language that was never supposed to be run server side to begin with;
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.
Doesn't this create some nasty coupling since your web components look like a div but can actually require an arbitrarily complex HTML schema underneath? Can I write that down somewhere?
Yeah that is my confusion too. The nice thing about react components is that I don't have to remember to write all the div elements inside them, but from this example I do.
If things like slots are used, it isn't necessarily nasty coupling. But I agree this approach does make more a more complex tree structure than something you would see in a typical JSX/TSX file.
That said, I think the author's bigger point was that augmenting, rather than replacing/abstracting away basic web elements will win out long-term. Some degree nastier-looking coupling is a worthwhile trade over more opaquely-operating render libraries. I suspect augmented web components fail more gracefully too.
> they can render before JavaScript. React components cannot do this — full stop
Not a full stop; SSR means they could render before client-side JS.
The example is a bit too simple to make the author's point IMO. A web component that handles changes to state would be a better comparison, and make for a better argument.
How would an "Html Web Component" handle state change? I was a bit lost on the benefits given the example of wrapping an img tag. Sure you could group and reuse common elements but you would still need javascript to do anything interactive. Even in the example given the alt text of the image is typically dynamic now because of localization so even then content is missing with javascript.
Do you want SSR for SEO, or for fast first interaction? Because if the latter, then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups.
This is a good point, but I would counter, perceived speed of rendering from a user perspective is more important than time to interact with the app/site (a reasonable time to interact is however very important.
Good load order and only loading in the content and JS above the fold initially helps a ton.
JS frameworks are huge and I am still saddened that proper tree shaking and optimization got left by the way side in how the modern web has evolved.
I worked with google closure in advanced modes and the closure components for a few years and the compiler was absolutely astounding (and the components designed with the compiler in mind) in code splitting, tree shaking and minimization.
It's a nice idea and I'm glad we can expand the language to differentiate between html web components and javascript web components. That's important because the vast majority of use of web components are in the form of javascript web components. The only time I've ever seen HTML web components are on blog posts talking about how you can use web components. Never on an actual website about something besides web components.
I want to believe... but reality is stacked against HTML web components. I'm just going to stick to HTML and leave the HTML with dashes to others.
I’ve made a couple of big SPAs that use Lit to manage views.
I can’t link you to them here without blowing my cover, but honestly I love working with web components, and being able to do it natively rather than propped up by a mound of JavaScript feels good.
You're not doing it natively. You're using a framework replete with its own custom DSL, multiple workarounds for issues like SVGs, its own data binding system etc.
It's just as native as any other framework under the sun.
Sorry, I’ve been working with web components since before they had wide browser support - so now, it’s ‘native’ in the sense that web component is a feature native to the browser, instead of being shimmed / polyfilled in. You can just write web components in an .html file, drag it into the browser, and it works, no build step or servers or external libraries required.
I do use them on my OSS work (https://github.com/mickael-kerjean/filestash/tree/master/pub...) since I've started migrating away from React to VanillaJS. The app itself is a file manager for every possible file transfer protocol there is (FTP, SFTP, S3, NFS, SAMBA, ....) and is used by many thousands of people
> No Build Steps, No Client-Side Router, No JSX, No Shadow DOM. We want you to build an MPA, with mainly HTML/CSS, and return HTML responses instead of JSON. Then add interactivity as needed.
> Declarative templates with lit-html. Supports event handling, attribute binding, composability, caching, and expressions.
For me, that's the beauty of Web Components. You can find (or build) a base class that works the way you need it. I like a React class component style class with an XState-inspired state machine built in.
Have you tried HTMX before? Seems strongly aligned, with HTMX perhaps having a bigger community. Curious if you have, and found it lacking in some way.
"For folks who have an existing server-rendered application, you can use Cami to add interactivactivity to your application, along with other MPA-oriented libraries like HTMX, Unpoly, Turbo, or TwinSpark."
One problem is that "web components" is not a thing, you don't make "a web component". "Web Components" is the name a stack of three things that, taken together, make up the Web Components API.
You don't really make "a web component", what you make is a Custom Element, which might use a Shadow DOM, and might use an HTML template. Three things of which the most important one is the custom element.
With the core concept being that you're just making "more HTML elements", everything you can do with those, including which attributes and JS API they support, is up to you, and the way you put them on a page, the way you interact with them, the way you listen for events on them, etc. etc. is the exact same as any other HTML element. If you known how to write web pages the "old school" way, then you already know how to use custom elements. You just need to learn how to declare them.
Not if you use react server components, then markup is streamed in chunks as it gets rendered on the server and patched into the dom on the client. The JS for those components is never sent to the client.
>The browser then re-hydrates the page via JavaScript loading all of the JSON/code and computing everything (rendering it again).
isn't this exactly what's going on under the hood with web components? if you send an html page including <user-avatar><img></user-avatar>, the browser is going to draw the <img> tag and treat the <user-avatar> tag as a no-op because it doesn't know what to do with that. then your javascript kicks in and transforms the <user-avatar> tag into whatever the javascript defines it as, at which point it will get re-rendered.
Of course there's a tradeoff--- if everything is a component then it may as well be an SPA (or at least bundle those files...).
I don't think the core idea was to ever use "hundreds" of components. HTML should be able to do a majority of the work, and you sprinkle a component here or there as needed.
That is one way to do it, provided `user-avatar` extends HTMLImageElement and not the more generic HTMLElement. Extending built-ins and using the `is` attribute is not supported in Safari however and last I checked they were firmly opposed to it.
They're different things, though with an extremely simple component they might achieve a relatively similar goal. The downside of `is` is that you can only specify a single element to map to the component. An example of why you'd need to take the slotted approach is if you had something like this:
With the massive caveat that I'm not a web developer or react developer, doesn't this stuff just look XML? I know html is a subset of XML but this stuff looks more and more like the XML that everyone complains about.
Edit: I'm meaning the attributes being longer than what the tags are denoting.
We use web components in our project (a reactive Python notebook that, among other things, lets users build simple web apps [1]) to make it easy for the user to instantiate and compose our UI elements. Users can easily interpolate these elements into markdown, for example, since their representation is just HTML.
I was interested to see this article explain what `user-avatar` actually did/provided but it never did. Does it just have styles in it? If so why wouldn't I just use css classes?
I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable?
Vue/React/Angular don't seem like they are trying to "replace" HTML (re: "XHTML wanted to replace HTML4, but HTML5 wanted to augment it. HTML5 won.", in the "On The Web, Augmentation Wins in the Long Run" section), they are taking HTML/CSS/JS and building on top of them. If they all used canvas to render instead I might buy that argument but they don't. They absolutely push those technologies to their breaking point but it's nothing short of amazing in my book what you can accomplish with them compared to just HTML/CSS/JS and even "web components".
I was excited when Web Components were first announced but they are incredibly lackluster with no "Batteries included" and feel like they don't really help you build web _apps_ like the frameworks do. Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app.
I mean, anybody is free to write how they like on their blog. I just don't find arguments like these convincing without realistic non-trivial examples.
I'll give it shot to build a super simple one with just vanilla JS without helper libraries like Lit or Stencil. I think I'd take the same approach as I would with React, and I think the biggest difference would be where the fetch gets executed. In React you'd expose a prop like "submitHandler", but here I would emit an event from the component (after whatever debounce amount) and expect the caller to attach an event listener to my custom event to perform the fetch.
Lack of substantial concrete examples is an issue with many of these anti-react technologies. Even svelte doesn’t seem to have many (any?) examples of large scale commercial projects using it.
In the last 10 years the only new web tech I’ve seen get traction outside of tech communities - so actual job postings etc - is vue.
>"with no "Batteries included" and feel like they don't really help you build web _apps_ like the frameworks do."
Define _app_. React doesn't have batteries, it has composability. Web Components do too but you have to know how (it's a lot easier in React, just return (html)) but in Web Components, you can register your custom element and provide the functionality that you call "batteries". [1] So if you don't care about attributes and just want semantic composable things, just call it whatever you want to. <user-avatar></user-avatar>. Conceptually it's a web component that extends HTMLDivElement.
The benefit boils down to progressive enhancement: because an img tag has built in behavior you simply rely on default rendering behavior and provide "augmentation" as needed via your web component.
What's the advantage of this over just using divs for everything, though? If this used shadow dom, I could understand. But custom elements don't even behave like blocks by default. Namespace collisions with custom components are just as bad as class collisions, if not worse since you can't `.myns.button`. Is it just the `connectedCallback` versus some manual method of wiring up elements to their javascript behaviors?
That still doesn't click for me. Why wouldn't you make the label/slider part of the component itself. It feels like you have the worst of both worlds. You more or less need/expect it to always wrap those elements but nothing enforces that so this seems very brittle to me, not to mention verbose.
They mention not wanting to pass though all those props:
We will ignore the last 2 since those are required anyway. How is `type="range"` not the default that you would just set, no attribute/prop needed? Then min/max/step/value all feel like things you could have defaults for and then, yes, pass them through. In forms I'm always pushing towards consistency, I don't want to make it easy to just set random attributes on the underlying element, it needs to be deliberate.
I can believe I'm just missing something but Web Components just seem like extra work with very little gain.
The article argues between the difference of a JavaScript Web component and a HTML Web component, you describing the former, thus the need for JavaScript.
Personally I think the main problem here is client side rendering to begin with, with a modern server side templating library you get a component based structure too and can abstract whatever HTML tags you want in your component before client side JavaScript.
Problem with React is that it is JavaScript first, you always begin with a JavaScript function, but in my opinion the web should be HTML first.
> The article argues between the difference of a JavaScript Web component and a HTML Web component, you describing the former, thus the need for JavaScript.
The article goes on to add a good little bit of JS to make everything work they way they want. They still need JS to accomplish what they want. If you turn off JS things will break in that example.
> Personally I think the main problem here is client side rendering to begin with
I mean unless you want to roundtrip for new HTML segments (aka Liveview or whatever Laravel has) you either need to have client-side rendering or duplicate your rendering logic (in something like both PHP and JS for the fast update without refreshing on each click). I'll never duplicate rendering logic again if I can help it and that means client-side render (potentially with SSR for the first render). It avoids so many bugs/issues.
> but in my opinion the web should be HTML first
This just feels dated to me. I fundamentally do not understand this desire. What do you gain from the web being just HTML? What does that even mean? With a CSR framework you are still rendering out HTML, I don't understand why some people care that the HTML was generated server side or client side. The web has moved on from being just documents, it's interactive and that provides a much better UX.
Sure, the article is incomplete in the sense that it doesn't fully commit to the idea of HTML Web component as opposed to JavaScript Web components, but it is the correct way of thinking about this.
There will almost always be a roundtrip, either to fetch HTML segments or to ask for more JSON data, except for the rare cases you already have everything, because that is the nature of client-server paradigm.
By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever, to the browser, over Ajax or in the email. No need for buggy asynchronous SQL JOINs over HTTP and infinite state handling.
If you always start with a JavaScript function, and all that comes with that, you need a programmer to be able to create the web, but with HTML (and CSS) first you can have other categories of people do that, like designers. And combine that with a library like htmx you can then enhance that experience for interactive parts and still keep everything in the same backend template. And if it still a need for more complex interactive parts a programmer can can add that with JavaScript afterwards. That is a much better division of labour.
And it is not outdated, browser actually excel in rendering HTML documents, that is what they are designed to do, thus it will always be faster to render the HTML document as it is rather than building it on the fly.
And also the core idea of reaching for JavaScript before HTML will result in suboptimal solutions, I have seen so much unnecessary JavaScript code that could have been easily solved with a few lines of HTML. This change of perspective changes how we think and reason about a problem and therefore our solutions as well. That is why the bootstrapping of a "modern" web app has become more and more asinine.
Another problem with frameworks like React, Vue, Angular and et al have is that they have their own lifecycle and that has made the web closed and not open how it once was, closed in the sense that you can't enhance the HTML document from the outside after it been rendered, thus this leads to the assumption that the person(s) who wrote the site is also the person(s) that manages or uses it, that is a bad assumption.
> Sure, the article is incomplete in the sense that it doesn't fully commit to the idea of HTML Web component
What is that, exactly?
> By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever,
All frameworks can do that. Web Components cannot.
> If you always start with a JavaScript function, and all that comes with that, you need a programmer to be able to create the web, but with HTML (and CSS) first you can have other categories of people do that, like designers.
Web components quite literally don't work without Javascript. And they need Javascript to be able to do trivial things like form participation.
The core of the web only need basic HTML with closing tags (and properly shaped singleton element/tags) with the basic grammar (from the specs), utf8 encoded, no script.
It is enough for a bazillion of online services, that without requiring a beyond insanely complex and massive web engine from Big Tech. basic HTML forms can do wonders.
Of course, you can have a full blown Big Tech web app, but don't forget to have a interop portal with noscript/basic (x)html browsers to avoid, at least for critical online services, Big Tech lock-in and unreasonable exit cost.
That said, it may be a good idea to be able to drive the display or not of <table> rules with the default styling (css or hardcoded) from the 2D semantic HTML document attributes (I should check the hardcoded style of links and lynx for <table> rules).
(I am not talking about the abomination of the "semantic" web we had a decade ago)
If you are only doing web as documents with links. As soon as you use any Forms and error back-and-forth you have to either patch over the web stardards, or annoy your users with sub-par functionality.
I don't agree, what you call "back-and-forth" is not negative, actually it appears more like "consistency" to me... and in the end, more than enough for a bazillions of online services and that at a ridicule technical cost compared to the one from Big Tech (not to mention all the corollary issues).
Of course, it is a trade-off, bells-and-whistles from rich GUIs are sexy, but the technical cost of such bells-and-whistles in a web context is grostesquely and absurdely unbalanced compared to what can be achieved with simple and consistent noscript/basic (x)html portals for any pertinent goal of a bazillions of online services.
If you don't care about UI/UX then I agree. I do and even if I didn't the companies I work for absolutely do and the customers expect a certain level of UI/UX that is absolutely not possible with no script. I also work primarily on web apps which cannot be done without JS.
Well, it all depends on what the "client" "wants".
The problem often lies with the client tantrums.
I was more talking about critical online services which have a duty of interop with Small Tech and must not force users into Big Tech engines only, that to keep the door open to alternatives of reasonable "size", and at the same time to lower significantly exit costs.
But that's smashing open doors, most are aware of those issues here on HN. The real issue is implementation: it has to happen in a regulatory framework, laws dealing with discrimination, and my lawer has been looking into other legal leverages (yeah, I have an open conflict with my administration). The regulatory framework is here, but lobby-ied heavily by Big Tech, making it ineffective and pointless.
A bit like what they have in the US with the "utilities" which then have much more regulatory duties than "non utilities". You also have anti-trust stuff: dominant corpos are much more tied to regulatory constraints, that to let alternatives to be viable (well, that does not seems to work very well in the US). In my country, anti-trust ultra-aggressive regulations did wonders in the telecom industry.
You can still have a web app with a rich GUI, an anonymous simple and stable in time public HTTP-based middleware protocol (which allows to develop Big Tech independent rich GUIs), etc, until the core functions are provided to noscript/basic (x)html browsers (if one thing must work, it is this one).
No JS makes HATEOAS-like experience easy. Like for example right clicking an object you want to edit to open on a new page, edit it there, and click back and get it loaded as it was in less than a microsecond. Or opening 3 things to edit in different tabs, splitting them across the monitor and working with 4 copies of your app.
Problem is, i dont see a page that does more then a blank text with simple logos to be user frendlly to regular non tech users. People care much more to what they see and the UX at the end, imagine handling all the use cases of a credit card register form before some payment without all the fancy schmancy we have today.
A lot of web apps fetch data from the server prior to rendering; and the data that's fetched is often necessary for rendering. I suppose for things like a "control panel" that doesn't have much data on it, HTML Web Components might work fine; but a lot of use cases need non-stale server-supplied user data. I guess one other use case is caching stale data in local storage, and rendering that -- but even that requires JS.
React has `props.children`, Web Components have `this.innerHTML`. But also, anything inside the custom tag you can query using regular DOM querying. Here's an example I just created: https://jsfiddle.net/qc35an1s/2/
I actually have zero Web Component experience so I'm not sure if I'm following best practices there, but I was able to get that working pretty quick
>Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends
True
>which feels like a massive step backwards and completely the wrong choice for building a web app.
Why?
I mean, I'd agree if by 'web-app' you mean something like google-sheets.
But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top"
> But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top"
We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top". Yes your blog probably doesn't need a full framework, nor does your news site (which is just a blog++) or your marketing web page. But so many other things really do or things break down quickly. Also what your web site needs today might not cover what it needs tomorrow. I've seen a number of "web admin"/backend control panels (customer-facing for config) start simple then grow until they start to collapse under their own weight with just added jQuery as needed. Sure, at the start, htmlx/jQuery might cover all you need but soon you are building custom UI to represent business logic/ideas and managing with that gets very unwieldy. The people that say "all you need is the built-in HTML elements" are living in a fantasy land, try using the default date/time picker and get back to me.
I'm sure there are things I'd agree with the anti-react crowd on (places you don't need a framework) but all their examples are incredibly contrived and feel like the "TODO app examples" you often see for frameworks or learning a language. They don't even scratch the surface of what's needed for complicated apps, they are great to show off the simple things but it seems like the anti-react/anti-framework crowd thinks those simple examples are all you need and that's just silly.
At the end of the day I'll admit I reach for a framework earlier than I absolutely need it and that's because I've built 10's and 10's of sites (web apps) from the ground up and eventually you either use a framework or you end up creating a shitty version of one. So yeah, day 1 I might not need Vue but day 100 I'm sure glad I have all of Vue to build on.
I think the future of webdev is a framework-like system that can be added gradually to basic HTML, rather than one which requires that you totally replace it with JSX, etc. from the start. Webcomponents are a huge step towards a time when we can add state managers and things like that without bringing in a monolith all at once.
Some projects require 1% of a framework, others require 98%, but the majority are in a range between 25% and 75% which currently need you to re-architect for a total perfusion of React or a competitor.
And I'll happily use such a system once it exists but Vue/React/Angular exist today and have allowed a level of productivity, DX, and UX unheard of with what browsers provide by default. If browsers want to compete then be by guest but FF seems to busy doing next to nothing, Chrome is eating everyone's lunch and giving the middle finger to standards, and Safari is derided for not being Chrome and slow to implement some things (while being fast on others).
I think it's more likely to see some kind of WASM-based replacement take off rather than browsers get their act together. That's not to say browsers aren't improving, they absolutely are, but when it comes to competing with the existing frameworks the only answer so far has been Web Components and it was very lackluster IMHO.
Svelte is pretty close to this (at the expense of a build step). It gives you (in my opinion) better ergonomics that React, has no runtime and outputs sites that don’t require JS unless they do.
Sveltekit (its official fullstack framework) even encourages building apps that fall back gracefully for users with JS disabled.
Of course, none of that is to say that you can’t build bloated, badly performing apps in Svelte. Just that you *can* have the best of both worlds, even for simple/static sites.
As a counterpoint: I consult for government agencies that have all separately decided to standardise on Angular.
They mostly publish static content: alerts, updates, reports, etc…
At most they might have a single page somewhere for submitting a payment or a simple form.
But because of this JS framework by default policy all their apps end up with extra complexity, extra build steps, and an awful amount of dependency maintenance.
Most of their sites could have been static HTML files on disk.
That's understandable. Though I actually can see some logic in it. It's got to be way easier to hire Angular developers than it is to hire someone who wants to eek out the maximum performance with this lightest-weight approach (and do it in a maintainable/understandable way).
I'll never say Vue/React/Angular are "light" and I'll fully admit we give up some performance for DX (and UX) but it's a tradeoff I think is worth it (I understand if you don't agree).
In the same vein, I know cross-platform frameworks like Ionic/Quasar are nowhere near as good as native apps. That said the skill set you need (and dedication to actually embracing the platform idiosyncrasies) to make _good_ native apps is not cheap or easy. Cross-platform apps might not fit in as well and might be heavier but they allow fewer people to do more with less. Heck, I have a side-business that relies _heavily_ on apps and it would not exist if I couldn't write them in HTML/JS/CSS as much as that makes some people's stomachs turn.
> It's got to be way easier to hire Angular developers than it is to hire someone who wants to eek out the maximum performance with this lightest-weight approach.
I disagree, at least around here. Frontend developers with react/angular experience are a hot commodity and really hard to hire, yet just about anyone from any tech tech can knock out html and some minimal css.
But also, you can mix things togheter.
You can just use react based app 'embeded' into mpa for when you need that heavy lifting, and the same keep the content part of your app simple.
"But why would i do that, if i'd already use react for some parts, why not every where".
Becuase then it leads to abominations like reddit or facebook, where websites that are basically glorified text
forums will use gigabytes of memory, have terrible UX, be slow and will crash your browser if you leave them open for too long.
Cool what Contexte did with HTMX, but personally I really dislike the amount of data packed into those HTML templates, those hx-get attributes are frighteningly long.
That file has like, 60 lines. Calling it a "wall of HTML soup" is a bit disingenuous. But if you REALLY have that much aversion to code, there is no inherent reason why you couldn't split it even more.
CSS being miles away is again, just a matter of taste. No inherent reason why you could't use Tailwind for example.
To have even more HTML soup? No thanks. Luckily I live in a world of better DX. With styled-components my CSS primitives are typechecked. Hell even with SCSS and CSS modules I have more sane and IDE supported experience.
But this styling lives in your component file, doesn't it?
So it makes just as much "wall of [code] soup there as it makes it here".
Tailwind was just an example pointing out you don't need a separate your code across entirely different directories, not recommendation of specific technology
But it is though?
I'm not talking about everything facebook provides, but main content page is just a list of posts with with discussion underneath them. Sure, you can embed some media into the it, but still. There is nothing inherently different about structure of facebook post compared to a post on a forum.
And yet, despite everything facebook is doing, the most (and only) reliable way to load new comments under the post is to force refresh entire site.
Except it's not easy anymore, because facebook tries to be SPA.
So we gave up simple and reliable solutions in favour of over engineering that doesn't even work. And all that for no good reason, other then being trendy and having an SPA
At some point quantitative change achieves a qualitative effect. I would think Facebook or LinkedIn or Twitter have all reached that qualitative effect to change from being just a discussion forum.
However qualitatively the social functions of these apps present an extra functionality missing from traditional discussion forums. Being able to track users, notifications of the users updates, blocking certain users from being in the message - which is a traditional messaging function not found in discussion forums. Suggestions of people or subjects to follow given on what you have done in the past, weighted based on various algorithms to determine how recent your past activity was and what your current interests seem to be.. I'm sure you could think of a load of other functions that are not traditional discussion forum functionalities.
I don't know if you are doing that intentionally, but you are completely ignoring the context of the argument, which is advocating of mixing and matching statically generated content and using component based spas only where it's needed.
In the parent coment alone I emphasized that I acknowledge that Facebook as a whole provides more then just a forum, but it's core content inherently doesn't differ much from being one.
Moreover, functionality like notifications or suggestions are inherently server generated, as such they don't require content itself to be served in specific way.
- the social graph underlying every post and content producer (one of the reasons FB introduced graphql)
- the recommendation and advertising algos that are interdependent on the content feed
- the realtime “fire hose” nature of the feed integrating a huge number of disparate data sources
Again I don’t like FB the app and I’m not on it. But even its core product is vastly more complex than a forum.
FWIW I’ve developed social networks and forums professionally; social networks are inherently more interactive. My first real exposure to front end dev was when I worked on a social network. If I had to build the same webapp today there is zero consideration of writing it as a backend rendered application or restricting to only progressive enhancement. It would only put off the inevitable migration to real FE tech.
It is a fancy HTML templating library first and foremost and you should use it when you need HTML templates, which means you that can use as little or as much of it as you want.
I’ve built mostly static pages with React loaded and embedded into parts of the page. The webpages would function without JavaScript enabled.
How does the React part of your page work without JavaScript enabled? Are you using a static site generator (or another server side rendering tool) like Next.js?
> The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top".
I would say it's precisely the opposite.
Say 97% of work done by web pages and web apps in practice boils down to "render some data available on the server as HTML, then show it to the user". For these cases, putting what amounts to an entire GUI framework written in Javascript on the frontend is massive, bandwidth-sucking, performance-killing overkill.
There are absolutely exceptions. Google Sheets exists. But your project is probably not Google Sheets.
What is this “entire GUI framework written in JavaScript”? React isn’t a GUI framework, even Angular despite being quite batteries included is not that.
I swear the people writing these comments aren’t working in web development?
IME there’s a crazy amount of strawmanning that goes on with these “anti-react” technologies/cults. Yes of course your html and css static site doesn’t need react. But most of us who are actual software devs/engineers aren’t working on static websites like that!
I think this is a little gatekeep-y. Building static sites is real engineering. When you're building a site that scales in content (for e.g. one that contains thousands of pages that are updated regularly) you need to really know what you're doing. A CMS can help you manage your content, but you need to decide how to build your pages from it. There are things in the React space that can handle a lot of the complexity (for e.g. Next.js on Vercel with ISR), but you need an engineer to make the right trade offs.
Basically, HTML Web Components are classes extending HTMLElement registered manually via JavaScript / DOM API.
class superSlider extends HTMLElement {
connectedCallback() {
let targetEl = document.querySelector(this.getAttribute('target'));
let unit = this.getAttribute('unit');
let slider = this.querySelector('input[type="range"]');
}
}
customElements.define("super-slider",superSlider);
My personal problem with these "native" components is, that the shadow DOM is pretty restricted compared to component frameworks like React, Vue or Svelte.
My take is: As explained in the article, user-avatar does absolutely nothing. If anything, it could only enhance the existing markup (with behavior), but never replace it. It’s… semantic markup, if you will.
Yeah I was thinking about what it could do, but I don't get it. The point of custom elements is to define a class in JavaScript that does something. Custom elements are just a part of web components tho, and you can use shadow DOM, more JS, and templating with slots.
I guess user-avatar could define a template that includes styles and slots to turn the image into a round image and maybe add some caption and link to it. But that would still require JS to print the template.content.
I wish this weren't so, but it perfectly describes my experience with every single web technology. JavaScript, DOM, Canvas, Web Audio... they all remind me of this quote:
"Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis
I am of course, slightly exaggerating, but... by way of analogy:
I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why!
Meanwhile, a browser is 10-20 MILLION lines of code, and ... I originally ranted for several pages, but I'll just go and say that I never want to see the string "undefinedundefinedundefined" show up during runtime (and that this is 100% realistic and achievable in a dynamic language, without type annotations).
At least PDF libray you can update to include new functionality under a new version, but you can't just out of blue change the JS behaviour of undefined being rendered. It would definitely break something without warning.
Exactly! You put that very elegantly. (I call that proposed flag "use sane")
I always thought JS needed static types to fix the insanity until I tried Python and realized that almost all the insane BS I get in JS are all runtime errors in Python.
There's a very good case to be made for reducing runtime errors, but it's a hell of a good start to at least have them!
Rather than what we have now, which is "assume the programmer is a beginner, who also never makes mistakes", and "given nonsensical commands, just do nonsense, and propagate garbage data throughout the entire program".
> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app.
Building an entire web app out of Javascript has been an incredibly dumb idea, and some ecosystems are trying to return us to the roots: most of the heavy lifting is done server-side, and JS is a sprinkle of interactivity on top, like the golden age of jQuery.
Before you bite my head off telling me about apps that necessarily have to be SPAs, how many apps are people using React for when a modern server-side framework would do (i.e. Phoenix Live View)?
I wouldn't put Phoenix in the "would do" pile. That looks like a decent learning curve. PHP Laravel and Ruby on Rails are in the "would do" pile. This doesn't take away from your point though!
> Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery
Have you used htmx? Since it doesn't solve the same problem jquery did (UX for client side JS), the accusation is misplaced. htmx is (primarily) a way of avoiding writing JS by extending the server-side rendered html paradigm to partial pages instead of full page re-loads.
I think he knows that. The comparison with jQuery comes from the fact it is a DOM replacement logic too.
Even if the syntax is way better, in the end, it’s still a way of working that scales badly, compared to components which embed their own logic.
htmx shines to add dynamic behaviour on some pages, but is not appropriate to replace a medium-sized SPA in my opinion.
I think the confusion caused by this article is because the author presents a false "pick your side" choice: "React-style" custom elements with props, or, custom elements with light DOM. Unfortunately, discussion of web frameworks often seems to occur with tribalistic attitudes, which can obscure a clear understanding of appropriate choices for a given application.
The author's dichotomy could be seen as unnecessarily divisive by creating an artificial distinction and suggesting only one must be chosen. It also seems not to reflect an underlying technical reality nor suggested best practice. In reality, both React and custom elements can enable either style, and the choice should depend on what's most appropriate for the situation.
Not only can both frameworks do both approaches, they can do them at the same time! You can have a wrapper style elements that also takes props. A window-box that provides diverse content with an OS-style draggable-window capability is a good example.
As to the author's suggestion that HTML components (which appear nevertheless to still require JavaScript) are better, and prop-style is to worse, in general, I'll have to think more about it. I may have underappreciated the light DOM style in my creation of Hyphen: https://github.com/00000o1/-
Instead of focusing on slots for templating (which you can still use if you want) in Hyphen, I made templates easy with JS template literals, because it's not always just elements you may want to insert, but rather class names, attributes, and so on. Check it out if you are interested in new approaches to custom elements! It's only 3K and less than 300 lines, aiming to provide maximal utility with minimal code.
The `details-utils` component enhances the behavior of the built-in HTML `detail` component. If for any reason you have JavaScript disabled, then using a web component like this would be just fine because the `detail` component would continue to behave like it always does. If you have JS enabled (or it's finished downloading) then you have an enhanced version of it that has features like collapsing when you click outside of it, etc. That's the part that's reusable when used like this.
That web component from the creator of 11ty is what made the point made in the article click for me. When I first started looking at web components I was like, "this still requires JavaScript and doesn't work without it," and that was the same point Rich Harris made in this article: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
If you're looking for a middle-ground between React and Web Components, check out Joystick [1]. I designed it to take a React v1 approach to ergonomics but you write your components with vanilla HTML, CSS, and JavaScript (no attribute hacks or new syntax to learn—if it's on MDN, it will work in Joystick).
I don't like web components because of the flash of undefined elements[1]. Hiding it with css tricks is clunky and ugly too. The sad thing is that web components seem like a great idea otherwise.
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.
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.
Yeah agreed, that is why I said "if you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice"
Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now.
I still prefer direct and custom with less dependencies but Lit is somewhat trying to communicate web standards while other current frameworks really want lock-in to the platform rather than caring about making sure devs understand the standards.
They need dozens of new web standards to fix their self-inflicted wounds and to work with the browser in a way that everyone else is already working
> Additionally, web standards like Web Components/templates/custom elements will always be faster at browser level.
[citation needed]
The 2010-era design choices that web components enshrined hinder a lot of optimizations that modern frameworks are doing.
There are reasons why almost none of the modern frameworks use web components as the foundation. Including those who originally used their design or whose authors were bullish on them (Vue, Svelte, Solid).
I mostly agree but Web Components is a web standards as is templates/custom elements now.
The others like React/Vue/Svelte etc are all going more for platform/framework lock-in over making sure people are doing augmentation of standards.
Those frameworks have incentive to lock you in while standards are lock-in at a lower level.
Other standards I like playing with direct like html/css/canvas/WebGL/storage/svg/video/audio/geo/etc and ones that are newer are WebRTC/WebGL/WebGPU/WebAssembly etc. All of these are and will be abstracted by some frameworks and people will know less about them and more about the platforms on top if they aren't regularly going direct. I think people that know about the standards more low level make for better framework developers an developers that use frameworks even.
I like platforms that make web standards the core aim not the platform lock in.
Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now.
Lit is somewhat Angular like since Google make both.
> I mostly agree but Web Components is a web standards as is templates/custom elements now.
People keep repeating this mantra as if this alone makes web components good
> Those frameworks have incentive to lock you in while standards are lock-in at a lower level.
Or: these frameworks have the incentive to solve problems that web standards have been unwilling to solve for decades, and won't solve for another few decades.
> I like platforms that make web standards the core aim not the platform lock in.
Then you should use literally anything else but web components. Because web components don't make standards their core, are broken on multiple levels, and will require 20 more new standards to fix things that are not broken in literally anything else: https://threadreaderapp.com/thread/1717580502280867847
> Lit is just a lighter weight version of that and closer to web standards
The only thing that is standard in Lit is that it compiles to web components by default.
I mostly agree but Web Components is a web standards as is templates/custom elements now. Web Components are a standard.
You did ask. heh.
As I mentioned, I prefer direct standards or at least frameworks that make standards a main part of the design, even if only on output.
Standards are slower to finalize, frameworks front ran them via abstractions that may have been needed for a while --like Flash with interactivity before HTML5/canvas/svg/WebGL/etc and I was huge into Flash and plugins, those days are over though. Standards will be around longer and more maintainable on standard schedules not just feature/dependency pump frameworks of today that have verbloat.
Plugins and now frameworks innovate and front run, and influence standards, then standards win the long game every single time. Like why use virtual DOM when shadowdom is now available, unnecessary abstraction now that will always lose to native dom abstractions like shadowdom.
Right now with web standards where they are at, Javascript how far it has come, and the coming WebAssembly + WebGPU platforms now being ready or close to ready, the current frameworks are about to be lapped. It is just the way things go and the typical waves in innovation to standards and repeat.
About Lit, I mentioned it as I said in another comment "if you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice"
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 '<img />' 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?
It depends on the architecture of your app. If you're using React to return HTML from the server, then indeed wrapping an <img /> in a React component means you're augmenting an existing element. But if you're rendering the entire thing on the client side, then the <img /> is ultimately inseparable from the React component.
In some cases, react seems to go out of its way to make the built-in functionality harder to access. For instance, if you assign "onchange" to an <input>, react will give you the "input" event, not the "change" event. (Actually, it gives a neither. It gives you a "synthetic" event that's closer to input than change) What if you know what you're doing, and you actually wanted "change"? You have to use an element ref an attach the handler using an effect.
Doesn't solve this problem. "change" fires at different times from "input". `nativeEvent` is useful if you want the real event data object for the event that actually fired. In this case, it's a whole other event.
When I read that I thought about the reverse: putting React inside other HTML. In my experience React works wonderfully when you’re using it from top to bottom (replacing your entire page structure) but it can be difficult to fit into an existing structure when you’re trying to do things like server side rendering.
I could be wrong, but it seems like the article is saying that the core difference would be this:
React (rendering in the browser, not server side):
Page Load -> Component Load
vs.
Web Component
Page Load -> Default Render -> Component Load
So if someone has JS disabled they would still see SOMETHING for the web component vs. nothing in React. And with JS they could get to some further render state.
You’re right for the large majority of cases, but there are exceptions. These days some use canvas or WebGL, in the past some have used Flash or Java Applets/Swing.
A popular app that some web developers here may use day-to-day recently is Figma, which uses WebGL for rendering.
The data would come as part of the server response in most cases.
A variation could be the rendering of a partial UI whilst you then fetch data client-side. Even in this case the web component has the advantage as no JS is needed to render the initial UI.
As long as you're not shoving everything into the shadow dom, then you've got a fallback HTML element that can render before JS is read (and even if the JS is completely broken)...
<special-image>
<img src="/example.png" />
</special-image>
This image will render before the JS is executed, so you've got no blockers and a perfectly fine fallback, then with the web component you enhance your image with whatever JS you want.
I believe Flutter doesn't (or didn't use to) - it rendered to canvas, and then in parallel built a hidden DOM structure so an accessibility tree could be derived and made available to screen readers.
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:
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 <tag> should be <tag tag="my_tag"> to make it inline. Or <$my_tag> 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 <head> or <script> 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 <my_tag data="2">.
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.
There are so many downsides of choosing web components you really need a very rare usecase to justify them. They are an artefact of a time we're all glad to be done with, they force you into OOP so you're doing inheritance acrobatics, add TS and now you're feeding two hierarchies of inheritance that don't quite match and bloat to a 80% of your codebase, making it unreadable, prone to hacks and bugs, impossible to maintain etc. The point of web components was to make components more shareable between frameworks, and code more reusable, but now code written in any of the major FE frameworks is more reusable (a component looks pretty much the same in React, Vue, Svelte, but not with web components).
246 comments
[ 3.2 ms ] story [ 255 ms ] threadhttps://meyerweb.com/eric/thoughts/2023/11/01/blinded-by-the... - "So there you have it: a few thousand words on my journey through coming to understand and work with these fully-Light-DOM web components, otherwise known as custom elements. Now all they need is a catchy name, so we can draw more people to the Light Side of the Web."
https://adactio.com/journal/20618 then suggests the catchy name.
Sure you can get re-usable components. But are you going to pull in a re-usable web component that might use say Vue underneath when you use React? It just doesn't make any sense.
The best example is a multi-select box, or a searchable select box with autocomplete (what W3 calls the combobox pattern https://www.w3.org/WAI/ARIA/apg/patterns/combobox/) which in jquery was usually via https://select2.org/
For example, on my company website there's a timezone select box with 151 options. Asking a user to scroll through 100+ options is a big ask vs typing a few characters and hitting enter. There really is no static server-side way to solve this problem (I tried hard to think of one)... without creating a multi-page Wizard for what should be a single field on a larger form.
If you're building a SaaS product there are many UI requirements that demand high-interactivity and and there's really no better mainstream solution atm than static-first sites with small "islands" of React/Vue/etc components (ideally with hydration).
People still abuse React/Vue of course and the trend is 100% moving back to "mostly static" rather than slow SPAs but IMO JS-powered components are not never going away unless browsers start offering a broad selection of built-in complex web components like comboboxes, datepickers, tooltips, etc.
You maybe don't get full control over the rendering style of it, but it's a still significantly more usable than the Angular Material autocompletes.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
It's a shame clicking on it doesn't show the options like a select box though.
> Recommended values in types text, search, url, tel, email and number, are displayed in a drop-down menu when user clicks or double-clicks on the control.
https://adrianroselli.com/2023/06/under-engineered-comboboxe...
> People still abuse React/Vue of course and the trend is 100% moving back to "mostly static" rather than slow SPAs
I'm not seeing this at all, in fact I can't remember the last React project I worked on that wasn't a full blown SPA. I don't see anyone starting or advocating for static sites with islands unless they're using a framework like Astro or something.
Do you have any example sites or codebases using this approach?
> const app = h('h1', null, 'Hello World!');
With Web Components no build step is required and you're still able to intermix HTML with JS just like JSX. See the code below this section: https://github.com/kennyfrc/cami.js#key-concepts--api
It is not completely the same, but far better than that h function madness.
Meanwhile, "use the platform":
- all form components written before form participation landed in browsers are broken
- all web components written before cross-root ARIA (not even a spec yet) are potentially broken due to shadow DOM
- ... you may continue this list at your own leisure ...
The issue is just some sort of "front end bad" feeling at this point, imo. It's like some people think web components are the answer to the popular perception of the frontend being a mess of yearly novelties. When again, you can just use react and could have done so for a decade now.
I wonder what minimal solutions to state management and routing might look like in Hyphen: https://github.com/00000o1/-
So much of the beauty & elegance of the web was how declarative everything is, as that grants such observability & malleability. Shadow dom felt such an enterprise desire, to build much higher encapsulation walls, to layer in so much certainty, and that never felt like a goal I shared.
This article shows how light dom work can compose. I want to see light dom advocacy go further. It always seemed clear to me a web component/custom element could and should just self-modify the dom inside of it, move children around, build new content. Another example in the comments talks about maybe the user avatar element adding a div with the users name... Maybe the page or framework adds the icon, and the custom element then inserts that name, or that name and some aesthetic embellishment.
I guess my one concern with light dom / html web components is it seems like there have been - in some cases - some good performance wins from shadow dom. This wouldn't change what I go for unless I was desperate, but as a dev, in my head I see how shadow dom can scope down and reduce the number of elements that have to be traversed for a css specifier. and I want that win to be available somehow to me.
Really elating to see a lighter take on custom elements / web components. Thanks for the great links Simon!
Render your react components on the server and send them over the wire as plain html. no client side javascript required — full stop.
Moving the render off the client is nice, but removing the prerender altogether is something much cooler.
Html templating
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.
Doesn't this then require the server to be written in Javascript as well?
That said, I think the author's bigger point was that augmenting, rather than replacing/abstracting away basic web elements will win out long-term. Some degree nastier-looking coupling is a worthwhile trade over more opaquely-operating render libraries. I suspect augmented web components fail more gracefully too.
Not a full stop; SSR means they could render before client-side JS.
The example is a bit too simple to make the author's point IMO. A web component that handles changes to state would be a better comparison, and make for a better argument.
Arguably they might be less optimisable than regular web frameworks, as they make it difficult to coordinate between different components on the page.
Good load order and only loading in the content and JS above the fold initially helps a ton.
JS frameworks are huge and I am still saddened that proper tree shaking and optimization got left by the way side in how the modern web has evolved. I worked with google closure in advanced modes and the closure components for a few years and the compiler was absolutely astounding (and the components designed with the compiler in mind) in code splitting, tree shaking and minimization.
You want to have the tags and content appear in the web component (not rendered by JS) which makes it easily and immediately available to crawlers.
Hydration solutions exist but are usually worse and come with surprising tradeoffs and harm composabilitiy.
I want to believe... but reality is stacked against HTML web components. I'm just going to stick to HTML and leave the HTML with dashes to others.
I can’t link you to them here without blowing my cover, but honestly I love working with web components, and being able to do it natively rather than propped up by a mound of JavaScript feels good.
It's just as native as any other framework under the sun.
Because they don't exist. "HTML web components" are just HTML, and you don't need components for them.
Web Components are useless without Javascript.
HTML web component is NOT a function.
You don't just compare those things, they work and compose differently.
I would rather combine them: A html web component renderer for React.
https://github.com/kennyfrc/cami.js
> No Build Steps, No Client-Side Router, No JSX, No Shadow DOM. We want you to build an MPA, with mainly HTML/CSS, and return HTML responses instead of JSON. Then add interactivity as needed.
> Declarative templates with lit-html. Supports event handling, attribute binding, composability, caching, and expressions.
https://github.com/codewithkyle/supercomponent/blob/master/s...
ctrl+f htmx
"For folks who have an existing server-rendered application, you can use Cami to add interactivactivity to your application, along with other MPA-oriented libraries like HTMX, Unpoly, Turbo, or TwinSpark."
You don't really make "a web component", what you make is a Custom Element, which might use a Shadow DOM, and might use an HTML template. Three things of which the most important one is the custom element.
With the core concept being that you're just making "more HTML elements", everything you can do with those, including which attributes and JS API they support, is up to you, and the way you put them on a page, the way you interact with them, the way you listen for events on them, etc. etc. is the exact same as any other HTML element. If you known how to write web pages the "old school" way, then you already know how to use custom elements. You just need to learn how to declare them.
Funny, huh.
Here is my blog post about custom HTML Elements. It covers state changes, etc.
P.S., I am looking for a Front End project, preferably writing vanilla JS. My email is on the page.
<template type=component name="user-avatar" parameters="[src,alt]"> <img src="{src}" alt="{alt}"/> </template>
This is my experience too, and this philosophy have made my web projects last a long time with minimal maintenance and dependencies.
Unless you... server-side render them. Then your definition of "render" needs to change
1. You convert the JavaScript/JSX into HTML on the server and send it down (along with multiple blobs of JSON/code to re-hydrate).
2. The browser parses all the HTML and added JSON/code.
3. The browser then re-hydrates the page via JavaScript loading all of the JSON/code and computing everything (rendering it again).
isn't this exactly what's going on under the hood with web components? if you send an html page including <user-avatar><img></user-avatar>, the browser is going to draw the <img> tag and treat the <user-avatar> tag as a no-op because it doesn't know what to do with that. then your javascript kicks in and transforms the <user-avatar> tag into whatever the javascript defines it as, at which point it will get re-rendered.
Reddit's new redesign downloads over 100 js files: https://x.com/dmitriid/status/1708772121260732494 to render a menu.
I don't think the core idea was to ever use "hundreds" of components. HTML should be able to do a majority of the work, and you sprinkle a component here or there as needed.
> <img src="https://example.com/path/to/img.jpg" alt="..." />
> </user-avatar>
I thought the standard way to do it is:
<img is="user-avatar" src="https://example.com/path/to/img.jpg" alt="..." />
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
https://github.com/ungap/custom-elements
<user-avatar>
<img slot="image" src="...">
<div slot="name">Bob Bobson</div>
</user-avatar>
Edit: I'm meaning the attributes being longer than what the tags are denoting.
[1] https://github.com/marimo-team/marimo
I also think having a `user-avatar` take a `src` prop makes way more sense than having to add an `img` tag inside it everywhere I use it. In that case what am I saving? What is reusable?
Vue/React/Angular don't seem like they are trying to "replace" HTML (re: "XHTML wanted to replace HTML4, but HTML5 wanted to augment it. HTML5 won.", in the "On The Web, Augmentation Wins in the Long Run" section), they are taking HTML/CSS/JS and building on top of them. If they all used canvas to render instead I might buy that argument but they don't. They absolutely push those technologies to their breaking point but it's nothing short of amazing in my book what you can accomplish with them compared to just HTML/CSS/JS and even "web components".
I was excited when Web Components were first announced but they are incredibly lackluster with no "Batteries included" and feel like they don't really help you build web _apps_ like the frameworks do. Every alternative to the big frameworks (looking at you htmlx) feel like minor syntaxic sugar for jQuery and friends which feels like a massive step backwards and completely the wrong choice for building a web app.
Yeah, the lack of concrete examples makes this feel a bit too much like a shower thought to me.
This was not a tutorial or an article on how to use Web Components.
I'm working on building exactly this resource alongside a series of posts on web components.
The Stackblitz example is quite good too.
I'll give it shot to build a super simple one with just vanilla JS without helper libraries like Lit or Stencil. I think I'd take the same approach as I would with React, and I think the biggest difference would be where the fetch gets executed. In React you'd expose a prop like "submitHandler", but here I would emit an event from the component (after whatever debounce amount) and expect the caller to attach an event listener to my custom event to perform the fetch.
In the last 10 years the only new web tech I’ve seen get traction outside of tech communities - so actual job postings etc - is vue.
Define _app_. React doesn't have batteries, it has composability. Web Components do too but you have to know how (it's a lot easier in React, just return (html)) but in Web Components, you can register your custom element and provide the functionality that you call "batteries". [1] So if you don't care about attributes and just want semantic composable things, just call it whatever you want to. <user-avatar></user-avatar>. Conceptually it's a web component that extends HTMLDivElement.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
The benefit boils down to progressive enhancement: because an img tag has built in behavior you simply rely on default rendering behavior and provide "augmentation" as needed via your web component.
They mention not wanting to pass though all those props:
We will ignore the last 2 since those are required anyway. How is `type="range"` not the default that you would just set, no attribute/prop needed? Then min/max/step/value all feel like things you could have defaults for and then, yes, pass them through. In forms I'm always pushing towards consistency, I don't want to make it easy to just set random attributes on the underlying element, it needs to be deliberate.I can believe I'm just missing something but Web Components just seem like extra work with very little gain.
Personally I think the main problem here is client side rendering to begin with, with a modern server side templating library you get a component based structure too and can abstract whatever HTML tags you want in your component before client side JavaScript.
Problem with React is that it is JavaScript first, you always begin with a JavaScript function, but in my opinion the web should be HTML first.
The article goes on to add a good little bit of JS to make everything work they way they want. They still need JS to accomplish what they want. If you turn off JS things will break in that example.
> Personally I think the main problem here is client side rendering to begin with
I mean unless you want to roundtrip for new HTML segments (aka Liveview or whatever Laravel has) you either need to have client-side rendering or duplicate your rendering logic (in something like both PHP and JS for the fast update without refreshing on each click). I'll never duplicate rendering logic again if I can help it and that means client-side render (potentially with SSR for the first render). It avoids so many bugs/issues.
> but in my opinion the web should be HTML first
This just feels dated to me. I fundamentally do not understand this desire. What do you gain from the web being just HTML? What does that even mean? With a CSR framework you are still rendering out HTML, I don't understand why some people care that the HTML was generated server side or client side. The web has moved on from being just documents, it's interactive and that provides a much better UX.
There will almost always be a roundtrip, either to fetch HTML segments or to ask for more JSON data, except for the rare cases you already have everything, because that is the nature of client-server paradigm.
By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever, to the browser, over Ajax or in the email. No need for buggy asynchronous SQL JOINs over HTTP and infinite state handling.
If you always start with a JavaScript function, and all that comes with that, you need a programmer to be able to create the web, but with HTML (and CSS) first you can have other categories of people do that, like designers. And combine that with a library like htmx you can then enhance that experience for interactive parts and still keep everything in the same backend template. And if it still a need for more complex interactive parts a programmer can can add that with JavaScript afterwards. That is a much better division of labour.
And it is not outdated, browser actually excel in rendering HTML documents, that is what they are designed to do, thus it will always be faster to render the HTML document as it is rather than building it on the fly.
And also the core idea of reaching for JavaScript before HTML will result in suboptimal solutions, I have seen so much unnecessary JavaScript code that could have been easily solved with a few lines of HTML. This change of perspective changes how we think and reason about a problem and therefore our solutions as well. That is why the bootstrapping of a "modern" web app has become more and more asinine.
Another problem with frameworks like React, Vue, Angular and et al have is that they have their own lifecycle and that has made the web closed and not open how it once was, closed in the sense that you can't enhance the HTML document from the outside after it been rendered, thus this leads to the assumption that the person(s) who wrote the site is also the person(s) that manages or uses it, that is a bad assumption.
What is that, exactly?
> By putting all your templates in the backend you can render them as a whole document or in parts in one go and send them wherever,
All frameworks can do that. Web Components cannot.
> If you always start with a JavaScript function, and all that comes with that, you need a programmer to be able to create the web, but with HTML (and CSS) first you can have other categories of people do that, like designers.
Web components quite literally don't work without Javascript. And they need Javascript to be able to do trivial things like form participation.
Component rendered before client side JavaScript.
> Web components quite literally don't work without Javascript.
That is why I'm not using them.
It is enough for a bazillion of online services, that without requiring a beyond insanely complex and massive web engine from Big Tech. basic HTML forms can do wonders.
Of course, you can have a full blown Big Tech web app, but don't forget to have a interop portal with noscript/basic (x)html browsers to avoid, at least for critical online services, Big Tech lock-in and unreasonable exit cost.
That said, it may be a good idea to be able to drive the display or not of <table> rules with the default styling (css or hardcoded) from the 2D semantic HTML document attributes (I should check the hardcoded style of links and lynx for <table> rules).
(I am not talking about the abomination of the "semantic" web we had a decade ago)
Of course, it is a trade-off, bells-and-whistles from rich GUIs are sexy, but the technical cost of such bells-and-whistles in a web context is grostesquely and absurdely unbalanced compared to what can be achieved with simple and consistent noscript/basic (x)html portals for any pertinent goal of a bazillions of online services.
The problem often lies with the client tantrums.
I was more talking about critical online services which have a duty of interop with Small Tech and must not force users into Big Tech engines only, that to keep the door open to alternatives of reasonable "size", and at the same time to lower significantly exit costs.
But that's smashing open doors, most are aware of those issues here on HN. The real issue is implementation: it has to happen in a regulatory framework, laws dealing with discrimination, and my lawer has been looking into other legal leverages (yeah, I have an open conflict with my administration). The regulatory framework is here, but lobby-ied heavily by Big Tech, making it ineffective and pointless.
A bit like what they have in the US with the "utilities" which then have much more regulatory duties than "non utilities". You also have anti-trust stuff: dominant corpos are much more tied to regulatory constraints, that to let alternatives to be viable (well, that does not seems to work very well in the US). In my country, anti-trust ultra-aggressive regulations did wonders in the telecom industry.
You can still have a web app with a rich GUI, an anonymous simple and stable in time public HTTP-based middleware protocol (which allows to develop Big Tech independent rich GUIs), etc, until the core functions are provided to noscript/basic (x)html browsers (if one thing must work, it is this one).
I actually have zero Web Component experience so I'm not sure if I'm following best practices there, but I was able to get that working pretty quick
True
>which feels like a massive step backwards and completely the wrong choice for building a web app.
Why?
I mean, I'd agree if by 'web-app' you mean something like google-sheets.
But I believe this whole "anti-react" movement isn't talking about such usecases, but rather against defaulting frameworks and building using them 'from the ground up', where trully all the website actually need is the "sparkling of interactivity on top"
We absolutely don't have shared language for these things and we aren't always talking about the same things. The thing is there are just vanishingly few places where you only need a "sparkling of interactivity on top". Yes your blog probably doesn't need a full framework, nor does your news site (which is just a blog++) or your marketing web page. But so many other things really do or things break down quickly. Also what your web site needs today might not cover what it needs tomorrow. I've seen a number of "web admin"/backend control panels (customer-facing for config) start simple then grow until they start to collapse under their own weight with just added jQuery as needed. Sure, at the start, htmlx/jQuery might cover all you need but soon you are building custom UI to represent business logic/ideas and managing with that gets very unwieldy. The people that say "all you need is the built-in HTML elements" are living in a fantasy land, try using the default date/time picker and get back to me.
I'm sure there are things I'd agree with the anti-react crowd on (places you don't need a framework) but all their examples are incredibly contrived and feel like the "TODO app examples" you often see for frameworks or learning a language. They don't even scratch the surface of what's needed for complicated apps, they are great to show off the simple things but it seems like the anti-react/anti-framework crowd thinks those simple examples are all you need and that's just silly.
At the end of the day I'll admit I reach for a framework earlier than I absolutely need it and that's because I've built 10's and 10's of sites (web apps) from the ground up and eventually you either use a framework or you end up creating a shitty version of one. So yeah, day 1 I might not need Vue but day 100 I'm sure glad I have all of Vue to build on.
Some projects require 1% of a framework, others require 98%, but the majority are in a range between 25% and 75% which currently need you to re-architect for a total perfusion of React or a competitor.
I think it's more likely to see some kind of WASM-based replacement take off rather than browsers get their act together. That's not to say browsers aren't improving, they absolutely are, but when it comes to competing with the existing frameworks the only answer so far has been Web Components and it was very lackluster IMHO.
Sveltekit (its official fullstack framework) even encourages building apps that fall back gracefully for users with JS disabled.
Of course, none of that is to say that you can’t build bloated, badly performing apps in Svelte. Just that you *can* have the best of both worlds, even for simple/static sites.
[1] There are very few monoliths among the frameworks these days, and apart from React and Angular [2] most aim for rather small bundle sizes
[2] Out if the blue Angular just released version 17 with all the goodies you'd expect from a framework in 2023
They mostly publish static content: alerts, updates, reports, etc…
At most they might have a single page somewhere for submitting a payment or a simple form.
But because of this JS framework by default policy all their apps end up with extra complexity, extra build steps, and an awful amount of dependency maintenance.
Most of their sites could have been static HTML files on disk.
Doesn't even make sense to me why anybody uses them.
You cant audit static sites (ones thing I don't like about having traditional linked libraries).
Why can’t you audit a static site? Seems very straight forward. We already audit static sites for accessibility (503 compliance).
Any resources you can point to? Seems like it would be a worthy effort to make other tools compliant.
Definitely something I want to learn about.
I'll never say Vue/React/Angular are "light" and I'll fully admit we give up some performance for DX (and UX) but it's a tradeoff I think is worth it (I understand if you don't agree).
In the same vein, I know cross-platform frameworks like Ionic/Quasar are nowhere near as good as native apps. That said the skill set you need (and dedication to actually embracing the platform idiosyncrasies) to make _good_ native apps is not cheap or easy. Cross-platform apps might not fit in as well and might be heavier but they allow fewer people to do more with less. Heck, I have a side-business that relies _heavily_ on apps and it would not exist if I couldn't write them in HTML/JS/CSS as much as that makes some people's stomachs turn.
I disagree, at least around here. Frontend developers with react/angular experience are a hot commodity and really hard to hire, yet just about anyone from any tech tech can knock out html and some minimal css.
But also, you can mix things togheter. You can just use react based app 'embeded' into mpa for when you need that heavy lifting, and the same keep the content part of your app simple.
"But why would i do that, if i'd already use react for some parts, why not every where".
Becuase then it leads to abominations like reddit or facebook, where websites that are basically glorified text forums will use gigabytes of memory, have terrible UX, be slow and will crash your browser if you leave them open for too long.
Stringly typed logic and CSS / JS somewhere miles away in directory structure making it very hard to reason about.
I very much prefer sticking to small, composable, encapsulated, actual components made in React or sth similar.
To have even more HTML soup? No thanks. Luckily I live in a world of better DX. With styled-components my CSS primitives are typechecked. Hell even with SCSS and CSS modules I have more sane and IDE supported experience.
And yet, despite everything facebook is doing, the most (and only) reliable way to load new comments under the post is to force refresh entire site. Except it's not easy anymore, because facebook tries to be SPA.
So we gave up simple and reliable solutions in favour of over engineering that doesn't even work. And all that for no good reason, other then being trendy and having an SPA
At some point quantitative change achieves a qualitative effect. I would think Facebook or LinkedIn or Twitter have all reached that qualitative effect to change from being just a discussion forum.
However qualitatively the social functions of these apps present an extra functionality missing from traditional discussion forums. Being able to track users, notifications of the users updates, blocking certain users from being in the message - which is a traditional messaging function not found in discussion forums. Suggestions of people or subjects to follow given on what you have done in the past, weighted based on various algorithms to determine how recent your past activity was and what your current interests seem to be.. I'm sure you could think of a load of other functions that are not traditional discussion forum functionalities.
In the parent coment alone I emphasized that I acknowledge that Facebook as a whole provides more then just a forum, but it's core content inherently doesn't differ much from being one.
Moreover, functionality like notifications or suggestions are inherently server generated, as such they don't require content itself to be served in specific way.
- the social graph underlying every post and content producer (one of the reasons FB introduced graphql)
- the recommendation and advertising algos that are interdependent on the content feed
- the realtime “fire hose” nature of the feed integrating a huge number of disparate data sources
Again I don’t like FB the app and I’m not on it. But even its core product is vastly more complex than a forum.
FWIW I’ve developed social networks and forums professionally; social networks are inherently more interactive. My first real exposure to front end dev was when I worked on a social network. If I had to build the same webapp today there is zero consideration of writing it as a backend rendered application or restricting to only progressive enhancement. It would only put off the inevitable migration to real FE tech.
What specific aspects of facebook's comment section under post make it that json response is so much better then a html one?
Building my first web application in react currently and this resonated with me on such a deep level.
It is a fancy HTML templating library first and foremost and you should use it when you need HTML templates, which means you that can use as little or as much of it as you want.
I’ve built mostly static pages with React loaded and embedded into parts of the page. The webpages would function without JavaScript enabled.
I would say it's precisely the opposite.
Say 97% of work done by web pages and web apps in practice boils down to "render some data available on the server as HTML, then show it to the user". For these cases, putting what amounts to an entire GUI framework written in Javascript on the frontend is massive, bandwidth-sucking, performance-killing overkill.
There are absolutely exceptions. Google Sheets exists. But your project is probably not Google Sheets.
I swear the people writing these comments aren’t working in web development?
IME there’s a crazy amount of strawmanning that goes on with these “anti-react” technologies/cults. Yes of course your html and css static site doesn’t need react. But most of us who are actual software devs/engineers aren’t working on static websites like that!
My personal problem with these "native" components is, that the shadow DOM is pretty restricted compared to component frameworks like React, Vue or Svelte.
The shadow DOM provides two things:
- style encapsulation (as well as `id` attributes)
- ability to use `<slot>` for templating
You should use it if you require one of the above or both.
Baloney if you ask me.
I guess user-avatar could define a template that includes styles and slots to turn the image into a round image and maybe add some caption and link to it. But that would still require JS to print the template.content.
I wish this weren't so, but it perfectly describes my experience with every single web technology. JavaScript, DOM, Canvas, Web Audio... they all remind me of this quote:
"Beware of the Turing tar-pit in which everything is possible but nothing of interest is easy." -Alan Perlis
I used a PDF library that didn't automatically flow text onto the page. You had to do it yourself. Line by line. Page by page. So, I wrote a few routines to do it. Maybe 50 lines? And I'm just like... this PDF library is twenty eight thousand lines lines long... and they couldn't have included those fifty?! Why!
Meanwhile, a browser is 10-20 MILLION lines of code, and ... I originally ranted for several pages, but I'll just go and say that I never want to see the string "undefinedundefinedundefined" show up during runtime (and that this is 100% realistic and achievable in a dynamic language, without type annotations).
No need to break existing software. "use strict" was a great idea. Let's do "use sane"!
Achievable by just removing automatic type coercion. Throw errors instead.
Would need to be feature flagged for backwards compatiability.
I always thought JS needed static types to fix the insanity until I tried Python and realized that almost all the insane BS I get in JS are all runtime errors in Python.
There's a very good case to be made for reducing runtime errors, but it's a hell of a good start to at least have them!
Rather than what we have now, which is "assume the programmer is a beginner, who also never makes mistakes", and "given nonsensical commands, just do nonsense, and propagate garbage data throughout the entire program".
Building an entire web app out of Javascript has been an incredibly dumb idea, and some ecosystems are trying to return us to the roots: most of the heavy lifting is done server-side, and JS is a sprinkle of interactivity on top, like the golden age of jQuery.
Before you bite my head off telling me about apps that necessarily have to be SPAs, how many apps are people using React for when a modern server-side framework would do (i.e. Phoenix Live View)?
Have you used htmx? Since it doesn't solve the same problem jquery did (UX for client side JS), the accusation is misplaced. htmx is (primarily) a way of avoiding writing JS by extending the server-side rendered html paradigm to partial pages instead of full page re-loads.
htmx shines to add dynamic behaviour on some pages, but is not appropriate to replace a medium-sized SPA in my opinion.
The author's dichotomy could be seen as unnecessarily divisive by creating an artificial distinction and suggesting only one must be chosen. It also seems not to reflect an underlying technical reality nor suggested best practice. In reality, both React and custom elements can enable either style, and the choice should depend on what's most appropriate for the situation.
Not only can both frameworks do both approaches, they can do them at the same time! You can have a wrapper style elements that also takes props. A window-box that provides diverse content with an OS-style draggable-window capability is a good example.
As to the author's suggestion that HTML components (which appear nevertheless to still require JavaScript) are better, and prop-style is to worse, in general, I'll have to think more about it. I may have underappreciated the light DOM style in my creation of Hyphen: https://github.com/00000o1/-
Instead of focusing on slots for templating (which you can still use if you want) in Hyphen, I made templates easy with JS template literals, because it's not always just elements you may want to insert, but rather class names, attributes, and so on. Check it out if you are interested in new approaches to custom elements! It's only 3K and less than 300 lines, aiming to provide maximal utility with minimal code.
The `details-utils` component enhances the behavior of the built-in HTML `detail` component. If for any reason you have JavaScript disabled, then using a web component like this would be just fine because the `detail` component would continue to behave like it always does. If you have JS enabled (or it's finished downloading) then you have an enhanced version of it that has features like collapsing when you click outside of it, etc. That's the part that's reusable when used like this.
That web component from the creator of 11ty is what made the point made in the article click for me. When I first started looking at web components I was like, "this still requires JavaScript and doesn't work without it," and that was the same point Rich Harris made in this article: https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
If you're looking for a middle-ground between React and Web Components, check out Joystick [1]. I designed it to take a React v1 approach to ergonomics but you write your components with vanilla HTML, CSS, and JavaScript (no attribute hacks or new syntax to learn—if it's on MDN, it will work in Joystick).
[1] https://github.com/cheatcode/joystick
[1] https://www.abeautifulsite.net/posts/flash-of-undefined-cust...
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/
https://vuejs.org/guide/extras/web-components.html
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 understand that argument, but Lit isn't a web standard, and it's an esoteric choice compared to Vue, which works great with custom elements.
Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now.
I still prefer direct and custom with less dependencies but Lit is somewhat trying to communicate web standards while other current frameworks really want lock-in to the platform rather than caring about making sure devs understand the standards.
That's what you get if you chose literally anything but web components. Because web components are really bad at using and playing nice with web standards: https://threadreaderapp.com/thread/1717580502280867847
They need dozens of new web standards to fix their self-inflicted wounds and to work with the browser in a way that everyone else is already working
> Additionally, web standards like Web Components/templates/custom elements will always be faster at browser level.
[citation needed]
The 2010-era design choices that web components enshrined hinder a lot of optimizations that modern frameworks are doing.
There are reasons why almost none of the modern frameworks use web components as the foundation. Including those who originally used their design or whose authors were bullish on them (Vue, Svelte, Solid).
IIRC even Angular beats Lit in benchmarks now.
The others like React/Vue/Svelte etc are all going more for platform/framework lock-in over making sure people are doing augmentation of standards.
Those frameworks have incentive to lock you in while standards are lock-in at a lower level.
Other standards I like playing with direct like html/css/canvas/WebGL/storage/svg/video/audio/geo/etc and ones that are newer are WebRTC/WebGL/WebGPU/WebAssembly etc. All of these are and will be abstracted by some frameworks and people will know less about them and more about the platforms on top if they aren't regularly going direct. I think people that know about the standards more low level make for better framework developers an developers that use frameworks even.
I like platforms that make web standards the core aim not the platform lock in.
Lit is just a lighter weight version of that and closer to web standards without having it bolted on to a larger, almost monolithic framework now.
Lit is somewhat Angular like since Google make both.
People keep repeating this mantra as if this alone makes web components good
> Those frameworks have incentive to lock you in while standards are lock-in at a lower level.
Or: these frameworks have the incentive to solve problems that web standards have been unwilling to solve for decades, and won't solve for another few decades.
> I like platforms that make web standards the core aim not the platform lock in.
Then you should use literally anything else but web components. Because web components don't make standards their core, are broken on multiple levels, and will require 20 more new standards to fix things that are not broken in literally anything else: https://threadreaderapp.com/thread/1717580502280867847
> Lit is just a lighter weight version of that and closer to web standards
The only thing that is standard in Lit is that it compiles to web components by default.
You did ask. heh.
As I mentioned, I prefer direct standards or at least frameworks that make standards a main part of the design, even if only on output.
Standards are slower to finalize, frameworks front ran them via abstractions that may have been needed for a while --like Flash with interactivity before HTML5/canvas/svg/WebGL/etc and I was huge into Flash and plugins, those days are over though. Standards will be around longer and more maintainable on standard schedules not just feature/dependency pump frameworks of today that have verbloat.
Plugins and now frameworks innovate and front run, and influence standards, then standards win the long game every single time. Like why use virtual DOM when shadowdom is now available, unnecessary abstraction now that will always lose to native dom abstractions like shadowdom.
Right now with web standards where they are at, Javascript how far it has come, and the coming WebAssembly + WebGPU platforms now being ready or close to ready, the current frameworks are about to be lapped. It is just the way things go and the typical waves in innovation to standards and repeat.
About Lit, I mentioned it as I said in another comment "if you like the component style of other frameworks but want to use Web Components, Google Lit is quite nice"
We can agree to disagree on the rest.
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?
[0]: https://react.dev/reference/react-dom/components/common#reac...
React (rendering in the browser, not server side): Page Load -> Component Load
vs.
Web Component Page Load -> Default Render -> Component Load
So if someone has JS disabled they would still see SOMETHING for the web component vs. nothing in React. And with JS they could get to some further render state.
The point is that the flavor "HTML Web Component" does not rely on JS to start rendering, unlike React.
A popular app that some web developers here may use day-to-day recently is Figma, which uses WebGL for rendering.
A variation could be the rendering of a partial UI whilst you then fetch data client-side. Even in this case the web component has the advantage as no JS is needed to render the initial UI.
<special-image>
</special-image>This image will render before the JS is executed, so you've got no blockers and a perfectly fine fallback, then with the web component you enhance your image with whatever JS you want.
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 <tag> should be <tag tag="my_tag"> to make it inline. Or <$my_tag> 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 <head> or <script> 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 <my_tag data="2">.
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.