The more meta-programming that a language allows, the more its functions will tend to be composable. The more composable it is, the more its libraries can be tied together without the need for an over-arching framework. The framework is there to provide needed cohesion at exactly those points where the language itself does not provide enough meta reflexion to enable fearless mixing of libraries that have little knowledge of each other.
There is also the historical trend toward lighter frameworks: Rails was lighter than Struts, and more recently we've seen a flood of frameworks that are much lighter than Rails.
The Clojure eco-system has gone furthest down this road. Although at first there was a feeling that there should be a web framework for Clojure (and people made wonderful efforts with Noir) eventually the consensus of the community was that it was sufficient to get by with various libraries, some of which (Ring) have become standards.
Languages that offer less in the way of meta-programming (PHP) have been slower to go down this road.
No matter what language you use, the future direction of the trend seems clear enough: less frameworks, less centralized effort toward organization, more emphasis on composability, better ability to mix libraries for maximum effect.
Look at this implementation: it's just a composition of a bunch of other libraries. no logic at all. This is how it should be: https://github.com/segmentio/myth/blob/master/index.js#L37-L...
I'm actually experimenting with `scotty` for haskell now. Though a tad limited (getting sessions to work is a bit whiney) I had a decently working URL-shortener up and running in an hour of composing haskell modules and writing a max of 20 lines of code.
This whole micro-framework thing is getting close to my view of the ideal way of programming. Use as much reusable components at any time. There is always someone who did what you were trying and probably already did it better. I prefer investing time in finding the right micro-frameworks then investing time to learn to program things in new ways (is this a bad thing?). Anyhow, I see a lot of classmates implementing their new login systems for their little websites in pure PHP and i'm just staring at them like 'what the hell'. Especially in things involving security, composable 'micro-modules' are a blessing. I just combine a few libraries and whoop I got an https server that securly talks to a database that securly stores credentials and sessions. I think it's just beautiful.
Okay of course I do implement things myself. that that is more out of curiosity. I'm like 'hey how does this security stuff work? how do I break things?' and I read up about it and prototype a little. but I would _never_ use such code in production just because I know someone already did better.
So yeah. to sum it up. programming microframeworks give us this:
* small, modularized code
* where each module on its own is at its best
* where the composition of these modules is clear.
* and the result is highly maintainable code.
I would even want to take it a step further. Where certain kind of frameworks stick to the same standard. Think Promises/A+ or WAI. Now at any time in the future, I can give my whole codebase a speed boost by just changing a single line. Isn't this great?
Using a large framework like Django should allow you to use "as much reusable components" at any time, plus you have the advantage of knowing that they will play nicely together, and should have some sort of consistency between them. Yes you get a bigger download, but it will be stored on the server, not downloaded each time a user clicks a link. Less dependencies, as more is included out of the box.
try doing something workflow heavy on appengine with datastore. The django orm wont work for datastore, so what you are left with out of the framework is regex based routing(ewww) and a bunch of crippled components(meaning depending on an orm you can't use).
django has it's place dont get me wrong, i would use it to quickly squeeze out internal db backed apps all day. maybe even use it as a cms. But i'd rather not do those kinds of projects at all.
You believe it, I tried it, and it failed, the non-rel project isn't even under active development anymore. And if appengine had not introduced cloudsql as an option, django would be useless on that platform.(IMO)
> And also Django is modular enough that you only need to use the parts you require.
As I said before, without the django orm, there's not much useful stuff left in django that will work without it. There's better request routing options than regex based IMO. There's better form libs and validation libs. There are certainly better performing template engines, what is left of django that's a better choice over something else?
Or... more unnecessary dependencies you're forced to code around if you happen not to want or need them.
Sure things are included and make Django a bigger download than microframeworks, but other than a bit of disk space on the server, I have never had a problem with parts of the framework I don't need.
Frameworks were originally being developed by people with high-end needs. They are then also adopted by people with low-end needs, who conclude that the framework is too big and complicated for them, and start developing/adopting more light weight frameworks.
This market is still young, so there are no dominant players like Rails, Django or Symfony yet.
It's more a matter of chronological than a trend. Big frameworks are still being used on a massive scale where appropriate, it's just a more stable market where the only news is the next release.
If all that bloat is getting in the way, why not go back to CGI? That must be the most minimal of frameworks.
Another problem with many of the existing big frameworks is that they don't do single page apps too well - A lot of stuff I do these days just doesn't need to be designed around the notion of composing templated widgets server side. I just want to ship static html/tpl/etc files and dynamically built data. Wrapping my head around pretending everything is a full page build gets a bit frustrating - why is the response to a query a view or *view? It's just a serialized model I'm pushing over the wire, or a remote function call. Pretending it is a view is a layer of cognitive overheard in between the work I'm doing and the data I'm using.
"when all you have is a hammer, everything looks like a nail"
I suggest trying out some screwdrivers for a while.
The analogy is closer to choosing between a pair of pliers and a leatherman. Maybe a drill would be more useful.
I think you can get the advantages of both if your big framework is built on smaller pieces that make sense in themselves. So in Scala land I'm very pleased to hear that Play is moving to be built on top of Spray (which is a microframework I'm using at the moment - and itself is built out of pieces like spray-json that can be sensibly used in isolation).
I loved those days. :)
Even when you don't rely on a traditional framework approach you still have to address the problem of finding libraries that are actively maintained and work well together. It's also helpful to have a standard for how an application is organized.
While somebody who's already experienced with the ecosystem might not get a lot of value out of this, it makes it provides a much better experience for newcomers.
Where are you coming up with that notion? Clojure's composability comes from being functional, not from meta-programming.
>The more composable it is, the more its libraries can be tied together without the need for an over-arching framework
A framework is just a library that inverts control. Your code is the library and the framework is the application. Writing main() yourself is not a benefit, and having a framework do it for you isn't detrimental.