At first, I wanted to attack in-house frameworks specifically. But decided to broaden my list of enemies... Me and my colleague from another department were debugging an app build failure. The thing is, we have zero clue what went wrong. Why? Well, what does it mean to build an app? It depends! The process is completely different for an Android app to iOS and so on. It can even be different for two Android apps in the same company. Well, we (and devs in general) have some idea what SHOULD happen as a result of a build. Frontend apps on the web consist of a html page, scripts and styles. And in the build process, source files get uglified and minified, TypeScript types get stripped, and so on. But what happened in our case? We have no clue. There are some additional steps. We don't know and don't care about these steps, in fact - they're neatly hidden inside some framework scripts. Yes, there's a stack trace, there are some docs about this framework, we can even try to ask maintainers. But in reality - no one knows what happened. Does this meta framework provide value? Well, yes, it kinda simplifies some things. But there's no single person who knows how it works. I don't want to say that ALL meta frameworks are bad. It depends. Let's take NextJS as an example: It's a framework that does a lot of stuff on top of React AND it is some kind of a backend framework (a shitty one), and some extra features on top of all that. I understand React, I understand backend and servers, I understand, let's say, Express, a backend Node framework. I don't understand NextJS. I have no clue what creators decided to do. There's a lot of custom extra stuff. Believe me, I've tried to debug such problems myself - but there are so many layers: You take a look at the stack trace and go down a rabbit hole of NPM packages. 10 levels deep and you forget what year it is. Here's my gripes with meta frameworks: * The docs are often lacking * It can and probably will break with an update of underlying libs * No one knows how it works - people treat it like a black box * ...Even developers/maintainers don't know how it works * No one will be able to help you * Some issues aren't going to be fixed ever * You may not even understand why certain issues happen * You wouldn't be able to rewrite the problematic part yourself * ...because such frameworks are usually big and monolithic You're probably not Facebook or Vercel or Evan Vue. Better think twice before making your own framework, doesn't matter if it will be based on something else or not. Libraries like React, SwiftUI or Jetpack Compose are a necessary abstraction. Frameworks like Angular, Symfony, Django and so on, are fine too. They all provide one layer of abstraction. There's one more good example: Svelte and SvelteKit. They fit like a hand and a glove: they have the same author and I believe they're made to work together well, and so it does. Nuxt and Vue, NextJS and React on the other hand... No. So in general I'd stay away from frameworks built on top of other libraries or frameworks. If it's possible to remove one layer of abstraction and not lose too much - I think it is the way to go.