Hacker News new | past | comments | ask | show | jobs | submit login

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.

A fantastic example of this (in javascript) is trending right now on hackernews – myth.


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...

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?

> Less dependencies, as more is included out of the box.

Or... more unnecessary dependencies you're forced to code around if you happen not to want or need them.

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.

Errm... then I fail to see how 'myth' isn't just a wrapper around 'rework'?

That's exactly what it is, and that's the beauty of it.

There is no trend towards lighter frameworks.

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.

I don't know what to say about someone wanting to not learn, other than the old metaphorical:

"when all you have is a hammer, everything looks like a nail"

I suggest trying out some screwdrivers for a while.

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.

there's middle ground between something heavy like django and CGI/WSGI, I think they are called micro frameworks.

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).

I loved those days. :)

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.

I haven't done any programming in Clojure for years but that looks really useful. It almost makes me want to start up Emacs and install Leiningen.

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.


Alternative: The iMacros addons for Firefox, Chrome or IE. Not exactly an autofill replacement, more like a macro recorder for web browsers.

I couldn't agree more.

>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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact