Hacker News Reader

Comment by TAKEMYMONEY | Hacker News Reader

> Was this slightly more work than using a library from npm?

> I'd definitely recommend using a library for this, and we settled on lit-html (link to library from npm)

This article is mostly about switching from React to Lit. You can use modern web APIs (like FormData) with React, FormData's not a replacement for state management.

You can use Web Components with React, the way Fluent UI does (https://docs.microsoft.com/en-us/fluent-ui/web-components/in...).

In this single case they replaced a couple validation functions with attributes. Good to move that direction but if that's all you use React for then yeah, you might not miss it much.

View on HN

Anyone know what is going on with lit-? Their TypeScript starter is painfully bloated and outdated and never seems to keep pace. I actually ended up looking at microsoft/fast for my use case but that seems to be stale in some way.

I kind of feel that given the "simplicity" of a single class wrapping custom elements, everything is pretty boring.

Note: I cannot do better.

Can't speak for the Lit framework, but never had any issues with lit-html or it's typescript defs, it's been rock solid.

I'm in the same boat.

I don't use lit-element, it's too heavy for me.

lit-html, on the other hand, is wonderful and rock solid.

I typically do light dom components, rendered with lit-html. Simple classes that extend HTMLElement.

When I want reactive style, I add setters that call render(). When I want imperative, I add class functions.

All my components generally take care of themselves and are mostly encapsulated, they'll generally have a init() method that loads the data they need, and calls a setter which kicks off the render cycle.

Alternately, data will be passed from a parent component via a property, and that'll also kick off the render cycle.

In many cases I do a combination of the two in order to support deep linking.

I'll mix and match design systems sometimes, depending on the payload weight. Ionic, shoelace, etc...

The Vaadin router ties everything together beautifully.

I also have a small state utility called ApplicationState[1] that I use for the edge case of cross-component communication and triggering. It provides a graph-based approach to notifications/state change.

I've been using this approach for several years with success, with deeply complex and large applications and small lightweight tiny footprint apps.

[1] https://claytongulick.github.io/applicationstate/

I feel like google does web component frameworks like it does messaging apps. Each new one is the silver bullet. I wouldn't build on any google web framework personally, even if it claims to be oh so simple and lightweight.

Mirrors my experience exactly. Used polymer, angular, react and lit element. I’ve been able to rely on react for almost a decade. The others have just been mistakes

You don't understand the context since Polymer and Lit Element do not solve the same problem space as Angular and React aim to solve.

This is very small thinking. The context is to produce value for a user on a web platform. I’m well aware of the APIs and limitations for each of these.

npm init @open-wc is a really nice starting point for Lit also mentioned here https://lit.dev/docs/tools/starter-kits/

I use Lit and have a tiny bit of MS/FAST in one project. You're right. Neither site gets updated. I think both have terrible doc, really. I didn't learn anything from the Lit starter or the intro doc. Only the interactive tutorial was of any use.

I think FAST is dead because MS doesn't want to play keep-up with it. In fact, all of the component libraries that Lit advertises on their home page (https://lit.dev) seem be Thanksgiving leftovers put out on a buffet. No one is seriously updating a set of web components for public use.

But... perhaps that is because Lit isn't really great for making components for others? It doesn't get you out of the work of documenting them, for example, which is already done with canned component libraries. It certainly puts all the fixes back on you.

In my experience, Lit is terrific for green sheet projects and ones where you can keep everything in-house. But there is no "Lit community" or resources for people getting into it who want a jump start. And no great tutorial doc.

Unsurprisingly, you don't see Lit discussed too much anywhere!

> This article is mostly about switching from React to Lit.

I'll freely admit I'm a backend guy and don't know much about JavaScript frameworks, but the author emphasizes they didn't use Lit, just lit-html, and for the same reasons they didn't use React.

Is lit-html really such a huge portion of Lit that you disagree with their own assessment of what they've done?

They combine lit-html with a "basic scheduler" that they've written themselves. I'm guessing that's intended as a replacement for React, but it could easily be seen as a replacement for Lit, which offers "reactive properties" too.

I think how they gloss over the "we'll just write a library to handle component rendering, lifecycle and state" portion as a "basic scheduler" is a bit disingenuous. The author even mentions they are essentially recreating some features of React, but felt it was worth the tradeoff.

There is no doubt that, when using Lit, you're going to re-write portions of some existing framework. That's the big selling point: You're going to write them your way, and only the ones you need. Instead of inheriting and learning React (or Angular, or Vue), you decide what syntax and behavior your components will have -- all the way down to "bare metal" of when and if they render and with what contents or results. None of this is specified by Lit so you will be re-writing those pre-fab aspects of any canned framework.

You'll also be writing any kind of routing or other validation tools that you need. Which is actually glorious! You get to make one that's small and easy to keep in your own head, yet flexible enough to be extended and expanded in any way that you can imagine.

There isn't a React component that would have helped me build this game[0], other than very basic stuff like buttons. But with Lit, I could write components all they way down to SVG graphical elements and create all kinds of new behaviors that React doesn't understand.

[0] https://hexxedgame.com (100% Lit/TS)

> create all kinds of new behaviors that React doesn't understand

Care to expand? (I'm working on SVG-as-React-component stuff.)

Sure! What I mean is that, since the web components are bare metal, they can be very specific to my game. I have SVG components that return graphics, change colors, move themselves around, etc. based on properties and state in the app. Because they aren't based on canned components, I don't have to worry about shoehorning what I want into a React component that's really made for something like text or a dropdown, etc.

Reply on news.ycombinator.com