Hacker News Reader

Comment by bjt | Hacker News Reader

On one hand, awesome to see Django getting first class Websockets support.

On the other hand this feels a bit like "Build the web applications of today, tomorrow!" I think that's an inherent problem with kitchen sink frameworks; new things that come along have be shoehorned into the old way of doing things, except when they can't, and then you have to restructure your foundation. I stopped using Django a couple years ago because the kind of apps I wanted to build were REST APIs, websockets, a little static file serving, and connections to realtime backends like redis pubsubs or RabbitMQ. Django wasn't great at any of those, yet carried a lot of baggage from stuff I didn't need (e.g. form handing, templates).

I would recommend Flask and/or its underlying Werkzeug library (my personal preference) over Django.

View on HN

I agree a little bit, but also part of building out a framework is making choices for people - waiting, looking at the problem space, and picking a solution that most people will be happy with.

There are some projects that Django is not the right solution for and something like Flask/Werkzeug is definitely better, for sure, but I'm hopeful that the work being done here will help out the majority of people; it brings a lot more than just WebSocket support to the table, that's just the headline feature most people run with.

Django has a community and leaders that care, and Django continues to get better.

Flask is basically abandoned, despite continually receiving undocumented commits.

Flask hasn't even had a PyPi release, or even a Git tag for that matter, since June, 2013. The documentation is also far behind.

Flask is not abandoned. It receives far less commits than Django because 95% of features common to Flask apps are in modules which are not part of Flask core. Flask plugins are thriving... The last commit in Flask-SQLAlchemy for example was 2 hours ago.

The other main difference is Django is developed as part of a large organization, Flask is not. Get the right people together and that could be fixed easily...

Most of Flask's heavy lifting is done by Werkzeug, which had its last PyPi release a month ago.

I use Werkzeug directly rather than Flask, so I can't speak to whether Flask is abandonware or not, but I'm very happy with Werkzeug. With very little effort, I get to build just enough framework for my application, without having to be shoehorned into someone else's tradeoffs.

Very interesting. I'm going to give Werkzeug a try.

Have you tried out Falcon, btw? If so, how does it compare to Werkzeug?

I haven't tried Falcon. I hear it's fast.

That doesn't seem to be the case: https://github.com/mitsuhiko/flask/graphs/contributors. The owner seems to be fairly active, but it is surprising that there hasn't been a release in two years. It is a micro-framework though so how much can they really add, and the apps and ecosystem around it hasn't stagnated at all.

> ... so how much can they really add

They add tons. There are many commits, bug fixes, etc. It's just that there A) hasn't been a release to PyPi, B) is an inordinate quantity of unmerged pull requests, C) are many undocumented changes, and D) issues like https://github.com/mitsuhiko/flask/issues/1272 that are over a year old (I left a comment https://github.com/mitsuhiko/flask/issues/1575#issuecomment-... explaining the vicious circle that I believe is created by not releasing to PyPi). I commit to Django (and donate), but I would never commit to Flask when it makes no attempt at Industry Standards™ like PyPi releases.

I shouldn't have said it's "abandoned", because that's an insult to the parts of the community that are very active.

Why is flask abandoned? Can't software just be done at some point?

We have been concerned about that as well - we have our infra built around Flask already.

Im wondering what's a suitable alternative.... with SQLAlchemy and Celery/RQ integration?

Pyramid?

I've felt a similar pull away from django on a number of apps. Just looking through the Channel docs [0] however, many of the reasons I get frustrated with Django (primarily the lack of a solid websocket/SSE story) are being addressed. Frankly, I'm addicted to Django's built in auth & admin UI, and I'm thrilled I won't have to bolt on a kludged solution if I want to get some realtime behavior. My frankenstein chat system of Node & Django can be put out of its misery... someday.

[0] http://channels.readthedocs.org/en/latest/concepts.html

I was thinking the same thing about building the technology of today in the future with respect to integrating Django REST Framework rather than GraphQL.

Reply on news.ycombinator.com