Has Django become a pay-for-features framework?

The money for migrations was to employ the guy who wrote south to work on those migrations fulltime. It wasn't as much of a "community" thing as one guy who did it all. That wasn't the django "community" but a single django contributor. I think you've got things a bit mixed up here. Overall, the core of django sholud be small. The real good stuff is in the reusable apps.

Besides, runserver isn't supposed to be for production. If you want things to run faster run it under a real wsgi server such as circus/chaussette, uwsgi, or gunicorn. That being said, I highly suggest looking into runserver_plus from: https://github.com/django-extensions/django-extensions, it is really nice stuff.

This has nothing to do with production mode.

The development experience is unacceptable with runserver in development mode. I have a trivial app with half a dozen apps and it takes 5 seconds to reload runserver when I touch a view file.

On the same hardware a ~6k SLOCs rails project with 40 gems reloads pretty much instantly because the rails dev server is smart enough to do code swapping.

Edit:

runserver_plus does nothing to make runserver reload faster, it is an improved stack trace with a built in debugger. Since I am already using django-extensions I tried runserver_plus and it added 2 full seconds to each reload.

So now it takes 7 seconds just for runserver_plus to reload after touching a view.

If you consider the development experience to be unacceptable, then use something else.

Why don't you try using Python's profiling tools and file a bug report with what you find? That might get you a better response than asking on IRC.

I don't have the time to audit and analyze the entire django framework and every third party app I touch. I am only using a few apps too that are popular in the community.

Realistically I'm a web app developer who wants to be productive. It's insane that I need to even consider doing that just to not have to wait 5 seconds for runserver to reload in development mode on a trivial app. It should be on the shoulders of the django core team to make sure their platform makes developers happy.

P.S., if you want to give me $100,000 I will quit my job and spend the next half a decade learning advanced python, audit the entire django code. You would probably laugh and call me insane right, but this seems like what the django core devs are forcing us to do because they don't want to address the problems with the framework.

idk what you're working on, but i'm currently working on a ~100mb app. It's pretty big, and i've never had anything like what you're talking about. are you sure it's not hardware related?

Devs clearly thought integrating South into Core was worth shelling out for, they could have sat on their hands after the project hit it's modest 2500 pound goal but, they didn't.

Django, and all open source projects, benefit from the law of increasing returns. As more people contribute to it, with code, money, or simply by using it, the entire user base benefits. WordPress is a great example. I remember the days when WordPress was kind of wonky, but as it rose in usage and attracted more developers (and more of us started getting paid to contribute to the theme/plugin repos or Core), it quickly became stronger and oh so much more stable. There are tons of paid ("premium") plugins and themes out there now, and so many people paying for WP.com, but it's by no means a "pay for features" platform.

With Django, paying Andrew Godwin to dedicate some of his time to integrate South into Core is definitely the kind of thing all of us will benefit from whether we contributed or not, as would runserver. At £2500 (his original goal) it's not like we're paying his salary. Even with the $30,000 he raised, it's not like he's living high on the hog ℅ the django community. If someone wants to field a kickstarter for £2500 to improve runserver and people want it as badly as people wanted South integrated, it'd probably be successful. That kind of voluntary patronage hardly makes it a pay-for-features platform.

No. I don't think the experience is that bad anyway.

Django is Free Software. You get a corpus of software developed by an incredibly competent and generous group of people for free. These people solve their own problems and kindly donate their solutions for all to use. For free.

If you have a problem that bothers you, you are free to solve it or to pay someone else to solve it for you. If it's a problem for too many people, it will, eventually, be solved by some generous person and you'll have your solution, again, for free.

If it's your problem and only your problem, nobody else has any obligation whatsoever to solve it for you. BTW, nobody has any obligation to solve any problem with Django. It's done out of either love or necessity.

We all have busy schedules. We all have families we love to spend time with. If I have to choose between spending time with my family and solving your problem, you'd better not hold your breath.

That's kind of my point. If there's no love from the core devs to solve real problems that the community has then what are our choices?

Having to throw up kick starters for every feature is unreasonable.

Migrations were something that SO many people wanted and the core devs didn't even think to add it. It had to be merged in by a random person in the community for $30,000 and it also took 14 months assuming Django ships 1.7 in May going by their roadmap.

That is 14 months and $30,000 to get a feature into the framework while already having a tested and battle hardened implementation as a third party module.

> solve real problems that the community has

Define "real". Like I told you, it doesn't bother me.

> Migrations were something that SO many people wanted

You are right - and we had South for it and we used it a lot. Integrating South into Django's core was not a trivial effort, however, but, again, since we already had South, it was not a big issue.

> That is 14 months and $30,000 to get a feature into the framework while already having a tested and battle hardened implementation as a third party module.

IIRC, the 30K were paid to the third party who created South to build a better migration engine it into Django. You can continue to use South for as long as you want. It's just that, starting with 1.7, you'll get migrations built in and South will no longer be required.

I still fail to see why do you think everybody has to be concerned with the problems you find important. If it bothers you so much, then solve it.

edit: corrected the character of the effort

The migrations project was a re-write, not an integration with South. Common misconception, but the new migrations implementation is actually better than South's.

That's even worse. So the author of south threw out all of his work and re-wrote it from the ground up rather than the core devs just working on it?

That's disgusting...

What is disgusting is a lazy coward creating a throwaway account to complain about the lack of generosity of people far more capable - and generous - then themselves.

Stop hiding.

I see the coward has a regular account and is capable of downvoting...

Except you could go look for yourself on Google and see this is my normal IRC name and if you wanted to read the conversation that sparked this topic since I'm pretty sure the #django IRC logs are public.

You can accuse me of down voting you but you're accusations are misplaced. I wouldn't waste my time. How about you go ask the site owner to check who down voted you.

I will bet my life that it's not associated to my IP address or this account. Go troll someone else man and lay off the insults, it makes you look like you're a child.

So, this is your first access to Hacker News?

Why should I believe it?

BTW, an SSD would be much cheaper than paying for someone else to solve your problems.

I shouldn't have to buy an SSD to develop comfortably with a dynamic language.

Even compiled languages like Go using non-trivial frameworks (Revel) reload faster than django's runserver. It's like django's runserver is still in 2007 while everyone moved on years ago.

I'm also not the only one who isn't happy with the speed because right now runserver polls for updates every second. Some core dev implemented a change so that it's push based now instead of polling every second and should be in 1.7, but this only happens if you have pyinotify.

Want the know the kicker? The ticket to do it was opened 5 YEARS AGO.

https://code.djangoproject.com/ticket/9722

That's only a small gain though but it's crazy to think that it's been polling this whole time. I'm all for polling in web apps when possible but seeing a comment you didn't know even exist pop up 3 seconds after it was made is much different than expecting immediate feedback when you spend ~60 hours a week developing a web app.

Or maybe you got the guy who knew how everything worked re-write it to function better than it had before, versus having core devs learn exactly how it worked and then implemented it.

To go back to your original question, of is Django pay for features, I don't know enough about it. But one place you could look into is the amount of corporate support Django gets. Maybe Rails has enough corporate support + people who want to work on Rails in their free time in order to get the features, versus Django. Sometimes you need to pay people to work on open source projects and the crowdfunded thing is just more visible than the corporate employees.

You seem to have a grudge against the world for some reason. Why are your posts so hostile?

Do you not see the bigger picture? The runserver problem is only 1 thing. People are expecting to be fed tens of thousands of dollars through kickstarter to create features that people want instead of the core django devs implementing them.

The reason why rails has an amazing development experience has nothing to do with rail's API or ruby.

It's because rails is extracted and built out of a product that some of the core devs work with 24/7 (basecamp). They add useful things like a development server that isn't garbage because they work with it on a daily basis full time.

I don't want to see Django fall over because they don't add any features that people actually want and instead force the community to beg for money on kick starter to do it.

You seem to have a misplaced sense of entitlement. I must admit I have a problem with people who have such personality issues.

You are expecting developers to adapt the amazing software they made (for free) to your needs and do all that immense effort for free. You see your problems and think they should be everyone else's top priority. Should they thank you for pointing The Way?

You have to understand the world does not revolve around you.

Django is free as in freedom. You have the freedom to modify it to your needs. Use it.

What you described is not a feature. Speed, or anything involving time, is an optimization, not a feature. Features are easy to add on to an application, but time, once lost, can never be regained.

Optimization usually requires fundamentally changes to architecture, and in the case of Django it is well-known that it is not for building fast or highly scalable apps.

Functional Reactive Programming is far better for building high performance apps.

Specifically, you are asking about code swapping which is something that is only used by developers during development, not during production. Most developers deal with such problems by getting faster hardware.

And finally, even if Django development stops today and it never gets any new features, it is still an ideal tool for building apps that are in its sweet spot. And it is easy to supplement with things like Celery or RabbitMQ to communicate with scalable non-Django backends. Nothing to fear here, move along.

pip install django-extensions

./manage.py runserver_plus 8080

Just saved your $30,000 ;)

If you feel the direction is lacking in Django I would recommend switching to something like Rails or Laravel.

I'm already proficient in rails, it's why I'm so jaded by having an unbelievably good developer experience. I'm not talking about ruby or even the rails API/community/etc. either.

It's just the problems that they address are the problems that matter for people who actually develop web applications full time because the core rails team develops basecamp full time and extracts rails features from their experiences.

The django guys are simply not doing this. I can't put my finger on it exactly but Python calls to me like a siren. It's unfortunate that Django doesn't seem to want to address problems that people have, aren't addressing modern web development problems and are calling out to the community to raise money to introduce features to django's core.

It took me like 3 weeks of hunting down random packages that add certain functionality, forking and fixing libs because the maintainers of those libs hate python 3 and won't support it just to get to the point where django was even usable as a development platform and now after all that I'm stuck having to waste 5 seconds of my life every time I touch a view or model.

Then I have to wait 1.5 seconds for SASS to recompile between page reloads because the django-pipeline author (who is awesome btw) doesn't have the time to make pipeline cache the sass files and only recompile them when they change.

It's one of the more anti-productive environments I've ever developed under and it's a pity because the django API is actually pretty good and I want to give it a chance.

I'm 100% agreeing with - I hope my comment wasn't taken as a snarky, "If you don't like it leave!". Take it as a "there are better alternatives, don't bother." :)

I, too, hate it when people ask to be paid for services rendered. You're supposed to be working for free, damn it!

There is a reason work is called work and not play!