22 ms·

Web components are okay

278 points by keybits 2y ago

burcs 2y ago
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
- candiddevmike 2y ago
  The only way to get out of the current front end hell IMO is if we get client side import: https://github.com/whatwg/html/issues/2791 https://github.com/whatwg/html/issues/2791
  - askonomm 2y ago
    I mean <script type="module"></script> can do ECMAScript module imports.
  - meiraleal 2y ago
    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 https://github.com/justinfagnani/html-include-element
    - PaulHoule 2y ago
      And that’s exactly what some people don’t want!
      - meiraleal 2y ago
        Some people will never be happy
  - arcbyte 2y ago
    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.
    - lelanthran 2y ago
      > I'm aghast at the comments in that thread. They are truly asleep at the wheel. And the wheel that they're at is the one in a clown car. Which is driving off a cliff. Just having a custom element `<my-include-html remote-src='...'>`[1] is enough to forgo 50% of the reason for using a front-end framework with a build-step. [1] One that executes scripts, allows `<style>` tags, etc.
  - halfcat 2y ago
    Would this be different from using HTMX to load an HTML partial on page load? Something like: <div hx-trigger="load" hx-get="/header.html"></div>
- stavros 2y ago
  Why aren't web components there/more popular yet? They seem like a fantastic solution
  - burcs 2y ago
    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.
    - throwawayha 2y ago
      Lots of open-source things got adopted without VC backing. There's a lot more options now, it would be good to have a way to have the best stand out.
    - stavros 2y ago
      Ah, well that's encouraging, if the tech itself is good, it means I can start using them more.
  - j45 2y ago
    New developers follow social proof often instead of learning from first principles. Web Components are seriously cool and worth looking at.
    - stavros 2y ago
      Excellent, thank you!
    - evilduck 2y ago
      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.
- tomjen3 2y ago
  Why would I used them over something like a Vue component?
  - throwawayha 2y ago
    Vue is great but it's a personal preference and interpretation for you. It's not about better or worse for you, maybe for the average person.
  - burcs 2y ago
    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.
    - throw310822 2y ago
      > 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.
      - apotropaic 2y ago
        Not entirely true. Making UI parts of your app using web components can future proof and prevent getting stuck on a framework.
- jitl 2y ago
  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/ 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.
  - burcs 2y ago
    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.
- shortrounddev2 2y ago
  I just rewrote my company's frontend ad code in webcomponents
tomrod 2y ago
I like seeing accessibility respected. Good post.
mentalgear 2y ago
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 https://svelte.dev/docs/custom-elements-api
- swyx 2y ago
  even Rich admits this is not a top priority goal of svelte, so do not be surprised if the reality falls short of the promise.
- rondini 2y ago
  Vue also does this! https://vuejs.org/guide/extras/web-components https://vuejs.org/guide/extras/web-components
skrebbel 2y ago
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 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!
- delusional 2y ago
  > 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"?
  - skrebbel 2y ago
    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.
webdevladder 2y ago
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. [1] https://x.com/Rich_Harris/status/1840116730716119356 https://x.com/Rich_Harris/status/1840116730716119356
- afavour 2y ago
  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.
  - webdevladder 2y ago
    As a Svelte user this argument rings hollow. You can't judge frontend by React and the way it's badly used.
    - afavour 2y ago
newhotelowner 2y ago
Safari is the only browser without the full support *Supports "Autonomous custom elements" but not "Customized built-in elements"
- deleted 2y ago
  [deleted]
MrThoughtful 2y ago
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?
- someothherguyy 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - tome 2y ago
    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.
    - deleted 2y ago
      [deleted]
    - EGreg 2y ago
      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
      - antifa 2y ago
        Now I'm curious, what template engines don't have dynamic slots? Is that actually a rare enough feature to declare webcomponents special for having it? Does webcomponents have an advanced version of it?
lapcat 2y ago
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.
- 0x1ceb00da 2y ago
  This. User agent configurability is the killer feature of web.
superkuh 2y ago
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. See: https://blog.jim-nielsen.com/2023/html-web-components/ https://blog.jim-nielsen.com/2023/html-web-components/
- claytongulick 2y ago
  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.
  - superkuh 2y ago
    Yes, https://www.gov.uk/service-manual/technology/using-progressive-enhancement 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.
    - royal_ts 2y ago
      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.
    - DecoySalamander 2y ago
PaulHoule 2y ago
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.
veggieroll 2y ago
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.
- mariusor 2y ago
  > 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_components/Using_templates_and_slots https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
  - debugnik 2y ago
    Allegedly, declarative shadow DOM lets you declare the template next to the prerendered slot, without JS.
    - mariusor 2y ago
      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
      - debugnik 2y ago
        Your link isn't showing the declarative shadow DOM, this does: https://web.dev/articles/declarative-shadow-dom#how_to_build_a_declarative_shadow_root https://web.dev/articles/declarative-shadow-dom#how_to_build... And the example below that one shows how to hydrate declarative shadow roots with JS custom elements, so the path to progressive enhancement should be clear. I say alleged because I haven't had the chance to try it beyond a toy example.
jeswin 2y ago
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 https://webjsx.org
- wslh 2y ago
  > I don't want to learn a complex framework. Completely agree. As a casual programmer, I just want something simple, inspired in VB6.
- azangru 2y ago
  > 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?
  - nsonha 2y ago
    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.
    - 2y ago
deleted 2y ago
[deleted]
claytongulick 2y ago
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".
- meiraleal 2y ago
  That's exactly it. We are just missing slots for lightDOM
- nolanl 2y ago
  I use shadow DOM every day, but yes, it is often the part of WCs that baffles people – probably because they don't need it. Alternative approaches that may work for your use case: - "HTML web components" [1] - light DOM only, SSR-first, good as a replacement for "jQuery sprinkles" - "Shadow gristle" [2] - use as little shadow DOM as possible. If you need styling or composition, put it in the light DOM! [1]: https://adactio.com/journal/20618 https://adactio.com/journal/20618 [2]: https://glazkov.com/2023/03/02/shadow-gristle/ https://glazkov.com/2023/03/02/shadow-gristle/
- kolme 2y ago
  In my last gig we had exactly the same stack (WC without the shadow dom part + just lit-html) and it's great. The best part is not having a dependency hell situation every other week.
apitman 2y ago
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]. [0]: https://bam.iobio.io/ https://bam.iobio.io/ [1]: https://bam2.iobio.io/ https://bam2.iobio.io/
- jitl 2y ago
  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)
  - apitman 2y ago
    Vue itself must be updated. And if you throw out the router, Vuetify, state management, etc, what is it adding above Web Components anyway?
    - athanagor2 2y ago
      As far as I know there's no simple and performant way to have the DOM be a function of the state with existing standards
      - hasanhaja 2y ago
        What do you mean specifically when you say? > DOM be a function of the state I understand the benefits of the mental model, but the tooling that delivers that generally have a lot of complexity that isn't trivial to parse and understand. I think the benefit of being able to parse and understand your abstractions (ones you build yourselves or buy off the shelf like a framework) is there are always gaps in the constraints under which they had originally been designed; so you'll always need to understand how it works under the hood. React's class-based components were simpler because the lifecycle methods were explicit, but the hook-based model is "easier"; however, the component lifecycle is still present. The demo code does look really clean, but in real life you quickly start to face the underlying complexity of the abstractions (e.g., useEffect, memoization, realizing how fine-grained your reactivity is is based on how you've drawn those component boundaries). You can write these optimizations yourself, or wait for the new auto-memoizing React compiler to land, but in all cases, the overall complexity remains the same (or is higher). And this isn't unique to React or other frameworks, and you'll always need to delve a little deeper. I agree that the DOM APIs could be more declarative (e.g., declarative custom elements proposal [1], declarative shadow DOM, `@scope` CSS as another way to scope styles), and there is activity in that space, both in the W3 Web Components Community Group and the Open UI Community Group. I'm trying to get more involved in those discussions and I'd recommend everyone who cares about the web and how we build for it to participate. I think the process of standardization for new features (through the proposals phases to finally landing in browsers) is the effort to raise the floor for all to build on top of. I remember when Promises were landing everywhere and feeling a little overwhelmed by what it meant to me because I was using Bluebird. Then the feeling of "maybe I can simplify what I'm doing and lean more on the platform" set in. Frameworks are a testbed for new ideas, and we can go further by trying to see what pieces we can pull out and standardize around (e.g., Signals proposal [2]), so we can go back to testing new ideas on top of that. [1] https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... [2] https://github.com/tc39/proposal-signals https://github.com/tc39/proposal-signals
tannhaeuser 2y ago
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.
renegat0x0 2y ago
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?
- ramones13 2y ago
  There’s a pretty thorough post covering this here - https://infrequently.org/2022/03/cache-and-prizes/ https://infrequently.org/2022/03/cache-and-prizes/
mtn6747 2y ago
[flagged]
- toddmorey 2y ago
  So just more AI comment spam, huh? It's unfortunately ruining my favorite communities.
  - meiraleal 2y ago
    it is only ruining if you decide to see the dead posts and still dislike that spam is being killed.
addicted 2y ago
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.
deleted 2y ago
[deleted]
thomassmith65 2y ago
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.
- mattlondon 2y ago
  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
  - thomassmith65 2y ago
    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.
    - thomassmith65 2y ago
      Note to whoever comes across this comment in future. So I have now explored using HTMLElement as the Controller, its shallow DOM as a data source for its Model class, and its ShadowRoot as a subclass. It is clear to me now that that design would be the most natural fit for MVC. However... it is also impossible. For whatever infuriating reason, they designed custom element's ShadowDOM class to not be subclass-able. You can neither give a ShadowDOM subclass a constructor, nor does HTMLElement reveal any mechanism to 'attach' a ShadowDOM subclass. Fantastic /s
mmcnl 2y ago
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.
drawkbox 2y ago
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/ 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.
wellpast 2y ago
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.
gaganyaan 2y ago
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.
dandrew5 2y ago
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.
- commanderkeen08 2y ago
  Stencil has a way better DX. Especially if you’re doing a whole library of components. You pay a slightly higher perf tax for their auto loader and light vdom. Lit is the way to go if you have opinions and want no magic
breck 2y ago
We do web components better than the web. We just call them Parsers. Geniuses build for The Scroll first. Retards build Web first. (Don't misinterpret, I love The Web, but The Scroll is on track to be 100x better)
impostervt 2y ago
A few months ago I started a job where I inherited a JS code base that is around 250,000 lines. It was one big class, with several sub classes, that did everything. Some files were 30k lines long. No frameworks, no reactivity. If you click a button, you had to update everything on the screen with event listeners manually. Took the guy years to write it. It's like a monk got locked in a cell for years with a basic book of javascript. I started by refactoring into web components, because I had to do it piecemeal. It's been a big help, and I've cut 50k lines of code so far. But the real point was to just learn everything the old code was doing before I start a rewrite.
- Sammi 2y ago
  > I started by refactoring into web components, because I had to do it piecemeal. Yes. The key to making an old and arcane code base understandable to yourself, is to refactor one small part of it at a time. That you're redoing with web components is just one way that would achieve this. I applaud you for not just throwing everything it away and starting anew. On risk of this approach is that you get some way though and then move on to some other project, and someone else comes along and inherits the old project and starts refactoring in their own style, and so now you have an old arcane code base in three different styles... it still beats a rewrite of a 250.000 line code base in one go.
jongjong 2y ago
Tech discussions are hard to have nowadays because people are highly biased in favor of their current tech stacks. The religiousness which used to be restricted to programming languages has expanded to include frameworks, databases, test runners, infrastructure, CI tooling, libraries; literally everything is a religion nowadays. It makes almost all technical arguments disingenuous and pointless. Like people arguing about whose religion is more correct. Observable facts don't matter so much. People see arguments in favor of some alternative stacks as a personal attack against their career. It's probably because companies themselves have become so focused on hiring based on these stacks. They have become a matter of livelihood. In the old days, many companies saw software engineering ability as a separate skill; now they barely even use the word 'software engineering.'
- hu3 2y ago
  Thanks for sharing this view. I relate a lot.
carlual 2y ago
I found a practical way to foster critical thinking skills and encourage independent thought at the end of Netflix's documentary, The Social Dilemma: > I follow people on Twitter that I disagree with because I want to be exposed to different points of view. Here is another good opportunity for it.
mrfinn 2y ago
How can it be possible that we are in 2024 a no one seems to be proposing the most obvious improvement to the web, which is to create a new standard designed for web applications and let the HTML alone serving it's original purpose, which was to serve documents? (H*T*ML the T goes for "TEXT"!). Instead of that, and make things complex and unmanageable to the extreme, to "improve" things now we dropped out completely the MVC philosophy and went completely ahead with an spaghetti mess of Javascript, HTML, CSS, and create-your-desired-tags-at-will everywhere, aka Components. PS. And not even mentioning Madnesscript which deserves another chapter in this story of horror.
- openrisk 2y ago
  There are probably many reasons. The history of technology development teaches us there are a lot of non-core factors that affect the adoption of alternative designs (influential entities and agendas, network effects, business models of those involved etc.) But there seems to be also an interesting intrinsic reason: The versatility of the digital "Document" paradigm itself. Text in its digital incarnation (a sequence of human readable strings) is not just your usual text. While printed text on a page involves the encoding and annotation of human language sentences you can encode a lot more things in human readable HTML/SVG/XML formats (e.g. numerical data, visual geometries, declarative UI etc.). The HTML family of documents is in this sense a sort of "super text". Its structure reflects already its huge dynamic (rich text) potential. But clearly you cannot solve everything in a declarative manner (though you should probably push it as far as possible). At some point the flexibility of code is important and the question then is what is the optimal way to do this (as in: easy, performant, versatile etc.). Alas at the moment we seem to be almost at the extreme opposite: everything as code. Ideally one would refactor all these declarative formats that have proven their utility and resilience and rethink the role of code / frameworks, taking into account all the developments and learnings of the past decades (web assembly, mobile, pwa etc.).
- mixmastamyk 2y ago
  It's a herding cats problem. Not practical for new actors to propose one and have it adopted; current principals are no longer trusted. No one else with deep pockets cares enough to donate the resources it would take and/or do the hard coordination work. We don't see viable new Operating Systems either, for example. That leaves minor feature additions as the only way forward.
auggierose 2y ago
Web components are not OK. They are shit. I wouldn't touch them, just as I wouldn't touch shit. If you find React hooks hard to understand, then I really don't need to hear your opinion about anything, including about how web components and HTMX are so great. Just learn programming.
- epolanski 2y ago
  As someone who uses all of web components, react and Vue, depending on the project I really feel like to give such aggressive and opinionated takes you should consider doing it in a mature and professional way that goes into the "why" you feel like that.
  - auggierose 2y ago
    Mature and professional is what gives us shit like web components, and people like you eating it. So, no, thank you.
    - epolanski 2y ago
      Have you considered that there are different tools for different problems and that web components have their own space in the wide array of problems? Because they are a decent fit to a specific set of problems (e.g. authoring components you can embed on different platforms, regardless of the technology they are built with). I myself, as detailed in another comment, have concerns with web components, and having worked with them extensively, I feel they fall short in several aspects (especially regarding layout control, where they aren't isolated enough due to a series of design choices) but it's manageable. A problem that I had in two different companies (embedding a set of elements that had to work in very different applications and required the host to know little to nothing) after much analysis was best solved with web components and they did well at that. The possibility of doing `<script type module>import "yourcomponent.js"</script> <yourcomponent foo="bar"></yourcomponent>` without for us web component authors having to worry about the wide array of different technologies the hosts used (both at compile and runtime) has been in the end the best solution for both us and the consumers. As Ryan Carniato points out, most of the criticism web components get is that their usage is misunderstood, some of their behavior falls short of their goals, and their name conflates then with framework's components creating further confusion, which are something very different. The problem with comments like yours is that they add nothing of value to the discussion. We don't know if, when and where did you try to use web components, what hasn't worked for you and why, or if you've ever had the kind of problems where web components would've been a good fit or not. You end up giving the hopefully wrong impression of an obtuse person lacking the engineering sensibility to understand the context of problems and of their possible solutions.
shortrounddev2 2y ago
I wish web components had a bit more to them 1. I wish you could reliably parse their attributes in the constructor instead of connectedCallback, so that they play better with typescript readonly properties 2. I wish I could declare properties in the class and have them automatically map to an attribute 3. I wish I could construct them using html instead of manipulating domnodes manylually 4. I wish I could construct child nodes first so that I can compose webcomponents with other webcomponents As it stands webcomponents provide the ability to construct a single element at a somewhat predictable moment in time, automatically. That's cool, but their interface is lackluster to me
wordofx 2y ago
> From my own personal experience: at Salesforce lol

278 points by keybits 2y ago

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

candiddevmike 2y ago
The only way to get out of the current front end hell IMO is if we get client side import: https://github.com/whatwg/html/issues/2791 https://github.com/whatwg/html/issues/2791
- askonomm 2y ago
  I mean <script type="module"></script> can do ECMAScript module imports.
- meiraleal 2y ago
  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 https://github.com/justinfagnani/html-include-element
  - PaulHoule 2y ago
    And that’s exactly what some people don’t want!
    - meiraleal 2y ago
      Some people will never be happy
- arcbyte 2y ago
  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.
  - lelanthran 2y ago
    > I'm aghast at the comments in that thread. They are truly asleep at the wheel. And the wheel that they're at is the one in a clown car. Which is driving off a cliff. Just having a custom element `<my-include-html remote-src='...'>`[1] is enough to forgo 50% of the reason for using a front-end framework with a build-step. [1] One that executes scripts, allows `<style>` tags, etc.
- halfcat 2y ago
  Would this be different from using HTMX to load an HTML partial on page load? Something like: <div hx-trigger="load" hx-get="/header.html"></div>
stavros 2y ago
Why aren't web components there/more popular yet? They seem like a fantastic solution
- burcs 2y ago
  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.
  - throwawayha 2y ago
    Lots of open-source things got adopted without VC backing. There's a lot more options now, it would be good to have a way to have the best stand out.
  - stavros 2y ago
    Ah, well that's encouraging, if the tech itself is good, it means I can start using them more.
- j45 2y ago
  New developers follow social proof often instead of learning from first principles. Web Components are seriously cool and worth looking at.
  - stavros 2y ago
    Excellent, thank you!
  - evilduck 2y ago
    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.
tomjen3 2y ago
Why would I used them over something like a Vue component?
- throwawayha 2y ago
  Vue is great but it's a personal preference and interpretation for you. It's not about better or worse for you, maybe for the average person.
- burcs 2y ago
  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.
  - throw310822 2y ago
    > 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.
    - apotropaic 2y ago
      Not entirely true. Making UI parts of your app using web components can future proof and prevent getting stuck on a framework.
jitl 2y ago
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/ 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.
- burcs 2y ago
  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.
shortrounddev2 2y ago
I just rewrote my company's frontend ad code in webcomponents

tomrod 2y ago

I like seeing accessibility respected. Good post.

mentalgear 2y ago

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 https://svelte.dev/docs/custom-elements-api

swyx 2y ago
even Rich admits this is not a top priority goal of svelte, so do not be surprised if the reality falls short of the promise.
rondini 2y ago
Vue also does this! https://vuejs.org/guide/extras/web-components https://vuejs.org/guide/extras/web-components

skrebbel 2y ago

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 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!

delusional 2y ago
> 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"?
- skrebbel 2y ago
  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.

webdevladder 2y ago

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. [1] https://x.com/Rich_Harris/status/1840116730716119356 https://x.com/Rich_Harris/status/1840116730716119356

afavour 2y ago
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.
- webdevladder 2y ago
  As a Svelte user this argument rings hollow. You can't judge frontend by React and the way it's badly used.
  - afavour 2y ago

newhotelowner 2y ago

Safari is the only browser without the full support *Supports "Autonomous custom elements" but not "Customized built-in elements"

deleted 2y ago
[deleted]

MrThoughtful 2y ago

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?

someothherguyy 2y ago
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.
- deleted 2y ago
  [deleted]
- tome 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - EGreg 2y ago
    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
    - antifa 2y ago
      Now I'm curious, what template engines don't have dynamic slots? Is that actually a rare enough feature to declare webcomponents special for having it? Does webcomponents have an advanced version of it?

lapcat 2y ago

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.

0x1ceb00da 2y ago
This. User agent configurability is the killer feature of web.

superkuh 2y ago

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. See: https://blog.jim-nielsen.com/2023/html-web-components/ https://blog.jim-nielsen.com/2023/html-web-components/

claytongulick 2y ago
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.
- superkuh 2y ago
  Yes, https://www.gov.uk/service-manual/technology/using-progressive-enhancement 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.
  - royal_ts 2y ago
    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.
  - DecoySalamander 2y ago

PaulHoule 2y ago

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.

veggieroll 2y ago

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.

mariusor 2y ago
> 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_components/Using_templates_and_slots https://developer.mozilla.org/en-US/docs/Web/API/Web_compone...
- debugnik 2y ago
  Allegedly, declarative shadow DOM lets you declare the template next to the prerendered slot, without JS.
  - mariusor 2y ago
    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
    - debugnik 2y ago
      Your link isn't showing the declarative shadow DOM, this does: https://web.dev/articles/declarative-shadow-dom#how_to_build_a_declarative_shadow_root https://web.dev/articles/declarative-shadow-dom#how_to_build... And the example below that one shows how to hydrate declarative shadow roots with JS custom elements, so the path to progressive enhancement should be clear. I say alleged because I haven't had the chance to try it beyond a toy example.

jeswin 2y ago

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 https://webjsx.org

wslh 2y ago
> I don't want to learn a complex framework. Completely agree. As a casual programmer, I just want something simple, inspired in VB6.
azangru 2y ago
> 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?
- nsonha 2y ago
  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.
  - 2y ago

deleted 2y ago

[deleted]

claytongulick 2y ago

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".

meiraleal 2y ago
That's exactly it. We are just missing slots for lightDOM
nolanl 2y ago
I use shadow DOM every day, but yes, it is often the part of WCs that baffles people – probably because they don't need it. Alternative approaches that may work for your use case: - "HTML web components" [1] - light DOM only, SSR-first, good as a replacement for "jQuery sprinkles" - "Shadow gristle" [2] - use as little shadow DOM as possible. If you need styling or composition, put it in the light DOM! [1]: https://adactio.com/journal/20618 https://adactio.com/journal/20618 [2]: https://glazkov.com/2023/03/02/shadow-gristle/ https://glazkov.com/2023/03/02/shadow-gristle/
kolme 2y ago
In my last gig we had exactly the same stack (WC without the shadow dom part + just lit-html) and it's great. The best part is not having a dependency hell situation every other week.

apitman 2y ago

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]. [0]: https://bam.iobio.io/ https://bam.iobio.io/ [1]: https://bam2.iobio.io/ https://bam2.iobio.io/

jitl 2y ago
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)
- apitman 2y ago
  Vue itself must be updated. And if you throw out the router, Vuetify, state management, etc, what is it adding above Web Components anyway?
  - athanagor2 2y ago
    As far as I know there's no simple and performant way to have the DOM be a function of the state with existing standards
    - hasanhaja 2y ago
      What do you mean specifically when you say? > DOM be a function of the state I understand the benefits of the mental model, but the tooling that delivers that generally have a lot of complexity that isn't trivial to parse and understand. I think the benefit of being able to parse and understand your abstractions (ones you build yourselves or buy off the shelf like a framework) is there are always gaps in the constraints under which they had originally been designed; so you'll always need to understand how it works under the hood. React's class-based components were simpler because the lifecycle methods were explicit, but the hook-based model is "easier"; however, the component lifecycle is still present. The demo code does look really clean, but in real life you quickly start to face the underlying complexity of the abstractions (e.g., useEffect, memoization, realizing how fine-grained your reactivity is is based on how you've drawn those component boundaries). You can write these optimizations yourself, or wait for the new auto-memoizing React compiler to land, but in all cases, the overall complexity remains the same (or is higher). And this isn't unique to React or other frameworks, and you'll always need to delve a little deeper. I agree that the DOM APIs could be more declarative (e.g., declarative custom elements proposal [1], declarative shadow DOM, `@scope` CSS as another way to scope styles), and there is activity in that space, both in the W3 Web Components Community Group and the Open UI Community Group. I'm trying to get more involved in those discussions and I'd recommend everyone who cares about the web and how we build for it to participate. I think the process of standardization for new features (through the proposals phases to finally landing in browsers) is the effort to raise the floor for all to build on top of. I remember when Promises were landing everywhere and feeling a little overwhelmed by what it meant to me because I was using Bluebird. Then the feeling of "maybe I can simplify what I'm doing and lean more on the platform" set in. Frameworks are a testbed for new ideas, and we can go further by trying to see what pieces we can pull out and standardize around (e.g., Signals proposal [2]), so we can go back to testing new ideas on top of that. [1] https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Declarative-Custom-Elements-Strawman.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... [2] https://github.com/tc39/proposal-signals https://github.com/tc39/proposal-signals

tannhaeuser 2y ago

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.

renegat0x0 2y ago

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?

ramones13 2y ago
There’s a pretty thorough post covering this here - https://infrequently.org/2022/03/cache-and-prizes/ https://infrequently.org/2022/03/cache-and-prizes/

mtn6747 2y ago

[flagged]

toddmorey 2y ago
So just more AI comment spam, huh? It's unfortunately ruining my favorite communities.
- meiraleal 2y ago
  it is only ruining if you decide to see the dead posts and still dislike that spam is being killed.

addicted 2y ago

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.

deleted 2y ago

[deleted]

thomassmith65 2y ago

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.

mattlondon 2y ago
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
- thomassmith65 2y ago
  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.
  - thomassmith65 2y ago
    Note to whoever comes across this comment in future. So I have now explored using HTMLElement as the Controller, its shallow DOM as a data source for its Model class, and its ShadowRoot as a subclass. It is clear to me now that that design would be the most natural fit for MVC. However... it is also impossible. For whatever infuriating reason, they designed custom element's ShadowDOM class to not be subclass-able. You can neither give a ShadowDOM subclass a constructor, nor does HTMLElement reveal any mechanism to 'attach' a ShadowDOM subclass. Fantastic /s

mmcnl 2y ago

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.

drawkbox 2y ago

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/ 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.

wellpast 2y ago

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.

gaganyaan 2y ago

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.

dandrew5 2y ago

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.

commanderkeen08 2y ago
Stencil has a way better DX. Especially if you’re doing a whole library of components. You pay a slightly higher perf tax for their auto loader and light vdom. Lit is the way to go if you have opinions and want no magic

breck 2y ago

We do web components better than the web. We just call them Parsers. Geniuses build for The Scroll first. Retards build Web first. (Don't misinterpret, I love The Web, but The Scroll is on track to be 100x better)

impostervt 2y ago

A few months ago I started a job where I inherited a JS code base that is around 250,000 lines. It was one big class, with several sub classes, that did everything. Some files were 30k lines long. No frameworks, no reactivity. If you click a button, you had to update everything on the screen with event listeners manually. Took the guy years to write it. It's like a monk got locked in a cell for years with a basic book of javascript. I started by refactoring into web components, because I had to do it piecemeal. It's been a big help, and I've cut 50k lines of code so far. But the real point was to just learn everything the old code was doing before I start a rewrite.

Sammi 2y ago
> I started by refactoring into web components, because I had to do it piecemeal. Yes. The key to making an old and arcane code base understandable to yourself, is to refactor one small part of it at a time. That you're redoing with web components is just one way that would achieve this. I applaud you for not just throwing everything it away and starting anew. On risk of this approach is that you get some way though and then move on to some other project, and someone else comes along and inherits the old project and starts refactoring in their own style, and so now you have an old arcane code base in three different styles... it still beats a rewrite of a 250.000 line code base in one go.

jongjong 2y ago

Tech discussions are hard to have nowadays because people are highly biased in favor of their current tech stacks. The religiousness which used to be restricted to programming languages has expanded to include frameworks, databases, test runners, infrastructure, CI tooling, libraries; literally everything is a religion nowadays. It makes almost all technical arguments disingenuous and pointless. Like people arguing about whose religion is more correct. Observable facts don't matter so much. People see arguments in favor of some alternative stacks as a personal attack against their career. It's probably because companies themselves have become so focused on hiring based on these stacks. They have become a matter of livelihood. In the old days, many companies saw software engineering ability as a separate skill; now they barely even use the word 'software engineering.'

hu3 2y ago
Thanks for sharing this view. I relate a lot.

carlual 2y ago

I found a practical way to foster critical thinking skills and encourage independent thought at the end of Netflix's documentary, The Social Dilemma: > I follow people on Twitter that I disagree with because I want to be exposed to different points of view. Here is another good opportunity for it.

mrfinn 2y ago

How can it be possible that we are in 2024 a no one seems to be proposing the most obvious improvement to the web, which is to create a new standard designed for web applications and let the HTML alone serving it's original purpose, which was to serve documents? (H*T*ML the T goes for "TEXT"!). Instead of that, and make things complex and unmanageable to the extreme, to "improve" things now we dropped out completely the MVC philosophy and went completely ahead with an spaghetti mess of Javascript, HTML, CSS, and create-your-desired-tags-at-will everywhere, aka Components. PS. And not even mentioning Madnesscript which deserves another chapter in this story of horror.

openrisk 2y ago
There are probably many reasons. The history of technology development teaches us there are a lot of non-core factors that affect the adoption of alternative designs (influential entities and agendas, network effects, business models of those involved etc.) But there seems to be also an interesting intrinsic reason: The versatility of the digital "Document" paradigm itself. Text in its digital incarnation (a sequence of human readable strings) is not just your usual text. While printed text on a page involves the encoding and annotation of human language sentences you can encode a lot more things in human readable HTML/SVG/XML formats (e.g. numerical data, visual geometries, declarative UI etc.). The HTML family of documents is in this sense a sort of "super text". Its structure reflects already its huge dynamic (rich text) potential. But clearly you cannot solve everything in a declarative manner (though you should probably push it as far as possible). At some point the flexibility of code is important and the question then is what is the optimal way to do this (as in: easy, performant, versatile etc.). Alas at the moment we seem to be almost at the extreme opposite: everything as code. Ideally one would refactor all these declarative formats that have proven their utility and resilience and rethink the role of code / frameworks, taking into account all the developments and learnings of the past decades (web assembly, mobile, pwa etc.).
mixmastamyk 2y ago
It's a herding cats problem. Not practical for new actors to propose one and have it adopted; current principals are no longer trusted. No one else with deep pockets cares enough to donate the resources it would take and/or do the hard coordination work. We don't see viable new Operating Systems either, for example. That leaves minor feature additions as the only way forward.

auggierose 2y ago

Web components are not OK. They are shit. I wouldn't touch them, just as I wouldn't touch shit. If you find React hooks hard to understand, then I really don't need to hear your opinion about anything, including about how web components and HTMX are so great. Just learn programming.

epolanski 2y ago
As someone who uses all of web components, react and Vue, depending on the project I really feel like to give such aggressive and opinionated takes you should consider doing it in a mature and professional way that goes into the "why" you feel like that.
- auggierose 2y ago
  Mature and professional is what gives us shit like web components, and people like you eating it. So, no, thank you.
  - epolanski 2y ago
    Have you considered that there are different tools for different problems and that web components have their own space in the wide array of problems? Because they are a decent fit to a specific set of problems (e.g. authoring components you can embed on different platforms, regardless of the technology they are built with). I myself, as detailed in another comment, have concerns with web components, and having worked with them extensively, I feel they fall short in several aspects (especially regarding layout control, where they aren't isolated enough due to a series of design choices) but it's manageable. A problem that I had in two different companies (embedding a set of elements that had to work in very different applications and required the host to know little to nothing) after much analysis was best solved with web components and they did well at that. The possibility of doing `<script type module>import "yourcomponent.js"</script> <yourcomponent foo="bar"></yourcomponent>` without for us web component authors having to worry about the wide array of different technologies the hosts used (both at compile and runtime) has been in the end the best solution for both us and the consumers. As Ryan Carniato points out, most of the criticism web components get is that their usage is misunderstood, some of their behavior falls short of their goals, and their name conflates then with framework's components creating further confusion, which are something very different. The problem with comments like yours is that they add nothing of value to the discussion. We don't know if, when and where did you try to use web components, what hasn't worked for you and why, or if you've ever had the kind of problems where web components would've been a good fit or not. You end up giving the hopefully wrong impression of an obtuse person lacking the engineering sensibility to understand the context of problems and of their possible solutions.

shortrounddev2 2y ago

I wish web components had a bit more to them 1. I wish you could reliably parse their attributes in the constructor instead of connectedCallback, so that they play better with typescript readonly properties 2. I wish I could declare properties in the class and have them automatically map to an attribute 3. I wish I could construct them using html instead of manipulating domnodes manylually 4. I wish I could construct child nodes first so that I can compose webcomponents with other webcomponents As it stands webcomponents provide the ability to construct a single element at a somewhat predictable moment in time, automatically. That's cool, but their interface is lackluster to me

wordofx 2y ago

> From my own personal experience: at Salesforce lol