Would anyone who is familiar with both Django and the .js ecosystem care to comment on how they compare? I'm curious to know what how I would find life in the server-side js world. I've not heard of anything in the js ecosystem that's taking on the sort of problems Django tries to solve. (not to say they aren't solving different problems in some better ways)
Is it more sensible to regard Django (and Rails and other frameworks from that generation) and the node ecosystem as complementary rather than competitive at this present time? i.e. to use Django for the content-heavy parts and run node alongside it for the more app-like or real-time aspects?
And is this likely to change over time?
(please - don't let this prompt another micro vs macro framework debate or a discussion on Django being 'too big' - save that for another time)
The simple fact that Django is an extremely mature framework with very experienced developers with a highly opinionated vision means that you'll definitely avoid a lot of work just because they've been addressing issues many years before Node even existed.
That said, it also comes with the baggage of the Python ecosystem. You're not going to find any support for async stuff like node (you'll depend on message queues for async stuff, but frankly there are really nice options out there), and you're not going to find anywhere near the amount of experimental projects. Django is used to solve the use cases of web developers that need to deliver.
I would stay away from it if you definitely need high performance or concurrency, but I have not seen many things comparable when it comes to well-engineered, pretty, and functional CRUD apps. Do not underestimate the difficulty of building those.
I think it depends entirely what you need to do and what your programming tastes are. Primarily, will Node's async nature bother you, or is one of the means of dealing via practices or libraries enough for you?
I've not found anything in the Node.js world that's as nice as Django's models to sit down with and model the data and relationships required for whatever you need to do and play with it in a REPL as you do so, or kick off an admin config to get the data working before you touch a line of request-handling code. It's a similar story for things that are built on top of django.models, like its auto-admin, or much of the ecosystem of django-* libraries. I couldn't leave django.forms behind, though, so I ported it to JS :)
In terms of your everyday handling HTTP requests, it's much of a muchness. Request objects, response objects, get some data, render a template, you know the drill. It's never going to feel the same as Python & Django, but you can comfortably write the sort of apps you write with Django in it, as long as you're down with the asyncness. If anything, certain parts can be even stronger - Jade templates, IMO, make it even more convenient to to do Django-style template inheritance, while its mixins make it much easier to extract reusable chunks of markup + logic without having to step outside templates. You also have the option to reuse templates - and other pieces which support the whole "isomorphic" thing - on the client side , but that not might be the sort of thing you need to do.
The default branch is currently focused on using it with React to add client-side interaction and using React's server rendering - master (0.4.2) can be used for rendering and validation anywhere, though.
I'm finding the authentication and permissions of Django makes Django Rest Framework trump every server side js library attempting to fill the same role, so far.
People do write entire conventional web apps (e.g. REST APIs) with Node, so I'd say they are competitive and that it comes down to taste.
If you're being drawn to Node because of real-time stuff, though, I personally would suggest a mixed architecture. I'm a fan of using Django for the conventional stuff and then something else alongside it for real-time. You can use a reverse proxy in front to make the services appear to be unified.
Can someone familiar with Grails and Django give their 2c? I've done a fair amount of work in Grails, and when I did a small project in Django I found it somewhat more difficult to work with.
With Django, the quick test runs and startup were wins (although Grails mitigates that a bit these days), but I thought Django's organization (or lack thereof) was a confusing mess and dealing with forms was an exercise in bending the API instead of working with it.
The idea in Django is that you really want to break up your project into several apps, with each app having just a handful of models and views. Aside from depending on some conventions such as a models and views file for each app, apps can live anywhere, so you can separate them through subdirectories if that works for you.
The forms API is, granted, not super easy to work with initially, but its abstractions are really powerful and bending them to your will is trivial, because everything is overridable.
When I used it (forms), it sure seemed powerful in idea, but I ended up with a ridiculous amount of code to generate dynamic forms (different field types depending on the object instance).
I will safely assume that as a beginner I was missing some part of the puzzle, but I was never able to track down a good way to do it. Oh well.
How useful Django's forms are (and which ones to use) varies widely based on your requirements. I've had projects where the combination of the UI I had to work with and the data that was being manipulated required Form classes to be built and validated manually. Right now I'm working on a project with a fairly complex data set, but everything is falling beautifully into place with generic ModelForms created implicitly via FormViews with only minor tweaking to field visibility.
It took me a while to get a solid handle on them, but Django usually does forms very well. The best case is that your UI requirements are fairly loose, otherwise it's likely you'll end up with mostly-custom HTML, but even then you still have the potential to save a lot of Python code with things like ModelForms and/or FormViews.
Well, StackOverflow helps a lot there. The important thing is that the process is standardized and fairly uniform.
If you're using a lot of code to generate forms that depend on models, look into ModelForms: they allow you to generate a form that maps to a specific model's fields trivially and allow adding additional validation and persisting the model to the database.
Dynamic forms in django are difficult. Personally, I think generalized handling of forms is just a hard problem - I have yet to see a library that handles every case, nor do I know how I'd go about writing one.
There is the package wtforms, however, which I've found is more pleasant than django forms.
while I'm not familiar with Grails, I am familiar with other frameworks besides Django and I've got to say, it seems like lots of the choices the Django developers made are completely backwards compared to how other frameworks manage things.
- Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it?
- ModelForm._meta knows it's app_label, why doesn't a regular Form
- 200-line migration files are just not fun to grok.
- ID based migration file names are a pain when multiple devs are involved (Rails / SQLAlchemy solve it using timestamps / SHA1s. South closed it as a wontfix years ago)
- Having a user model you're not supposed to touch
- urls.py gets way too disconnected from what they are actually routing to
- managing 'apps' is silly, making a new directory in python gives you just about the same advantages.
- if request.method == 'POST': ...
- The `class Meta:` pattern.
SQLAlchemy is the better ORM for python.
Jinja2 is a similar template syntax but with better performance.
WTForms are easier to work with than Django forms.
Tastypie also makes a lot of dubious decisions.
I just really don't see where this framework fits in.
> Form. ModelForm? Formset. Inline formset? Model Formset ... ? Jesus I just need data POSTed back. Why must I use your management_form when you don't also give me the JS to ... manage it?
Because Js stuff belongs in the frontend? Django very explicitly does not do frontend logic.
> ModelForm._meta knows it's app_label, why doesn't a regular Form
Because ModelForms depend on models which depend on apps to function properly. Forms are just plain old classes.
> 200-line migration files are just not fun to grok.
No, but they allow the migrating class a lot more flexibility by letting you access the ORM within a migration with no concerns about what your current models files look like.
> Having a user model you're not supposed to touch
1.5 and on have pluggable user models. Prior to that most of the important stuff was highly overrideable.
> urls.py gets way too disconnected from what they are actually routing to
That speaks more of the issues with your routes rather than what the framework allows. There are a few well-established patterns which make the routing no less clear than any other framework.
> managing 'apps' is silly, making a new directory in python gives you just about the same advantages.
Then you're not understanding what a Django app actually is and how it differs from a regular module.
> if request.method == 'POST'
As opposed to?
> SQLAlchemy is the better ORM for python. Jinja2 is a similar template syntax but with better performance. WTForms are easier to work with than Django forms
Seriously, these are non-issues, they have been touched upon dozens of times, and you clearly have not used the framework's integration capabilities sufficiently to understand its strengths, so either use something else or learn to leverage its unique advantages.
Django has a steep learning curve (but following the tutorial is good, as opposed to some books that are touted as "very good" but only confuse things)
The problem with Django is two-fold: the docs are very good but you need to know Django to be able to find the things there
Also, Django is "magic" but less magic than people think and sometimes you need to go beyond the "public API" to do what you want (it doesn't mean you're piercing the API, but it is more grained than you think)
And sometimes of course the API is faulty and you have to work around it (like password reset emails that are text only and is being fixed in 1.7)
So, I'm still at 1.4.10 for my startup that's still in private beta. I'm feeling left behind very rapidly. Is the effort to update from 1.4.x to 1.7.x worth it before going public? Also, as a general policy, is it best to always stay one version behind?
Take a look at the release notes for 1.5 and 1.6, and see if there's anything there that would be useful to your project. I would advise keeping as current as you're able to, to reduce the migration costs in the future. Migrating to 1.5, testing, and then to 1.6 would probably be the best way forward.
Just take a look at the backward incompatible changes in both sets of release notes to get an idea of how the migration will affect you. There are lots and lots of nice improvements in 1.6 and especially 1.7 that you may be interested in.
At least get to 1.5 before you have significant data. Get proper time zone support now while it's still painless, particularly if you have an app that relies on sensible time representation.
Also, remember that when 1.7 is released, 1.4 will no longer received security updates, only 1.5 and 1.6 will.
Ah, sorry, I'm mistaken about the 1.4 series specifically. It was designated an LTS release and is scheduled to receive security updates through March 2015 [1].
However, this is only security updates, not necessarily bug fixes.
> Is the effort to update from 1.4.x to 1.7.x worth it before going public?
Having recently upgraded two production projects from Django 1.3 to 1.6, I'd say YMMV but it likely isn't. Go public unless you have someone at hand with enough eagerness and knowledge of the codebase to do the migration quickly so you don't have to postpone the release.
The migration itself is no big deal, as others pointed out—you just make a checklist of backwards-incompatible changes and walk/grep through the codebase for every item. I don't think any DB schema migrations were required. Took me two days a project, not counting manual testing afterwards (unit tests were there, which is convenient but can't guarantee that everything will work).
The process is not very exciting, though. It helps when codebase is stable and you have the time to go through it without rush and make sure everything works for some time after deploying the upgrade to production (being ready to roll back quickly). That's also why I'd suggest going public and leaving Django upgrade for later, when things calm down a bit.
1. How many 3rd party apps are you using? Be especially wary if the a) perform any clever black magic on Django internals or b) are only lightly maintained and the job of updating them might fall to you.
My app actually broke going to 1.6 so we had to go to 1.5. At some point soon we'll try again to see what went wrong, but I remember looking into it and it was actually a bug in 1.6.0 iirc.
We recently upgraded a large Django app from 1.4 to 1.6, we actually begun the transition when Django was on 1.6b1 as we hoped they would hit stable before we were ready for production (they did). To be honest the only issues we had were 3rd party apps that had not been updated, which wasn't surprising as 1.6 was still in Beta when we began. And as 1.6 neared release we found fewer and fewer apps that still had problems.
Beyond that it was pretty straight forward, but it really helps if you have good unittests to begin with.
In the final stages of upgrading a 1.4.x project to 1.6. The process seems to have been very simple, other than two very specific bugs that you are unlikely to run into (one had to do with our own code and how it interacted with django_compressor, the other was in the Oracle driver which I doubt you are using).
Do the upgrade. Just read the release notes for every release between the versions you are going through and make sure to make the changes they suggest/require. It'll take you 2 hours and yes it is worthwhile.
This document[1] seems to imply that Django works with Python3 since 1.5. But I don't find mentions of it in the release notes of 1.7b1[2] on the Python Compatibility area.
My main interest in porting my 1.3 Django App to a newer version is to get Python 3 support.
Does anyone here run Django on Python3 and care to share the experience?
Django 1.7 supports Python 2.7, 3.2 and 3.3 [1]. I guess Python 3 isn't mentioned on the 1.7 release notes because Python 3 support has not changed from 1.6. I can see how you'd find that confusing.
I was just about to get started learning how to use South migrations. Should I continue, or just focus on the development of the rest of the project while I wait for a stable Django 1.7 to get released? What sort of timeline does its releases usually follow? Is the API fairly consistent with South, seeing as its from the same developer?
https://www.kickstarter.com/projects/andrewgodwin/schema-mig...