[balloob]

Home Assistant [1] has been written using web components and it has been great. In 13 years that we've been around, we never had to do a full rewrite of the frontend but always have been able to gradually update components as needed. Not being tied to the JavaScript industry upgrade cycle (which is short!), has allowed us to pick our own priorities.

We currently use Lit for the framework on top (you do need one, that's fine). For state management we just pass props around, works great and allows community to easily develop custom cards that can plug into our frontend.

The downside is lack of available components. Although we're not tied to a single framework, and can pick any web component framework, the choices are somewhat limited. We're currently on material components and migrating some to Shoelace.

I talked more about our approach to frontend last year at the Syntax podcast[2].

[1] https://www.home-assistant.io [2] https://syntax.fm/show/880/creator-of-home-assistant-web-com...

[catskull]

I've written quite a few web components that were more or less standalone. I've looked at lit quite a bit but never fully understood the "why". Could someone share their own personal experience with why they needed lit? What does it offer that can't be done with standard spec web components?

For me, a big draw of web components is that there's no `npm install` needed. I prefer to ship my components as plain JS files that can either be hot linked from a CDN or downloaded and served locally. Call me paranoid but I just don't fully trust node modules to be clean of bloat and spyware and I just don't want to have to regularly deal with updating them. I'd prefer to download a web component's static JS file a single time, read through it, and forget it. Maybe down the line I might revisit the source for the component as part of standard maintenance.

For example, I made a simple like button component[1]. Later, my friend made a cool component for showing a burst of emoji confetti[2]. I decided to optionally pull it in if an attribute was set on the like component. I downloaded his source and hosted from my own domain. However, there was actually a bug in his code that caused the confetti to "rain" if you spammed the like button a few times quickly. He fixed that, but I actually kind of liked it so I just didn't update the source for the confetti component.

[1]: https://catskull.net/likes [2]: https://github.com/samwarnick/confetti-drop

[troupo]

> I've looked at lit quite a bit but never fully understood the "why".

Because people don't want to write hundreds of lines of useless boilerplate by hand.

Web Components API is verbose enough that you want to handle it with at least some abstraction. And at one point it was explicitly marketed as aimed at library/framework developers.

[zackify]

The cycle isn't short like people continue to say each year. I use react since 2014 and it hasn't changed much in 6-7 years.

I just built a script tag based reusable library for our company with react as the only dependency and thanks to stuff like shadow Dom and dialogs I get a much higher quality dev experience than plain js.

[afavour]

Best practises have changed dramatically in React since 2014 though. It’s easy to say “oh you don’t have to use hooks, you can keep using class components” but that’s not really true when the entire ecosystem is pivoting.

My bigger problem with React is that it ends up being used as a form of vendor lock in. Once your entire page is in the React VDOM it’s very, very difficult to pivot to a different framework piece by piece. That’s a core strength of web components.

[sheept]

Class components still work, and you can still use function components with hooks inside class components and vice versa.

In the parent comment's case of not having other dependencies, whatever the React ecosystem does isn't relevant if you aren't using any React libraries, which aren't really necessary anyways, especially nowadays when the LLM can reimplement what you need for you.

Nothing has changed about react-dom that prevents you from using React piece by piece—its docs still recommend attaching to a #root node even for single page apps.

Including web components in a React app is very seamless, and embedding non-React-controlled elements inside React is not uncommon (e.g. canvas, Monaco, maps), though for common use cases there's usually convenience libraries for React that wrap around these.

[hliyan]

I think React originally started with the opposite intent: a library where you can mount a component onto selected elements of the web page. The lock in only happened when React was used to develop SPAs, which effectively meant that React takes over the document root. With that came state management, and frameworks that managed the complexity of state were not far behind.

[mickeyp]

Indeed. I've gradually adapted a server rendered jquery and HTML site to react by making react render a component here and there in react and gradually convert the site. Works great.

[harrall]

React state management has changed a lot.

React DOM/views have not significantly changed in 12 years.

Our 10 year React projects that used mobx have not changed very much.

Savage take: I found React when it came out and I thought “wow you made this gorgeous DOM library and then you bolted on this messy ugly wart for state.” Then hooks came out and I’m like… this is a good electrician pretending they can also do plumbing.

[colordrops]

it's also impossible to look at the DOM and figure out what the hell is going on with React.

[llbbdd]

React has excellent dev tools of its own that cover this.

[colordrops]

I have those dev tools installed. I wouldn't call them "excellent".

[llbbdd]

Agreed I might have gone too far with "excellent". :) I think they do a good job though at operating at the level of abstraction React lives at, which generally requires less detail to live in the DOM (e.g. ids/classes used only for JS bindings compared to classic jQuery soup).

[socalgal2]

I have react projects from less than 6-7 years ago that are bit-rotted because of changes to react. I have wanted to add features but can't because I don't have the time to fix everything that rotted.

To be clear, it's not 100% react. It's the entire ecosystem around it. Want to take wigdet-x v3 for bug fixes. It requires newer react, which may or may not be compatible with widget-z I'm using. Newer react requires newer tools which aren't compatible with the configuration that was created by create-react-app from 2 versions ago. etc...

[nextaccountic]

> I have react projects from less than 6-7 years ago that are bit-rotted because of changes to react. I have wanted to add features but can't because I don't have the time to fix everything that rotted.

That's what AI is for. It makes previously unfeasible projects feasible again

[socalgal2]

I thought so too but it failed for me. Maybe I'll try again

[jshen]

What model did you use? Curious if something like Opus 4.6 does a better job.

[megaman821]

Exactly what are you using in React land that has lasted for 6-7 years. No components to hooks transition? No styling library changes? No state management changes? No meta framework changes? The React ecosystem is the least stable thing I have ever worked with.

[nayroclade]

Hooks were introduced in 2019. so, seven years ago.

[megaman821]

Even only looking at React provided hooks, they added a lot over years and best practices around things like useEffect have changed a lot.

If you have a complex app from 2019 that you haven't updated, it is virtually guaranteed that it has memory leaks and bugs.

[c-hendricks]

I don't really agree that "best practices around useEffect have changed a lot". It's more that that particular hook was used a lot when it didn't need to be so the team finally wrote some guidelines.

[zackify]

yeah same... i have always tried to useState and minimal effects, those have not really changed in 7 years

[shafyy]

Hey, cool to see you here on HN. I was recently looking through your codebase to see how you handle automations. It looks like you are relying on asyncio? I was wondering how you came to this decision and if you ever considered alternatives like a APScheduler or any other job library?

[gitaarik]

For state management, you might be interested in looking at Lit State. It's a very lightweight state management lib written specially for Lit, with the same mindset. With it you won't have to pass props everywhere all the time.

https://github.com/gitaarik/lit-state

[troupo]

> Not being tied to the JavaScript industry upgrade cycle (which is short!),

> We currently use Lit for the framework on top

These two are contradictory statements.

1. lit is both newer than React, and started as a fully backwards incompatible alternative to Polymer

2. Despite being acrively promoted as "not a framework just a lib" it's rapidly sucking in all the features from "fast moving js": from custom proprietary syntax incompatible with anything to contexts, a compiler, "rules of hooks" (aka custom per-dieective rules) etc.

> We're currently on material components and migrating some to Shoelace.

Again, this is exactly the "fast js churn" you're talking about.

[spankalee]

Lit is fully compatible with Polymer (and any other web components).

[troupo]

The output of lit is.

Not lit.

Stop pretending this isn't the case

[spankalee]

I can't even tell what you're arguing.

Lit helps you write web components.

Those web components are interoperable with other web components made with Polymer, Stencil, FAST, etc...

[bflesch]

> Home Assistant [1] has been written using web components and it has been great.

That could explain why the percentage slider is not showing a current value tooltip when sliding it :P