[HN Gopher] Lit: Simple, fast web components
___________________________________________________________________
Lit: Simple, fast web components
Author : tambourine_man
Score : 67 points
Date : 2023-07-20 21:05 UTC (1 hours ago)
(HTM) web link (lit.dev)
(TXT) w3m dump (lit.dev)
| downvotetruth wrote:
| Defaulting to v2 instead of v3 for the documentation selector in
| the upper right seems odd, especially considering the extent of
| the changes.
| aranw wrote:
| v3 appears to be pre-release version? Surely that makes sense
| to not default to pre-release code for the docs?
| downvotetruth wrote:
| The upgrade is claimed to be seamless when running Lit 2.x
| with no deprecation warnings; defaulting to deprecated API
| documentation is a bit counterproductive.
| spankalee wrote:
| v2 documentation is not deprecated. v3 isn't released yet.
| downvotetruth wrote:
| If v3 is "not released" then having it accessible with
| the other 2 releases is contradictory - this "prerelease"
| is still a form of release; no claim was made that the
| entirety of the v2 documentation was deprecated.
| donmcronald wrote:
| Does anyone know if the social icons on that site are from a set
| somewhere?
| hbcondo714 wrote:
| One scenario for using Lit is with a PWA; it comes pre-built with
| Microsoft-founded PWABuilder's starter kit:
|
| https://docs.pwabuilder.com/#/starter/adding-content?id=addi...
| formerly_proven wrote:
| > Tiny footprint, instant updates
|
| I can see that, the website re-renders only three times on load
| (text - image - fonts).
| samwillis wrote:
| Lit looks really good, I keep trying to find an opportunity to
| try it out. I feel like web components and the tooling around
| them has finally got there. Major front end frameworks like
| React, Vue and Svelt finally also have good support for them.
|
| What I really want is a good set of _unstyled_ web components
| implementing many of the common UI controls that we all end up
| either building ourselves or finding an implementation of in our
| framework of choice. Things like drop down menus, select boxes,
| and tool bars. They could then be used with any of the common
| front end toolkits.
| sublinear wrote:
| At my workplace we only ever used it once to build a skinnable
| white label customer support widget for about a dozen of our
| client's websites.
|
| It's a webcomponent that gracefully degrades to es5 + polyfills
| for IE (this was years ago).
|
| Getting the rollup build to work correctly was a bitch and a
| half, but it turned out nice and it's still in use today.
| psygn89 wrote:
| Agreed. I get excited to see "headless components" until I read
| the fine print that it's locked into framework x (usually
| React). I wish there was a robust headless AND framework-
| agnostic component library (preferably relying on Lit or
| Stencil).
| samwillis wrote:
| Think thing is that Ionic have proven this can work with the
| massively underrated Ionic Framework (built with Stencil,
| which they also built). I just wish they expanded a little
| further into desktop UI components and provided an no/low
| styled variant - I dislike Material as a base style, it's too
| opinionated.
|
| They are 50% of the way to building a universal mobile+
| desktop ui toolkit.
|
| Do the same with Ionic Capacitor, make a desktop version, and
| that would be an incredible improvement over Electron - it
| uses the OS supplied web view.
| commanderkeen08 wrote:
| Nobody wants Shadow DOM though. Using ::part is always clunky
| and we're all lying to ourselves when we say "oh no that's
| the feature".
|
| The whole shadcn/tailwind philosophy of having you own your
| components is the future.
| jakelazaroff wrote:
| Wait, but that _is_ the feature. My issue with Shadow DOM
| is that "base" styles (like fonts and colors applied to
| tag selectors) don't come through, not that I can't
| override any given style from outside.
|
| I'm not really sure what you mean by "own your own
| components"?
| johne20 wrote:
| You don't need to use Shadow DOM though?
| e111077 wrote:
| unstyled web components: look into ING Lion Web Components
| (Lit-based) or @generic-components/components (vanilla)
| UnixSchizoid wrote:
| Sounds pretty lit, Edit:Dang you guys really hated that
| atarian wrote:
| I think web components were almost a good "built-in" way of doing
| React/Vue. Where it lost me was the Shadow DOM. I get that it's
| supposed to encapsulate the contents of a component and restrict
| JS/CSS to itself, but it's overkill IMO. It's basically like
| having a bunch of iframes and makes it much harder to query
| things, which is very much unlike the rest of the DOM. I don't
| need guard rails to tell me how to do encapsulation.
| benno128 wrote:
| I think framing it this way can lead to real gripes with the
| interface. Web Components are a great way to build _individual_
| components that can be reused across an app, website, or shared
| as part of a library. They are like helper functions for HTML.
|
| They don't work as well for building apps, sure you can do it,
| but tools like React/Vue/Svelte are much better at building a
| whole app experience. Particularly when you consider meta-
| frameworks and the ecosystem around them.
| acedTrex wrote:
| poorly designed web components are so painful because of that
| e111077 wrote:
| Yeah, this is not an issue for very well-designed WCs like
| https://shoelace.style or in cases where it's not necessary
| like https://modelviewer.dev/
| spankalee wrote:
| Encapsulation might be overkill for a single developer, but it
| very much matters for teams and using third-party components.
|
| If you want to drop in a calendar component into your page from
| npm, it helps if that component's styles don't leak into the
| page, and if page scripts don't accidentally mess with
| component internals.
| lcnPylGDnU4H9OF wrote:
| > makes it much harder to query things
|
| This seems overstated. It's different but not really harder.
| document.querySelector('my-lit-element').elementIWant
| class MyLitElement extends Lit { get elementIWant() {
| return this.renderRoot.querySelector(...); } }
|
| Though, maybe one doesn't like querying twice. I'm not sure of
| performance implications there, to be honest, but I'd expect it
| to be negligible in most cases.
| no_wizard wrote:
| I've used Lit. For what it is, its pretty decent.
|
| One of my complaints with Lit and others[0] is they're most
| definitely becoming something of an "Angular Lite". Heavy on
| decorators if you want developer ergonomics, but yet they embrace
| none of the advanced toolchain things you get with angular-cli.
| Due to this, it can feel very clunky to build apps using web
| component frameworks like this. The community as a whole seems
| very anti-tooling and I think its to the long term detriment of
| the ecosystem.
|
| The only exception is Stencil[1] that I can find.
|
| They're also missing first class concerns you get handled with
| other frameworks, like SSR, compiled templates etc. There's no
| web component equivalent to Next.js that I am aware of.
|
| I don't like using them for design systems. You bail on your
| framework of choice rendering model, and that's problematic to
| me.
|
| [0]: https://www.fast.design/
|
| [1]: https://stenciljs.com/
| spankalee wrote:
| Lit doesn't require decorators, and if you do use them they
| only require a pretty standard TypeScript or Babel compile.
|
| Are decorators the only thing making Lit like Angular? Angular
| is not the only project that uses decorators, and decorators
| are standardized in JS now.
|
| Stencil is good, but requires a compiler where Lit doesn't.
|
| What tooling are you looking for? We have template type
| checkers and eslint plugins. Starter kits. Prettier works for
| formatting...
|
| https://lit.dev/docs/tools/development/
| no_wizard wrote:
| I am aware you don't need decorators, this isn't what I was
| saying. I said its the only way to use Lit with any measure
| of good developer experience.
|
| Decorators are not the only thing that make it like Angular.
| The way templates work, template helpers (directives),
| controllers are all very Angular like in practice.
|
| Tooling is much more than linters, eslint plugins and starter
| kits.
|
| Unit & e2e testing helpers, build tools, HMR / dev server
| support. These all matter too and its important that they
| keep up to date with expectations of developers in what they
| expect out of these experiences. Even better when it is all
| rolled up in a nice CLI interface.
|
| Not to mention it would be nice to have optimized convenience
| features, like Vue style SFCs for authoring components and
| templates.
|
| Stencil requiring a compiler is not a negative. It makes it
| an end to end solution and thats very popular for a reason
| (Next.js, Nuxt, Sveltekit are all very popular for a reason).
|
| I believe strongly that projects need to provide these things
| as 1 party concerns. I think the Vue community is proof
| positive of how strong this can be for the ecosystem.
|
| I'm certain between Google, Microsoft, Ionic, and many others
| there could be real solutions for all this. After all, the
| biggest advantage of using web components is they are a
| shared interface
| yesimahuman wrote:
| Stencil does have SSR but requires compatible framework tooling
| https://stenciljs.com/docs/hydrate-app
| no_wizard wrote:
| Thats why i called it out as an exception to what I've seen
| otherwise
| andrewstuart wrote:
| I took an interest in Lit at one point and I gave up when I
| discovered that its core functionality is ungoogleable.
|
| At the heart of Lit are components named "html" and "css".
|
| Confusion reigns, search engines cower, beginners try to grasp
| the conceptual different between html and actual html and css and
| actual css. You'd think the authors would have gone to the
| trouble of naming those critical components something like
| lithtml and litcss to give them a little searchability and to
| deconfuse them, but it seems not.
| colordrops wrote:
| Lit doesn't use any special dialect of HTML or CSS. It's just
| HTML and CSS.
| [deleted]
| ssss11 wrote:
| I think they're referring to Lit naming components 'html' and
| 'css' - if you go to the tech docs here the very first
| example imports 'html' and 'css'.
|
| https://lit.dev/docs/components/overview/
|
| I agree that those are odd choices and the arguments provided
| seem reasonable I.e. they're likely ungoogleable, and
| beginners would be confused.
| [deleted]
| spankalee wrote:
| In Lit `html` and `css` are template tags, not components.
|
| Those names are well supported by editors and enable syntax
| highlighting. If we named them anything else it wouldn't
| work without extras tools.
| andrewstuart wrote:
| The fact that you are explaining this to me reinforces my
| point.
|
| One of my primary criteria in choosing a technology to
| work with its how accessible is community support,
| documentation, third party articles and writing.
|
| It had better be a compelling technology that names its
| main things exactly the same as the biggest concepts in
| web development, thereby making it a battle to resolve
| questions and issues and adding unnecessary confusion.
|
| I do use a nodejs library called "Postgres" which
| provides a Postgres SQL driver but I really hate the fact
| that searching for documentation/issues is essentially
| impossible. I use it because I feel I had no choice, it's
| the best possible technical solution.
|
| Names matter.
|
| Searchability matters a huge amount.
| hmcdona1 wrote:
| So your gripe is essentially you don't like reading the
| documentation of the libraries you use, just, in general?
|
| Template literals are just a feature of javascript, it's
| not even anything that bespoke. That's why it's called
| "lit". The output of those tag functions are just
| rendered with standard DOM features too.
|
| https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| [deleted]
| mirekrusin wrote:
| It's like complaining that sql library has tagged
| template function called sql - of course it will and it
| makes perfect sense.
| jonny_eh wrote:
| Surely just adding "lit" to your query helps narrow down the
| search.
| [deleted]
| bobmaxup wrote:
| https://github.com/lit/lit/tree/main/packages/lit-html
| benno128 wrote:
| I've been using lit in side projects (e.g. runno.dev) and really
| enjoyed it. Just like any framework it can be a bit confusing
| learning the primitives but I've found it as productive as React,
| Vue or Svelte.
|
| The thing I like most about lit is that it embraces web
| standards. Sometimes that means the ergonomics are a bit strange.
| But it also means it gets performance benefits, and
| interoperability bonuses. Plus it feels like you're learning
| something about the underlying platform while you're using it.
|
| The best example is that it uses reactive data binding via
| attributes for passing data down the tree, and native DOM events
| for passing data up the tree. That allows you all the same safety
| that a framework like React offers, but also means your component
| can be used by any other framework, or by vanilla JS (because
| they all support the DOM).
| imadj wrote:
| Seems like it lacks support for SSR? I'm wondering if it's ready
| or make sense to replace web framworks or what is its optimal use
| case
| superkuh wrote:
| There's nothing simple about custom-html element defined by
| javascript. It may be "Interoperable & future-ready" but it sure
| isn't interoptible with pretty much everything from 1995 to 2019.
| benno128 wrote:
| This is just plain wrong. Web Components work in every browser
| that matters. They are standard DOM elements and can be written
| in plain HTML server-side or via legacy front-end libraries.
|
| I'm using web components in production to help interoperability
| between 2012 era Handlebars/jQuery/Backbone and modern tools
| like React and Prosemirror.
| djbusby wrote:
| I was looking for comparison and found this post
|
| https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co...
|
| Which puts 61 of web-component libraries side-by-side. Sadly my
| favorite, RiotJS, is not on the list.
| dsissitka wrote:
| > Sadly my favorite, RiotJS, is not on the list.
|
| Looks like it might be in the "Wrapped into a custom-element"
| category.
| superchris wrote:
| Been using Lit for a few years now, it just keeps getting better.
| It does what it does, and stays out the way. Please don't call it
| a framework though, the best part of Lit is that is basically
| some (very lovely!) sugar over standards built into your browser.
| And as browsers keep improving (at an amazing pace IMO) Lit keeps
| getting smaller, which might be my favorite thing about it.
| spankalee wrote:
| Maintainer of Lit here!
|
| A few of the unique things I try to emphasize when talking about
| Lit because it's so different from a framework:
|
| Lit is just helpers to make web components. It's implementation
| detail. On the outside the components are just standard HTML
| elements.
|
| Because of that, Lit makes no assumption that other elements
| you're using in your components are made with Lit. This low
| coupling preserves interop, and makes it easy to incrementally
| adopt Lit, and incrementally leave it if you wish. Low lock-in is
| an important principle for us.
|
| Because of the low coupling, Lit doesn't have any centralized
| scheduling, diffing, etc. Each component is its own independent
| render root and schedules its own updates in microtasks. This has
| some great upsides - it's very easy to modify scheduling per
| component, and decouple costly subsections of a page to limit
| jank.
|
| And we get great performance from the emergent global properties
| of independent roots. We check for data changes in the property
| setters for each component, so data updates only cause component
| updates along the paths in the tree that both use that data and
| see a change. Then lit-html, the template system, doesn't use
| VDOM, but remembers where data is bound to the DOM and only
| updates that if the data changed. It's very efficient.
|
| Also, Lit requires no compiler to toolchain. You can use it from
| a CDN, or with import maps, or with a tool that resolves JS
| modules import specifiers. You can use decorators with
| TypeScript, or not. You can bundle or not. We do have TypeScript
| and ESLint plugins for working with templates.
___________________________________________________________________
(page generated 2023-07-20 23:00 UTC)