Comment by arianvanp | Hacker News Reader

Comment by arianvanp | Hacker News Reader

Parent Full thread

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.

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

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?

Reply on news.ycombinator.com