<loud>I am a full stack engineer</loud> I don’t care who hears that, I full stack and I proud. As half of you shrug with a “so what, everyone is full stack” and the other half scoff that I cannot be good at either if I claim to both.
As you, dear reader know, I have been going through a bit a renaissance of code. While I tend to think in a whole system way and I, in the past, would build from the back-end forward. Today’s tools allow for a freedom that was not available to the solo (lonely 🥲) engineer. My overconfidence in front-end development usually results in a 4-hour (4 day) rabbit hole on Webpack configs, broken build pipelines and npm being anti-Scottish for some reason. This time, I reached for something I hadn’t touched in a while but instantly loved during my first taste: Lit.
And honestly? It still feels like the future.
Not in the flashy, hot-take, Silicon Valley keynote kind of way. More in the “quietly brilliant, feels so easy its cheating, 👏why-did-we-ever-stop-using-this👏” kind of way.
A Little Context
My first framework love was AngularJS (actually it was php cake but that is a story for another time). It felt magical at the, two-way binding, directives, services, it blew my tiny mind. Then came Angular 2.0, and I clung on through the rewrite, the RxJS everything, the modules and decorators, the ever-changing CLIs and I will admit to enjoying a banana in a box. It was… a character-building time. Like a kind of JavaScript boot camp that nobody asked for.
Lit is a lightweight library for building fast web components. Think of it as the spiritual successor to Polymer, but stripped of the Googley overhead and blessed with actual ergonomics. It leans into the Web Components spec, doesn’t try to take over your build pipeline, and it Just Works™ in a way that feels increasingly rare. Like it just works …
I’ve been around long enough to remember the first wave of frontend frameworks. AngularJS, Backbone, Ember – all trying to solve the mess jQuery left behind. Then React got super popular and turned everything into divs pretending to be logic. We got hooks, we got context, we got… complex.
And that complexity didn’t go away. It just mutated.
These days, being a frontend developer feels like needing a PhD in the JavaScript ecosystem. You don’t just build buttons, you choose between Vite, Webpack, or esbuild to compile them, debate between Redux, Zustand, or signals to manage their state, decide whether you’re styling with CSS Modules, Tailwind, or some CSS-in-JS cryptid… and let’s not even talk about SSR, hydration, or the AI-generated boilerplate that may or may not work offline.
It’s a far cry from sprinkling a wee bit of jQuery on a page and calling it a, productive AF, day.
So when I picked Lit back up, it was like exhaling for the first time in ages. No complex mental model. No ecosystem overhead. Just:
- Standard HTML templates
- Reactive properties
- Encapsulation via Shadow DOM
- No virtual DOM nonsense
Chef’s kiss
Why Lit Still Feels Right in 2025
We’re knee-deep in the age of megaframeworks. Your “simple” frontend stack now has more npm packages than IKEA has Allen keys. Things had gotten harder for so long.
Meanwhile, Lit is over here saying:
“Here’s a class. Here’s a template. Ship it.”
No opinionated router. No state management library wars. Just good old components that play nicely with each other and the wider ecosystem.
This is especially relevant if you’re building design systems or multi-app platforms where interoperability matters. Want to use a component in an old MVC app? Lit’s got you. Building a modern monorepo? Works there too.
And (!) unlike some other frameworks-that-shall-not-be-named, Lit isn’t trying to lock you in. Your stuff remains web-standard, portable, and future-proof-ish.
It’s Not Perfect
Nothing is.
Some tooling still lags behind React’s gravity well. Lit’s ecosystem is smaller. TypeScript support is solid, almost magical but not exactly. And if you’re the type that needs a plugin for every passing idea, Lit might feel a bit… sparse.
But what you lose in prebuilt everything, you gain in clarity. Your mental model stays intact. Your components are readable. Debugging feels more like actual programming and less like deciphering monkey-generated soup.
Where in the world does it fit (where does lit fit – Chat make a rap about where does lit fit)?
| Feature / Framework | Lit | React | Angular | Vue |
| Learning Curve | Low – just TS/JS, HTML & decorators | Medium – JSX, hooks, tooling quirks | High – TypeScript, RxJS, DI, modules | Medium – simpler than Angular, more opinionated than Lit |
| Boilerplate | Minimal – native classes + decorators | Moderate – lots of setup & config | High – lots of ceremony | Moderate – single file components, but custom syntax |
| Bundle Size | Tiny (~5KB) | Medium (~30-40KB+) | Large (~60KB+) | Small–Medium (~20-30KB) |
| Web Standards | ✅ Native Web Components | ❌ JSX, custom renderer | ❌ Heavy abstraction | ⚠️ Partially (custom templating) |
| Reactivity Model | Simple reactive properties | Complex (hooks, context) | Complex (RxJS, zones) | Reactive system, clear but abstracted |
| Shadow DOM / Encapsulation | ✅ Native Shadow DOM | ❌ None by default | ❌ Emulated | ⚠️ Scoped CSS, no Shadow DOM |
| Tooling Overhead | Low – works without a build step | High – needs bundler, Babel | Very High – CLI, build tools, schematics | Medium – has a CLI, but lighter than Angular |
| Great for Prototyping | ✅ Absolutely | ❌ Slower to set up | ❌ Way too much config | ⚠️ Possible, but still needs setup |
| Component Reusability | ✅ Drop into any HTML page | ❌ Tied to React runtime | ❌ Tied to Angular runtime | ⚠️ Possible but not as portable |
| SSR Support | ⚠️ Limited, still evolving | ✅ Strong (Next.js etc) | ✅ Built-in | ✅ Nuxt and similar tools |
| Community Size | Small but growing | Massive | Massive | Large |
| Opinionation | Low – bring your own tools | Medium – ecosystem conventions | High – everything included | Medium – Vue way of doing things |
Where I’m Using It
These days, I find myself spinning up a lot of frontends for weekend projects, prototypes, and proof-of-concepts, just enough UI to show an idea has legs without getting bogged down in framework ceremony. And Lit absolutely shines in that space.
I don’t want to scaffold three folders of boilerplate just to render a button. I want to drop a component on a page, wire it up to some state, and move on with my life (ideally before the coffee wears off or the wine is poored). Lit’s minimal setup and instant compatibility with native browser features make it perfect for quick iterations and disposable frontends—especially when I’m validating an idea or mocking up an internal tool no one wants to “invest in” yet.
It’s fast, focused, and flexible, the holy trinity of the side project stack. The whole thing feels lean. Like I’m building something instead of configuring something. That’s the Lit difference.
The TL;DR
Lit won’t be the hot new thing at React Conf. It doesn’t have 17 competing router libraries or a mascot with a bowtie. But it does something more valuable, you build solid, maintainable, fast frontends without the fluff.
And in a world full of shiny distractions, that still feels like the future.
The rap “where does lit fit”
Redacted – it was terrible.