3 comments

[ 3.3 ms ] story [ 9.4 ms ] thread
Not bad, but it seems like the author conflates an app's architecture with a framework here.

App architecture, at it's best, is a intentional structuring that isolates what the system does from how it does it. In other words, it separates the business concerns from the technical concerns, as they may change for separate reasons. This is what results if you don't use a framework. It may seem impossible, but there were tons of desktop apps made without a framework (I consider .NET/GTK/Win32 et al to be class libraries because they did not force any architecture on you.)

Contrast this with a framework: a ready-made set of abstractions used for solving a particular problem. Most frameworks prescribe an architecture: their own.

Good point. In theory, I agree; one particular app's "glue" is not necessarily a framework. If you come with your own architecture for your app, you are only creating a framework if you then abstract that architecture and embody it in software in such a way that it can be used for other apps.

However, there are so many layers and necessary abstractions in a web app that I think you do end up with a framework in practice. It's kind of like making a game without a game engine -- you end up writing a game engine. You can't not abstract certain things, like sprites and backgrounds for a 2D game, or the draw loop.

You don't need to write it all yourself, though. There's nothing wrong with a loosely-coupled collection of libraries that are hand-picked to do the task at hand. Add in a dash of abstraction, and you can even change those somewhat easily.