Live data from Hacker News

Django 2.0 released

docs.djangoproject.com

41–50 of 177 posts

Re: Django 2.0 released

#41
post #4

This is probably your best bet if you're just going to build a nice CRUD frontend for a business app, possibly with an API (via DRF). I am doing this right now on a project as it's the shortest path to a win. The API however is written in Java 8 / vertx.

Also APIStar from the creator of DRF is something to keep an eye on. It has Django integrations and I believe is async.

It's not inherently async, but it supports async. Although database support for that isnt great, so I'd recommend just sticking to synchronous stuff for now unless you don't mind using raw SQL.

If it were me, I'd probably use something else before I tried to squeeze that much performance out of Python at this point to though. I hope library support catches up and it becomes more convenient, but I don't think a predominantly synchronous ecosystem has really successfully transitioned to async before.

Re: Django 2.0 released

#42
post #21
post #4

This is probably your best bet if you're just going to build a nice CRUD frontend for a business app, possibly with an API (via DRF). I am doing this right now on a project as it's the shortest path to a win. The API however is written in Java 8 / vertx.

I would rather use Flask for that.

Flask for a CRUD ?

I'd agree with you for a very simple API (like a simple slack/irc bot), but for a CRUD, you'll need to write a LOT of boilerplate code with Flask

Re: Django 2.0 released

#43
post #4

This is probably your best bet if you're just going to build a nice CRUD frontend for a business app, possibly with an API (via DRF). I am doing this right now on a project as it's the shortest path to a win. The API however is written in Java 8 / vertx.

> as it's the shortest path to a win. Rails is the "shortest path to a win". Django is well made, but it just hasn't had the same level of focus on RAD or the same level of intensity of community support. Edit: My goodness there are some insecure, vindictive Django advocates here! What I wrote above is the truth and no level of tribalism can change it.

But the trade-off isn't usually worth it.

The time you save initially you'll later spend fighting the framework or debugging its internals.

Python's "explicit over implicit" scales a lot better, especially with large teams.

(personal opionion of someone maintaining production-critical Django and Rails applications)

Re: Django 2.0 released

#44
post #26

Respect to the Django team that even after 12 years they have only one major version shift (which seems to only because of dropping support for Python 2) and the backwards incompatible changes are minimal.

There have been lots of breaking changes along the way. Django is pretty good at giving developers a heads up of what is deprecated and slated for removal, but there have been lots of growing pains in the 1.x release cycles.

I really dread upgrading Django. We have a codebase that has been with us since the 1.3 days and each time there's an upgrade, someone on the team sets about one month aside to deal with all of the breakage. You could say that this is our fault for "doing it wrong" but we just wanna get stuff done. Sometimes the only way to do it that we could figure out was by doing something that Django later decided we shouldn't have done.

Going to Python 3 is going to be the biggest annoyance yet.

Re: Django 2.0 released

#45

Earlier quoted context omitted.

I’d posit that a simple crud app would take an order of magnitude less time with Rails. I’ve been a Django developer since 0.96 and have built dozens of apps with it. After transitioning to Rails, it’s hard to justify the use unless you’re in an evironment that absolutely must use Python.

How about performance? Bugs that might come up due to the implicit nature of Rails? Just curious, since you have seen both sides.

The implicit “magic” thing isn’t a real thing. It’s a fallacy. I have not come across real world problems like this.

Re: Django 2.0 released

#46
post #35

Earlier quoted context omitted.

> This is probably your best bet if you're just going to build a nice CRUD frontend for a business app, possibly with an API (via DRF). If I had to choose a framework for a web API these days, I would go with something that is async from the ground up.

Why? Async isn’t cost free - it’s more complicated and that complexity comes at a cost. If your company has only basic needs, you have to question whether you’re providing the best value for your company by doing anything more.

Especially when a platform doesn't have libraries that support it fully. Node and ASP.NET are the only fully async platforms I'm really aware of where this isn't a huge problem. Of course there are others with great but not async concurrency models as well. Regardless, it's definitely a minority of use cases where the concurrency model should even be a priority.

Re: Django 2.0 released

#47
post #43

Earlier quoted context omitted.

> as it's the shortest path to a win. Rails is the "shortest path to a win". Django is well made, but it just hasn't had the same level of focus on RAD or the same level of intensity of community support. Edit: My goodness there are some insecure, vindictive Django advocates here! What I wrote above is the truth and no level of tribalism can change it.

But the trade-off isn't usually worth it. The time you save initially you'll later spend fighting the framework or debugging its internals. Python's "explicit over implicit" scales a lot better, especially with large teams. (personal opionion of someone maintaining production-critical Django and Rails applications)

FWIW I've never had these issues with Rails, though it does make sense that this would be more common with Rails than most things.

Re: Django 2.0 released

#48
post #44
post #26

Earlier quoted context omitted.

There have been lots of breaking changes along the way. Django is pretty good at giving developers a heads up of what is deprecated and slated for removal, but there have been lots of growing pains in the 1.x release cycles.

I really dread upgrading Django. We have a codebase that has been with us since the 1.3 days and each time there's an upgrade, someone on the team sets about one month aside to deal with all of the breakage. You could say that this is our fault for "doing it wrong" but we just wanna get stuff done. Sometimes the only way to do it that we could figure out was by doing something that Django later decided we shouldn't h…

I have been writing Django professionally since 2013, It's ain't that bad. Our codebase is huge & it never takes us more than 2 weeks to do it and lately, it has always gotten less and less. Wonder if the issue is with your codebase that it breaks so much on upgrades.

Python3 upgrade is a task, agreed. But it actually gives good returns. The language is nicer to write in and we even saved some memory and CPU on the same load after the upgrade. So highly recommended.

Re: Django 2.0 released

#49
post #44
post #26

Earlier quoted context omitted.

There have been lots of breaking changes along the way. Django is pretty good at giving developers a heads up of what is deprecated and slated for removal, but there have been lots of growing pains in the 1.x release cycles.

I really dread upgrading Django. We have a codebase that has been with us since the 1.3 days and each time there's an upgrade, someone on the team sets about one month aside to deal with all of the breakage. You could say that this is our fault for "doing it wrong" but we just wanna get stuff done. Sometimes the only way to do it that we could figure out was by doing something that Django later decided we shouldn't h…

Huh. At my last job, we went from 1.7 to 1.11 and while it wasn't seamless, I suspect we spent about that much actual work time making upgrade-related changes/fixes (120ish person-hours) for all of those upgrades combined. We hadn't jumped to Python 3/Django 2 before I left, but we were starting to plan for it. I knew it was going to be painful, but that's part of the cost of holding out for so long, isn't it?

Re: Django 2.0 released

#50
post #38
post #32

Earlier quoted context omitted.

The advantage of Django is it comes bundled with everything you could need. Flask is simple, but then you need user authentication. Which library do you use? Is it updated and maintained? What about an ORM, forms, templating, localzation. Do they all work together? Suddenly it's not so simple. That being said, if your app really is simple (single file, under 100 lines) flask is excellent.

If your app is that simple, Bottle is probably a better fit than Flask (even more minimalist and non-opinionated).

Flask is a great fit with smaller APIs but not tiny like this in my experience. Great support for SQLAlchemy and database migrations. Better than Django ORM in my opinion.
Post reply on HN