Why Lit Just Quietly Became My Go-To Frontend Framework (And Angular’s Component Story Might Surprise You)

The 2 AM Revelation That Changed Everything

Picture this: you’re three cups of coffee deep, staring at a React component tree that looks like someone exploded a dependency graph in your face, and you realize you’ve spent four hours debugging why a simple state update isn’t propagating correctly. Sound familiar? Last month, I found myself in exactly this spot when I decided to rebuild a client dashboard that had grown into what I can only describe as “architectural spaghetti with a side of regret.”

That’s when I stumbled back into Lit and had one of those rare moments where everything just clicked. No virtual DOM overhead. No complex state management ceremony. Just web components that work exactly like you’d expect HTML elements to work. Sometimes the best solutions are the ones that feel boring until you realize they’ve solved all your problems without fanfare.

The Component Architecture Reality Check

Let’s talk about what actually matters when you’re building something people will maintain for years, not months. React’s component model is brilliant until you hit the inevitable prop drilling nightmare or watch your bundle size balloon because you needed one tiny utility from a massive library. Vue’s composition API gets close to elegance, but you’re still wrestling with reactivity quirks that make you question your life choices at inconvenient times.

Angular, though? Here’s where it gets interesting. While everyone was busy arguing about React vs Vue, Angular quietly built the most robust component architecture I’ve encountered in production. The dependency injection system actually makes sense once you stop fighting it. I recently migrated a complex data visualization tool from React, and the Angular version has 40% fewer lines of code with significantly better separation of concerns. The downside? Your junior developers will need three months to stop looking confused during code reviews.

Then there’s Lit, which takes a radically different approach: why not just enhance the web platform instead of replacing it? Your components are actual custom elements. No framework lock-in, no massive runtime, no explaining to your backend team why the JavaScript bundle is larger than their entire API. When I tell people I can drop a Lit component into a Django template or a Rails view without any build step, they look at me like I’ve performed actual magic.

Bundle Size Reality vs Marketing Promises

Here’s something nobody talks about in those framework comparison charts: real-world bundle sizes after you’ve added routing, state management, form handling, and all the other stuff you actually need to ship a product. That “lightweight” React app? It’s now 300KB gzipped before you’ve written a single line of business logic. Vue does better, but not by much once you’ve added Vuex and Vue Router.

Lit’s entire runtime is 15KB. Not a typo. The component I built last week for handling file uploads weighs in at 8KB including all its dependencies. No tree-shaking required because there’s barely anything to shake. This isn’t just about mobile users on slow connections, though that matters too. It’s about that moment when your CI/CD pipeline thanks you because builds finish in seconds instead of minutes.

Angular is the outlier here because it doesn’t pretend to be small. The framework is honest about being heavyweight, but it earns that weight with features that actually solve enterprise problems. Real dependency injection, proper lazy loading, a CLI that doesn’t make you want to throw your laptop out the window. When you’re building an application with 200+ components and a team of 15 developers, Angular’s bulk starts feeling less like bloat and more like infrastructure.

The State Management Plot Twist

Every framework discussion eventually degenerates into state management philosophy, so let’s get weird with it. Redux taught us that immutability is good but ceremony is exhausting. Vuex simplified the API but kept the complexity. Zustand and other modern solutions are genuinely delightful until you need time travel debugging at 2 AM on a Tuesday.

Here’s what I’ve discovered after shipping production apps in all these frameworks: the best state management is often no state management. Web components naturally encapsulate state, and browser APIs like localStorage and sessionStorage handle persistence without the elaborate orchestration. My latest Lit project has zero external state management libraries, yet the component tree shares data more elegantly than most Redux applications I’ve maintained.

Angular’s Services and RxJS integration deserves special mention because it’s either brilliant or torture depending on your perspective. I’ve seen teams build incredibly sophisticated data flows with minimal boilerplate, and I’ve also seen developers quit rather than debug another switchMap chain. The learning curve is steep, but the ceiling is remarkably high if you’re building complex interactive applications.

Performance Beyond the Benchmarks

Benchmark wars are mostly theater, but let’s talk about performance that actually affects users. React’s reconciliation algorithm is impressive until you have a few thousand DOM nodes and realize you’re spending more CPU cycles on virtual DOM diffing than actual work. Vue strikes a better balance, but you’re still paying the framework tax on every update.

Lit components update only when their properties change, using the same mechanisms browsers use internally. No synthetic event system, no virtual DOM overhead, no wondering why your perfectly optimized React component is still slower than vanilla JavaScript. I recently replaced a React data grid with a Lit equivalent, and scroll performance improved so dramatically that users started asking if we’d upgraded the server.

Angular’s change detection gets unfairly maligned, but OnPush change detection with observables creates some of the most performant UIs I’ve ever built. The secret sauce is designing your data flow to work with the framework instead of against it. Yes, there’s a learning curve. No, most developers never climb it. But when you do, the performance characteristics are outstanding.

The Framework Choice That Actually Matters

After building production applications in every major framework over the past decade, I’ve reached a controversial conclusion: the framework choice matters less than your team’s relationship with web fundamentals. The best React developers I know could build elegant applications in any framework because they understand JavaScript, the DOM, and browser APIs at a deep level.

That said, if you’re starting a new project today and want my honest recommendation? Try Lit for anything that needs to integrate with existing systems or live for more than five years. Consider Angular if you’re building complex applications with large teams and can invest in proper training. React and Vue are safe choices that won’t get you fired, but they’re not necessarily the most interesting ones.

The web platform keeps getting better while framework churn continues accelerating. Maybe it’s time to bet on web standards instead of the next shiny abstraction. What would your application architecture look like if you designed it to outlast the framework wars?