Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

List of minimalist frameworks

github.com

Post reply on HN
Print view View original

81–90 of 95 posts

Re: List of minimalist frameworks

#81

Post by sophacles »

collyw wrote: post #53
bowlofpetunias wrote: post #41

Earlier quoted context omitted.

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…

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.

Re: List of minimalist frameworks

#82

Post by tbatterii »

collyw wrote: post #79
tbatterii wrote: post #75

Earlier quoted context omitted.

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

> a) They will play nicely together.

depends

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

Re: List of minimalist frameworks

#83

Post by krapp »

collyw wrote: post #78
krapp wrote: post #69

Earlier quoted context omitted.

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

Re: List of minimalist frameworks

#84

Post by collyw »

sophacles wrote: post #81
collyw wrote: post #53

Earlier quoted context omitted.

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 flas…

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.

Re: List of minimalist frameworks

#85

Post by tbatterii »

collyw wrote: post #77
tbatterii wrote: post #71

Earlier quoted context omitted.

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 y…

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?

Re: List of minimalist frameworks

#86

Post by collyw »

jsmeaton wrote: post #67
mercurial wrote: post #59

Earlier quoted context omitted.

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 ar…

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.

I have been tempted to switch the Django ORM for SQL alchemy, but I would loose the Django Amdin interface.

Re: List of minimalist frameworks

#87

Post by ErikAugust »

For PHP - Silex is really awesome.

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

Re: List of minimalist frameworks

#88

Post by sophacles »

collyw wrote: post #84
sophacles wrote: post #81

Earlier quoted context omitted.

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 flas…

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.

Re: List of minimalist frameworks

#89

Post by asdasf »

lkrubner wrote: post #27

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, t…

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

Re: List of minimalist frameworks

#90

Post by mercurial »

jsmeaton wrote: post #67
mercurial wrote: post #59

Earlier quoted context omitted.

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 ar…

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.

Post reply on HN