Thoughts on Framework Churn

I often worry about framework churn. A lot. But using a framework isn't a bad thing. After all, they save time. They help you build things faster.

Yes, there are costs associated with frameworks later on, especially as new versions come out and your app instantly feels like legacy software. It can be exhausting trying to keep up, especially when your work schedule doesn't account for that type of maintenance.

While the upfront savings of using a framework offsets much of the eventual cost of its churn, there might be ways to reduce it even more.

A Tale of Churn #

Over the years, I've become somewhat averse to frameworks because I've had bad experiences with churn. One time, I wrote an app using Vue 2 and, less than a year later, Vue 3 shipped. I went to upgrade and realized that Element, the Vue-based component library I was using, didn't support Vue 3! I was stuck, unless of course I wanted to swap out every single UI component in the app.

Eventually, Element released a version for Vue 3, but then I had to deal with breaking changes from both the framework and the component library. It felt like absolute chaos and I never want to deal with that again.*

It's easy to say "fuck frameworks" out of frustration, but that's not a realistic option. Modern apps expect too much to write everything from scratch. Yes, the Web platform is getting more and more amazing features, but many APIs are intentionally lower level. Frameworks smooth out those rough edges and tend to provide better DX.

The Age of Metaframeworks #

As React, Vue, et al continue to evolve, we're seeing more and more metaframeworks pop up. It's almost as though you can't be successful as a framework without having a metaframework. React has Next.js and Remix. Vue has Nuxt.js. Angular has Analog. Svelte has SvelteKit. Solid.js has SolidStart.

This seems like complete madness to me. We're building abstractions on top of abstractions, further locking users into those ecosystems and making churn more of a problem than ever.

Sure, the box looks nice and shiny on the outside but, once you take the shrinkwrap off, there's a lot of stuff inside that won't age well. Many developers don't realize this until it's too late. Or maybe they just don't care.

In this industry, you don't win by building well-architected apps. You win by shipping fast and moving on. It will be someone else's problem soon, so fuck it. We used to joke about the Web being the wild west of the programming world, but it really is.

Tread Lightly #

I've been thinking about this for a long time and I believe the compromise is to use whatever framework you like, but don't go all in on it. Consider avoiding metaframeworks. Avoid component libraries that aren't interoperable. (This is one place web component libraries such as Shoelace shine, because they work everywhere and won't break as frameworks evolve.) Avoid building every possible piece of your app in a framework-specific way and try to make the important chunks more portable.

Each framework is different and it's probably impossible to codify this advice, so I'm not going to attempt to. What I will say is, as you develop your app, consider the effort it would take to swap out your current framework for another. Would it be trivial or would it require a complete rewrite? Which pieces will be reusable and which pieces will need to be redeveloped?

Frameworks save you a lot of time up front, so consider using some of that time to architect your application more thoughtfully. Allow your app's concerns to be separated in such a way that the important pieces of it are more portable than if you were to write it in and for the framework.

I care about my craft. I care about the quality and maintainability of the things I create. Sometimes that means choosing the hard right over the easy wrong. While some level of framework churn is inevitable, a well-designed application can alleviate a lot of that pain later on.