"Didn't you just build your own framework?"

Wow, my last post got way more attention than I expected, even making it all the way to the front page of Hacker News this past Saturday! To my surprise most of the response was positive. Even Reddit and Hacker News weren't too brutal. There was the expected amount of snark, to be sure, but there was also some genuine misunderstanding and confusion about a few things, so let's clear them up.

# So... this is a framework. You just built a framework.

Well, no.

You could blindly use the resulting code as your new micro-framework, but I wouldn't recommend it. It's not intended to be used in production, and the only documentation for it is the blog post that shows how it was wired up.

Indeed, the point of that post was to show how it was done.

At some point in the future, you will find yourself starting down a legacy application. Perhaps you didn't make any of the decisions to get the application to this point, but here you are. It doesn't have a DI container, but it needs one.

Faced with such a need, I've seen countless developers assume this means they need to rebuild the application in a framework, or worse, try to slap a framework onto the existing codebase. In all but the simplest of applications, both courses of action are a fool's errand.

Aside from a rewrite nearly always taking longer than estimated and blocking new business value while in progress, it's impossible to know all the business knowledge contained in that existing application. You'll almost certainly lose some of it in the rewrite.

Oh, and you'll introduce new bugs. The rewrite won't be perfect either.

To avoid a rewrite though, you need to know how those frameworks do what they do under the hood. If the only experience you've ever had building PHP applications was with a framework, you might not even know how to add Composer or how to send a response back to the client that requested it. And that's okay. It's actually pretty hard to find an easy-to-follow guide that connects all the dots, especially for those things that a framework usually handles for you. The blog post attempts to fill in some of those gaps.

# This looks like Java. You should just use Java.

I saw some variation of this comment several times, and I'll bundle with it another one I saw: If you want to grow as a developer, you should learn Go, Node.js, Python, etc.

Missing the point, of course. Yes, you can learn a lot by trying your hand in another language, but the blog post is specifically speaking to PHP developers about a circumstance that they will one day face if they haven't already: an existing PHP application in much need of some modernization.

I can't think of more terrible advice than to tell that developer they should rewrite the whole thing in another language.

# Interoperability is over-rated. Nobody actually swaps out components in real applications.

I remember years ago hearing that a great benefit to using a database-agnostic query builder was that you could swap out your database system later on. That was ridiculous, of course. Nobody actually did that with real applications.

So I get where this argument is coming from. But the benefit to interoperability and the PSR standards isn’t that you can swap out implementations later on. The benefit is that packages can be designed and built by different vendors without being tightly coupled to a particular implementation of a more foundational component like HTTP messages, a DI container, a logger, or a middleware handler.

Before PSR-11, any PHP library that needed to resolve dependencies would simply require a particular DI container. If you didn’t use that DI container, you couldn’t use that library. A common interface for dependency injection containers means that such a library can easily be written for compatibility with a wide variety of DI containers.

Even more commonly, third-party packages that dealt with any aspect of HTTP messages tended to be tightly coupled to a particular framework. Since one of the previously unique benefits PHP frameworks provided was an abstraction of HTTP messages, that was the only way these package developers could be sure their library would work in a given codebase.

Ultimately, interoperability standards lay the groundwork for a richer component ecosystem with packages that are available for much wider usage than before.

As an application developer, interoperability means you can build with the confidence that you won’t be pigeonholed into a particular dependency graph just because your application makes use of a particular package now. If you stick to the standards, there’s a wide variety of packages available to plug in whenever you need them.

# But a framework lets me get started building a real application right away.

Sure, but the blog post wasn’t talking about greenfield projects. It was encouraging developers to learn how it works under the hood so they can apply modern coding techniques to existing PHP applications.

# This is wildly over-engineered just to display Hello World.

I mean, come on.