Hacker News Reader

Comment by StevePerkins | Hacker News Reader

I'm a backend developer, so pardon my ignorance. I'm reading here that this basically a thin wrapper on top of the Web Components standards, which I've been reading about for nearly 15 years now. So this makes me wonder... why does basically no one ever write directly to the Web Components standard?

There are really only two major web browser engines left in existence (three if you are extremely generous and still include Firefox). Are there really enough differences in Chrome and Safari's implementation of Web Components to still require a polyfill after all these years?

The original polyfill was Polymer, and I believe that both it and this Lit library are both Google projects. If so, then what is the delta between the two? It looks like Polymer is now in maintenance mode, so clearly Lit is the successor. But are there fundamental changes beyond a branding refresh?

View on HN

Probably just due the network effect of React coming to the scene first, and the cost of change.

I've used Web Components nearly exclusively at multiple jobs for 7 years now, so my experience is that they are out there and in use.

Had to start using React recently for a job and it feels like a mess in comparison. Too many ways to do things, big black box components that are hard to introspect, compilation is not optional, and poor documentation on some aspects due to not using standards. I'm still struggling to understand "stale closures" and the react component life cycle. It seems to have a lot of baggage.

Speaking as a front end developer with 4 years experience using Lit -

It’s like using jQuery in the mid 2000s - it’s not like it allows you to do anything you couldn’t normally with vanilla JavaScript, it just provides some shortcuts for common scenarios. The process of defining the class that controls a custom html element is a bit of a slog in vanilla JS - in Lit, especially with Typescript decorators in play, it’s a breeze. It saves time and helps keep things fairly DRY.

I should think the dream is that Lit, like jQuery, will slowly get absorbed into the web components spec itself, until all the things you used to need to reach for a library to do efficiently - will simply be a part of the vanilla language itself. Like jQuery’s css selector functionality has now been superseded by JS’s querySelector.

This is definitely the dream of the Lit team, that Lit itself gets smaller and smaller as the platform gets more capable. For example, the DOM Parts proposed spec would let us drop a lot of the most complicated code in lit-html.

Lit is not a polyfill, it's an easier way to write Web Components without writing DOM manipulations manually.

Building on top of the Web Components standards, Lit adds just what you need to be happy and productive: reactivity, declarative templates and a handful of thoughtful features to reduce boilerplate and make your job easier.

This in itself is why web components have had such a hard time actually taking off as a viable platform to build on. You need some other library to handle the things you actually need to accomplish.

That's how open standards work. Create a common ground so every tool built on top of it can be integrated. So Lit integrates with other web components frameworks. Imagine if React, Vue and Angular could be integrated? That's the change that Web Components brings. And currently Lit is a great choice to create components that can be integrated with those frameworks.

Vue allows Lit components

All of them allow Lit components. Almost all frameworks support them, because they are just standard web components underneath. The only way they wouldn't work is if the framework did something actively stupid to break web components.

Aka React.

> why does basically no one ever write directly to the Web Components standard?

Web components provide a life cycle (mounted, unmounted, attribute changed) and an encapsulation mechanism; but they aren't reactive. They don't rerender when you change an attribute or a property. They don't have a concept of local state, whose changes would result in a rerender. Html templates don't have a convenient syntax for binding properties or events. Lit adds all this convenience, with very little code. The result is that the web components that it produces remain standard and interoperable, but are also much more pleasant to author than plain components.

Web Components solved problems that the Dojo and YUI frameworks had in 2004, ignoring the fact that nobody even remembers what they were.

People designing WC think vdom is a pointless overhead, and React is a fad that will have to switch to Web Components eventually.

I'm not sure what you're talking about, but DOM rendering systems aren't really part of the web components suite of standards right now. That's left to userland and there are a few web components libraries that do use VDOM for rendering.

Now, as a Lit maintainer I do think that VDOM is a lot of unnecessary overhead, and the benchmarks show that, but rendering libraries and web components are orthogonal things.

Given that React is the only frontend technology that refuses to support WC, they will eventually have to.

Imagine if a big OS vendor like Apple decided that people were not "using the platform" correctly by building on top of third-party database libraries instead of using the filesystem directly.

So they introduced "File System Tables" which was their vendor-blessed replacement for databases, but it did a bunch of things really differently from SQL databases for no clear reason, and forced you to think about things like file locking and write durability that you were actually pretty happy to let a DBMS take care of for you.

Web components are just a natural fit for the web platform, which has grown into a general GUI platform and deserves a built-in component model. No other GUI platforms lack a standard way of building components.

The "standard" GUI solutions on platforms like Windows, are also being abandoned in favor of React.

Reply on news.ycombinator.com