Hacker News Reader

Comment by mladenkovacevic | Hacker News Reader

I know purists and more experienced developers will disagree, but for a clueless beginner like myself with no real-life connections to the developer community, it's awesome how external projects have been integrated into official Django releases as they become widely adopted and production ready. From staticfiles, through migrations (developer of South took this one to Kickstarter too) and now channels and DRF. Python 3 followed a similar path with virtualenv.

Does any other framework ecosystem work the same way? I don't follow Rails or other ones as closely as I do Python and Django.

View on HN

Whether you're a fan or merely tolerate the Python environment, to me the biggest advantage of Django above literally every other web framework I've worked with, is the fact that the developers are extremely serious about maintenance, compatibility, and documentation, things which matter in large, long-lived projects much more than the newest bell and whistle.

The core team has been willing to rip out and improve central infrastructure but never at the cost of unreasonable backward incompatibilities, and all changes are documented. Upgrading is never easy on large projects but it's been the easiest in Django. And the third-party packages pretty much fill every niche in a very modular way.

I see other devs complaining about their current frameworks' lack of documentation or testing and I feel like I'm in a parallel universe. I can never go back trivially to year-old JS code (and Rails isn't that much better) without some level of breakage or a new way of doing things.

Of course other technologies share a similar position on the matter, but they generally don't move as fast as Django does.

The one thing that constantly impresses me in Django is how the devs handle changes. As much as possible they follow a deprecation schedule, provide opt-in support for future changes ("load url from future" for the url template tag change was introduced in Django 1.3 for a breaking change set to be default in 1.5), and document these changes.

For the most part they've not had to make huge changes because they've made good decisions at the beginning and resisted doing silly things in the core. Contrast with Rails and their scriptaculous past, which was dumped for coffeescript, which I'm pretty sure will be dumped soon (coffeescript is fading from the js mindset now for react/jsx/angular/typescript).

> compatibility

You're joking, right? They break compatibility with every minor version, forcing tens of thousands of developers to waste valuable hours each time they update.

If there's something to learn from this project, it's that if you find your niche and gain enough momentum, you can piss on your user base and they'll say it's raining.

Name one single framework that is perpetually backwards compatible while being even remotely modern.

I think the major difference with Rails is that major new features and maintenance of the framework is extracted from a wildly successful service (Basecamp).

A quick Googling estimates that Basecamp generates 10 million+ a month[0] in revenue.

That's the one thing I like about Rails. Features and design decisions tend to come from real life use cases. The core developers have every reason in the world to make it the best it can be because their entire business depends on it.

https://www.quora.com/How-many-paid-customers-does-Basecamp-...

Reply on news.ycombinator.com