[dpark]

> magically solves everything

This is the real problem. Too often frameworks/libraries are geared towards making things magic instead of making things solid. Magic solutions are usually very one dimensional. e.g. The Magic only works for a really narrow use case, or at low load. I don’t think this is specifically a problem with “mini frameworks” but homegrown stuff exhibits this more, if only because magic solutions tend to die in the wild when the bug tracker is full of “this only works for trivial case; make it actually work”.

When frameworks/libraries advertise how easy they are to get started, there is often a lot of magic to make it trivial to start and they don’t scale to real projects without breaking through all the magic abstractions.

[bccdee]

That's one thing I'll say for in-house "mini-frameworks": Real frameworks often try to present a smooth façade of abstraction which is hard to punch holes through. An in-house "mini-framework," though, is often just a hodgepodge of compostable abstractions which you can individually take or leave without too much hassle.

Of course, your hodgepodge ecosystem will eventually ends up a bit of a mess, but I'll take that over a flashy off-the-shelf framework that insists on handling everything itself.

[gejose]

> lot of magic to make it trivial to start and they don’t scale to real projects

Ruby on Rails is probably a great counter example here though.

[TOGoS]

I have never really grokked Ruby on Rails and I passionately hate all the frameworks that try to adapt it to some other language.

That said, I suspect that Ruby on Rails itself occupies kind of a special space where the magic is acceptable because people who write Ruby are used to having very very sharp tools and have learned to wield them carefully. Give that magic to a PHP or Java programmer and there is immediately gallons of blood on the floor.

(says former Rubyist who was put off by the RoR stuff because I'm apparently more of a Haskeller at heart.)