Frameworks Aren’t the Problem — Our Dependency on Them Is

I often get pushback when I share my philosophy: I prefer native development for mobile apps and use core Java without Spring for the backend. Not because I think frameworks are terrible, quite the opposite, but because I think we’ve grown too dependent on them. This isn’t a hot take or a rejection of modern development. It’s a reflection on where we are as an industry, and where I believe we should be more intentional. Why I Go Native and Framework-Free When I build mobile apps, I choose native: SwiftUI for iOS, Kotlin for Android. No Flutter, no cross-platform abstractions. Native gives me fine-grained control over performance, UI/UX, and system APIs. I don’t have to wait for the framework to catch up. I build what I need, when I need it. On the backend, I use core Java with JDBC, and I built my own internal framework. It handles the essentials such as JWT auth, encrypted passwords, DAO generation without the bulk of Spring Boot or Hibernate. I get full visibility into what’s happening under the hood, and I can optimize for my own use cases, not someone else’s assumptions. I’m Not Anti-Framework Let me be clear: I’m not against frameworks. Spring Boot is incredible for bootstrapping projects. Flutter is a game-changer for MVPs. Laravel, React, Express, etc. All of these have saved time, enabled startups, and leveled the playing field for developers around the world. But they are tools, not crutches. The Problem: Blind Dependence Too often, I see developers rely on frameworks they don’t truly understand. They ship fast, but they can’t explain what’s happening behind the scenes. They use annotations, DI containers, ORM layers and when something breaks, they’re lost in a maze of magic. I’ve worked on codebases where performance bottlenecks were caused by lazy loading in Hibernate, or where a small Flutter plugin bug held back an entire release. In those moments, the abstraction becomes the problem. And without the foundational knowledge, debugging turns into guesswork. Build Your Own Tools (Even If You Don’t Use Them) When I built my internal backend framework, it wasn’t because I wanted to reinvent the wheel. It was because I wanted to understand the wheel and how it’s built, where it breaks, and how to shape it for my needs. I engineered an open-source tool, appaveli-cli, which is a lightweight Java-based code generation tool that helps you scaffold DAO, Domain model classes, JDBC connections, and more. Appaveli-cli generates boilerplate code based on custom templates. That experience gave me more confidence as an engineer than any framework could. Even if you use Spring, write a barebones REST API in core Java. Even if you love Flutter, try building the same screen in native Swift or Kotlin. That knowledge pays dividends not just in code quality, but in leadership, architecture decisions, and developer growth. Intentional Engineering Frameworks should be chosen with intention, not by default. They should accelerate what you already understand not replace your need to understand it. I’m not saying everyone should ditch Spring Boot or rewrite their apps in native code. I’m saying: don’t forget how to code without them. Your career, your team, and your software will be better for it.

Apr 24, 2025 - 01:42

Frameworks Aren’t the Problem — Our Dependency on Them Is

I often get pushback when I share my philosophy: I prefer native development for mobile apps and use core Java without Spring for the backend. Not because I think frameworks are terrible, quite the opposite, but because I think we’ve grown too dependent on them.

This isn’t a hot take or a rejection of modern development. It’s a reflection on where we are as an industry, and where I believe we should be more intentional.

Why I Go Native and Framework-Free

When I build mobile apps, I choose native: SwiftUI for iOS, Kotlin for Android. No Flutter, no cross-platform abstractions. Native gives me fine-grained control over performance, UI/UX, and system APIs. I don’t have to wait for the framework to catch up. I build what I need, when I need it.

On the backend, I use core Java with JDBC, and I built my own internal framework. It handles the essentials such as JWT auth, encrypted passwords, DAO generation without the bulk of Spring Boot or Hibernate. I get full visibility into what’s happening under the hood, and I can optimize for my own use cases, not someone else’s assumptions.

*I’m Not Anti-Framework
*
Let me be clear: I’m not against frameworks.

Spring Boot is incredible for bootstrapping projects. Flutter is a game-changer for MVPs. Laravel, React, Express, etc. All of these have saved time, enabled startups, and leveled the playing field for developers around the world.

But they are tools, not crutches.

The Problem: Blind Dependence

Too often, I see developers rely on frameworks they don’t truly understand. They ship fast, but they can’t explain what’s happening behind the scenes. They use annotations, DI containers, ORM layers and when something breaks, they’re lost in a maze of magic.

I’ve worked on codebases where performance bottlenecks were caused by lazy loading in Hibernate, or where a small Flutter plugin bug held back an entire release. In those moments, the abstraction becomes the problem. And without the foundational knowledge, debugging turns into guesswork.

*Build Your Own Tools (Even If You Don’t Use Them)
*
When I built my internal backend framework, it wasn’t because I wanted to reinvent the wheel. It was because I wanted to understand the wheel and how it’s built, where it breaks, and how to shape it for my needs. I engineered an open-source tool, appaveli-cli, which is a lightweight Java-based code generation tool that helps you scaffold DAO, Domain model classes, JDBC connections, and more. Appaveli-cli generates boilerplate code based on custom templates.

That experience gave me more confidence as an engineer than any framework could.

Even if you use Spring, write a barebones REST API in core Java. Even if you love Flutter, try building the same screen in native Swift or Kotlin. That knowledge pays dividends not just in code quality, but in leadership, architecture decisions, and developer growth.

*Intentional Engineering
*
Frameworks should be chosen with intention, not by default. They should accelerate what you already understand not replace your need to understand it.

I’m not saying everyone should ditch Spring Boot or rewrite their apps in native code. I’m saying: don’t forget how to code without them. Your career, your team, and your software will be better for it.