If anyone's looking for something like a framework that works with buildless workflows you might check out the project I work on: Lit ( https://lit.dev )
Lit gives you reactive components, declarative HTML templates, runtime encapsulated DOM and styles, interoperability with frameworks and HTML via web components, and a lot more - with no required build tools at all.
We take great care to make sure our libraries are usable without build tools. We support plain JS (in addition to TypeScript). Our libraries work straight from CDNs like Unpkg. When installed locally you can use a dev server that rewrites bare module specifiers or use an 8-line import map to make all of our core packages importable (we carefully keep all of our import specifiers compatible with the web and compact import maps). Components are inspectable with regular DevTools. You can even write components right in DevTools, or in a script tag in plain HTML.
I honestly wish this weren't a unique selling point of Lit, but as far as I can tell, of the "major" frameworks or component libraries out there (including React, Vue, Angular, Solid, Ember, Svelte, Stencil, Preact, and more) we're the only ones that fully work with plain JS within our regular mainstream usage patterns.
I've been looking for a modern JS library that doesn't require a build step, and I've always skipped over Lit because I thought it depended on a build until this comment.
Is there any documentation about using it without a build? All the documentation and tutorials seem to assume a build step. I've found several different "getting started" entrypoints on the site, and they all begin with "npm install" and "import {LitElement, html} from 'lit';" which won't work without a build step, correct?
Some of this depends on what you consider a build step. I generally don't consider installing from npm a build step. I also don't really consider rewriting import specifiers a build step - it's just locating files on disk.
Regardless, we do have some workflows for completely "tool-less" (or local-tool-less).
- You can import directly from JS module CDNs like unpkg.com, ie:
import {LitElement, html} from 'https://unpkg.com/[email protected]/index.js?module';
Ultimately we're not really dogmatic about things and support a wide variety of tools. The thing we care about is that tool-less development is possible, and that you can use standard semantics and tools with no special configuration (ie, regular Node resolution is all that's required locally, we stick to standard ES2020).
>I generally don't consider installing from npm a build step. I also don't really consider rewriting import specifiers a build step - it's just locating files on disk.
Sorry, maybe this is just my JS ignorance, but I don't understand how this runs without a build step.
If I run npm -i lit, it puts lit into node_modules. But then if I put "import {LitElement, html} from 'lit';" into a JS file and run a dumb static webserver (like python3 -m http.server), what's linking "from 'lit'" to the necessary files in node_modules?
I just tried running the first tutorial[0] verbatim after npm installing lit to the same directory, and I get:
Uncaught TypeError: The specifier “lit” was a bare specifier, but was not remapped to anything. Relative module specifiers must start with “./”, “../” or “/”. my-element.js:1:31
I'd love to use this, I'm just not following how this works.
Is it designed to run server-side rather than for static sites?
So you have four-ish options to tell the browser where to look for 'lit':
1. Use a server that will use the node module resolution algorithm and transforms it to a relative specifier as it encounters the import (transform/build-ish?)
2. Use experimental "import maps" to go fully buildless to tell the browser where to point that bare module to (buildless)
3. Bundle all your code (build step)
4. Use a bundle from a CDN
Here are some examples of each:
Server that transforms import specifiers (lit.dev does this by default):
if you change your application code on disk and reload the page and it works, then there's no build step. 1-time setup actions like installing from NPM aren't considered.
We used Lit for a project a while ago and I definitely vouch for it.
We were embedding the component into a legacy application and needed to use a build tool for older browser compatibility but it was a breeze to work with even with the extra complication our build setup added.
Getting back to basics and targeting what most modern browsers support out of the box is a huge plus.
I've been doing web dev for 20 years and Lit has finally allowed me to achieve my dream of what I've imagined web dev should've been like this entire time. Thank you for your work, please keep it up!
I just want to point out there is a great alternative from Microsoft called `fast-design`[0] which provides a more fleshed out experience than Lit does, in terms of out of the box components.
It does have lower level packages if you don't want ready made components too
FAST is kind of like a Lit-clone (though it patches global prototypes) plus a design system base.
There are lots of design systems built with Lit that you can chose from instead of us including our own: Shoelace, Adobe Spectrum, Redhat Patternfly, IBM Carbon, Material Web Components and more.
First of all, thank you for the work you have done on this, I love lit, use it all the time at work.
One thing I struggle with from time to time is that if I have a web component created in lit, and somewhere inside I have a dependency that has some CSS, that CSS doesn’t seem to work when the web component is consumed by JS.
The only workaround I found was to override the behaviour and instead of returning a shadow dom, return the component on its own, but that has its own downsides.
Thanks for the reference, interesting, I will have a look.
vuejs can work without build system though. it's mentioned in the article, and I used to wwork that way. Eventually i made my own (minimal) build system though using quickjs and esbuild. Precompiling templates and minimising can be useful.
I really like Lit. It makes you in most cases write better reusable components, though you should still check all the properties to see if they are too reliant on some property.
We started using it because we knew it could be embedded into any other framework, we are using two others in the company. But are starting to use it for SPA also. Glad to see it growing quickly.
Thinking about possibly reworking our SPA to use Phoenix LiveView most of the abstractions are there already.
How much do I have to know about web components before using Lit?
But thank you for your response. Did not know that I was looking for Lit all these time. Every time I want to dabble into web dev, I get frustrated by multitude of tools need to setup first. All I wanted was to import a library using script tag and start building.
> ... we're the only ones that fully work with plain JS
Vue (v2, don't know about v3) can also work without a build script, either with a render function, or a "template" (an string that mixes HTML with expressions).
Hey, long time lit-html fan here. Had always held off on using Lit itself because from the documentation it felt like build tools were required. Great to see that's not the case! Definitely going to check this out.
Most devs have no idea what lit-html + DOM event + sub 100 lines glue code (mvc) is capable of. No useThis useThat non-sense, just call render() manually, really, it's not a big deal like at all.
Lit-Html is a templating library similar to say Mustache or something like that but I would argue much more expressive. You can see a demo of how it looks here https://www.npmjs.com/package/lit-html
Lit is another library that is made up of a couple of things one of which is lit-html but is closer to a React or Vue by way of comparison.
Some noticeable differences between it and other view layer libraries include the fact that it was written by a team who are arguably much closer to actual browsers engineers and it uses native Web Components. The side-effect of this is that it’s incredibly fast and lightweight. I tend to think of it as the 5kb developer experience enhancement that takes Web Components as a primitive and makes them an actual pleasure to work with.
There are also a series of enhancement packages that are also totally opt in if you want more out of the box like internationalisation, client side routing etc.
If you go to lit.dev the documentation is actually pretty great and it’s probably the easiest way to get started.
Lit gives you reactive components, declarative HTML templates, runtime encapsulated DOM and styles, interoperability with frameworks and HTML via web components, and a lot more - with no required build tools at all.
We take great care to make sure our libraries are usable without build tools. We support plain JS (in addition to TypeScript). Our libraries work straight from CDNs like Unpkg. When installed locally you can use a dev server that rewrites bare module specifiers or use an 8-line import map to make all of our core packages importable (we carefully keep all of our import specifiers compatible with the web and compact import maps). Components are inspectable with regular DevTools. You can even write components right in DevTools, or in a script tag in plain HTML.
I honestly wish this weren't a unique selling point of Lit, but as far as I can tell, of the "major" frameworks or component libraries out there (including React, Vue, Angular, Solid, Ember, Svelte, Stencil, Preact, and more) we're the only ones that fully work with plain JS within our regular mainstream usage patterns.