5 ms·
I've come to the conclusion that the only things that matter, in the end, are the SQL going across the wire in one direction, and the HTML going across the wire
by tjpick 15y ago
I've come to the conclusion that the only things that matter, in the end, are the SQL going across the wire in one direction, and the HTML going across the wire in the other.
The code in between those should be as small as possible and as simple as possible, and as obvious as possible given the point of view of someone who knows nothing about your application architecture, to give you the best chance of fixing the bugs in the places that it matters.
A framework tries to occupy the space in between those 2 wires, and unfortunately for frameworks are very rarely small and simple.
- fhars 15y agoOne of the reasons for that may of course be that the framework unlike your simple code knows all the edge cases where strings going in one direction or the other need to be escaped to avoid obvious security errors.
- jamesbritt 15y ago... and unfortunately for frameworks are very rarely small and simple. Quite a few start out that way, but for whatever reason feature-creep sets in and soon your off to J2EE land. If you start seeing more than one or two books covering a framework it's time to find a simpler one.
- antihero 15y agoI think microframeworks like Flask strike a really nice balance with this.
- jamesbritt 15y agoI like the idea of layered frameworks. For Ruby, there's Innate, a light-weight framework, and on top of that is built Ramaze, a more developed framework (though still comparatively light). Likewise there is Sinatra, and on top of that was built Padrino. And both Innate and Sinatra are built on top of Rack. So if you don't care for the direction or feel of a framework you can pop down the layers once or twice and build something you like without having to start completely from scratch.