Django 2.0 released(docs.djangoproject.com)
docs.djangoproject.com
Django 2.0 released
https://docs.djangoproject.com/en/2.0/releases/2.0/
176 comments
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.
Going to Python 3 is going to be the biggest annoyance yet.
That's surprising to me as I have updated a large production Django code-base on my own for every version from 1.5 to 2.0 and it has never taken me more than a day, with an equal or lesser (typically lesser) amount of time dedicated to deprecations when I updated to the previous version. Any blockers past that point have always been due to slow-to-update third-party libraries.
The Python 3 update took longer and had a longer legacy of surprise breakages, but I don't ding Django for following the intended life cycle of Python.
The Python 3 update took longer and had a longer legacy of surprise breakages, but I don't ding Django for following the intended life cycle of Python.
> That's surprising to me
I'm surprised you're surprised. Have you seen the size of the breaking changes documented with each release notes? We typically hit about 10 of these changes per release, sprinkled all over our code.
https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar...
https://docs.djangoproject.com/en/2.0/releases/1.9/#backward...
https://docs.djangoproject.com/en/2.0/releases/1.8/#backward...
And those are just the intentional breaks. We find a lot of unintentional breakage too, and sometimes we accidentally use undocumented stuff which of course also isn't documented when it breaks. Each Django release has added an average of 32 commits per release for the past four releases just to deal with the version upgrade.
I'm surprised you're surprised. Have you seen the size of the breaking changes documented with each release notes? We typically hit about 10 of these changes per release, sprinkled all over our code.
https://docs.djangoproject.com/en/2.0/releases/1.10/#backwar...
https://docs.djangoproject.com/en/2.0/releases/1.9/#backward...
https://docs.djangoproject.com/en/2.0/releases/1.8/#backward...
And those are just the intentional breaks. We find a lot of unintentional breakage too, and sometimes we accidentally use undocumented stuff which of course also isn't documented when it breaks. Each Django release has added an average of 32 commits per release for the past four releases just to deal with the version upgrade.
Some things to do that could help everyone (this is what I do):
If documented stuff changes, Please report it (though that likely means testing against the alpha / beta versions (or just master). Keep Django honest.
If you find yourself using undocumented features, consider documenting them; that way they’re held to backward compatibility.
Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.
Disclaimer: Core dev now, though I had this attitude before that too.
If documented stuff changes, Please report it (though that likely means testing against the alpha / beta versions (or just master). Keep Django honest.
If you find yourself using undocumented features, consider documenting them; that way they’re held to backward compatibility.
Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.
Disclaimer: Core dev now, though I had this attitude before that too.
> Also, follow the development of Django and comment on the intentional breaks if you think they’re not worth changing.
I really don't want to be sucked into Django's drama:
https://us.pycon.org/2015/schedule/presentation/381/
I've encountered very little sympathy from Django developers. Everyone seems to have just accepted that it breaks often and it's totally my fault for not keeping up with the breaking changes. Everyone seems to think that Django breaking compatibility all over the place is good, proper, acceptable, and inevitable. Nothing is sacred, anything can break, and make sure you go through that list each release to see what you have to change in your code.
This makes me sad and frustrated.
http://stevelosh.com/blog/2012/04/volatile-software/
I really don't want to be sucked into Django's drama:
https://us.pycon.org/2015/schedule/presentation/381/
I've encountered very little sympathy from Django developers. Everyone seems to have just accepted that it breaks often and it's totally my fault for not keeping up with the breaking changes. Everyone seems to think that Django breaking compatibility all over the place is good, proper, acceptable, and inevitable. Nothing is sacred, anything can break, and make sure you go through that list each release to see what you have to change in your code.
This makes me sad and frustrated.
http://stevelosh.com/blog/2012/04/volatile-software/
I hear you, and I've heard others say the same.
I think it would help if you bring it up on the Django-developers mailing list, if you haven't yet. I think that would help raise awareness about the issue, and I hope it would lead to some policy changes.
I think it would help if you bring it up on the Django-developers mailing list, if you haven't yet. I think that would help raise awareness about the issue, and I hope it would lead to some policy changes.
My guess here is that still being in Python 2 makes this more difficult.
If you're in Python 2 the bytes/str story is still mixed up, so API solidification happening in Django iteratively (in preparation for Django 2.0) will likely break a good amount of your code.
Inversely, we moved over to Py3 in the 1.7 days so we were spared some pain on that end.
If you're in Python 2 the bytes/str story is still mixed up, so API solidification happening in Django iteratively (in preparation for Django 2.0) will likely break a good amount of your code.
Inversely, we moved over to Py3 in the 1.7 days so we were spared some pain on that end.
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.
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.
Saved some memory and CPU after the upgrade? Could you give some numbers?
https://thenewstack.io/instagram-makes-smooth-move-python-3/
How has Python 3 performed since then?
"Ding: We did not have performance gain expectations for Python 3 right out of the box.
So it was a pleasant surprise to see 12 percent CPU savings (on uswgi/Django) and 30 percent memory savings (on celery).
It’s only been four months since rollout, we don’t expect to see constant 10 percent performance improvement, but that was a very promising start."
How has Python 3 performed since then?
"Ding: We did not have performance gain expectations for Python 3 right out of the box.
So it was a pleasant surprise to see 12 percent CPU savings (on uswgi/Django) and 30 percent memory savings (on celery).
It’s only been four months since rollout, we don’t expect to see constant 10 percent performance improvement, but that was a very promising start."
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?
> You could say that this is our fault for "doing it wrong"
Do you have decent test coverage and use tox to run your tests against multiple versions of Django?
If not I can recommend this approach from experience.
Do you have decent test coverage and use tox to run your tests against multiple versions of Django?
If not I can recommend this approach from experience.
I am currently upgrading a code base from 1.4 to 1.5.12 as a weekend project.
On the plus side the original authors managed to avoid using Django features so that makes it a bit easier. Someone actually wrote their own ORM in the process
On the plus side the original authors managed to avoid using Django features so that makes it a bit easier. Someone actually wrote their own ORM in the process
Given the functionality Django offers, the "cost" of the growing pains has been well worth it. Especially for the 1.7 upgrade that happened a while back (when they introduced the new migrations framework). Relative to modern JS projects, where whole frameworks are switched out quarterly, maintaining a Django project is trivial.
I really like the new URL syntax they introduced. I'd been relying on 3rd party libraries like Django REST for years at this point, because the raw regex URL syntax was always annoying and verbose. The new syntax looks well executed.
I've been working with 1.11 and Python 3, so I'm looking forward to upgrading soon.
I really like the new URL syntax they introduced. I'd been relying on 3rd party libraries like Django REST for years at this point, because the raw regex URL syntax was always annoying and verbose. The new syntax looks well executed.
I've been working with 1.11 and Python 3, so I'm looking forward to upgrading soon.
The plan going forward is to make every third release semver-major, but these will still be incremental releases. The semver-major ones will be backwards-incompatible only in that they'll drop support for features that had already been deprecated for at least two releases.
Right. It’s a change in version numbering scheme. Not any major backwards compatibility. It will bump every two years from now on.
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’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.
Interesting. What would you say is the biggest reason for this >10x development speed difference?
Django forces you to declare everything. Lots of manual boilerplate. Example, you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database. You can run rails on an existing db for example if it follows what are widely used conventions such as lowercase model name is the table, foreign keys are foo_id, etc...
This is where people fear the “magic” of things like pluralization of models to table name and introspection... but it’s all just code! You can read it and look at it and understand it. No magic here. Just convenience and a smaller mental model as an end developer.
Also... resources as a first clsss citizen is the biggest reason and the reason it defeats Django for this use case. You define ‘resources’ in your routing layer instead of just routes that map to a function. This allows you represent multiple crud actions with a single controller and even nest them, all with a few lines of code. Then you get access control for free on your sub resource, knowing you’ve already passed the parent checks and have that context.
Example: /users/:id/photos/:id
In this case, my Photos controller will already know who the user is (and if they can view these photos) based on work that the parent did. It’s single responsibility principle. You can even have a top level photos resource devoid of the user context and support both cases with minimal effort.
Yes, you can do these things in Django. But it’s not designed to make these things composable and seamless. I’d argue it’s not REST-friendly. Don’t even get me started on Django Rest Framework which is a massive beast in and of itself.
You get all of that out if the box on Rails. You can stand up extremely robust and ergonomic API’s with so little code you’ll feel like your cheating.
I should probably write a blog post.
This is where people fear the “magic” of things like pluralization of models to table name and introspection... but it’s all just code! You can read it and look at it and understand it. No magic here. Just convenience and a smaller mental model as an end developer.
Also... resources as a first clsss citizen is the biggest reason and the reason it defeats Django for this use case. You define ‘resources’ in your routing layer instead of just routes that map to a function. This allows you represent multiple crud actions with a single controller and even nest them, all with a few lines of code. Then you get access control for free on your sub resource, knowing you’ve already passed the parent checks and have that context.
Example: /users/:id/photos/:id
In this case, my Photos controller will already know who the user is (and if they can view these photos) based on work that the parent did. It’s single responsibility principle. You can even have a top level photos resource devoid of the user context and support both cases with minimal effort.
Yes, you can do these things in Django. But it’s not designed to make these things composable and seamless. I’d argue it’s not REST-friendly. Don’t even get me started on Django Rest Framework which is a massive beast in and of itself.
You get all of that out if the box on Rails. You can stand up extremely robust and ergonomic API’s with so little code you’ll feel like your cheating.
I should probably write a blog post.
Rails is definitely more convenient to prototype, but the magic issue is real. You never know where a variable or a function comes from by reading the source -- you'd need to run a debugger to do that (in Python you can just follow the import statements). The overall Rails architecture feels convoluted and unnecessary complicated (Railties, Engines etc). I also dislike the fact that there is no single source of truth for data in Rails. You have schema.rb, but you can't edit that directly, it is generated by running `rails db:migrate`, so one might say that migration files are a single source of truth, which is inconvenient: I need to generate a migration, then edit the migration file to add any modifications not supported by generator script and finally add accessor and validators in model file. In Django we have a model definition as a single source of truth (data model, validations). Also, once I've created (or updated) a model definition, I run `manage.py makemigrations` and all necessary migrations (which capture the current data model state + what's necessary to do to perform a database migration automatically) are created automatically. I also like the fact that in Django data integrity is enforced by default.
Though, when it comes to prototyping, I think Rails is a much more convenient option. In Rails I can launch a working CRUD app with authentication in 10 minutes, literally. In Django I have to manually create directory structure, manually specify each route mapping, create and program controllers (views), etc. Django doesn't even have a built-in authentication templates, only controllers (views), so I end up writing this boilerplate over and over again. The other thing is that the authentication requires a username and password, which feels kind of clumsy, when every other authentication relies on email and it is not very trivial to modify that (built-in admin dashboard relies on built-in authentication for example).
Though, when it comes to prototyping, I think Rails is a much more convenient option. In Rails I can launch a working CRUD app with authentication in 10 minutes, literally. In Django I have to manually create directory structure, manually specify each route mapping, create and program controllers (views), etc. Django doesn't even have a built-in authentication templates, only controllers (views), so I end up writing this boilerplate over and over again. The other thing is that the authentication requires a username and password, which feels kind of clumsy, when every other authentication relies on email and it is not very trivial to modify that (built-in admin dashboard relies on built-in authentication for example).
Example, you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database
Someone still had to create that database with those tables in it. It didn't magically pop out of the aether. Your complaint, then, is not "you must define every bit", but with where you do it, since you have to define things no matter what.
And if you have an existing database you'd like to use with Django, 'manage.py inspectdb' will reverse-engineer a set of model definitions from it.
Someone still had to create that database with those tables in it. It didn't magically pop out of the aether. Your complaint, then, is not "you must define every bit", but with where you do it, since you have to define things no matter what.
And if you have an existing database you'd like to use with Django, 'manage.py inspectdb' will reverse-engineer a set of model definitions from it.
> you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database.
If you have an existing database, sure, Rails is preferred. If you're starting from scratch, the Django definitions can create the tables for you. If you do have existing tables though, you can use inspectDB to have Django create the models for you.
If you have an existing database, sure, Rails is preferred. If you're starting from scratch, the Django definitions can create the tables for you. If you do have existing tables though, you can use inspectDB to have Django create the models for you.
I enjoy having a well-structured framework that saves me time and does not need to be spoon-fed. But I have a theory that no programmer ever died from writing an import statement.
Have you tried Django’s inspectdb?
Just wanted to anecdotally affirm whalesalad's experiences with my own. I desperately wanted to like Django more than Rails (I just really appreciate python as a language), but I find projects much quicker to build in Rails. It really is the convention-over-configuration magic that makes the difference. There's less to do in Rails to add commonly used web/crud functionality - but it's much less explicit and relies on you getting all the conventions correct. Rails is really the only framework that I've found fairly hard to learn, simply because you have to memorize the conventions to know e.g. where to pluralize and what magic helper methods will have been auto-generated.
It should be noted I've never worked on a large Django project - I suspect once a site's data structure and main functionality has been nailed down and you get a larger team involved, Python and Django's 'explicit is better than implicit' design philosophy will start to provide increases in efficiency.
I feel like you can tell a good rails developer by finding who thought it was hard to learn. There really is a lot you need to know under the magic, and if you can learn to create compatible magic in your own code the framework becomes incredibly extensible.
My Rails projects have always been the ones that felt the most done on their initial release. That extra time not typing and configuring goes into caching, validation, UX, and making nice solutions to project specific problems that fit nicely and don't become pain points as time goes on. All these things that can feel shortchanged in other projects get more of the polish they need sooner.
My Rails projects have always been the ones that felt the most done on their initial release. That extra time not typing and configuring goes into caching, validation, UX, and making nice solutions to project specific problems that fit nicely and don't become pain points as time goes on. All these things that can feel shortchanged in other projects get more of the polish they need sooner.
I've worked on a handful of large to very-large Rails apps, and I find that after a certain level of size, you're dealing with a Ruby code base that happens to have Rails as the way it is presented. Rails' implicit functions are either obvious because you use them often, or just not relevant, since you're deep in plain Ruby objects implementing your business logic.
Python - Django
Ruby - Rails
PHP - Laravel
all nice choices
Ruby - Rails
PHP - Laravel
all nice choices
And if you don't mind the learning curve (which will make you a better thinker!), I would add
Elixir - Phoenix
I wish there was a complete Clojure - ???
Elixir - Phoenix
I wish there was a complete Clojure - ???
Elixir with Phoenix is phenomenal. An absolute joy to use.
Elixir itself is an excellent language that leveraged the strengths of the Erlang VM, and Phoenix is like a massively improved, blazing fast and reliable version of Rails.
Elixir itself is an excellent language that leveraged the strengths of the Erlang VM, and Phoenix is like a massively improved, blazing fast and reliable version of Rails.
I'd wait for the ecosystem to mature before building a business app with Phoenix. You never know what taken for granted library is missing in Elixir, and it's going to be damn hard to hire a developer experienced with Phoenix. Everyone on your team will be slow and will be making a steady stream of mistakes as they learn the framework
I think Phoenix (and Elixir) is mature enough already to use in production. I've made pretty good, bordering on oracle-like :) predictions about directions in technology over more years than I care to think about; so I'm confident that Phoenix is only going to grow in use and positive attention.
It will be the logical successor to Rails. It already is.
That said, I use a good mix of Elixir+Phoenix and old-school cron launched Python utility scripts, and that works nicely. Anything that's difficult (probably because I am still a newb) in Elixir I can easily do out of band with a Python script.
But your point about difficult to hire experienced people is the reason for my reply. This is the mentality that is ruining IT and development. Yes, having someone with hands on experience in all of your tools is nice - a rare luxury in fact. But it's really not necessary. I would be quite happy to have someone that has willingly built something in Rails, Django, and Nodejs with an "Oh I can learn that" attitude. Especially if you come from a modern MVC framework, Phoenix itself is easy. Elixir is the part that requires some real effort, imo.
It will be the logical successor to Rails. It already is.
That said, I use a good mix of Elixir+Phoenix and old-school cron launched Python utility scripts, and that works nicely. Anything that's difficult (probably because I am still a newb) in Elixir I can easily do out of band with a Python script.
But your point about difficult to hire experienced people is the reason for my reply. This is the mentality that is ruining IT and development. Yes, having someone with hands on experience in all of your tools is nice - a rare luxury in fact. But it's really not necessary. I would be quite happy to have someone that has willingly built something in Rails, Django, and Nodejs with an "Oh I can learn that" attitude. Especially if you come from a modern MVC framework, Phoenix itself is easy. Elixir is the part that requires some real effort, imo.
Closest is probably Luminus, but it's really just a Leiningen build tool that can pull in your choice of libs to stitch together. It's good, and speeds up Clojure web dev, but is in no ways a framework by itself.
Agree, note that Laravel was heavily influenced by RoR.
I personally find that Laravel is less heavy than Django which is way less heavy than RoR. I would never use RoR for small projects.
I personally find that Laravel is less heavy than Django which is way less heavy than RoR. I would never use RoR for small projects.
Scala - Play
I'm not sure about that. Compared to Django, RoR and Laravel it's not opinionated enough. No resources like RoR and Laravel, no buil-in database mapping, no built-in authorization etc.
btw: what do you use for the database access? Slick, Quill, Doobie, ScalikeJDBC, Anorm, Squeryl, jOOQ, Relate, Activate or something else? There seem to be gazillions of sql libraries for scala (although the big three and most relevant are probably Slick, Quill and Doobie).
And what do you use for Authorization? Something custom build? If I look at Laravel there are quite a few maintained authorization libs with ~1000 stars on youtube (even more if we count unmaintained), for play there is not really much (deadbolt, play4j and t2v/play2-auth, I don't count Silhouette since the lib is mainly about authentication).
btw: what do you use for the database access? Slick, Quill, Doobie, ScalikeJDBC, Anorm, Squeryl, jOOQ, Relate, Activate or something else? There seem to be gazillions of sql libraries for scala (although the big three and most relevant are probably Slick, Quill and Doobie).
And what do you use for Authorization? Something custom build? If I look at Laravel there are quite a few maintained authorization libs with ~1000 stars on youtube (even more if we count unmaintained), for play there is not really much (deadbolt, play4j and t2v/play2-auth, I don't count Silhouette since the lib is mainly about authentication).
[deleted]
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.
Well. I disagree that it is not a real thing. For better debugging, you need to know more what's behind the scenes. Personally, I have seen some of my colleagues struggling to find the cause or better architect the thing because most of the decision has been hidden/taken by the framework. Not saying, it's true for all Rails dev but for some beginners, it really bites them.
Sure but there is magic everywhere. You trade convenience for the risk of not knowing the underlying mechanism in action. The inverse is long boilerplate code, setting up multiple services and factories and fooWidget stuff just to do a simple thing. It’s more clear, yes, but is it always better?
Rhetorical question by the way... just food for thought. There is a balance. I happen to love the convention rails imposes and the “magic” it offers. That being said, there isn’t anything about it that I consider wizardry or don’t understand. It’s just ruby.
Rhetorical question by the way... just food for thought. There is a balance. I happen to love the convention rails imposes and the “magic” it offers. That being said, there isn’t anything about it that I consider wizardry or don’t understand. It’s just ruby.
> The inverse is long boilerplate code, setting up multiple services and factories and fooWidget stuff just to do a simple thing
Are you not talking about Java here? ;)
Clearer code makes it easier to reason and hence easier debugging. Correct me if I am wrong.
Also, it really depends on person to person on how they write the code. Django does not mean big boilerplate nor does Rails.
My main question was on performance. How do they stack up next to each other? Python3 with Django is really working well these days. You can also check out the performance improvement on Instagram because of it. https://thenewstack.io/instagram-makes-smooth-move-python-3/
Are you not talking about Java here? ;)
Clearer code makes it easier to reason and hence easier debugging. Correct me if I am wrong.
Also, it really depends on person to person on how they write the code. Django does not mean big boilerplate nor does Rails.
My main question was on performance. How do they stack up next to each other? Python3 with Django is really working well these days. You can also check out the performance improvement on Instagram because of it. https://thenewstack.io/instagram-makes-smooth-move-python-3/
I can get a fairly feature-complete Python up with Flask + Flask Admin, within a few weeks. 1-4 weeks I'd say is a good timeframe. Have done this multiple times. How does Rails stack up there? Not trying to enter a pissing contest .... I agree that Django is not faster than Flask for simple business crud apps.
Just out of curiosity, if the API is already being built in Java, why not just build a single-page-app to utilize the API instead of Django? I'd assume the deployment and overhead of maintaining a single-page-app would be way lower than Django. (i.e. uploading to s3 and setting up CDN vs. setting up a VM for Django with nginx, uwsgi, etc.)
One reason would be because you don’t know react or angular or whatever the latest js framework is. You have known Django for a decade and it still works so why waste time learning some js framework which might be out of fashion in 2 years.
Generate dynamic HTML on the server, that still works just fine. And codebase will be way simpler as you just generate HTML on page refresh. No need to fiddle with event listeners and DOM and AJAX or whatever.
Single page web apps are often wrong choice if you just need some UI other than some fancy dashboard. Let’s say you need an admin panel where you can do CRUD operations, that’s perfect for Django/Rails and would be much much more work as SPA.
Generate dynamic HTML on the server, that still works just fine. And codebase will be way simpler as you just generate HTML on page refresh. No need to fiddle with event listeners and DOM and AJAX or whatever.
Single page web apps are often wrong choice if you just need some UI other than some fancy dashboard. Let’s say you need an admin panel where you can do CRUD operations, that’s perfect for Django/Rails and would be much much more work as SPA.
Static pages and full refreshes really limit what a page can do though.
My personal preference (for most use cases) is a combination. Some things are easier done in static templates but JS is needed to really bring a page to life IMOP.
Lately there is too much SP-appage around where there are simpler alternatives though, with that I'll agree. I guess it keeps people employed screwing around with webpack so there's that.
My personal preference (for most use cases) is a combination. Some things are easier done in static templates but JS is needed to really bring a page to life IMOP.
Lately there is too much SP-appage around where there are simpler alternatives though, with that I'll agree. I guess it keeps people employed screwing around with webpack so there's that.
> Static pages and full refreshes really limit what a page can do though.
Yes. But for 90% of business UI cases, you have some sort of collection of pages (i.e. website = collection of pages not a single page with everything crammed into it) with navigation menu. You use the menu to navigate to different pages with HTML forms that submit POST data and do GET redirects.
Trying to cram an entire business logic into a single page is often detrimental, split it into multiple pages. Highly interactive apps that fit into a single page model is maybe 10% of use cases or less I have seen in my career last few years.
This is all just my opinion obviously but I just think SPAs are a fad that will hopefully go away.
Yes. But for 90% of business UI cases, you have some sort of collection of pages (i.e. website = collection of pages not a single page with everything crammed into it) with navigation menu. You use the menu to navigate to different pages with HTML forms that submit POST data and do GET redirects.
Trying to cram an entire business logic into a single page is often detrimental, split it into multiple pages. Highly interactive apps that fit into a single page model is maybe 10% of use cases or less I have seen in my career last few years.
This is all just my opinion obviously but I just think SPAs are a fad that will hopefully go away.
I have never written an SPA but after writing a fairly complex ecommerce admin backend (handling orders, shipping etc), I wish I had. There are a lot of complex UI state and some of it would have been easier in React/Vue
As someone already suggested, writing an SPA comes with a lot of work to get going. This is a side project I need to write, and then hand off to an external development team at some point. Then it helps to simplify the equation as much as possible.
Depending on the app, writing a SPA could be a lot of work vs just writing your UI as a frontend server.
About NGINX, is still needed in both cases IMO, for the API or the frontend server.
About NGINX, is still needed in both cases IMO, for the API or the frontend server.
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.
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.
AFAIK, C# navigated the sync-async transition well. Admittedly, this is a function of time, as it has had async/await for quite awhile.
Totally forgot about that one. Having nearly everyone on one the same framework probably helped a lot with that. I don't think anyone else really has that advantage. Except maybe Ruby and Rails... Perhaps some good concurrency stuff will come of Ruby 3.
+1 for APIStar. I love Django but if all you want to build is an API, it can be a bit much. APIStar has been great so far in the one production API I've helped build even if there are a few pain points that come with using such a new framework.
We use Django for large single page GIS web apps that still always need some CRUD somewhere (e.g. configuration is done through the Django admin). Parts that Django doesn't do can still be done in Python.
What does GIS mean?
Geographic information system. Dealing with maps, etc.
https://docs.djangoproject.com/en/2.0/ref/contrib/gis/tutori...
https://docs.djangoproject.com/en/2.0/ref/contrib/gis/tutori...
> 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.
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.
> Why?
Because we are getting more and more CPU cores to utilize. I don't think this trend will stop soon. The software stack will have to adjust to this and it already does. The next generation of mainstream (highlevel)languages/frameworks will be those that are designed to easily utilize CPU cores. It may be more expensive for now, but it might pay out later and I think it's much more exciting. ;)
Because we are getting more and more CPU cores to utilize. I don't think this trend will stop soon. The software stack will have to adjust to this and it already does. The next generation of mainstream (highlevel)languages/frameworks will be those that are designed to easily utilize CPU cores. It may be more expensive for now, but it might pay out later and I think it's much more exciting. ;)
I honestly don't understand this argument.
With 30 workers threads in Python Django, I should be able to make very good use of 6 CPUs even if the workers only run 20% of the time.
With 30 workers threads in Python Django, I should be able to make very good use of 6 CPUs even if the workers only run 20% of the time.
I mean, actually think that I don't understand and would like to be educated.
Django Channels [1] + ASGI is exactly that. However making that the default would be a hit to the very good backward/forward compatibility Django keep having.
[1] https://channels.readthedocs.io/en/latest/
[1] https://channels.readthedocs.io/en/latest/
One disadvantage of Django is that database providers need to know a lot about the internals of the framework. This shows once you rely on a 3rd party developed database provider, which can break even on minor upgrades.
What do you mean with a database provider?
Possibly, database backends?
Like those: https://docs.djangoproject.com/en/2.0/ref/databases/#using-a...
They are, indeed, quite complex.
Like those: https://docs.djangoproject.com/en/2.0/ref/databases/#using-a...
They are, indeed, quite complex.
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
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
There's flask-restless, which removes most of the boilerplate. There's still good reasons to choose django over flask though, but easy rest apis can be achieved with both.
To me the beauty of a restful API in flask is that you don't need to commit to anything. As far as the user is concerned, as long as /api/v1/user/15 gives back the user details for user number 15 (after checking authorization if necessary). The person who follows in my footsteps should be able to rewrite things one end-point at a time (as long as we clean things up after every transaction) in any other language (go lang or rust or swift seem like best bets). At least that is my hope, even if the person who follows in my footsteps is me!
This can be achieved with any framework.
(1) Write your new endpoint. (2) Proxy to it via your old one.
Or for a full re-write you might want to do things the other way.
(1) Wrap the whole old app with a skeleton of the new one - just proxying the endpoints for now. (2) Start replacing the endpoints.
(1) Write your new endpoint. (2) Proxy to it via your old one.
Or for a full re-write you might want to do things the other way.
(1) Wrap the whole old app with a skeleton of the new one - just proxying the endpoints for now. (2) Start replacing the endpoints.
> (1) Write your new endpoint. (2) Proxy to it via your old one.
OR: (1) write your endpoint. (2) use something like apache's mod_rewrite to adapt endpoints.
OR: (1) write your endpoint. (2) use something like apache's mod_rewrite to adapt endpoints.
I am learning Python right now and want to build a website using this programming language. Django and Flask seem to be the best frameworks for this purpose. I understand that Django has steeper learning curve and comes with "everything", whereas Flask is more modular and compositional.
If I were to use Flask, is there anything that I could not do but that Django could?
If I were to use Flask, is there anything that I could not do but that Django could?
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.
Suddenly it's not so simple.
That being said, if your app really is simple (single file, under 100 lines) flask is excellent.
Oh, come on. There are plenty of large websites written in flask. It's not that hard to use at all, and all those things you list are definitely a part of it. Hell, I have a 20 KLOC website written in bottle, and no one ever said it was poorly done, insecure, and so on.
The problem is that a lot of people writing Python web stacks don't know how to write Python at all, and no framework will save that shortcoming.
The problem is that a lot of people writing Python web stacks don't know how to write Python at all, and no framework will save that shortcoming.
Part of my point was that if your site is going to be 20 KLOC then why not use a framework that is aimed at building 20 KLOC large sites rather than one that is aimed at writing 200 line sites.
Flask is advertised as a micro framework. if you want to rebuild Django with it then sure you can, but I personally can't see why you'd want to.
Flask is advertised as a micro framework. if you want to rebuild Django with it then sure you can, but I personally can't see why you'd want to.
Flask is used by Pinterest and LinkedIn, which I'm guessing are a touch more than 100 lines of code.
Flask is, of course, more powerful than bottle, and has less batteries included than Django. Saying Flask is good for 100 LOC sites is terrible advice, no matter which way you try to slice it. It isn't. It's widely-used and well-maintained.
Don't get me wrong, I like Django as well.
Flask is, of course, more powerful than bottle, and has less batteries included than Django. Saying Flask is good for 100 LOC sites is terrible advice, no matter which way you try to slice it. It isn't. It's widely-used and well-maintained.
Don't get me wrong, I like Django as well.
I've used Flask for single file sites with 10-250 lines. It's great (ish). What's bad about it? Your saying it's only good for writing large applications? How so?
Your contention is that it's only good for small sites. I'm saying it's good for any sized site as long as you actually know how to RTFD and program in Python.
Django is no different. Django falls apart spectacularly in the hands of people who can't program.
Django is no different. Django falls apart spectacularly in the hands of people who can't program.
Does eventually needing a truck justify driving one when for now everything fits in a van? The structure Django imposes on you may get in the way while you're still experimenting.
What I like most about Flask is, it provides the barebones for request/response handling, and gets out of your way. Add SqlAlchemy to the mix, and python handles the rest.
I'm using Flask, but building my apps with Python.
This simple/complex equation should be reversed IMHO. Want to throw together something quick? Go with Django, where everything you need is built-in. Want to build a big app? Go with Flask, and build your stack specific to your needs.
As a bonus, once you have built a complex app with your own abstractions/magic succesfully, it becomes faster for you to build new projects with your own framework than any other alternative.
I'm using Flask, but building my apps with Python.
This simple/complex equation should be reversed IMHO. Want to throw together something quick? Go with Django, where everything you need is built-in. Want to build a big app? Go with Flask, and build your stack specific to your needs.
As a bonus, once you have built a complex app with your own abstractions/magic succesfully, it becomes faster for you to build new projects with your own framework than any other alternative.
I've ever understood this argument. Any library you can pick and mix into your Flask app you could just as easily pick and mix into your Django app. It's all just Python.
not really. Did you ever tried to use SQLAlchemy with Django? Good luck with that.
You most certainly can. I've built several Django apps with Elasticsearch-DSL as a backend and another app with a completely custom backend (you need a really good reason to do this).
There are tradeoffs of course: you give up the Django admin and a bunch of other things, at which point we might as well have used Flask. But our shop has a number of other "normal" pure-Django apps so it makes sense for us to use Django as a common base.
Awhile ago there was a book called "Lightweight Django" in which the authors showed how to use Django in a stripped-down Flask-like manner. Ultimately Django is just a big bag of parts that you can use or not use.
There are tradeoffs of course: you give up the Django admin and a bunch of other things, at which point we might as well have used Flask. But our shop has a number of other "normal" pure-Django apps so it makes sense for us to use Django as a common base.
Awhile ago there was a book called "Lightweight Django" in which the authors showed how to use Django in a stripped-down Flask-like manner. Ultimately Django is just a big bag of parts that you can use or not use.
Ever tried using SQLAlchemy with Flask?
It's exactly the same situation: either you luck out, and someone already wrote all the conveniences and utilities and integrations with components for you exactly the way you want them with exactly the set of other components you wanted, or you do it yourself.
Also, you could make a similar argument about swapping major components into, say, Pyramid. Most of the alternatives people promote to Django are not really some paradise of trivially-swapped-but-tightly-integrated components. They just do exactly what Django does, with a different set of "use these or lose the integration" components chosen up-front for you.
It's exactly the same situation: either you luck out, and someone already wrote all the conveniences and utilities and integrations with components for you exactly the way you want them with exactly the set of other components you wanted, or you do it yourself.
Also, you could make a similar argument about swapping major components into, say, Pyramid. Most of the alternatives people promote to Django are not really some paradise of trivially-swapped-but-tightly-integrated components. They just do exactly what Django does, with a different set of "use these or lose the integration" components chosen up-front for you.
I've used SqlAlchemy with Flask. You only need a few lines of code to integrate them.
But yes, with Flask (or similar frameworks/libraries), you need to do the integrations yourself with the components you want to use. Advantage of Flask in this regard is, you don't need to fight with Flask to make it happen. That's why I'm saying it's better suited for complex apps that you want to build with your own abstractions.
The real problem is the cargo cult thinking when it comes to frameworks, instead of doing a cost/benefit analysis and thinking about trade-offs.
Following statements like "Django for complex apps, Flask for 100 lines of apps" without researching the reasons behind probably will result in more problems in the future.
But yes, with Flask (or similar frameworks/libraries), you need to do the integrations yourself with the components you want to use. Advantage of Flask in this regard is, you don't need to fight with Flask to make it happen. That's why I'm saying it's better suited for complex apps that you want to build with your own abstractions.
The real problem is the cargo cult thinking when it comes to frameworks, instead of doing a cost/benefit analysis and thinking about trade-offs.
Following statements like "Django for complex apps, Flask for 100 lines of apps" without researching the reasons behind probably will result in more problems in the future.
You only need a few lines of code to integrate them.
Really? So you got all the things you get in Django -- ORM, forms with validation, etc. etc. -- from "a few lines of code"?
Somehow I think that's not true.
Really? So you got all the things you get in Django -- ORM, forms with validation, etc. etc. -- from "a few lines of code"?
Somehow I think that's not true.
I built a project on Django and SQLAlchemy back in 2008/2009.
If you have little experience with backend development, Django may help you by forcing you to code into a predictable and sensible structure; Flask won't limit you in any way, which is great but It's easier to shoot yourself in the foot and its harder to keep a consistent codebase.
If you're familiar with SQL, it may take some time to adapt to the Django ORM, which is really great but favors ease of use over power.
All in all, with Django you'll fight to override defaults and with Flask to enforce them. I loved both enemies
If you're familiar with SQL, it may take some time to adapt to the Django ORM, which is really great but favors ease of use over power.
All in all, with Django you'll fight to override defaults and with Flask to enforce them. I loved both enemies
> If I were to use Flask, is there anything that I could not do but that Django could?
No, but it might be simpler.
When I started doing webdev in Python I used Flask (it's so slim, they said) and I still like it, but if you have some kind of DB in the back and care about user management, Flask won't help you.
Most people then use sqlalchemy and specific extensions for Flask to handle the user and security stuff. Although this works, I would advise you to start with Django.
No, but it might be simpler.
When I started doing webdev in Python I used Flask (it's so slim, they said) and I still like it, but if you have some kind of DB in the back and care about user management, Flask won't help you.
Most people then use sqlalchemy and specific extensions for Flask to handle the user and security stuff. Although this works, I would advise you to start with Django.
If you are learning python, I would stick with Django. It'll get the basics up and running for you and you can focus on python specific code. If you go with flask you'll need to be piecing everything together on your own, and then you're not just learning python, you're learning web application components and flask as well.
With frameworks, the more they do for you, the more risk you will end up fighting against them if you need to do something they're not designed for.
Django isn't particular bad at this (it has some escape hatches to allow you to e.g. write custom SQL), but it is overal still quite a big framework and it's certainly harder to bend to your will than Flask.
So, you need to know the extra things it gives you and figure out if they will be helpful for your website.
Loosely, Django is: routing + HTML request parameter handling + HTML rendering + templating + user sessions + lots of database read/write help, assuming simple CRUD access patterns.
Flask is: routing + HTML request parameter handling + HTML rendering. Then, if you want any of the other things, you go and find a library for them.
Django isn't particular bad at this (it has some escape hatches to allow you to e.g. write custom SQL), but it is overal still quite a big framework and it's certainly harder to bend to your will than Flask.
So, you need to know the extra things it gives you and figure out if they will be helpful for your website.
Loosely, Django is: routing + HTML request parameter handling + HTML rendering + templating + user sessions + lots of database read/write help, assuming simple CRUD access patterns.
Flask is: routing + HTML request parameter handling + HTML rendering. Then, if you want any of the other things, you go and find a library for them.
I do not have much experience with flask, but I recently told a coworker: if you are fighting the Django framework to do something, atleast question why you are doing that because there is a good chance you are going down the wrong path. The caveat is, yes there are some times when that is necessary, but it is also necessary to question what you are doing, and why it isn't possible.
I would miss the django ORM. Depends if you like the ORM.
i vote turbogears for crud apps
As a beginner/intermediate level myself, I think new routing syntax, which is similar to flask is itself a major feature of the django 2.0. This really simplifies the url routing than the regex(which is lot powerful though). For simple projects of mine, it may well cover 60-80% of my needs, maybe more.
Indeed. The somehow clunky syntax for named groups in python re was (in my opinion) a big drawback with old style routing. I hope this new style gains traction.
Nice this release will be the final push that tips over the balance towards Python 3. With Django taking the lead I think more projects will drop Python 2 support. Well it sure took a while, but glad the ecosystem is standardizing around 1 language again.
Time for Python 4!
Guido was imo pretty clear that there won't be backward incompatible changes for python 4, if at all
https://twitter.com/gvanrossum/status/501172370690699265?lan...
https://twitter.com/gvanrossum/status/501172370690699265?lan...
Notable feature: no Python 2 support!
yes and it is indeed a feature. death to python2. I would pay money to that.
just yesterday someone at cuny sps told me a professor is teaching them flask using python 2.6...
sigh
sigh
It'd likely be better to use Python 3, but the actual differences in syntax are pretty small, it's big Python 2 code bases that present a problem, not the switch over to using Python 3 syntax and names for new code.
Yeah, for the types of programs intro students write, it's basically "Okay, now add parens to your prints." And if they're running Python 2.7 they might be doing that already.
No Python 2 support, good thing.
I understood that the Django codebase is lighter thanks to this, but I'm asking myself if it has any implication for the developper? (I was already using Python 3.6)
My guess: - The Django codesource is easier to read - Maybe error messages are cleaner? (just a supposition.. I don't know)
My guess: - The Django codesource is easier to read - Maybe error messages are cleaner? (just a supposition.. I don't know)
The documentation is a little cleaner too, with fewer “except on Python 2, it’s like this..”
Also, this will eventually allow type hinting in the future.
Also, this will eventually allow type hinting in the future.
Does anybody know if there is better support for WebSockets?
If I remember right, with Django(1) it is not easy to do it. And is it possible to use GraphQL?
With Django Channels there is great support, with some quite interesting things you can do. GraphQL can be handled by a third party package, there are a few out there at the moment.
Seconding this. Channels was actually shockingly easy to implement, maintain, and expand, even at a small startup with a fairly small and relatively inexperienced team.
For GraphQL I think there is only graphene / django-graphene right now.
Congrats to the team, this has been a long time coming. No Python2 support which is unfortunate, my Python3 migration strategy was to move to C# for my main language instead. No regrets, I like it a lot. I describe it as industrial strength. Good IDE and granted me a larger job market with Xamarin for iOS coverage.
For web stuff, I'll probably be using a C# framework, or Wordpress with one of the JITs. Still, a lot of hard work has gone into Django 2.0 and I'll be keeping tabs on it, rooting for the team. It's not likely but not barring the idea of using Django again.
For web stuff, I'll probably be using a C# framework, or Wordpress with one of the JITs. Still, a lot of hard work has gone into Django 2.0 and I'll be keeping tabs on it, rooting for the team. It's not likely but not barring the idea of using Django again.
Why would you not want to use Python 3?
I think choosing to migrate to a completely different language rather than rewriting in python 3 is a totally valid strategy.
Maybe they’ve switched to c# lately and are using lack of py2 as a trigger to rewrite. Maybe going after the benefits of a compiled language. Maybe just wanting to use c# because it’s one of the best languages out there.
There are some python apps out there I’ve contributed to that I’d rather rewrite in a static type lang rather than migrate to py3. Others I’d move to py3 no problem.
Maybe they’ve switched to c# lately and are using lack of py2 as a trigger to rewrite. Maybe going after the benefits of a compiled language. Maybe just wanting to use c# because it’s one of the best languages out there.
There are some python apps out there I’ve contributed to that I’d rather rewrite in a static type lang rather than migrate to py3. Others I’d move to py3 no problem.
I really wish they merge Django and DRF.
DRF has stated that they don't wish to be brought under the Django org, as they don't want their releases tied to Django's release timeline.
The value of the ecosystem is that each component does its part and each other component that has interaction with that component reaps the rewards. This leads to a natural evolution of components in the ecosystem (for instance, DRF evolved out of the need for better REST support, since projects like Tasty Pie were lacking thing that the rest of the ecosystem desired).
The idea that anything of value has to be nationalized and assimilated by the framework is a misguided effort to prevent chaos in the ecosystem, but the end result of trying to maintain order in an emergent ecosystem is usually disaster.
The idea that anything of value has to be nationalized and assimilated by the framework is a misguided effort to prevent chaos in the ecosystem, but the end result of trying to maintain order in an emergent ecosystem is usually disaster.
OT but gonational you asked a couple weeks back to tell my story. I finally got around to doing it: https://news.ycombinator.com/item?id=15762821
seconded, it's amazing how many people claim to make "REST APIs", but they fall so short in a lot of aspects. DRF makes it almost impossible if used correctly.
Could you elaborate what you mean? Looking at https://en.wikipedia.org/wiki/Representational_state_transfe... I would think that esp. ModelViewSets are pretty RESTful
The way I read the parent comment is that using DRF helps you building a truly RESTful API.
I think the "it" in the sentence:
> DRF makes it almost impossible if used correctly.
Refers to
> claim to make "REST APIs", but they fall so short in a lot of aspects
I think the "it" in the sentence:
> DRF makes it almost impossible if used correctly.
Refers to
> claim to make "REST APIs", but they fall so short in a lot of aspects
Yeah or at least brought it "in house" as a Django officially supported app, like Django Channels
[deleted]
The new URL routing syntax is one of the most welcome changes for me (i mostly work with Flask). I just couldn't get myself to work with regex.
Wow, I remember being curious about Django a year ago.
Now it's at 2.0 ! It already felt overwhelming then, but now even more so.
I can't wait to check it out more.
On a sidenote, I feel bad for the developers who have to migrate to Django 2.0. Hopefully it's not too much work, I know a codebase review and full update can't be fun with the business managers and customers at your throat.
I can't wait to check it out more.
On a sidenote, I feel bad for the developers who have to migrate to Django 2.0. Hopefully it's not too much work, I know a codebase review and full update can't be fun with the business managers and customers at your throat.
If you were already using Python 3, and your code wasn't emitting any deprecation warnings, then it's a fully backwards-compatible change and you can just bump the version number in your requirements.txt with no other changes.
If your code was emitting deprecation warnings, then you have to fix them before upgrading, but this should be relatively rare and they shouldn't be that hard to fix.
If you're still on Python 2, then you have to either migrate to Python 3 or stay on Django 1.11 (which is an LTS release). 1.11 EOL is April 2020, which is the same time as Python 2's EOL, so you were going to have to migrate your codebase by then anyway.
If your code was emitting deprecation warnings, then you have to fix them before upgrading, but this should be relatively rare and they shouldn't be that hard to fix.
If you're still on Python 2, then you have to either migrate to Python 3 or stay on Django 1.11 (which is an LTS release). 1.11 EOL is April 2020, which is the same time as Python 2's EOL, so you were going to have to migrate your codebase by then anyway.
> so you were going to have to migrate your codebase by then anyway
That's an optimistic viewpoint.
That's an optimistic viewpoint.
If you're already on Python 3, upgrading from Django 1.11 to Django 2 is pretty much the same amount of work as upgrading from 1.10 to 1.11 was. The "2" in the version here reflects the dropping of support for Python 2, and the switching over to a new versioning scheme: https://docs.djangoproject.com/en/2.0/internals/release-proc...
If you need to upgrade from Python 2 to Python 3 it will likely be a fair amount of work.
In case it's useful, here's what I did to upgrade my blog (a pretty simple application, though one that's been around for a long time and survived a lot of different Django versions): https://github.com/simonw/simonwillisonblog/pull/10
If you need to upgrade from Python 2 to Python 3 it will likely be a fair amount of work.
In case it's useful, here's what I did to upgrade my blog (a pretty simple application, though one that's been around for a long time and survived a lot of different Django versions): https://github.com/simonw/simonwillisonblog/pull/10
The biggest challenge with upgrading Django is making sure all your Django-related dependencies have fixed things up.
Django only has one paid full-time maintainer to my knowledge (Tim Graham). So given the team's limited peoplepower Only the last two releases (+LTS releases) get security updates. This means that Django 1.10 (released 18 months ago) won't get updates, so if you use any new features you're on the upgrade treadmill.
Django itself is very good about offering clean upgrade paths. Very vocal about breakage, usually will not introduce breakage unless there's some good reasons to. Unfortunately third party libraries often take a while to update, so you can quickly find yourself overwhelmed with figuring out which deps are safe to upgrade and which aren't.
I try to be a good OSS citizen and send in compatibility fixes for libraries that fall behind, but maintenance can be hard when you're only really using about 25% of a library.
I wouldn't be comfortable with sticking to older Django LTS releases (there was still a lot of obvious improving to be had in the ORM and migrations in particular), but I think Django 2.0 is in an amazingly good place now. Sticking to this for a couple years would be fine for a lot of people.
Django only has one paid full-time maintainer to my knowledge (Tim Graham). So given the team's limited peoplepower Only the last two releases (+LTS releases) get security updates. This means that Django 1.10 (released 18 months ago) won't get updates, so if you use any new features you're on the upgrade treadmill.
Django itself is very good about offering clean upgrade paths. Very vocal about breakage, usually will not introduce breakage unless there's some good reasons to. Unfortunately third party libraries often take a while to update, so you can quickly find yourself overwhelmed with figuring out which deps are safe to upgrade and which aren't.
I try to be a good OSS citizen and send in compatibility fixes for libraries that fall behind, but maintenance can be hard when you're only really using about 25% of a library.
I wouldn't be comfortable with sticking to older Django LTS releases (there was still a lot of obvious improving to be had in the ORM and migrations in particular), but I think Django 2.0 is in an amazingly good place now. Sticking to this for a couple years would be fine for a lot of people.
> Django only has one paid full-time maintainer to my knowledge
It indeed does, but I don't agree that it is too limiting in that respect. A lot of Tim's time is spent curating, reviewing and merging PR's contributed by the community. It's far, far from a one-man band.
Not sure if that was what you are implying, but that's how I read it.
It indeed does, but I don't agree that it is too limiting in that respect. A lot of Tim's time is spent curating, reviewing and merging PR's contributed by the community. It's far, far from a one-man band.
Not sure if that was what you are implying, but that's how I read it.
I can't agree more with you.
That's the one and only reason I'll stick to the 1.11 version.
Garanty of compatibility between Django and ALL my external packages is a lot more valuable that a responsive admin panel and a new syntax for urls.
I would love "important" (yeah it's opiniated) packages move to the official Django repo (like Channels), to help reduce this risk when migrating. It's actually surprising how often I can't find the compatibility information of a Django package.
Garanty of compatibility between Django and ALL my external packages is a lot more valuable that a responsive admin panel and a new syntax for urls.
I would love "important" (yeah it's opiniated) packages move to the official Django repo (like Channels), to help reduce this risk when migrating. It's actually surprising how often I can't find the compatibility information of a Django package.
I've had decent luck for the most part, but it only takes one package.
I would love to see someone start on a combination of `pyup` and some "maintenance fee" for projects that are found in ones `requirements.txt`.
For a monthly fee you can make sure that at least someone is checking to see that your Django dependencies are being kept up to date as time moves forward. The pitch being "get an extra maintenance developer for a fraction of the cost".
I would love to see someone start on a combination of `pyup` and some "maintenance fee" for projects that are found in ones `requirements.txt`.
For a monthly fee you can make sure that at least someone is checking to see that your Django dependencies are being kept up to date as time moves forward. The pitch being "get an extra maintenance developer for a fraction of the cost".
(Channels is in the Django Github _organization_, separate repo.)
Though, in theory, I don't think there's any actual difference in support having it under the Django _organization_.
Though, in theory, I don't think there's any actual difference in support having it under the Django _organization_.
The policy of only supporting two releases + LTS predates having a paid person handling releases.
Source: before we hired Tim, I was doing most of the releases.
Source: before we hired Tim, I was doing most of the releases.
Kind of funny, but I had the opposite reaction. I was playing with Django when I was first getting into web dev 6 or 7 years ago. When I saw this, I thought "Oh wow, they're just barely getting to 2.0 and making breaking changes?"
They always make breaking changes. There's usually a deprecation period though. They didn't do semver but it seems they will now.
It's roughly semver, but if you receive warnings when using 2.0, for example, your code may break in 2.1.
If you don't receive warnings, your code will work fine on future 2.x releases.
If you don't receive warnings, your code will work fine on future 2.x releases.
I'm excited by seeing support and continued development. Nothing worse than a dead framework, but I def see your point.
Stability is very important too.
Stability is very important too.
If you're already at 1.11 and on Python 3, it should not be too bad of an upgrade. If you have to go from an earlier version _and_ do the swap from Python 2 to 3, you may be in for a world of pain.
Yeah, make the 2.7 -> 3 (preferably 3.5+) transition on 1.11, _then_ do the 1.11 -> 2.0 upgrade.
I run a fairly large Django app. Looking at the release notes, it doesn't seem like it will take more than an hour or two to upgrade.
[deleted]
At this point in time for me, having worked with a couple of Python web frameworks, I would recommend Django hands-down every time.
For me it comes down to one simple thing though: Migrations
Django has, far and away, the best migrations system I've used in a Python framework (although I won't claim to have used them all).
Compared to Alembic it's vastly superior also beats most jerry-rigged solutions.
For me it comes down to one simple thing though: Migrations
Django has, far and away, the best migrations system I've used in a Python framework (although I won't claim to have used them all).
Compared to Alembic it's vastly superior also beats most jerry-rigged solutions.
Really nice! Should force more people into python3 as a side effect which is great since python2 is getting close to its EOL.
Claps for the changelog, it's always a joy to read, I haven't really used Django in some years but could easily read and see the changes. The new URL formatting is a very good add-on, was always the thing that annoyed me the most.
Claps for the changelog, it's always a joy to read, I haven't really used Django in some years but could easily read and see the changes. The new URL formatting is a very good add-on, was always the thing that annoyed me the most.
* updates requirements.txt from django==2.0a1 to 2.0 *
Great work! I love Django and look forward to seeing how it continues to improve.
Great work! I love Django and look forward to seeing how it continues to improve.
Nice! Coincidentally I had my very first Django experience two weeks ago (and blogged about it [0]). It struck me as a very solid and clean and lean framework. But I do think there is somewhat of an entry barrier: you need to understand quite a few concepts, which if you do, would open up many more options besides Django. So it's not unique in that regard. However, I had trouble finding QUICK CRUD app solution i.e. here is my database, please make some forms for me. And Django: with the builtin admin/user mgmt, did exactly that.
[0] https://j11g.com/index.php/2017/11/23/django-in-10-minutes/
[0] https://j11g.com/index.php/2017/11/23/django-in-10-minutes/
[deleted]
Excellent, Django team made a really great job.
This is great news! The Django project is such a wonderful project, I've enjoyed working with it over the years.
I wish they'd skip-jumped their version to "Django 3.0". That would have allowed a simpler message about the Python dependency: "Django 3.x requires Python 3.x".
Django 3.0 will be out soon enough (Dec 2019). There's going to be a major version bump every two years.
Alas, that doesn’t help for presenting a simple version story to low-attention beginners:
“Django 3.x requires Python 3.x”
“Ah, OK, so to use Python 2.x I should go back to Django 2.x?”
“No, Django 2.x requires Python 3.x. If you want to use Python 2.7 you should use Django 1.x.”
“Django 3.x requires Python 3.x”
“Ah, OK, so to use Python 2.x I should go back to Django 2.x?”
“No, Django 2.x requires Python 3.x. If you want to use Python 2.7 you should use Django 1.x.”
There's a huge amount of talk about Django vs. Other Frameworks here, which is not surprising. Bottle and Flask come up. Sadly, Pyramid comes up. Rails comes up.
I think the real crux of the discussion around which framework is best is really about the relationship between the framework and the language it's based on.
Let's separate this from the Python world for a second and talk about the relationship between Objective-C and iOS. Knowing the former doesn't in any way imply that you know the latter. There's an incredibly host of things you have to know to write an iOS app in addition to knowing Obj-C. XCode, UIKit, all the different xKits there are. Which are basically magic, and the APIs you're referencing are not necessarily written in Obj-C.
It is even possible to be a competent iOS developer and not really know anything but the framework. No real understanding of Obj-C or Swift is required, let alone any guiding principle of how programming languages work or how computers work, or how computer science works.
That's not a dig against people who went to code camp or took an online course or just read a book. I'm someone who learned about stuff mainly by reading books. And that worked out fine for the first few years of my career. But there's a legitimate problem that you run into (I know first hand) about what you do when the framework breaks down or you encounter something unexpected.
Anyone can learn a framework relatively quickly. What do you do when the framework fails for some reason?
As someone who learned SQL and Python from the ground up--language-first--I love that Django exists. It's damn impressive, and only ever gets better. But I like Flask + SQLAlchemy better, and I like Pyramid + Stored Procedures best.
I would probably have a different attitude if I started with Frameworks first. And again, that's not a criticism. It's just a different approach. One way to get things done is to learn the fastest way to get things done, and in many cases that's quite possibly Django or Rails.
But both of those make me a little nuts when I dig into the internals. Magic isn't bad by definition. Good magic is when you can invoke a class you don't have to understand to use well. Bad magic is when you have to understand the internals of a class to work around it when it fails to meet your needs.
But I think we need some context about this when we talk about which framework reigns supreme. If you're taking a class and learning to write web apps for the first time with no other experience at all, Django is the bomb. You can spend an entire career as a Django developer and do well.
Just like you can spend an entire career as an iOS developer writing apps, do well, and never actually learn anything about programming. I think this is a wonderful development in our world of programming because it brings so much economic opportunity to such a large group of people who wouldn't otherwise have access to it.
I think it's safe to say that Django is creating jobs for people who wouldn't otherwise have them, and that's a good thing. My 98-year-old father and WW2 vet is starting to help me with a Django app just as a thing we can do together. And I don't have to teach him anything at all about anything except that framework.
It's a brilliant and beautiful framework, and I love it. But to me, it's a little bit more like iOS or RoR than it is a framework that's really ideal for people who started with bottom-up rather than top-down development.
I know what I need in a new project, and it isn't going to be all of that. And I know how to quickly integrate the boilerplate things I will need. That's what repos and plugins are for.
The short version of my response to everyone talking about different frameworks is this: we need them all. Bottle and Flask are great; Pyramid is great; Django is great.
What you are using them for is an important consideration, as is who you plan to have working on them.
I think the real crux of the discussion around which framework is best is really about the relationship between the framework and the language it's based on.
Let's separate this from the Python world for a second and talk about the relationship between Objective-C and iOS. Knowing the former doesn't in any way imply that you know the latter. There's an incredibly host of things you have to know to write an iOS app in addition to knowing Obj-C. XCode, UIKit, all the different xKits there are. Which are basically magic, and the APIs you're referencing are not necessarily written in Obj-C.
It is even possible to be a competent iOS developer and not really know anything but the framework. No real understanding of Obj-C or Swift is required, let alone any guiding principle of how programming languages work or how computers work, or how computer science works.
That's not a dig against people who went to code camp or took an online course or just read a book. I'm someone who learned about stuff mainly by reading books. And that worked out fine for the first few years of my career. But there's a legitimate problem that you run into (I know first hand) about what you do when the framework breaks down or you encounter something unexpected.
Anyone can learn a framework relatively quickly. What do you do when the framework fails for some reason?
As someone who learned SQL and Python from the ground up--language-first--I love that Django exists. It's damn impressive, and only ever gets better. But I like Flask + SQLAlchemy better, and I like Pyramid + Stored Procedures best.
I would probably have a different attitude if I started with Frameworks first. And again, that's not a criticism. It's just a different approach. One way to get things done is to learn the fastest way to get things done, and in many cases that's quite possibly Django or Rails.
But both of those make me a little nuts when I dig into the internals. Magic isn't bad by definition. Good magic is when you can invoke a class you don't have to understand to use well. Bad magic is when you have to understand the internals of a class to work around it when it fails to meet your needs.
But I think we need some context about this when we talk about which framework reigns supreme. If you're taking a class and learning to write web apps for the first time with no other experience at all, Django is the bomb. You can spend an entire career as a Django developer and do well.
Just like you can spend an entire career as an iOS developer writing apps, do well, and never actually learn anything about programming. I think this is a wonderful development in our world of programming because it brings so much economic opportunity to such a large group of people who wouldn't otherwise have access to it.
I think it's safe to say that Django is creating jobs for people who wouldn't otherwise have them, and that's a good thing. My 98-year-old father and WW2 vet is starting to help me with a Django app just as a thing we can do together. And I don't have to teach him anything at all about anything except that framework.
It's a brilliant and beautiful framework, and I love it. But to me, it's a little bit more like iOS or RoR than it is a framework that's really ideal for people who started with bottom-up rather than top-down development.
I know what I need in a new project, and it isn't going to be all of that. And I know how to quickly integrate the boilerplate things I will need. That's what repos and plugins are for.
The short version of my response to everyone talking about different frameworks is this: we need them all. Bottle and Flask are great; Pyramid is great; Django is great.
What you are using them for is an important consideration, as is who you plan to have working on them.
Serious question: is the famous bug of correctly annotating multiple counts fixed now?
I'm guessing you're referring to this - https://stackoverflow.com/questions/6795202/django-count-in-...
Another solution not mentioned in the link is the `Subquery()` expressions added in Django 1.11. A lot of databases will optimise those just as well as the `SELECT ..., COUNT() FROM ..JOIN..` that you would write by hand.
Another solution not mentioned in the link is the `Subquery()` expressions added in Django 1.11. A lot of databases will optimise those just as well as the `SELECT ..., COUNT() FROM ..JOIN..` that you would write by hand.
Nope that's still a limitation and a tricky one to solve, and I agree it's really really annoying.
I added support for filtered aggregates[1] in this release, if you're annotating multiple counts this might be useful for you.
1. https://docs.djangoproject.com/en/2.0/ref/models/conditional...
I added support for filtered aggregates[1] in this release, if you're annotating multiple counts this might be useful for you.
1. https://docs.djangoproject.com/en/2.0/ref/models/conditional...
Huh, I'm a big Django user but not heard of this. Link? :)
Me either
I am guessing it is one of the points where the ORM breaks down.. which the answer is "use rawSQL"
I am guessing it is one of the points where the ORM breaks down.. which the answer is "use rawSQL"
https://www.djangoproject.com/fundraising/
I’d like to encourage everyone that uses Django in a commercial setting to speak to their company about donating to the DSF to continue getting timely bug, security, and feature releases.