Hacker News Reader

I agree about Flash/Django. But SQLAlchemy is definitely not "better". It is more powerful, more correct, more proper, more flexible. But boy is it a fucking obtuse, verbose, difficult piece of bahoo to use. Django ORM follows Django's philosophy of pragmatism. Assume sane defaults/be opinionated. Make the easy, everyday shit easy! The hard stuff can be figured out later (or just drop to raw SQL). SQLAlchemy's philosophy is to be correct, like RDBMA academic correct and proper. Make the insanely rare and/or difficult stuff possible even if it means making the common stuff a PITA.

It's like the difference between an esoteric and powerful language like Haskell which is objectively more correct. And Python, which is "who cares purity, it lets me get shit done fast and easy."

There's also, I think, a huge divide in the way developers think/reason about problems. Cause I've never seen anyone like both ORMs. Everyone likes/tolerates one and hates the other. I'm guessing some devs "think" the way SQLAlchemy works and others "think" the way DjangoORM works.

So, I do think both ORMs have their place. Just wish SQLAlchemy's place was not in code I have to write/maintain.

I like both ORMs, exactly for the reasons you mention. I wish SQLalchemy had a "simple" mode that resembles the Django orm API though yeah.

I'd wager it would be possible to implement the django ORM on top of SQLAlchemy.

Probably - as long as it didn't have to adhere to the unit of work pattern that Alchemy uses. I've considered trying to implement the Django ORM frontend on an Alchemy backend but.. time.

There was a project to do this back in the day.

I'm in the camp of liking SQLAlchemy, and not really liking Django's ORM, which I am admittedly much less familiar with. I especially find Django's functionality for aggregations to be completely arcane and a long way from the SQL that I am modeling in my head. I wonder if that's what it comes down to - as someone who tends to think in terms of the SQL I want to build I find SQLAlchemy to be a lot closer to my mental model than Django.

For just getting an object by ID I don't think there's much difference, for me.

I think one thing in Django's favour is that SQLAlchemy can be confusing to setup (do I need scoped sessions?). Also, you need to find and setup your own solution for migrations, whereas Django will just sort that out for you. So getting up and running is a lot easier.

> I especially find Django's functionality for aggregations to be completely arcane and a long way from the SQL that I am modeling in my head.

Do you mean https://docs.djangoproject.com/en/dev/topics/db/aggregation/ and https://docs.djangoproject.com/en/dev/ref/contrib/postgres/a... ? How would you improve it?

> But SQLAlchemy is definitely not "better". It is more powerful, more correct, more proper, more flexible.

Indeed - for my purposes, it's better. But I loves me' databases.

> And Python, which is "who cares purity, it lets me get shit done fast and easy."

Oh - ouch. It is possible to write quite pure python, y'know. But it allows you to break the rules when purity would just lead you down very obtuse paths. Or when your code is fundamentally side-effecty.

It is not practical to write pure python code. There's always the implicit state of a generator so lazyness is fucked. And you don't know whether you're passed a list or a generator and then you tuple-unpack it and the generator is empty. And then, of course, you can override the dot-operator and even bare statements can have side effects.

Have you ever tried to write really _pure_ python? I did and it is harder than it needs to be.

Fancy seeing you here njharman. And yeah I am working with a Sqlalchemy codebase right now, and it really really makes me miss django orm.

yo!

> boy is it a fucking obtuse, verbose, difficult piece of bahoo to use.

I have used SQLAlchemy a lot, and find it very easy to use. I've used other ORMs as well, in other platforms.

I find SQLAlchemy a very good ORM.

Maybe I have programmer Stockholm syndrome, but SQLA is one of the best ORM in existence. Period. I have spent a lot of time with it.

I think in terms of Python style and SQL and I think SQLA fits it better than Django ORM. Django ORM fits Django better. SQLA makes it easy to do OO style SQL modeling in a very Pythonic way.

I don't hate Django ORM. If I used Django I would use the ORM it comes with. It is ok. I think data is so important I avoid Django because I think its ORM becomes the limiting factor for medium or large projects. For small projects, it hardly matters. Use what you know or has a path of least resistance for you.

An aside, Pyramid is actually in between Flask and Django, but people often think it has to be Flask or Django. Pyramid is beautiful and much less opinionated than Django, but still has some batteries, or rather it supports several different types of batteries.

Practical programmers don't hate tools IMO. Makes you too vulnerable to overvaluing your opinion.

To be honest, SQLAlchemy was the single reason I chose to dive more into Python. I learnt it first because of being curious about it. Then, when I found SqlAlchemy, I, having had long years of using Hibernate and NHibernate, thought "if the other Python packages are as good as this one, i should use Python for serious stuff". Which I did.

SQLAlchemy is damn easy to use.

I've found sqla easy to use but it's documention is exactly how you describe. Often I have read a section a few times and still don't quite get it.

>More broadly, this is the whole opinionated vs. non-opinionated debate, and I've come to the belief that the vast majority of programmers need the guidance that an opinionated framework gives.

The vast majority of programmers need opinionated because they want to string together 15 or 20 different plugins to do ordinary things like CMS, rate limiting, caching, facebook/github authentication, csv export from the admin, drag and drop within admin, and hundreds of other things where you don't want to reinvent the wheel.

With Django there is a larger ecosystem and those modules tend to play better together, and they are pretty much equally loosely coupled. With Flask you get a few modules that use SQLAlchemy, some that use peewee and others like Quokka (flask CMS) that just decided to use mongo for the hell of it. That's the dark side of not being opinionated.

The "batteries included" argument is a red herring, IMO. It doesn't really matter that Django includes admin in the 'django' package and flask separates it out into 'flask-admin'. You don't have to use either if you don't want and being in a different package is orthogonal to coupling.

The magic argument is also sometimes a bit of a red herring too. SQLAlchemy, django ORM, django admin and flask admin all use tons of magic but everybody loves them. Magic is horrible in the wrong place but incredibly powerful in the right place. Rails gave it a bad rep because it used magic too much in the wrong places.

What about Django makes you feel it is the better framework? It's a great singular package, but basically everything in it is done better somewhere else. I'd take Flask's templates over Django's any day and Peewee or SQLA over Django's ORM as well. I never liked regexs for routing and as I've gotten older and liked regexs more, still don't like that approach - Flask's approach is better.

Django is nice for beginners cause you can say "learn this" and they've got a bunch of books and docs to go through, but having watched Django evolve over the last decade, it hasn't really changed from it's stable but boring and does nothing best manner.

They're both kind of dead tech anyway given enough time. Python isn't the best choice for today's websites. That being said, don't know what language/framework is the right thing to push on a beginner.

Integration, documentation and ecosystem. And together, weight heavily in the balance.

This.

If I tell someone to go away and write me a project in flask or a project in django, provided they "go with the flow", the django one will almost always be nicer. A sensible `manage.py` interface. Apps that can be built to be installable, read-only python packages rather than "here's a project repo, clone it, cd into it and run ./godknows.py".

It is of course possible to design such a project in flask, but it takes some work. The gravity is strongly towards "I am the world" projects.

I've also been very surprised at how much less community support there seems to be for flask. Googling/StackOverflow-ing an issue has tended to get me significantly fewer results, and of those results I do get far fewer of them seem to have (sensible) answers. In the django world there is a much broader coverage of generally-accepted sensible ways of doing slightly obscure things.

Being opinionated is a feature. It's just a feature that not all people agree on. But it is one, since it gives all the user a common ground to build tooling, write doc or tutorials and organize things.

This is a side effect of the FOSS community. We (I, included) believe we should have choice, diversity, openness, flexibility. We see only the good things in those. And it's easy to forget how much having one place to start and a clear direction to go to can help.

> So having used both, this is what I tend to say about them: some of Flask's commonly-used components are better than django's (SQLAlchemy notably), but altogether, django is a better framework.

Most Flask dev however, are unable to leverage the full power of SQLalchemy. They do miss the nice integration of the Django ORM, espacially the form generation, admin and fantastic app ecosystem that assumes you have a User object.

> Making a sane and maintainable project layout is not a particularly easy thing to do

+1000 on this. I noticed this as a dev AND a trainer. In the end, flask is great if you are either very beginer and want to do simple things, or very experienced. For all the rest, you want Django.

But the price to pay to enter the Django world is higher.

> It shouldn't be a shock to you by this point if I say that I don't think flask is particularly well designed either, but I won't go into my interface-by-interface rant now...

Well, the global objects such as request is one of my pet peeve... And the decision of a central "app" object make modularity kinda difficult, and blueprint feel like afterthoughts.

But flask also almost invented the whole @route API, which is really awesome.

> But flask also almost invented the whole @route API, which is really awesome.

-1000 on this. It's a side-effect-on-import nightmare. Not to mention scattering your url scheme all over your view modules makes it much harder to spot where your scheme doesn't make sense.

In my opinion.

It's declarative configuration, I don't see how more side effects you get than with the Django way.

Views "register themselves" as functions that should be called given a certain URL at import time. That is a side effect and it's horrible if you want to do anything more subtle. Way more "magic" than anything django does.

Django does the same thing. urls.py are imported automatically at startup, even if you run a regular manage.py command that doesn't run the server.

That's not remotely the same thing. In django, one specific file is looked for and imported if it exists, django then looking for an `urlpatterns` in it. No side effects anywhere. Just a default place to look for something, much like it does with models.py.

You can use regular routing instead of route decorators in flask, iirc.

  http://flask.pocoo.org/docs/0.12/api/#application-object
  add_url_rule

>But flask also almost invented the whole @route API, which is really awesome.

Hasn't that been inherited from bottle?

> But flask also almost invented the whole @route API, which is really awesome

Emphasis on the 'almost' :)

Turbogears was doing something similar with @expose about 5 years earlier.

Just want to point out since you mentioned it that turbogears is still out there, maintained, new releases, and a great framework.

> I strongly disagree with the notion expressed by some that beginners should start with flask "to learn how things work". Making a sane and maintainable project layout is not a particularly easy thing to do, >90% of people (not just beginners) will generally fuck it up somehow and end up living with a really weird app initialization routine as a result. Django's project/app layout and initialization is really quite well considered and I would say appropriate for 99% of projects. That 1% would probably be better off with flask.

I actually feel like this is why I recommend beginners start with Flask though. I think learning the mistakes and seeing the problems and pain firsthand let's you appreciate and hopefully understand the decisions that were made.

Of course, I should say I recommend it for something like a toy project that you don't intend to maintain. If it's something that's long term then I would agree that Django is likely to be the better choice.

In the end I suppose everyone is different in the same way some people recommend learning Python vs C as their first language.

> I think learning the mistakes and seeing the problems and pain firsthand let's you appreciate and hopefully understand the decisions that were made.

In my experience, people just don't. They just continue on oblivious thinking nasty code is just part of life. I think I'm lucky having gone to django first so that I'm able to see that things don't have to be nasty.

This is my experience too, looking through online communities based around React and it's tooling. The vast majority of people in these communities work with a few too many abstractions and a bit too much tooling, and are content just auto-piloting through their day to day, praying to god that the trendy stack doesn't change too soon.

Some people learn re-usable code patterns and concepts, the majority just learn APIs.

> In my experience, people just don't.

Agree. Most don't. Most learn best by example and by "partial imitation" not by 1st hand experience... Unfortunately :( This is why I find it frustrating when I try to teach people something the way I learned it best: 99% just "don't get it" if I go about it my way. And it's infuriating, I'd want to stuff them in a concentration camp and do some brain-reprogramming procedures on them!

I'm personally horrible at learning by example / by imitation / from others: you can show me 10 times how to do something and I'd still not get it! But make me experience the problem first hand so I can understand the "why" of the solution and all lightbulbs turn on instantly in my head! Or give me a good book with clear conceptual explanations and a set of problems/projects I can work through alone, and I'll learn in a day what others need a month to learn "by example"...

So for me it's definitely what the OP said, "learning the mistakes and seeing the problems and pain firsthand lets you appreciate and understand the decisions that were made" works incredibly well, especially when complemented with some well-written "design documents"!

I guess that's because some people learn best from experience (kinesthetic learning) while some people learn best from examples (rote learning).

Hmm... then I'll label myself a "conceptual-kinesthetic" learner, that'll surely confuse the hell outta' everyone.

It kinda makes sense, in a way what I'm doing in my head while learning is like "simulations of wrestling matches or gladiator fights between concepts" and keeping the pain and bloody mess in your head drives you slightly insane... guess if you put it this way I can grok why most people don't take well to this learning style... most don't enjoy bloody gladiator fights either... same as they don't enjoy being put to learn C or assembler first so they can actually feel the pain that higher level programming languages were invented to alleviate :)

I was never able to do what I wanted to do in Django. The moment you have something that even slightly breaks apart from the MVC model, it all breaks down. It's great for a blog or simple web app, but not much more than that.

In Django I always felt like I had to do things the Django way. In Flask I always felt like I was doing things the Python way.

Can you give a more concrete example? I have a fairly complex app in Django and it is in no way limited. What magic does flask let you do that you cant in django?

- Using a graph database such as Neo4j is a mess with Django and you can't make use of Django's ORM

- Using something that's not a database (e.g. ElasticSearch) and where you prefer speed over ACIDity also sucks because you probably don't want to use an ORM.

- Django's stubbornly-rigid MVC model sucks for building reactive web apps.

- If your structure is an API back-end that serves up JSON, and static JavaScript front-end that makes API calls to access data as needed, with appropriate API call restrictions, caching, and so forth, Flask is much more suited to this task. Doing this in Django just feels like you're swimming upstream the whole way. Django's ORM is also inefficient if you're dealing with a lot of data and only want to serve a small subset of it.

Yes, there have been improvements on all of these fronts with various Django projects, but a lot of the time Flask just gets the job done easier without the bloat.

I agree that if your server is just serving a JSON API, you're probably not using 90% of Django's capabilities. So you might as well use Flask instead.

But as for non-relational databases or other external systems, Django does not help you nor hinder you in any way. If you want to connect to, say, Redis - the code would look the same under Django and under Flask. You simply don't use the ORM for those things, since it's irrelevant. You use the appropriate client library for connecting to the external system.

ORM stands for Object Relational Manager. I wouldn't expect to use a graph database with it. Its possible to use Django without the ORM, and is in no way required. Haystack integrates Django with Elasticsearch.

I have to say that Django-rest-framework's features blow Flask out of the water in terms of building maintainable, reusable REST enpoints.

That makes sense about project organization done correctly.

The thing that really stands out about Flask to me (using it for small projects, I don't really get to use Python at my day job) is that the codebase is incredibly easy to understand in it's entirety. Anytime I have needed to look something up I can go to the code and usually understand it within a minute or so.

I'd classify myself as a mediocre programmer by big tech company standards and Flask is very easy for me to understand and use.

I would think most Django projects are easy to read also. Part of Python generally...

I think the parent meant the codebase of flask itself.

I have a horrible time reading the Django-based project we support at work.

while Django's outer layer is pretty great, the innards are somewhat messy.

This is mostly around performance reasons, but also a lot of hard-to-follow code paths.

Though a lot of Django projects can take this and make very clean code, it can bite you when you go deep enough into certain things.

You should have a look at the monster my team maintains at work. Even with a good framework and one of the most readable languages some people still manage to produce a mess. Some of the worst code I have seen has been by Python users (narrowly beaten by unindented Perl).

I would have to agree with you, there's no point in learning Flask if you're going to do Django projects. Things don't translate well between the two. I like both frameworks, for different things, but you shouldn't try to do a Flask application in Django.

To benefit from Django, you need to do exactly what the documentation want you to do. You'll be happier, everything will be easier and you write a LOT less code. I tried fighting Django, because I didn't agree with some of the design decision, especially in the Django Rest Framework. The result was a worse product, too much and too complex code. The rewritten version did everything "The Django Way". It took less time, and the result was infinitely more understandable and testable.

> >90% of people (not just beginners) will generally fuck it up somehow and end up living with a really weird app

tbh I've seen this plenty of times regardless of whichever framework people choose. At least with Flask the original developer sometimes gets a twinge of 'hmm this seems like a lot of work & might be a mistake'; Django smooths it over so you end up with cached property counts for things which are trivially computable from the DB (+the associated invalidation bugs).

> Django smooths it over so you end up with cached property counts for things which are trivially computable from the DB

Uuuh I've never encountered this problem

I guess you've never had to support someone else's/a 3rd-party vendor's code.

> It is said that flask doesn't try to suggest any particular structure for your project, but I would say that the effect of that the majority of the time is to produce a project with no structure.

Don't blame Flask, blame whoever hired mediocre developers in your company. No framework that "enforces" things will compensate for bad human capital.

I'm not sure why you're getting down-voted. You're (mostly) right.

Though it tends not to be a black and white decision. More of a sliding scale between how badly you want shit done and how much you're willing to sacrifice for that. 10 programmers with an ultra-opinionated library will get more work done than 2 good ones with proper tools for the job. They'll get the finished product fairly close to as good for a fraction of the cost.

Almost every business is time constrained in some way. Sometimes you have to make a conscious decision to hire people that are just "good enough" and write "good enough" code. Sometimes you just don't have a choice in the matter if the talent market is sparse.

> 10 programmers with an ultra-opinionated library will get more work done than 2 good ones with proper tools for the job

Maybe. But if the "2 good ones" cost less than 5 times the rate-per-hour than the so-called "mediocre" ones, i'd hire the good ones without hesitation. And in real life, it is that way, at least here the rph factor is 3x at most, usually 2x.

This topic it's worth a HN thread of its own, really.

Oh don't get me wrong, I'd hire the good ones in a heartbeat. I was just saying I can see why managers like the strategy of going with something like Django then hiring a bunch of cheap "Django" programmers to whip up a CRUD app.

Are we in lake Woebegone, where all developers are above average? Odds are, your company is going to hire mediocre developers. Odds are, you are a mediocre developer. An average or mediocre developer is not bad human capital. It's the only kind of human capital you can reasonably expect to have access to.

I am the one who hires devs at my workplace. Have recruited for years.

I would never call my devs "mediocre". If they were, I was to blame.

I guess i live in lake Woebegone, according to you.

Yes, I think so.

There is nothing wrong with cheerleading (we are better than the competition). But there is something wrong with drinking your own kool-aid.

Then again, you might have all above average programmers working for you -- it's certainly possible to arrange that if your engineering department is very small, and for one instance in time. But the odds of that diminish very rapidly as your company becomes more successful and the size of your engineering department grows. And the idea that no one at your company is mediocre is just crazy. I've seen a lot of start ups, and all of them had some below average people, not to mention mediocre people -- even the very good start ups. Moreover, if you do have good people then your company will grow, possibly rapidly, at which point it's pretty much impossible to beat the market long term -- e.g. to consistently have above average developers while at the same time growing in size. Of course that doesn't stop everyone from saying they are above average, just like every kid needs a trophy and a good grade.

But if you are really responsible for engineering, you will be focused on building an architecture and processes that work well for average people and that can be resilient to even below average people, because you either have them on your team now or will have them in the future, whether you like it or not.

You can't just pretend these people don't exist. The bulk of the developer population are what could be called mediocre. Heck, I'd class myself as fairly mediocre. You will end up working with these people or inheriting a project that was started by one of then sooner or later.

> I strongly disagree with the notion expressed by some that beginners should start with flask "to learn how things work". Making a sane and maintainable project layout is not a particularly easy thing to do

For help with this: https://www.starterkit.win/

Do you think Flask would be any better a choice for a smaller project?

No. It is a common mistake thinking that Flask is simple so it's better for small (simple) projects. Flask is very flexible. I would say too flexible. It can be useful for very complex projects but in 99% projects, Django is better. You can be sure that everything will work together.