Hands down the most underrated front end library out there. It powers some major projects like ChromeOS, Chrome Devtools, I think most of Firefox’s UI, Photoshop for the web, MDN etc.
Lit: a library for building fast, lightweight web components
61–70 of 180 posts
Re: Lit: a library for building fast, lightweight web components
#62Re: Lit: a library for building fast, lightweight web components
#63I'm all for a lightweight approach to software development. But I don't understand the concept here. Looking at the first example: First I had to switch it from TS to JS. As I don't consider something that needs compilation before it runs to be lightweight. Then, the first line is: import {html, css, LitElement} from 'lit'; What is this? This is not a valid import. At least not in the browser. Is the example somethin…
https://unpkg.com/lit@3.3.1/index.js?module
You can even dynamically import that in the a running browser console and use it directly on any webpage.
Re: Lit: a library for building fast, lightweight web components
#64Lit maintainer here. I should be going to bed, but I'll answer any questions if people have any! Not sure why Lit showed up on the front page tonight :)
Sometimes, I am wondering why it is not more widely used ...
Re: Lit: a library for building fast, lightweight web components
#65For the frontend work that I did, Lit was a godsend. It really helps you build components and apps without getting in the way. In comparison, Angular is a monster, and React is designed for the old browser capabilities, and is now staying around by inertia, not by inherent quality.
That’s also why I really like Aurelia framework. Its component model feels very intuitive, and it embraces standards like custom elements and decorators instead of inventing new patterns. Compared to Angular’s boilerplate or React’s hook gymnastics, Aurelia lets you write less code that looks more like plain JS/HTML. Too bad Aurelia never got the same traction as the big frontend names, because the DX is really solid…
Its .html temples were shipped unmodified directly to the client (yes, including comments). Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template.
Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch for mutations). It would frequently resort to polling on every tick or break completely.
DI used TypeScripts experimental decorators, even long after it was clear that it would never become stable.
On the other hand, templates weren't type checked.
Re: Lit: a library for building fast, lightweight web components
#66I'm all for a lightweight approach to software development. But I don't understand the concept here. Looking at the first example: First I had to switch it from TS to JS. As I don't consider something that needs compilation before it runs to be lightweight. Then, the first line is: import {html, css, LitElement} from 'lit'; What is this? This is not a valid import. At least not in the browser. Is the example somethin…
I guess for most people the standard is to install things from NPM which explains the format of the documentation. If you want to do something completely raw, you can replace 'lit' with something like this: https://unpkg.com/lit@3.3.1/index.js?module You can even dynamically import that in the a running browser console and use it directly on any webpage.
Re: Lit: a library for building fast, lightweight web components
#67Earlier quoted context omitted.
Curious which web platform features are missing that are preventing Web components to complete with React(for application development not widgets)?
I think web components already compete extremely well for application development, and you see very complex apps built with Lit out there: Photoshop, Firefox, Chrome OS, Chrome DevTools. Apps are well served because they have more control about how components are used: they can import the same shared styles into every component, take are to not double-register elements, etc. But I think there are some important stand…
What people using web components want is to get rid of shadowDOM and not feel like they are deviating from the correct path. shadowDOM sucks, stop trying to convince the world that we are using it wrong. shadowDOM is the whole reason web components did not become mainstream (yet?).
Re: Lit: a library for building fast, lightweight web components
#68For the frontend work that I did, Lit was a godsend. It really helps you build components and apps without getting in the way. In comparison, Angular is a monster, and React is designed for the old browser capabilities, and is now staying around by inertia, not by inherent quality.
"React is designed for the old browser capabilities and is now staying around by inertia, not by inherent quality." this makes me feel old and I guess React is famous for supporting Internet Explorer /s
Re: Lit: a library for building fast, lightweight web components
#69Earlier quoted context omitted.
Any whispers of something like lit being made part of the webcomponents standard? Web components are nice because they're browser-native, but they don't support reactivity, which in hindisight, is a massive oversight, issue, whatever you want to call it - it's hindered adoption. Lit is nice because there's a very straightforward progression from web components.
Lit has always been designed partially as a prototype for where web component standards could go in the future. That's a big reason Lit is fairly conservative and un-opinionated. It doesn't try to undo or paper-over any of the DOM APIs, but add to them instead. There is a proposal in TC39 for native signals, which I think would make a huge dent towards library-less reactivity. I'm also working on a proposal for nativ…
Re: Lit: a library for building fast, lightweight web components
#70I have been using Lit in production for 3 years now. I think it is the best abstraction over the web components API out there.
Same here. I have actually wrote a few web components by hand in an environment where I didn't want any external dependencies and when that requirement was dropped I really liked how easy was to convert them to LitElement (and how much nicer it is to work with them). I also have embraced the shadow DOM which is a default, but I think it's more trouble than it's worth. Now I use LitElement without shadow DOM and it wo…