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

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

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

[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).

[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