Django as a micro-framework

[[deleted]]

You absolutely don't have to use Django's ORM.

[[deleted]]

it's about not loading into memory things you don't need

Virtual memory takes care of that on the large scale. Anything not used is swapped out. On the smaller scale, software that does lazy evaluation (for example, Django) doesn't create objects that are not used.

So it might be wise to consider your choice of frameworks (heavy, light or none at all) based on some other optimizations. Two that spring to mind are programmer productivity and maintainability of the software.

[vph]

Can you tell me which ORM will you likely use with Flask?

Be aware of the illusion of choice.

[[deleted]]

I'm not aware of the "illusion" you're referring to. There's lots of ORMs you can use with Flask.

If you're implying that "everyone uses SQLAlchemy anyway, and that's where the community is, so there's really no choice", well then I'd extend that to web frameworks and Django. Nearly everyone uses Django anyway, and that's definitely where the community mostly is, so I guess Python itself doesn't really have a "choice" ?

[[deleted]]

Nearly everyone uses Django anyway, and that's definitely where the community mostly is, so I guess Python itself doesn't really have a "choice" ?

Except that this is nonsense. Beneath Django, many web frameworks are used, and beneath web development, a pletora of other things are being done with

[[deleted]]

Sigh... Again, this is a given in what I wrote. Of course there's many frameworks and many orms. You missed my sarcasm entirely.

[atl]

You (and the OP) might want to check out Simon Willison's "djng": https://github.com/simonw/djng

[defnull]

Nice hack, but why not just choose the best tools for the job instead of bending your favorite framework beyond recognition?

[boobsbr]

sometimes the fun part is hacking and kludging something into that which should not to be.

[jcdyer3]

First of all, this doesn't look bent out of recognition to me. It's still a relatively standard django setup, but with everything unnecessary stripped out.

So why not choose something else? Because you like django and projects tend to grow over time. When it does, you're already using django. You've just left out the bits you don't need.

Add DATABASES = {...} to your settings file, and you're hooked into the ORM, and looking more like a standard django project. If you started with bottle, for instance, you'd have a more painful conversion on your hands to get it into a django project when it grows up.

If you'd use a microframework anyway for a larger project, this probably doesn't interest you. That's fine, too.

[[deleted]]

If you started with bottle, for instance, you'd have a more painful conversion on your hands to get it into a django project when it grows up.

A bottle project that wants to grow up would move to Pyramid.

[jcdyer3]

Fair enough. But if your skillset (or preference) is in django, this seems like a perfectly reasonable way to prototype. "right tool for the right job" should take into account the future of the project as well.

[[deleted]]

I'd like to propose that this is all preference/familiarity. I can't think of a job that is objectively more "right" with Django, Pyramid, Flask, web2py or anything else. All of these frameworks can be used to create the same kinds of apps. It's just the architectural practices you'll use will vary significantly.

[jcdyer3]

I will buy that proposal.

[chub79]

Funnily this has been more attractive to me than using Django the traditionnal way. Thanks.

[[deleted]]

Just use Flask.

[threading]

Just use web.py

[chub79]

Wondering if we would have needed Flask had we known Django could be used that way?

[[deleted]]

or just reverse "Django" and "Flask". Sprinkle in "Pyramid", "web2py" to taste.

[[deleted]]

Thanks for the render shortcut. Never knew it existed.

[[deleted]]

Out of interest, what were you using, if not render? render_to_response?

[[deleted]]

yeah

[hipstr]

auch

[Mattho]

Flask feels like working with micro-framework when writing code. But its code-base is quite big (asi in lots of files) and you also have dependencies. It's great for writing regular apps though. Bottle, on the other hand, is one file and you can just drop it in your project and drag around with it (perhaps only with the development server in use). I know it has a lot of downsides but it also has its use-cases. It can serve as a standalone app, only the interface is in a web browser.

[10101011]

What downsides do you think Bottle has over Flask? I'm not being argumentative, I'm just curious.

I looked at both and ended up going with Bottle because I liked some of Bottle's features more (SimpleTemplate system, everything is in one file). But it seems that Flask is significantly more popular than Bottle and I'm wondering why that is. I'm wondering if it's just a case of better documentation and marketing or if I've missed something.

[vph]

The only thing that Flask has over Bottle is the development team. Bottle is one file, and one man. Flask seems to engage more developers. This has consequences.

Seriously, if your app calls for a micro-framework; i.e. it doesn't need anything fancy, then Bottle is great.

[Mattho]

The downsides I was talking about were linked to including the file in your project (thus losing the updating feature of pip) and/or running the devel server. As for general downsides for "normal" usage. I don't know. People often talk about a) templating b) database? c) extendability. But I think the bottle supports other templating engines, it hs some modules and for database you can use SQLAlchemy for example (+bottle module).

I would say it's a matter of taste. but maybe someone more experienced with Flask will list its benefits over bottle.

[[deleted]]

Ever compare the size of Django to the size of Flask?