First, What Is Lit?
Before diving into the drama, let's get the basics straight. Lit is a small JavaScript library from Google designed to make it easier to build 'Web Components'. Think of Web Components as a browser-native way to create your own reusable HTML tags, like
or . These components are standards-based, meaning they are designed to work in any major browser, with or without a framework like React, Vue, or Angular. Lit provides a clean way to handle the tricky parts, like making these components react to data changes and managing their internal HTML templates efficiently. It's tiny, fast, and promises to free you from 'framework lock-in'.
The 'Love' Camp: A Bet on the Web Itself
Engineers who champion Lit are often playing the long game. Their core argument is that by building on native browser standards, Lit offers unparalleled longevity and interoperability. A Lit component you build today should, in theory, work in any web application for the foreseeable future, because its foundation is the web platform itself, not a proprietary framework model. This is a huge deal for large organizations that want to build a single design system or a library of shared components that can be used across dozens of projects, regardless of whether those projects are built in different frameworks. Senior developers who have lived through multiple framework hype cycles—and painful migrations—see this as a way to stop reinventing the wheel. They value the performance gains from Lit's optimized rendering and the stability that comes from avoiding a heavy, opinionated framework that might fall out of favor in five years.
The 'Hate' Camp: Verbose and Un-Ergonomic
On the other side of the aisle are senior engineers who find Lit's developer experience to be clunky and verbose compared to mature frameworks like React or Vue. While Lit simplifies raw Web Component development, critics argue it still involves more boilerplate for certain tasks and that its approach to state management and component composition feels less intuitive. For example, things that are straightforward with React Hooks might require more manual wiring in Lit. Some also take issue with the way Web Components encapsulate styles using the 'Shadow DOM', which can make global styling and theming a frustrating experience for teams accustomed to traditional CSS workflows. For these developers, the theoretical purity of web standards doesn't outweigh the immediate productivity and rich ecosystem offered by a framework that has solved these real-world problems over the last decade. They argue that Lit is too low-level, forcing teams to essentially build their own mini-framework on top of it.
The Philosophical Divide: Stability vs. Velocity
Ultimately, the love/hate relationship with Lit isn't just about syntax; it's about a fundamental philosophical difference in what senior engineers prioritize. One camp prioritizes long-term stability, interoperability, and aligning with web standards. They are wary of dependencies and have been 'burned' before by fast-moving trends. They see the constraints of Lit as healthy discipline. The other camp prioritizes developer velocity, a rich ecosystem, and powerful abstractions that let them build complex applications quickly. They see the 'framework lock-in' as a reasonable trade-off for the immense productivity gains and the massive talent pool available. They believe that a framework's job is to provide strong opinions and solve common problems, even if it means moving further away from the browser's native APIs.
