I tried to understand the referenced article "Web Components Are Not the Future" - but found that there weren't many convincing arguments.
The current state of Front-end frameworks is an absolute mess. Speaking for myself, I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al). Magic in frameworks is often a hack, unlike magic in libraries. The first library I used was Prototype. It felt like magic, and it truly was. And so was jQuery, and Backbone. I never had to guess what "useState" does behind the scenes.
There are many things which don't carry over into Web Components from current JS frameworks. But if you start from Web Components (ignoring everything you know about frameworks), it suddenly becomes intuitive. And it brings in abilities which are missing otherwise, such as isolation via Shadow DOM. It grows on you.
In my view the only thing we should retain from the React era is JSX (for many reasons, true type-safety, autocomplete etc). I wrote a library last week for using Web Components with JSX. No magic other than JSX. https://webjsx.org
> I don't want to learn a complex framework. I don't want to learn magic that I don't understand without reading the documentation (useState, createSignal et al).
I can't really parse this sentence. It seems to have a lot of ideas in it. Do you want to learn a framework at all, or have one that is so magical that it feels like it doesn't need to be learned? Do you want to read documentation or not? Do you think the problem with React is that its primitives are unsuited to the work you do in it? Or to the work anybody needs to do?
I've spent most of my professional career in Vue, so I don't have a great perspective on the React ecosystem. But Vue feels like it must be included in your "complex framework" statement. I've definitely felt some pain from overuse of the framework, or poor understanding of various features, libraries, etc. The ecosystem around full-on SPAs is indeed complex. I'm just not sure what other systems would let me personally, and us broadly, manage a complex stateful client-side app.
(This is entirely separate to overuse of SPAs for things that shouldn't be SPAs.)
I'll try to give an example of "bad magic".
Did you know React renders twice in developer mode to try to expose bugs with side effects?
If this doesn't raise an eyebrow, I don't know what will.
I think the point is that frameworks ' magic isn't 100% there yet. You eventually HAVE to dive deep and understand things about the implementation to understand how to use it.
I think he was pretty clear that the "magic" in frameworks is not something you can easily understand, therefore have to guess how it really works. He doesn't like that.
You do not need to know how `useState` works to understand how to use it to write a React application, it is fairly intuitive to understand how to apply the pattern.
If I look at your library, it seems to me like it requires a much more complex mental model to begin to use.
Of course, it is better in theory for a developer to thoroughly understand the details of their framework, but empirically, React has been very successful in allowing people to build relatively sophisticated applications while understanding very little of the underlying model.
"You do not need to know how `useState` works"
I feel like you eventually do. The issue with React, at least in my experience, is that it's a type of abstraction that seems ill-suited for how the web works under the hood, so it's incredibly leaky. Everything seems to make sense initially, and you get along just fine, but then you run into an edge case, and there's an official workaround for the edge case, but then you run into edge cases for the workaround for the edge case, and suddenly, that's your whole life.
Before you know it, you really do have to know how things actually work under the hood.
Seems like that happens with every frameworks I've ever used since 2000 (in Perl, PHP, Ruby, JS, etc). Every framework makes the easy things slightly easier, the boring stuff is included and you get to focus on the fun/hard part - and I think then, naturally, you bump into the edge. But! You get to that point faster. And then you have to know the guts to solve the issue the "framework" way or do some lower-level shit-hack.
I feel like it's just a natural law of any general purpose framework.
It made the first 80% of the job easy. Now you just have to finish the other 80%.
This hasn't been my experience at all. The implementation details even leak into this crazy thing called "the rules of hooks". It looks like a function but it's actually this new thing called a hook. Which state will you get? That depends on whether the reconciler considers this invocation to be a mount or update. Getting the wrong one? Try restructuring your elements or adding or removing a "key" attribute.
People tolerate this because they learned it but I don't think there is anything essentially simple about it.
> If I look at your library, it seems to me like it requires a much more complex mental model to begin to use.
How so?
It has two functions:
(1) createElement(jsx): Allows you to use JSX to write HTML markup. Returns Virtual Nodes.
(2) applyDiff(parent, vNodes): Merges Virtual Nodes created with JSX into the real DOM efficiently.
This is all you need to know. I can keep it simple because I am not doing much in the library. I felt that if I stayed close to the standards, I wouldn't need to do much.
Maybe you have the luxury of users who want applications that have all the reactivity of a DMV form, but in my apps at some point I'll need the very simple priciple of "do something complex when this value changes" and reimplement useState/useEffect in an ad-hoc manner anyways.
I'm more of a backend/embedded developer than a web developer and I still honestly don't get how people find useState/useEffect as intimidating as your comment makes them out to be.
You don't need to understand how useState works if you're writing a page with a button that increments a number when pressed, from a beginner's tutorial.
As soon as you work on any remotely complex codebase, you will run into problems that require a decent mental model of the underlying "magic" to properly understand and solve. "Building sophisticated applications while understanding very little of the underlying model" is how you end up with gigantic piles of unmaintainable spaghetti code full of awful hacks, which seems to be the standard for React applications.
Is this less true of Web Components?
I've worked with a lot of different tech stacks over my career and every single one of them has required understanding the internals once you start using them seriously. I haven't found React to be substantially worse for that than any other tech stack I've used.
With webcomponents you are pretty close to the “metal”. If you know how to write good vanilla JavaScript, you can take most of that knowledge into webcomponents. You only need to learn the custom components lifecycle, and shadowDOM, which is knowledge about web-standards. With other frameworks you need to learn template syntaxing, how state propagates, how the compiler works, etc etc. Lot of that knowledge might be obsolete in 10 years.
Which isn’t to say it can’t be worth it. Learning multiple frameworks and libraries is also very helpful to skill up because you are learning about different concepts and implementations.
Another advantage of web components is the syntax is similar enough to Java (especially with JavaDocs) switching between coding a Java spring backend and a Web component based front end is doesn’t need as much of a mental context switch.
One aspect of this is how you think about UI. The underlying pattern of jQuery is fully side-effects -- you select an element and make some changes to it. Frameworks like React and Vue.js allows to create UI components whose states are completely determined by data, i.e. what the UI looks like is the value of a pure function, mathematically speaking. It also updates the UI with minimum DOM changes when the data changes. (Although you don't have to make them pure, and arguably you can achieve the same thing with jQuery.) Depending on where you are, it makes UI widgets much more readable and maintainable. These frameworks are innovative in terms of state management compared to "old approaches" (of course, with additional benefits like reusability etc)
Bear in mind that today's websites and web based desktop applications are much, much more complicated than two decades ago, and has a much higher requirement for scalability and maintainability. If you just want to create simple UI, indeed they may not be your best choice.
I'm building my most recent project with web components + htmx, and it's mind-blowing how much better all of this feels to me than the typical React/Angular stack. I think there's a place for React and Angular and technologies like them, but 90% of the projects that currently use them would be better off with a much simpler stack.
> The current state of Front-end frameworks is an absolute mess. Speaking for myself, I don't want to learn a complex framework.
It's really not that hard. I was able to pick up Angular to a level where I could create complex sites with it, or submit acceptable PRs that involved in, in week or so.
Granted, I am an experienced developer (C# since beta, HTML/JS/CSS from the start) but it seemed to just make sense quickly.
So when I was asked by a company to replace their aging, complex portal to manage critical infrastructure, I chose Angular for the front end.
That was smooth sailing. It was stable, performant, looked good and everyone was happy.
People often avoid it because it has a "steep learning curve" but that mainly seems to come from developers who came into the industry knowing only JavaScript and maybe a little React. If you are more experienced, you can pick it up right away.
And it helps, a lot, to use such frameworks on large complex sites. For various reasons.
It's a libraries vs frameworks thing. Libraries are relatively safer.
Frameworks in C# are slightly better (compared to those on JS), because there are blessed Frameworks and most people are using them. In the JS world, you can see very popular frameworks (with millions of downloads) get abandoned. Not saying that all is well in the .Net world; desktop frameworks are an example. But overall it's a bit different because one company more or less controls it.
> In my view the only thing we should retain from the React era is JSX
How do you deal with the non-existing difference between attributes and properties in JSX? Is every attribute a property and vice versa? Do properties reflect back as attributes?
jsx is just a syntax to construct elements with attributes. You can still add properties like you do in a web component. In React you mostly never deal with instances (and properties) but that doesn't mean other ways to model components utilizing jsx cannot.
Jsx uses properties, not attributes, while pretending that it uses attributes. Html attributes are strings, whereas jsx allows you to pass different data types to child components. Thus, properties. Which is also why is uses camel-cased names, or insists on className. Because these are the names of HTMLElement's properties.
that's React's implementation, we are talking what it would be if not React. IMO the semantic is similar to attribute, example:
let element = <my-thing my-attribute={value} />
element.property = prop
Well, there is a project to convert react components to native ones[1]... this way you can write react and use it everywhere. I think this is the way to go, similar to svelte's approach. Write what you want but compile it to native standards.
Yeah. I know React quite well, there are legitimate use cases where it shines, but...
What we've lost is the ability to say "let's make a website today" and just start making UI without build tools or crazy install trees or massive libraries that need maintenance and security updates, and drop it on a server somewhere.
I keep thinking I can have that back... ES6 imports are fully supported now, modern CSS is amazing, all we really need is an SSR/a11y-friendly way to do some kind of nestable HTML macro/component, and we can party like it's 2007 (but with grid, and import statements, and all the other new shiny objects).
As I'm thinking about this, the main thing that is left before I could imagine a build-free website/webapp is TypeScript support in the browser. Even just esbuild-style stripping of types would be enough, but I can't imagine bringing myself to write even a small amount of JavaScript without types any more.
Even without that, a tiny system that just depends on tsc should be within reach at this point.
I wouldn’t personally make these tradeoffs but for the sake of argument if you're willing to write substantially more type info into JSDocs (AI tooling may alleviate this nowadays) you can retain most of the coverage and assurances without using anything Typescript adds to the syntax superset while still using it for type checking during development. Even without the type-heavy JSDocs you might be able to alter your coding style to lean into easing and increasing inference (more classes instead of types or interfaces) and get pretty far.
Honestly though, I just never really run into use cases where I need to "make a page in a day" and where modern tooling gets in the way. I'm comfortable with create-react-app, NextJS, Gatsby, and a couple other things, I can definitely put a new static asset project from one of those on a VPS by shuffling files over scp in the timespan it takes to make a pot of coffee, and I would strongly prefer having those tools than trying to be "pure" for hand-wavy reasons and unproven benefit.
In my admittedly little experience with shadow DOM, it doesn't isolate as much as it claims. CSS variables pierce the boundary, so if your styles are built around that, you can still run into trouble.
I just haven't seen any benefit whatsoever once you have CSS modules. And CSS layers help too.
ShadowDOM, and by extension web components are great for providing an extended set of HTML ‘native’ components. Let’s say your company has multiple frontend SPAs with different technologies (angular, react, svelte,…) they could all use the same set of company custom components, like a custom datepicker, or fancy selectbox.
> I never had to guess what "useState" does behind the scenes.
It's weird to me that React hooks are always dragged out in these arguments as some kind of bogeyman. If you understand the idea of a virtual DOM and a render loop, then it is only a tiny step from there to understand hooks. And you can understand all of these concepts in about 15 minutes: https://www.youtube.com/watch?v=1VVfMVQabx0
I just don't get all the hand wringing regarding frontend frameworks. I've been using React since 2014 and in 10 years, there has been exactly one big change to the framework: hooks. When they came out, I spent 15 minutes to understand them. It didn't kill me.
And React has been undisputed king the frontend frameworks hill for at least 9 years, but people still act like it's some sort of ever-changing, confusing landscape of options. If you want boring, stable front-end development, choose a super popular, well documented tool like React. Or if you don't like frameworks, use vanilla JS. It's not a crisis.
How does your library deal with state management and data flow? What primitives does your library offer for optimization?
You implied but didn't say explicitly, are you doing your front-end development with web components now personally?
Yes.
Have you tried the Lit library? Using lithtml to write web components based on Lit Component is DREAMY imo, if you’re into web components. It really reminds me of using jquery’s helper methods for ajax - like why wasn’t it just this way by default all along.
If you use web components enough you realize why tools like useState exists then you have to bring in another library like alpine to offer the functionality.
The whole point of web components is the ability to offer class encapsulation within the browser without anything other than a file server.
JSX has much nicer syntax but I’d rather not have to deal with the overhead of launching a node server. Makes developing time quicker when working with smaller codebases.
> I don't want to learn a complex framework.
Completely agree. As a casual programmer, I just want something simple, inspired in VB6.
I think part of the reason people talk past each other on this issue is because they're optimizing for different things. If you're working for a VC-backed startup with a central product that needs to move quickly and is going to require constant maintenance anyway, a framework might be a good fit for you.
But I work in an academic lab. We don't have tons of money to maintain the apps that we've written. We need them to just keep working once funding has moved on to new projects.
We're just finishing up a rewrite of an app from Vue to Web Components. It had dependency rotted to the point where we couldn't update anything because of dependency hell. Rather than spend hours trying to fix it, which we've done before and would have to do again until the end of time, I decided to experiment with Web Components. The experience was immediately so nice that we went all in. No regrets. We went from ~15 dependencies to ~1 (d3js).
If you're curious to try the apps, old one[0] new one[1].
If you can rewrite to remove all dependencies except for d3js, why couldn’t you do the same thing, but also retain a dependency on Vue? What is it about Vue that requires the extra dependencies - is it built system things? (I’ve never used Vue)
Vue itself must be updated. And if you throw out the router, Vuetify, state management, etc, what is it adding above Web Components anyway?
Sometimes I don't understand this argument because theres nobody forcing you to always be on the latest version of a framework. You could have just stayed on the version of Vue you were using without issues. Unless theres some compelling reason you could use it into the end of time and be just fine.
Thats not to say that maybe for your use case you could have not used it in the first place or that removing the dependency was a bad idea - just that if you do like Vue there doesn't seem to be anything forcing you to always be on the latest version.
What happens when old versions stop receiving security updates?
Rarely do security issues come from directly as a result of your choice of frontend/client framework which should really only be in charge of displaying your data. Almost all issues should be handled by your backend.
Most cases where it becomes an issue is when people drop security best practices falsely believing their frontend/client validation is a security layer.
Anybody thinking updating your frontend solves your security issues has deeper problems.
Doesn't matter, a security update is a security update. So, especially when you work in a larger company, you end up having strict compliance requirements to keep things up to date.
I'm as annoyed by it as the next guy. The supposed vulnerabilities are almost never actually relevant for frontend code, and rather assume that you are running Node as a web server.
It's just one of those weird things that has resulted from how the JavaScript ecosystem has centralized around using node for everything (i.e. building frontend code as well as executing backend code - even though the two have kind of nothing to do with each other.)
> Rarely do security issues come from directly as a result of your choice of frontend/client framework
Front end client frameworks now span the backend. Nextjs is the prime example. It has plenty of CVEs already.
Well next is not a frontend framework and doesn't claim to be. Its very clearly a full stack framework. Vue by itself isn't.
I have been following the web components discussion for years now and just don't see what I can do with them that makes my life as a fullstack developer better.
All the examples I have seen use them to template some data into html. I can do that with handlebars already.
Am I missing someting?
Full native isolation. HTML, CSS, JS, the whole thing, no tricks, the browser isolates it for you. It's really nice to be able to make a web component, clearly define the JS, HTML and even CSS API in terms of variables, and then throw it into any environment without it breaking, or without creating a complex maze of CSS name spaces and framework dependencies.
Is there really ever a use case for that?
When do you want part of your page to have different fonts, colors, everything from the rest of the page?
It is not a choice in many situations. For a large company that has many different teams that own many different parts of a product, even though teams adhere to the same "UI standards", things get complicated quickly. For example, CSS classes that have name conflict can cause UI to break (which happens more often than you think, and strictly adhering to naming rules is just hard for humans). That's just one example. Custom elements with shadow DOM is a simple and straightforward solution to this, and it makes sense -- JavaScript code are scoped to modules and use imports/exports to define interfaces, and it is just natural to do that for UI instead of putting every class that other people don't care about in the global CSS space.
We ran into this too, and ended up not using the Shadow DOM at all. We want our stuff to automatically use the page's fonts, sizes, colors etc. Also we want customers to be able to customize stuff with CSS without having to use JS hacks to inject CSS into the shadow DOM (this gets especially cumbersome when you're nesting web components). Personally I feel like the shadow DOM is the most oversold part of web components, in that it's so all-or-nothing that it often creates more problems than it solves.
Which is another thing I love about web components - if you don’t want shadow dom, then don’t use it - you can build using just custom elements.
In terms of style isolation, the answer is very much “it depends”. And it depends as much on the nature of what the component does, as the kind of isolation you want to achieve.
- Namespace isolation. Example: you have different components in the same codebase or otherwise meant to work together; you may want assurance that a locally defined style attached to class “foo” doesn’t have unexpected effects on other components which happen to use the same class a different way. This is commonly achieved with build tooling, eg by mangling class names.
- Cascade isolation. Example: you have an embeddable widget that you want to look consistent in any context, regardless of the styles of its parent DOM. This is achievable to some extent without custom elements, but they are a way to achieve it with confidence in a relatively straightforward way (at the expense of other limitations and complexity).
The use-case for having isolated objects with parameters, much like classes in Java, is to be able to a) share code, b) hide internal details, and c) have object behavior be governed solely by a constrained set of inputs.
So the point isn't to have your web component be different from the rest of the page. The point is that you can pass in parameters to make an off-the-shelf component look how you want. However, exactly how much freedom you want to give users is up to the component author. It is possible for there to be too little freedom, true.
See here [1] for a concrete example of someone writing a reusable web component, and figuring out how to let users customize the styling.
[1]: https://nolanlawson.com/2021/01/03/options-for-styling-web-c...
This 100%. Web components get praised for this isolation - and it’s like the exact thing I do not want if I’m building an application. Like try to have a global CSS theme, or use bootstrap, etc. (Please don’t suggest I embed a link to global CSS in every component.)
Like I get it if you’re sharing a component on different sites, like an embedded component or ad banner, etc. But it just gets in the way if you’re trying to do normal things that the majority of web apps need.
There are ways to apply global styles to your components other than importing a global sheet. There's just not a standard way defined in the spec. Isolation by default is the correct path for them to take compared to the alternatives. That doesn't make it useless just because you don't know how to do it in a good way.
See https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
My main point is that gets in the way, unlike most other web frameworks when building normal applications. It's a headwind that always comes up and hurts adoption imho.
There are two models of the "web", where HTML is a document and where HTML is the scenegraph of a more complicated app.
If you're using HTML as a document you can use web-components to include fancier interactive real-time feature
* A terminal emulator web component that attaches to a websocket * A date picker web component, add features like checking if a date is already taken * Custom form elements in general, a search-box that takes a URL for auto-completion suggestions * A map, but not a full mapping application * A data table, like the jquery plugin of old * Lightweight interactivity like tab widgets * Basically any of the custom components that jquery-ui provided
Yes you can do all of these without webcomponents, but the HTML is a lot cleaner and a lot more document like if it's a custom component. Mixing the model and scenegraph views of the web is not my favorite. It sure would be nice if there was a consistent library of web components available.
You can actually do pretty decent live-chat with something like HTMX and server-sent-events, I think. But it's sort of a progressive-enhancement view of HTML as a document model.
Web Components let you use a UI component made in a different framework than yours. That's it. For most other purposes they're pretty awful.
Also they let you publish a UI component that works in every framework, without having to build 7 versions of it (or just exclude everyone who's not on React, or something like that)
That’s also the conclusion I’ve drawn. This seems to be the reason Web Components exists.
the examples probably avoid talking about the dynamic APIs because they are super ugly and very stateful. It's hard to say that Web Components are the future when your demo shows 200 lines of manual DOM reconciliation.
I‘ve come to the same conclusion while using them pretty extensively. The idea is nice, but they are not there yet.
This could summarize every interaction I’ve had with Web Components since the beginning. Web Components are becoming the Nuclear Fusion of Web standards.
Sure, there is some pain but after years of several Angular and a Vue migration, I'd say that pain is much less than the pain of framework migration. People often overlook the experience of a framework for a long term use.
They are very good for progressive enhancement, for example you could have a web component that wraps a <table> to add fancy features like filtering or drag-and-drop reordering. If JS is disabled or fails to load, the user just gets a plain table, but they still get the content. When this stuff was new, that was much better for the user than what would happen with a front-end framework (they would get a white page), but now server-side rendering is widely available in those frameworks it’s less of a selling point.
They are also good for style encapsulation, i.e. you could drop someone else’s component in your page and not worry about it affecting or being affected by your CSS. Anecdotally I feel like that is less of a common desire now than it was ~10 years ago, with the rise of both “headless” UI libraries (behaviour without dictating appearance) and the prevalence of scoped styles in front-end frameworks.
What does annoy me about the standard is that to use slots you must opt into the shadow DOM, which means that if you’re trying to create reusable components for your own stuff, you can’t style them just by dropping a stylesheet into the page. I’m sure there’s a technical reason why this is the case, but annoying nonetheless.
Without the shadow dom, your component can still have children.
If you need several slots, there's an example duplicating that functionality with javascript in the second comment of this blog post: https://frontendmasters.com/blog/light-dom-only/
IMO the slots that allow a component to have children are the difference. You can compose indepent components that way. Also the styles are scoped to the component by default, and you can only break the scope with custom vars (css vars)
Are you genuinely asking as a professional? Seems like a big ask for someone to go over all you are misunderstanding if you think they are equivalent to a template language.
The standard, like PWA, is designed for maximum feasible misunderstanding. To the average dev it seems like a random bunch of features that don’t hang together. Five developers could look at it and be like the blind men discussing the elephant —- hung up on individual parts and not seeing the whole, if there is a whole.
There are a lot of candidates for “what’s wrong with modern web standards” but this fragmentation, which comes from a rather mathematical view of programming, is one of them. Thing is, a lot of web devs never studied computer science (even CS 101) and less than 5% live in San Francisco.
> and less than 5% live in San Francisco
How will they ever understand web components.
On the other hand, if they're completely different from a template language it seems like it should be just a moments work to demonstrate why, and help a fellow professional understand what they're missing.
Well um
1) You dont have to load an external library
2) Shadow DOM
3) Dynamic slots
That’s about it, honestly LOL.
I guess the main point of most browser APIs was to let apps use browser features.
This one actually tried to make a standard way for apps to use other apps. But they already had their own libraries so nyeh, thank you very much! LOL
One of the things I really appreciate about Svelte is its support for generating Web Components through the Custom Elements API. Since Svelte compiles down to plain JS/HTML/CSS, creating reusable components that work across any framework or vanilla JS becomes seamless. https://svelte.dev/docs/custom-elements-api
I don't really get this "frameworks vs. web components" discussion. They are both tools to solve different problems. Frameworks exist to render your view as function of state in a declarative way. They use web primitives to define the view layer. Web components can help there, but it doesn't solve the state management issue that frameworks aim to solve. That's a different problem that requires different solutions. In my opinion they can perfectly co-exist.
The worst part about web components and the shadow DOM is how they can prevent browser extensions from working correctly, or working at all.
And the browser vendors aren't in a hurry to remedy this situation.
One thing about web components that I've appreciated is that they can work without JS enabled (at least in theory). I've done this a few times for progressive enhancement.
Broadly I agree with Nolan, though. Web components have enough rough edges that they're not going to take over the world in the current state. But, they are pretty nice for certain use cases.
I'm not sure what he means by not playing well with server side rendering though. I've been doing that without issues.
> they can work without JS enabled (at least in theory).
I wonder what makes you say that. All that I've seen seems to indicate[1] that Javascript is needed in order to register the template with a specific tag.
[1] https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
Allegedly, declarative shadow DOM lets you declare the template next to the prerendered slot, without JS.
Where is this "alleged" though? From one of the paragraphs behind my link:
> This won't appear in your page until you grab a reference to it with JavaScript and then append it to the DOM
that's just wrong
Using HTML and CSS to make web interfaces without JavaScript is like using concrete to make garden gnomes without rebar, while the rest of the adult world is more concerned with using pre-stressed concrete with rebar to make skyscrapers and superhighways. Sure it's a marginal whimsical decorative use case, but not an important or interesting one.
Most people who think turning off JavaScript is an important use case are only inflicting it upon themselves (and aggressively evangelizing that other people do it too) as performative luddites, to feed their martyr complex, so they have something to whine and complain about how the web is so unfair and out to get to them, and have exactly zero customers or products to support.
You seem to be quite careless about whom you offend, but I'm not a fan. Please quit it, the only one whining right now seems to be you.
really I feel the same as them
How is this supposed to work?
With reactJS I know I can server render a component or template and I’ll say JSX makes a pretty good tempting language.
With web components as far as I understand there is no good templating language built in anyways (so you have to bring your own) I’m not aware of a standard mechanism in which I can take some chunk of JS for a component associated with a tag and have it render out HTML that does not require JS to run.
Author here. I cover this in another post [1], but basically the interop benefits you get on the client just aren't there (yet) on the server. My north star:
> Maybe in the future, when you can render 3 different web component frameworks on the server, and they compose together and hydrate nicely, then I’ll consider this solved.
[1]: https://nolanlawson.com/2023/08/23/use-web-components-for-wh...
I love web components and am bullish on them breaking us out of the current frontend hellscape we have created for ourselves. I was recently able to give a short talk on the future of frontend, and it seemed like a lot of other people are hopeful for a way out as well.
As far as performance we built out a data table for our DB GUI that can load in hundreds of thousands of rows and the scrolling through is still buttery smooth.
We actually are getting ready to release our web component library, it's a bit early and rough around the edges but would love to get some more eyes on it! www.astra-ui.com
The only way to get out of the current front end hell IMO is if we get client side import:
I'm aghast at the comments in that thread. They are truly asleep at the wheel.
No wonder the front end is such a disaster with those mindsets running the show.
I mean <script type="module"></script> can do ECMAScript module imports.
That's a solved problem. You can create a custom element for that with some 5 lines of code. Or use one ready: https://github.com/justinfagnani/html-include-element
And that’s exactly what some people don’t want!
Some people will never be happy
I looked at your docs:
- renders very weird on my iPhone iPhone 15 Pro Max in Safari 18.0. Consider responsive design for smaller screen sizes to restyle the sidebar and set a body max-width instead of a width. You might not expect your users to develop on phones, but you might have a hard time with adoption if the docs are mobile hostile.
- the “explore components” button at the bottom of the home page seems to link to nowhere
- site claims “Learn from well-structured, accessible component implementations” as an advantage but I didn’t find any links to the implementation from the docs
- site claims “No dependencies to manage or update” but isn’t astra-ui a dependency? It has a changelog (https://www.astra-ui.com/changes/). Likewise “Full control over the code and styling” I don’t understand how I can both have full control but also be taking a dependency on implementations provided by a library.
I’m curious why you’ve decided to release this library? I’ve come to view open-sourcing internal software as useful to the company for a few specific reasons but to generally be a time-sink without much return unless it’s accomplishing a goal. Component libraries need to fight for general ecosystem adoption or there’s no audience and you might as well not publish at all.
Really appreciate the write up here!
Maybe rough around the edges is an understatement haha, we are actively working to make the docs here better.
So a few things, these are very primitive components that can easily be updated and restyled.
There’s a given that there will be a dependency when using a library, right? The thing is with this you don’t even need to npm install if you don’t want to. Just plug and play.
As far as why… there isn’t much out there in terms of a web component driven component library and I think we’ve done some great stuff with ours. That plus we have customers embedding our components into their platform and it’s always helpful to see the source code.
I hear you on the docs quality though we will work on that.
Why aren't web components there/more popular yet? They seem like a fantastic solution
> They seem like a fantastic solution
for which problem? They don't replace the need for a framework nor do they make writing in one easier. They don't make dev ex better. What is the actual use case? If they were highly useful, they would be used.
Creating self-contained components that don't rely on loading extra management code, in a standard way.
Maybe they aren't useful because the modern trend of web development is to not care about speed or size as much.
Web Components have some nice features, some bad features, and no killer feature. Developers have mostly chosen to ignore them for other approaches (React, Vue) where there are better ergonomics and stronger network effects.
ShadowDOM should be a killer feature for people that wants to make web scrappers life a bit more difficult.
just do a quick scan in this thread, many say it's the one thing that makes web components not work for them. It's the opposite of what a killer feature means
What users/devs like and what CEO/PMs want (stop bot scrapping) are different things.
It was a joke tho, I use custom elements heavily but never with ShadowDOM. It is indeed a PITA.
The cynic in me wants to say it’s because they aren’t VC backed so there’s no main catalyst driving them.
I don’t think a lot of people know about them, or if they do they have just heard about it in passing and have never actually used them.
Whatever the reason is they have a marketing problem that’s for sure.
Ah, well that's encouraging, if the tech itself is good, it means I can start using them more.
New developers follow social proof often instead of learning from first principles.
Web Components are seriously cool and worth looking at.
Social proof does tend to follow employment opportunities. If you're a new dev you don't have the luxury to make principled choices in technology, you're more worried about housing and food security and maybe paying back student loans. Asking new developers to trend-set the industry would be deeply unfair. If we want them to learn from first principles then entry level jobs should have first principles opportunities available.
I meant social proof like prejudice against technologies that employ but don’t seem popular and cool.
Another confusion might be expecting an employer to educate you. That’s part of it but not the requirement.
Self-directed learning is critical to go with any formal learning.
First principles are needing to be taught where or before people are learning things like react. But they don’t, and get pulled into a world of complexity.
Excellent, thank you!
Why would I used them over something like a Vue component?
They are framework-agnostic, meaning you're not locked into Vue, React, Angular, or any specific framework. They work natively in the browser, which makes them reusable everywhere, now and in the future.
> They are framework-agnostic
This is a selling point only if your job is producing component libraries. Otherwise, if you're an application developer, you'll be using a framework anyway.
Not entirely true. Making UI parts of your app using web components can future proof and prevent getting stuck on a framework.
I think this minimizes the fact that interop - the main selling point to me as a user - comes at a performance cost where every component you use could have its own unnecessary runtime attached.[1] Using a framework like Lit with web components is the recommended way to use them.
This cost will compound over time where new frameworks emerge, and components get stuck on older versions of their frameworks.
I can't see this as anything but significant, and not to be minimized. Having multiple redundant libraries on a page is not the direction I would advise anyone to take, particularly not when baked into the accepted best practices. This bodes poorly in the long term.
I've listened to the arguments from web component advocates in blog posts, social media, and videos for years now, and I should be in the target market. But on top of the interop tax, they're full of negatives that aren't present in the mainstream frameworks.
Interop works great within each framework's ecosystem. The same dynamics that cause developers to seek interop cause them to huddle around a small number of mainstream frameworks. So we get a few vibrant ecosystems that push the state of the art together. Web components cannot keep up on the tech side of things, and introduce a ton of complexity to the web platform - ignorable to me as a dev, but not for browser implementers - in service of their early 2010s designs.
I cover this in another post [1], but broadly:
- Not every web app is perf-sensitive to every extra kB (eCommerce is, productivity tools typically aren't)
- Plenty of frameworks have tiny runtimes, e.g. Svelte is 2.7kB [2]
- I wouldn't advocate for 100 different frameworks on the page, but let's say 5-6 would be fine IMO
No one is arguing that this is ideal, but sometimes this model can help, e.g. for gradual migrations or micro-frontends.
BTW React 17 actually introduced a feature where you could do exactly this: have multiple versions of React on the same page [3].
[1]: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp...
[2]: https://bundlephobia.com/package/svelte@4.2.19
[3]: https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
While this is true I think the multiple libraries problem is a rounding error when you look at the majority of web apps created today. React and react-dom combined are over 100KB. Svelte and Lit are in the single digits. So you could embed a lot of frameworks before you get close to the bloat people use every single day without even thinking about it.
As a Svelte user this argument rings hollow. You can't judge frontend by React and the way it's badly used.
> You can't judge frontend by React and the way it's badly used.
IMO you can because it’s the vast majority of webapp usage today. I’m also a heavy Svelte user and I love it but front end web dev is practically a React monoculture so it makes sense to think about it when evaluating options.
I’m not saying it isn’t a problem inherent in web components, it is. But using it as a reason to not adopt web components runs contrary to the logic the vast majority of the industry currently uses. Perfect as the enemy of good and all that.
React is irrelevant for me and my users. This is not an argument in favor of web components over Svelte. Adopting web components would mean an objectively worse UX for my users - for example requiring them to enable JS.
You won't get a Svelte to look past the flaws of web components by saying "React is bad".
Yes, you’re talking about you and your users. I’m talking about the industry at large. Those two perspectives don’t have to line up.
The article we’re discussing is titled “Web Components are okay”, not “Web Components are better than Svelte for webdevladder and their users”.
Look at the thread you've created here - I'm arguing that the article minimizes the antipattern cost they impose, and your response brings up React as if it somehow changes that.
Yes, I previously mentioned the “perfect as the enemy of good” argument.
Like I already said, I use and like Svelte. But the vast majority of the web dev ecosystem uses React. Web components would be better than everyone using React. Arguably everyone using Svelte could be better still but that’s a separate debate.
> your response brings up React as if it somehow changes that.
It does. Because the industry clearly has no problem with a large upfront cost, given that it imposes one today. Web components would be better than what we have today even if it isn’t the ideal.
You absolutely can judge tools by how they are used, especially if said tool encourages poor usage.
You can judge React, but like I said, not frontend. You're responding to an argument I didn't make.
React has one up-front size for rendering code whether you use 1 component or 10,000 components.
Svelte and Lit rendering code size just keeps going up, and up, and up....
You can argue about which is better, but this kind of naive size comparison is disingenuous.
While it’s true that Svelte and Lit can grow in size dependent on project there’s no world in which even large projects get close to the base level of the React runtime.
Only if you are doing it wrong. https://lit.dev/docs/tools/publishing/
A more broad observation, I'm being pointed in the parent comment - web components need to win over framework authors. The signs are not trending well here from what I've seen consistently. That community is on X and web components are not addressing their problems and they're not used in optimal scenarios. I hope web components can win them over but they're mostly saying they've been a failure, arguably on balance bad for the web.
I don't really understand this argument, to be frank. Most runtimes are pretty small, and there's not much of a performance overhead to both runtimes running at the same time. It's not like these are two realtime engines both purring along in the background or something like that. All modern web frameworks are reactive, and won't do anything unless something needs responding to. If one part of the page is built with React, another part is built with Lit, and a third part with Svelte, I don't see how that will have noticeably worse UX (or battery consumption) than a page made with just one framework, even when reactive triggers are frequently exchanged between them.
The tweet you quote is about whether web components are "useful primitives on which to build frameworks". I doubt many web component fans (who actually really used them) would say that they are. They're a distribution mechanism, and the only alternative I've seen from these framework authors is "just make the same library 7 times, once for React, once for Preact, once for Svelte, once for Solid, once for Vue, once for vanilla JS". This is awful.
You're ignoring page bloat as a performance cost. That's hugely impactful for UX on the web.
Not entirely, I said "Most runtimes are pretty small".
I think people got trained by React into thinking that frameworks are big. SolidJS is 7kb, Lit is 5kb, Svelte is tiny and used to have no runtime at all, etc. Only React is big. And, well, if you're writing React components and publishing them as web components, it's usually quite feasible to build them with Preact instead, which is tiny as well.
So on a page with like some hodgepodge of 5 frameworks purring along inside various web components, there's still going to be only 20-30 kb of extra overhead. You can compress one image slightly better and save more than that.
The point being made is that web components can pay this cost per-component, and this problem will compound over time. This is an unprecendented cost to frontend framworks and it's the expected usage pattern.
I've yet to see this go wrong in practice. The kinds of components that are worth publishing as web components are often large, non-trivial components. Eg media libraries, emoji pickers (like the one made by this article's author), chatboxes, and so on. They are the kinds of things you only have a limited number of on your page. They're also the kinds of things where application code tends to be much bigger than the framework (except if the framework is React).
On the other hand, if a component is small and focused in scope, it's likely either written in vanilla JS (like https://shoelace.style/), or made for a single framework (like the average React infinite scroll component).
In other words, I don't think you're wrong, but I do think you're prematurely optimizing a problem that doesn't really exist in reality. And the cost is big: if you get your way, every component author needs to either lock themselves into a single framework's users, or make 7-8 different versions of their component. I'd argue that that's much more wasteful than a few kb extra framework JS.
It’s also just not actually true though. It’s not considered good practice to bundle your web components when publishing to npm for this exact reason. That’s something that should happen inside the final app itself where the components get used so you only have one instance of Lit for example if you are using that.
Web Components are fun. I've played around with Lit, which some people have mentioned. Anybody tried Stencil? It looks similar from the outside but wondering how it plays out mid/late-term.
I really dislike the Shadow DOM part of Web Components. Someone didn't learn any lessons from past mistakes and went and reinvented iframes. Trying to write tests or any automation for a web page that uses shadow dom is an exercise in misery, unnecessary at that.
Let me explain the argument to you:
> You can always add another layer of abstraction to solve a problem but removing one can be difficult.
The argument being that there's no need to add anything to the browser stack and make it even more complex when it doesn't add any essential capability. There's already JS making everything possible; and yet, they keep on piling stuff. When with custom elements specifically, you also require JS anyway (to declare them).
> Elements are not components.
Idk maybe for "web devs" the concept is difficult to grasp that HTML isn't for them. It's for text authors, and as such a markup vocabulary where low-level elements are placed next to complex custom controls nilly-willy isn't really a useful evolutionary direction.
I use web components, but I often want to design classes as MVC. It isn't obvious how this should work (though I assume the Web Component spec authors discussed the topic at some point). The awkwardness is:
(a) When you instantiate your View class (ie: 'web component') from JS, you probably want your Model and View to be 'owned' by properties of the Controller (eg: con.model and con.view). However...
(b) when an HTML tag instantiates your View, the View has to create its Model and Controller. And now there's no obvious place to store a reference to the Controller.
As a result, you have either to stick the Controller in a global variable somewhere, or - more likely - end up, not just with 'con.model' and 'con.view', but also with a new property: 'view.con'
So... two paths to create everything (Controller-based, or View-based), and this ugly '.con' property stuck in the View.
But, aside from this gripe, Web Components are okay.
I don't think we components were intended as a complete "framework" for writing web apps, but more for the rendering of reusable UI components.
So trying to do MVC with just web components feels a bit weird, at least to me. You'd need something extra I think
The problem is that the ShadowDOM is sort of the real View, and the CustomElement (judging it by its methods), is kind of a mix of a View and a Controller.
Perhaps I should try making my controllers the HTMLElement subclasses, instead of my views. My gripe remains: the best approach is not obvious.
Web components are lacking some basic functionality that makes using them in something complex difficult.
For example, one of the deal breakers we faced was the inability to unload and reload a web component. Once you load a web component you’re stuck with it until you refresh the browser.
You cannot have an SPA with one page loading 1 version of the web component and another loading another version without some ugly namespace mangling.
I'm bullish on web components as a distribution mechanism. In fact, we're currently hard at work betting our entire company (https://talkjs.com - a component library + API for chat) on it.
I agree with Nolan here that the performance is fine. People keep comparing web components to React or Solid components, but the latter inherently have a tiny granularity whereas web components is primarily a way to distribute reuseable elements, not an application framework on its own. Don't make every tiny piece of your app its own little web component (or, at least, don't do it without a framework such as Lit to skip the pain). But web components are the way to build a component once and have it usable in all web frameworks (including none at all) out of the box. That's fantastic! And also unprecedented (on the web, that is).
It bothers me that so much of the discussion is still about whether web components are good primitives to build frameworks on top of. No, not really, they're pretty awful for that! But for distribution, nothing else comes close.
I'd love it for some alternative standard to emerge, without all the awful design choices of web components. And I agree with Rich (Svelte) and Ryan (Solid) that WCs being built into browsers are getting in the way of some other collective component interop design emerging. But until the framework authors stick their heads together and invent a fast, modular, non-shitty, property-only, functional-smelling standard for distributing components, I'm sticking with web components. For component authors, the only alternative is making a React version, a Preact version, a Lit version, a Svelte version, a Vue version, an Angular version, a Solid version and a vanilla JS version of the same UI component. That's awful! Web components are clunky but they're here, now!
> With every programming language, you can do
There are plenty of programming languages where you can't do that. If you really need that, can't you just register it as "my-thing-1" and then register the other one as "my-thing-2"?
Sorry, I edited my post and took that out for being too detailed.
> If you really need that, can't you just register it as "my-thing-1" and then register the other one as "my-thing-2"?
Yes you can, but it means you gotta search-replace something, whereas in every modern programming language you just do an import or an alias or something like that.
And you still can't solve hot-reloading a web component that way.
I did a project that used Shadow DOM and related tech to address the problem of embedding a widget into a partner’s web site without any risk of CSS interference. Worked great, but this was one medium-sized widget that did not interact with the rest of the page.
I like seeing accessibility respected. Good post.
I dig WebComponents because I love building on standards which promote interoperability across frameworks and have long term lifelines. Standards reduce platform + dev lock-in and reduce framework balkanization and frankly chaos in many cases. You are a better developer if you understand the root standards and core systems, which WebComponents get you closer to.
I also like the Lit Framework (https://lit.dev/) from Google which is rarely mentioned but it is quite nice for some of the simplifications and extras you might need when building them but it doesn't get in the way or try to take over your entire domain with dev-lockin.
Whether going direct to WebComponents or a higher level simplification like Lit, they really are a freedom from dev lock-in that is nice to see.
Web components are okay as long as you only use them to progressively wrap actual HTML elements. If you're using custom-elements by themselves like a JS frontend replacement and just making entire web pages full of blank grey boxes that do nothing without JS, you're doing a bad job.
Oh? So anyone writing applications, PWAs, healthcare software, responsive mobile web apps, or a billion other business domains where the web makes sense as a UI is doing a bad job?
Guess I've been doing a bad job for a long time now.
Yes, https://www.gov.uk/service-manual/technology/using-progressi...
“All [UK] government services must follow progressive enhancement, even if part of the service or a parent service needs JavaScript”
But more seriously, it's okay to do a bad job if you're being paid/forced to do it by a for-profit entity. That's what jobs are. Being paid to do things you wouldn't do otherwise (like making a webpage entirely inaccessible to people with screen readers because there's no text in the custom-elements pre-JS execution and not caring because the visually impaired don't contribute significantly to profit). Just don't chose to do a bad job for personal stuff.
While that link is great advice it's not 100% true that you need to have JS enabled to render anything in a web component - there's declarative shadow dom. Also while it's also true to depend on as little as possible JavaScript it's also required for some accessibility aspects. You can get far with only HTML and CSS but not always all the way.
Screen readers that can't do their job on dynamically generated pages are faulty and should not be relied upon by anyone, especially for browsing the web. There is absolutely no reason to be beholden to the incompetence of the developers of such software.
Yeah, those visually impaired people should be constantly changing their screen reader software so as to follow the eternally changing wave of web dev. That's totally a feasible and reasonable thing to ask. I'm sure the shadow dom is giving those dynamic screen readers zero problems. /s
Please, please just consider putting actual text in the HTML. It helps a lot.
Safari is the only browser without the full support
*Supports "Autonomous custom elements" but not "Customized built-in elements"
I think one of the biggest "mistakes" with web components was coupling them in people's mind with shadow dom.
For app dev (not library dev) web components are a super lightweight easy option when you stick with the light dom.
You can continue to use bootstrap or tailwind or whatever css thing you like, but get great functional encapsulation with near zero cost, especially if you use lit-html or something similar as a renderer.
My teams have generally found working with native web components refreshing. It takes a dev coming from the framework world about a week to adjust, and then they never want to go back.
Just using simple class properties and a manual call to a render function on set() gives you all the benefits of reactivity without all the hassle of frameworks.
The problem most people have with getting started with WCs is that there's not much out there showing how do to it in "easy mode".
Most of the getting started things throw you right into shadow dom, css parts, and all these really painful technologies that were primarily intended for use by library authors, not app devs.
I've been building apps with native WCs for a long time now, I should get off my keister and write a guide on how to make your life easier with WCs, something like "The Good Parts".
I use shadow DOM every day, but yes, it is often the part of WCs that baffles people – probably because they don't need it.
Alternative approaches that may work for your use case:
- "HTML web components" [1] - light DOM only, SSR-first, good as a replacement for "jQuery sprinkles"
- "Shadow gristle" [2] - use as little shadow DOM as possible. If you need styling or composition, put it in the light DOM!
That's exactly it. We are just missing slots for lightDOM
This might be a stupid hot take, but I am surprised that so little of web UI exist outside of the browser. I mean why bootstrap or other frameworks are not managed by browser ecosystem? Why millions of people how to download same frameworks over and over?
There’s a pretty thorough post covering this here - https://infrequently.org/2022/03/cache-and-prizes/
What’s missing in his point and examples about “performance isn’t everything” (aria properties, forEach, …) is that these are cases where you could optimize later when and if needed. Using forEach is a fluid coding choice at the time but if for any reason you need to optimize to a for loop you can with minimal fanfare. But buying into web components is more of a one-way door and harder to iterate optimizations, and that’s the problem.