Shame about Channels, but I see the logic in not including it. Django is pretty awesome as a backend, and while it's not a 'cool' framework anymore (I feel old!) it's amazing for writing back-office applications.
I use it as an API backend with Django-rest-framework. The advantage is you get ridiculous amounts of packages that all integrate with Django that does pretty much anything you want. Also the ORM doesn't suck now so that's a bonus.
Why a shame? What would Channels buy you if it were included into the framework?
I would love to see Django split up into smaller official external packages and repackaged as two or three different official starter packs (Traditional, API, SPA, etc.) with each containing a different set of packages that make sense (DRF, Channels, Models, Views, Forms, etc.).
I know this goes against the current "Batteries are included" model, but why can't we treat Django as the standards body, and the various starter packs as the more targeted "batteries are included" frameworks.
So does that mean we should pick a new language/framework that is "hot" now and write a bunch of libraries for it? Basically, reinventing the wheel over and over and over again?
Huh. Your argument in favor of Django is basically "it may not be cool, but it's got a lot of libraries written for it." Which is basically the same thing people used to say (and still say) about Java, compared to something "cool" and "new" like, say, Django or Rails (at the time). In other words, Django used to be picked because it was the hot new thing, but since then it's no longer hot or new, but since enough people adopted it, they wrote enough libraries for it to make it worth continuing to use on new projects.
Recently after a 6 year hiatus from Django, I've experimented migrating a smallish flask API and wholly cow did the Django API get CLEANER. Like my god people talk about Django as if it hasn't changed in 6 years but it feels to me like many of the warts got removed and it's just down right pleasant to work with. I love Flask but there is just a little too much boiler plate when you compare it to modern Django for even small projects (IMO).
Edit: looks like this is now the 2nd to last release to support Python2.
Original: It doesn't mention it on this page, but this is also planned to be the last Django release to support python2. Django 2 will require python3.
Now that the transition is in full swing, it's encouraging to see more projects adopt a Python 3 First attitude.
I only wish Ansible would catch up (a recent release broke the core Python 3 support that was there, and no-one seemed to care as Py3 isn't yet officially supported).
As a Rails dude...is there any reason for me to learn Django at all? Everything I've heard about it is that it provides a lot of sane defaults (like Rails) but has much less "magic" than Rails is typically thought to have.
And if the answer to my question is yes, what books/tutorials/screencasts/courses to people recommend to get started with?
As someone who picked Django over Rails ~10 years ago and has used it for everything since then-- I wouldn't bother.
Django and Rails, like Python and Ruby, look more and more similar as time goes on. Not because they are becoming more similar, but because the web ecosystem around them has become a lot more diverse. If you want a break from Rails, learn Phoenix! Or Node, I guess.
Furthermore, with the advent of fat front-ends, the utility of both of these frameworks has gone down in absolute terms. When they first came out, front-end features like form generation and HTML templating were really important, but now they're arguably better to avoid. (That's why channels are so important to the future of Django.)
That said, I still like Django a lot and use it all the time. I don't want to discourage you from learning it. But I wouldn't do it because you're trying to make a leap from Rails.
The typical recommendation to getting started with Django, is to go through the tutorial included in the documentation [0]. This is the path I took several years ago, it'll get you up and running in no time.
I found Two Scoops of Django[0] to be a great resource if you want to follow the best practices for a Django app. The authors are also very active in the community.
If you're familiar with Ruby/Rails, I don't see any reason to switch. They're both good large frameworks. As you said, yes Django may sometimes feel a bit less "magic", due to Python's "explicit is better than implicit" motto, https://www.python.org/dev/peps/pep-0020/
If you want to give it a try anyway, Two Scoops of Django is a wonderful book, by two warm contributors from the Python community. https://www.twoscoopspress.com/
I can't answer your first question, they're similar high-level web frameworks - do you want to learn another?
As for books, I'd recommend Two Scoops of Django[1]. Between that and the tutorial you should be up to speed pretty quickly. Maybe read it and see if anything appeals to you about Django?
My 2 cents is that if you have a lot of Rails knowledge it's probably not worth changing.
However, Django has a much better security track record, and Python is used in a lot of other fields so learning the language has broader benefits. For these reasons I absolutely recommend Django to newbies over Rails.
If you plan to use Django as an API server, you might be interested in Lightweight Django (http://shop.oreilly.com/product/0636920032502.do), which shows you how to design and build an API server using Django, Django Rest Framework (another great Django related project) and Backbone on the front-end.
I don't see why you would need to learn it unless you wanted/needed to work on Python web projects. It is a fairly standard, opinionated web framework. I don't think there is anything unique enough to make learning it special.
No any reason. RoR is great.
But as a personal experience, most of my pals who came from the academic area ( Python in scientific programming is beautiful...), we felt more familiar with Django because, you see, it's more straight to use Python in producing dashboards or other Web based app. But I've personally found that the main thing is to generate backend data (Json, http request...) with Django/RoR and build the fronted with Js.
If you want to use in an effective manner your Python skills acquired in scientific programming to build web apps,...I would recommend Django.
The online documentation will serve you well. I recently had to learn django for my new job and I must say that I enjoyed every bit of the learning process.
There is no point unless you are going to using a lot of Python's scientific computing apparatus, or you want the ability to rewrite "hot" code in Cython for better performance. If you are primarily focused on social-esque or CRUD-heavy apps there isn't really an upside vs Rails.
Django has a time based release schedule [1]. The class based authentication views weren't committed until after the feature freeze for the 1.10 alpha.
To quote Channel's author, Andrew Godwin: "I will take the path-most-trodden for me and large Django features, which is to run it as an external package, compatible with 1.8 through 1.10 (which the package already is), and let it mature and develop outside of core, before coming round to look again at inclusion for 1.11 or 2.0."
I'm still stuck with Django 1.4 for one of my projects, it's such a big hurdle to upgrade it. I wonder if it's worth to just straight up rewrite it in 1.10.
As others have said, going release-by-release is the way to go. I migrated a project from 1.4 to 1.8 (LTS to LTS) over the course of a few months. It wasn't trivial, but it wasn't too difficult either.
The deprecation notices are usually (always?) accompanied by the code giving `DeprecationWarning` messages. These are silenced by default, but can be enabled by setting the environment variable: `PYTHONWARNING=d`. After upgrading to each major version, I'd recommend running with warnings enabled for a little while (in addition to reading the release notes), to see what may bite you at the next jump.
It is quite scary for me to read that people have serious issues upgrading their frameworks, wouldn't it be better to use pyramid (or flask eventually) instead?
It is very mature and well supported - and the upgrades are usually painless since you can upgrade all the components separately so sqlalchemy for ORM or Jinja2 for templates - whenever you feel you are ready.
You will not get things like admin panel as a downside though.
I agree with the advice of moving the project forward release by release. With that said, it might be useful to create a new project from the django-admin startproject template, and then add your apps back in.
Starting at 1.7, getting everything working and then doing it again with 1.10 would be my recommendation. YMMV though.
As someone who's picked up Python only in the last few years, Django is amazing. I'm particularly fond of Django CMS.
Does anyone know of a working "static site generator" for Django that works with Django CMS? Or maybe Wagtail? Something that would build out the static HTML pages ready to deploy to S3. Django CMS (thanks to Django itself) has a wonderfully robust back-office UI, and I feel like my Google-fu has failed me in finding that last puzzle piece to static site nirvana.
If there are any Django masters in the building: If you were starting a project today would you use 1.10 or stick with the LTS release (1.8)? I have a fairly mature django project using 1.6 that I would be borrowing a bit from, and my experience not upgrading off 1.6 due to pain makes it feel like an LTS path might be a good choice?
The next LTS will be released in about 9 months. If you're willing to make a small upgrade at that time, I'd build on 1.10 and then upgrade to 1.11 LTS, which will give you 3 years (I think..) plus 9 months of 1.10 support.
Moving from 1.8 to 1.11 shouldn't require any changes provided that you're running with 0 deprecation warnings on 1.8. The new release scheme means that if you're running on an LTS with no deprecation warnings, then you should be able to upgrade to the next LTS release with no changes (but lots of new deprecation warnings).
TL;DR: always update Django to the latest version you can, if your app is a little bit bigger, jump from one LTS to another may take some time.
LTS is great, if there is some reason that you cannot upgrade when new release comes. But if you use any plugins, just update to the latest version your all plugins support. Some plugins like (or even need) to use internal Django API's and if your app becomes pretty big, you may be tempted to use those internals in some places as well, which makes upgrades more painful due to internal API changes.
Speaking from personal experience of upgrading pretty big and rather legacy app from Django 1.4 to 1.8. Took more than a week.
If you are going to be around and have time to actively upgrade the project every time a new release comes out until it's running on the next version of LTS, I'd choose 1.10.
If you are just going to write it, and not constantly improve and upgrade it until the next version of LTS, I'd choose the LTS.
Django has managed to avoid collapsing under its own weight and for that it should be commended. If you've invested time in less-opinionated microframeworks, you're probably better off just not going the Django route(no pun intended).
[+] [-] Flimm|9 years ago|reply
https://docs.djangoproject.com/en/1.10/releases/1.10/
[+] [-] orf|9 years ago|reply
I use it as an API backend with Django-rest-framework. The advantage is you get ridiculous amounts of packages that all integrate with Django that does pretty much anything you want. Also the ORM doesn't suck now so that's a bonus.
[+] [-] ubernostrum|9 years ago|reply
[+] [-] graffitici|9 years ago|reply
[+] [-] hrayr|9 years ago|reply
I would love to see Django split up into smaller official external packages and repackaged as two or three different official starter packs (Traditional, API, SPA, etc.) with each containing a different set of packages that make sense (DRF, Channels, Models, Views, Forms, etc.).
I know this goes against the current "Batteries are included" model, but why can't we treat Django as the standards body, and the various starter packs as the more targeted "batteries are included" frameworks.
[+] [-] rdudek|9 years ago|reply
[+] [-] sdegutis|9 years ago|reply
[+] [-] ben_jones|9 years ago|reply
[+] [-] stenius|9 years ago|reply
Original: It doesn't mention it on this page, but this is also planned to be the last Django release to support python2. Django 2 will require python3.
[+] [-] davb|9 years ago|reply
Now that the transition is in full swing, it's encouraging to see more projects adopt a Python 3 First attitude.
I only wish Ansible would catch up (a recent release broke the core Python 3 support that was there, and no-one seemed to care as Py3 isn't yet officially supported).
[+] [-] evansd|9 years ago|reply
[+] [-] sold|9 years ago|reply
[+] [-] hrayr|9 years ago|reply
- Full text search for PostgreSQL.
- New-style middleware to solve the lack of strict request/response layering of the old-style of middleware.
- Official support for Unicode usernames.
[+] [-] dchuk|9 years ago|reply
And if the answer to my question is yes, what books/tutorials/screencasts/courses to people recommend to get started with?
[+] [-] bdr|9 years ago|reply
Django and Rails, like Python and Ruby, look more and more similar as time goes on. Not because they are becoming more similar, but because the web ecosystem around them has become a lot more diverse. If you want a break from Rails, learn Phoenix! Or Node, I guess.
Furthermore, with the advent of fat front-ends, the utility of both of these frameworks has gone down in absolute terms. When they first came out, front-end features like form generation and HTML templating were really important, but now they're arguably better to avoid. (That's why channels are so important to the future of Django.)
That said, I still like Django a lot and use it all the time. I don't want to discourage you from learning it. But I wouldn't do it because you're trying to make a leap from Rails.
[+] [-] hrayr|9 years ago|reply
I found Two Scoops of Django[0] to be a great resource if you want to follow the best practices for a Django app. The authors are also very active in the community.
[0] https://docs.djangoproject.com/en/1.10/intro/tutorial01/
[1] https://www.twoscoopspress.com/products/two-scoops-of-django...
[+] [-] ronjouch|9 years ago|reply
If you want to give it a try anyway, Two Scoops of Django is a wonderful book, by two warm contributors from the Python community. https://www.twoscoopspress.com/
[+] [-] nprescott|9 years ago|reply
As for books, I'd recommend Two Scoops of Django[1]. Between that and the tutorial you should be up to speed pretty quickly. Maybe read it and see if anything appeals to you about Django?
[1]: https://www.twoscoopspress.com/
[+] [-] kibibu|9 years ago|reply
However, Django has a much better security track record, and Python is used in a lot of other fields so learning the language has broader benefits. For these reasons I absolutely recommend Django to newbies over Rails.
[+] [-] heyts|9 years ago|reply
[+] [-] varikin|9 years ago|reply
[+] [-] babayega2|9 years ago|reply
If you want to use in an effective manner your Python skills acquired in scientific programming to build web apps,...I would recommend Django.
[+] [-] fortharris|9 years ago|reply
[+] [-] collyw|9 years ago|reply
[+] [-] Walkman|9 years ago|reply
[+] [-] bedros|9 years ago|reply
http://www.marinamele.com/django
[+] [-] CuriouslyC|9 years ago|reply
[+] [-] plumeria|9 years ago|reply
[+] [-] alasdairnicol|9 years ago|reply
[+] [-] hrayr|9 years ago|reply
According to channels' documentation:
> You can install Channels as a library for Django 1.8 and 1.9, and it (should be) part of Django 1.10.
[+] [-] czk|9 years ago|reply
[+] [-] heyts|9 years ago|reply
https://groups.google.com/forum/#!msg/django-developers/QRd4...
[+] [-] hrayr|9 years ago|reply
[+] [-] Walkman|9 years ago|reply
[+] [-] mamcx|9 years ago|reply
Normally I prefer that, and translate code manually. even more if the jump is big. Except if the goal is just stay current.
[+] [-] gtaylor|9 years ago|reply
[+] [-] stable-point|9 years ago|reply
The deprecation notices are usually (always?) accompanied by the code giving `DeprecationWarning` messages. These are silenced by default, but can be enabled by setting the environment variable: `PYTHONWARNING=d`. After upgrading to each major version, I'd recommend running with warnings enabled for a little while (in addition to reading the release notes), to see what may bite you at the next jump.
[+] [-] ergo14|9 years ago|reply
It is very mature and well supported - and the upgrades are usually painless since you can upgrade all the components separately so sqlalchemy for ORM or Jinja2 for templates - whenever you feel you are ready.
You will not get things like admin panel as a downside though.
[+] [-] bebop|9 years ago|reply
Starting at 1.7, getting everything working and then doing it again with 1.10 would be my recommendation. YMMV though.
[+] [-] asimuvPR|9 years ago|reply
[+] [-] EDevil|9 years ago|reply
[+] [-] spdustin|9 years ago|reply
Does anyone know of a working "static site generator" for Django that works with Django CMS? Or maybe Wagtail? Something that would build out the static HTML pages ready to deploy to S3. Django CMS (thanks to Django itself) has a wonderfully robust back-office UI, and I feel like my Google-fu has failed me in finding that last puzzle piece to static site nirvana.
[+] [-] encoderer|9 years ago|reply
[+] [-] jsmeaton|9 years ago|reply
Moving from 1.8 to 1.11 shouldn't require any changes provided that you're running with 0 deprecation warnings on 1.8. The new release scheme means that if you're running on an LTS with no deprecation warnings, then you should be able to upgrade to the next LTS release with no changes (but lots of new deprecation warnings).
Hope that helps.
https://docs.djangoproject.com/es/1.9/internals/release-proc...
[+] [-] trymas|9 years ago|reply
LTS is great, if there is some reason that you cannot upgrade when new release comes. But if you use any plugins, just update to the latest version your all plugins support. Some plugins like (or even need) to use internal Django API's and if your app becomes pretty big, you may be tempted to use those internals in some places as well, which makes upgrades more painful due to internal API changes.
Speaking from personal experience of upgrading pretty big and rather legacy app from Django 1.4 to 1.8. Took more than a week.
[+] [-] mozumder|9 years ago|reply
Always start new projects with the latest version. You don't want to be stuck on really old versions when you eventually upgrade.
[+] [-] OriginalPenguin|9 years ago|reply
If you are just going to write it, and not constantly improve and upgrade it until the next version of LTS, I'd choose the LTS.
[+] [-] asimuvPR|9 years ago|reply
[+] [-] hoodedfang|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]