

Has Django become a pay-for-features framework? - antelopesalad

I happened to ask a question on IRC last night to see if it would be possible to improve runserver such that it was able to reload between code changes faster or swap in new code on the fly without reloading.<p>It got a response from Russell Keith-Magee and others who are very skilled with Python&#x2F;Django.<p>Basically the general census was it&#x27;s possible but it would be a ton of work. Russell immediately placed the blame on third party apps and shrugged off the feature request while others said a feature like this would take a lot of time and is a massive under taking.<p>To get migrations in 2014 with a future release of Django required the community to pony up $30,000 USD through kickstarter.<p>I&#x27;m really worried about Django&#x27;s future because it seems like we won&#x27;t get any new features in the framework in a reasonable amount of time unless the community pays them tens of thousands of dollars. Couple that with the 2 BDFLs leaving recently, then who is using Django in a project where they can extract&#x2F;create features into the framework based on real needs rather than invented ones?<p>It really sounds like to me that none of the core devs even use Django, so it&#x27;s up to the community to figure out useful features that people actually want but the community wants money because it takes up their time.<p>Thoughts? Would you pay real $ through kickstarter if runserver swapped new code in like rails so development wasn&#x27;t a torturous experience?
======
SEJeff
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](https://github.com/django-extensions/django-extensions), it is
really nice stuff.

~~~
antelopesalad
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.

~~~
hexsprite
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.

~~~
antelopesalad
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.

------
gboone42
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.

------
rbanffy
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.

~~~
antelopesalad
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.

~~~
rbanffy
> 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

~~~
sethish
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.

~~~
antelopesalad
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...

~~~
rbanffy
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.

~~~
antelopesalad
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.

~~~
rbanffy
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.

~~~
antelopesalad
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](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.

------
memracom
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.

------
jasonlfunk
pip install django-extensions

./manage.py runserver_plus 8080

Just saved your $30,000 ;)

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

~~~
antelopesalad
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.

~~~
sergiotapia
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." :)

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

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

