I know this issue has been brought up many times before, but to some extent the existence of a framework suggests a lack of composability in the language being discussed. This gets discussed a lot in the context of Clojure, where people new to Clojure often ask, "Where are the frameworks?"
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.
We see this with a lot of new Ruby frameworks as well: composability over centralized organization. Javascript is going down this road as well.
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.
Wow. that's brilliant. As we would say on tumblr " This is why we can have nice things".
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?
Not surer I understand the popularity of microframeworks, over fuller frameworks.
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.
bigger frameworks like django tend to get in your way for anything that the framework was not intended for. not every web app is a "fetch content from db and display to users"
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.
I believe there is a plugin for working with the App engine. And also Django is modular enough that you only need to use the parts you require. So again, I don't see the advantage on messing with micro-frameworks, and cobbling together multiple libraries, when you have one set of libraries that you know works nicely together.
> I believe there is a plugin for working with the App engine.
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?
I have never felt the need to "code around a dependency". (Is dependency the right word? In Django you have less deployment dependencies, because lots of stuff is included already.)
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.
Maybe 'library' would be a better word than 'dependency'? I would just prefer to add them when I need them than remove them when I don't, although with Python frameworks this might not be much of an issue.
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.
As a Django user, I hear a lot of people rant about microframeworks, and I have to ask, why? I was amazed at the productivity gains and organization Django brought to my code.
If all that bloat is getting in the way, why not go back to CGI? That must be the most minimal of frameworks.
The problem is not bloat so much as forced paradigm. There are a lot of problems that don't fit nicely in Django, and suddenly you find yourself writing a bunch of code to work around the framework. An example - something I hear a lot of from local Django fans: "Oh that's simple - just ship it off to another process using celery and be done with it". That's great sometimes. Other times why not just use Bottle or flask and do a thin "translate to http" layer and move on?
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.
That's the best reason anyone has given so far, but say you only need the URL router, nothing is forcing you to use the views layer. Admittedly when you strip out that much stuff then a micro-framework probably is a better choice. For me however I know Django well, and don't see much to be gained by learning a micro-framework.
Its not that I don't want to learn, its that I see more benefit in learning different things, rather than what appears to be a repeat of something I know fairly well (with parts subtracted).
The analogy is closer to choosing between a pair of pliers and a leatherman. Maybe a drill would be more useful.
Surprisingly PHP with Composer, coupled with type hinting and interfaces allows you to achieve what you're discussing. It's how I write web apps now -- small libraries, classes that expect interfaces, and unit testing. It's great - no frameworks!
That's not a uniform trend; five years ago in Python you put together a lot of small pieces (and e.g. Turbogears was a nominal framework that was actually a lot of small libraries being composed together). Nowadays Django has a lot more mindshare, and many of those libraries are abandoned. I'm not sure why you're comparing Rails with Struts, which never seemed particularly popular in my experience; Rails certainly feels heavier than spring-webmvc/wicket/tapestry (e.g. it reaches down to the ORM layer, while the Java frameworks expect you to handle that yourself) which is what I saw in use. Many of the Javascript libraries that are coming out are "micro" oriented, but we're also seeing the rise of Angular which is much more of a heavyweight framework.
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).
> five years ago in Python you put together a lot of small pieces (and e.g. Turbogears was a nominal framework that was actually a lot of small libraries being composed together).
Flask is very similar, but they do plugins better - many of the plugins are just thin wrappers around the existing (good) libraries for namespace and context handling -passing the core library functionality to the user. It's also been growing in popularity (hence support and active development).
I'm maintaining a micro-framework for Clojure called Luminus (http://www.luminusweb.net/). The approach I'm taking with it is to provide a standardized template that generates all the common boilerplate.
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.
A really good example is the Gorilla toolkit for Go. A few modules for common tasks such as sessions and routing, super easy to use with the standard net/http package thanks to implicit interfaces.
>The more meta-programming that a language allows, the more its functions will tend to be composable
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.
What is Log4J doing there? It's an incredibly complex framework for doing something incredibly simple - logging. It's the exact opposite of a minimalist framework.
Not using a framework requires creating your own and just not calling it a framework. One way or another you're using a framework, it's just a matter of whether your framework is grid-only, like Skeleton, Suzy, etc, or includes a ton of additional bells and whistles like Bootstrap and Foundation.
I agree. Having just finished a project with Flask, I ended up using no less than 8 million dependencies that I'd never heard of. "BYO everything" frameworks would be more appropriate, but even then, Flask brings with it an entire basement of sub-frameworks that I would argue make it so that you might as well just use a full-fledged framework like Django.
We use Flask for most things at my work; while it can have many dependencies, you usually don't need that many. Of course, you'll bring some in for certain tasks that your app needs to do, but especially for little doodads that just need to present a RESTful interface to some service, this usually isn't that many (or if there are many, they'll mostly have to do with the service, and not the app). Of course I don't know the details of your project. Either way, the advantage of a minimal framework like that is having the ability to easily install just what you need, so obviously that advantage is going to be less and less the more it is that you require it to do.
That's how it works with micro-frameworks, you pay for what you use. Now, it's not necessarily a problem, last time I checked, there was a decent list of functional Flask components. What do you feel is the advantage of having a huge 'contrib' folder, as long as the extensions are maintained? Because the advantage of not having an ORM bundled per default, and easily switching something like the templating language are pretty clear to me.
I have a django project that swapped out the django templates for mako. Mako templates are awesome to use. The problem is it becomes extremely difficult to use packages that have bundled templates of their own. I would think it'd be the same with flask, no?
Making assumptions about the available ORM and templating package allows 3rd party modules to do more of the work for you.
Jinja 2 is a Flask dependency, it is always configured, so that's a bad example (though I have to confess that I don't know how a Flash webapp with a different templating engine works with an extension using Jinja 2 for its views).
As for the ORM, yes and no. Many extensions have no need for it, but I think 99% of the others use SQLAlchemy, because it's the most popular. But if you want to make a website backed by a NoSQL solution, you don't need to depend on an ORM. Obviously, any extension based on SQLAlchemy will not work, but baking the ORM into the framework offers no solution to that.
..and every 3rd party module that contains their own models, which would be a very large number.
If you want to use SQL Alchemy, you're better off using a different framework. I'm currently trying to decide if this is the angle I should follow for my next project, which requires fairly sophisticated SQL (comparable to the django ORM anyway).
i just finished up a django project that also had "8 million" dependencies, the difference was a lot of them started with "django-" and some dependencies I would have liked to use were off the table.
But the fact they start with Django means you can expect
a) They will play nicely together.
b) There will be consistencies between the libraries.
c) Magic things like the Amdin interface will work.
(Is there any good replacement for Djangos Admin in another framework? Its amazingly powerful with a small amount of configuration).
> b) There will be consistencies between the libraries.
depends
> c) Magic things like the Amdin interface will work.
true
the workflow for this particular project seemed to go like this...
* get requirement from client
* search google for plugins/modules/etc
* choose some
* try to get them to work
* use them or fork them or find others
which to me seems a pretty roundabout way of getting something accomplished if you already know what needs to be done. it doesn't feel like programming, it feels to me like assembling things and testing/hoping there are no issues. I'd rather be programming.
Not necessarily. It's minimalism in terms of a framework (though in more objective terms I guess you would be right.) To me that means having not much more than a url router and a way to do MVC - no asset management, no HTML helpers, no ORM, no default templating language.
I'm surprised Slim Framework isn't listed under PHP though, is that not considered minimalist?
I think in many cases a good minimalist framework will get a core set of functions out of the way (in web for example: routing, autoloading, dependency injection, etc.). Grabbing something small that provides a proven but efficient backbone can let you focus on delivering core value, but then can easily be switched out later as the solution grows.
One would think that you wouldn't want to switch out a framework later. After all, your choice of network is one of the defining factors of how everything will work. Swapping it out means rewriting most, if not all, of your CRUD functionality and then doing a whole lot of regression testing. Doesn't seem very cost or time-effective.
Regression testing is inevitable, but with a minimal framework, you'll essentially end up rewriting the controllers, and part of the views. If you switch templating systems, modifying the views can't be helped. And the controllers should only be a glue between your view and the service layer, so it ought to be solely administrative code.
It's intention refers more to an easy-to-use, low overhead and already-written solution, because people either don't understand or don't want to invest the time anymore.
That's the "Fork" step he mentioned. The "Edit" button on GitHub automatically forks the project and dumps you into the Markdown editor. The rest of the steps are still required to get changes merged into a file.
Unsurprisingly (I think only a few dozen people know about it), the PHP framework I use isn't there: http://sifo.me It's a framework created by a friend of mine and it's used in quite a few actual businesses (including my own). I can't say I've looked around much in the PHP framework landscape in the last few years, so can't compare, but I'm really happy with it. Simple, flexible and powerful.
You get the minimal app controller/router similar to Express. And you can pick and choose Symfony2 (and other) components to add. It makes putting together an API for your front-end a snap.
For those interested in this approach, I've put together a boilerplate called PHANG that combines Silex and AngularJS: https://github.com/ErikAugust/phang
One of my favourite frameworks! I abandoned Rails for Camping when I saw how easily I could grok the entire framework. One thing I liked doing when building web apps was to rip out the View infrastructure so that I could more easily render alternative formats. I've written a couple of articles on Camping here [1], [2] that people might be interested in (be gentle, my writing wasn't as good 6 years ago)
https://github.com/aemkei/fishbone.js/ - A super lightweight (½kb) JavaScript library with automatic method chaining, automatic context binding, event support and simple inheritance. c-{{{-<
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.
We see this with a lot of new Ruby frameworks as well: composability over centralized organization. Javascript is going down this road as well.
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.