by keybits on 9/29/24, 11:57 AM with 356 comments
by jeswin on 9/29/24, 2:00 PM
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
by apitman on 9/29/24, 2:37 PM
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].
by mentalgear on 9/29/24, 12:59 PM
by MrThoughtful on 9/29/24, 1:33 PM
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?
by lapcat on 9/29/24, 1:38 PM
And the browser vendors aren't in a hurry to remedy this situation.
by claytongulick on 9/29/24, 2:01 PM
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".
by webdevladder on 9/29/24, 1:27 PM
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.
by burcs on 9/29/24, 12:47 PM
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
by impostervt on 9/29/24, 11:45 PM
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.
by veggieroll on 9/29/24, 1:47 PM
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.
by superkuh on 9/29/24, 1:38 PM
by mmcnl on 9/29/24, 4:33 PM
by mrfinn on 9/30/24, 8:22 AM
PS. And not even mentioning Madnesscript which deserves another chapter in this story of horror.
by gaganyaan on 9/29/24, 6:19 PM
by addicted on 9/29/24, 3:01 PM
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.
by drawkbox on 9/29/24, 4:56 PM
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.
by skrebbel on 9/29/24, 1:25 PM
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!
by tannhaeuser on 9/29/24, 2:40 PM
> 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.
by tomrod on 9/29/24, 12:47 PM
by thomassmith65 on 9/29/24, 3:50 PM
(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.
by PaulHoule on 9/29/24, 1:41 PM
by shortrounddev2 on 9/30/24, 1:15 PM
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
by dandrew5 on 9/29/24, 6:34 PM
by newhotelowner on 9/29/24, 1:29 PM
*Supports "Autonomous custom elements" but not "Customized built-in elements"
by carlual on 9/30/24, 4:04 AM
> 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.
by wellpast on 9/29/24, 5:31 PM
by jongjong on 9/30/24, 12:04 AM
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.'
by renegat0x0 on 9/29/24, 2:45 PM
by wordofx on 9/30/24, 6:30 PM
lol
by breck on 9/29/24, 10:12 PM
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)
by auggierose on 9/30/24, 9:10 AM
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.