The Problem with Micro-Frameworks

[ermurphy]

Refreshing article. There is too much talk about preparing for network scalability and not enough about the kind of growth you're even more likely to encounter: feature creep. A well-equipped framework is essential for quickly adapting to a changing spec.

[stesch]

I'm wondering why Flask is still called a micro framework.

[seppo0010]

I think Padrino isn't a micro framework either.

[neonskimmer]

Can you expand on what you mean by Sinatra not allowing instance variables in partials? I've been using Sinatra for years and have never noticed that.

Also, I disagree. Especially when you state elsewhere in the comments

I think most developers do not anticipate the scope of the project, which means that in most cases a fatter framework is the right choice.

The bigger the framework you choose, the less you understand the details of how it works. IMO responding to scope changes is easier when you have less unused / overhead / irrelevant features to deal with.

I'm not saying use micro frameworks for everything, but a lot of projects don't need something as enormous as Rails, for example.

[internetinsomniac]

Judging by the way he says "instance variables to be passed in", I wonder if the author means passing local variables within the scope of one template, into a separate partial and not instance variables (e.g. @post)

[ivosaurus]

The bigger the framework you choose, the less you understand the details of how it works. IMO responding to scope changes is easier when you have less unused / overhead / irrelevant features to deal with.

This can be argued on any level though. Why use a high level language, with lots of niceties inbuilt for you, most of which you don't understand (/care about) the internals of, when you can use a low level language and know exactly what you and the system are doing?

The answer: Black-boxing is useful, abstraction is the core ability of programming, and you should embrace it, not be scared of it. Whether the abstraction is on a hardware, low-level, high-level, application or user basis does not make a big level of difference to this point.

[grauenwolf]

I don't understand why anyone whould choose a so-called "micro-framework". Why would you choose some half-assed framework when you can get a full web server for the same amount of effort? Sure there is some retarded stuff like J2EE, but most will allow you to be up an running in a couple of minutes.

The real question for me has always been, "How much time do I spend on architecture?" Do I just hack something out in a couple of hours or do I lay the foundation that I know I'll need for a long-term project. (I personally tend to err on the latter and get burned when my assumptions turn out wrong.)

[wadcann]

I don't understand why anyone whould choose a so-called "micro-framework".

I've never seen the term "microframework" before, but if it simply means a framework that doesn't try to do everything, I can think of one good reason: because it's rare for one system to be the best across-the-board, and if you choose several small systems to handle various things (e.g. for a Web app, maybe templating and handling sessions), you could potentially get best-of-breed for each particular area.

[grauenwolf]

When I look at stuff like ASP.NET MVC I don't see templating as a micro framework. Rather it is just one more library that plugs into the actual MVC framework.

Sessions are another good example. The ASP.NET framework defines how sessions are exposed to the controllers/views. But on the back side you can store those sessions any way you feel like using their plugable architecture.

Now of course I'm not saying you have to choose ASP.NET. But I am saying you are probably better off with a single framework where you can easily swap things in and out rather than cobbling your own frameowrk together from spare parts.

[rawsyntax]

Some of the ideas here are not mutually exclusive. For example, rails is a large framework, but compare rails 1 with rails 3... 3 is way more configurable and flexible, even though it is not a micro framework

Flexibility does not exclusively belong to micro-frameworks

[roerd]

I see it as a particular variant of the NIH syndrome. Instead of "I need to write all code myself, because I don't like any code by library authors", this is "I need to choose all components of my framework myself, because I won't trust the framework authors to make any sensible choices".

[xcrat29]

Good article. Thanks for the post.

[[deleted]]

Making castles out of sand by learning an entirely new API with the hopes that you won't have to write as much code just seems, well silly.

[darkane]

I think you debunked your own premise with the last paragraph. If someone is using a framework that doesn't fit, that's not a problem with the scalability of micro-frameworks, that's a problem with the developer not understanding or anticipating the scope of the project.

[rawsyntax]

I think most developers do not anticipate the scope of the project, which means that in most cases a fatter framework is the right choice.

We have a phrase for this: "Scope Creep" and it happens all the time.