3 ms·

I started Python programming 8 or 9 years ago and went from bottle to flask to Falcon to Django to Sanic. Django is incredible - I wish I'd started with it. I

I started Python programming 8 or 9 years ago and went from bottle to flask to Falcon to Django to Sanic. Django is incredible - I wish I'd started with it. It's truly the most useful framework I've ever used - a real workhorse for building applications. Flask and bottle are minimalist and get the job done for focused tasks - for example I hacked together various web examples into an mjpeg server recently used Flask (based on Miguel Grinberg's webcam server). You can get a simple web site up and running in 3 minutes with bottle or Flask. I'd recommend against using them for anything bigger though - you'll just spend all your time reinventing Django (badly). I use Sanic for asynchronous web servers. Falcon is great to use to build APIs - it's raw and minimal and built to task. Indeed in my latest project I use Django for the main web application, Flask for the mjpeg server and sanic as a long polling web server acting as a message queue server.

dragonsh 7y ago
I have used Django a lot for applications where front-end is server generated HTML page with templates. For REST API or GraphQL minimalist framework like CherryPy, flask, bottle and others combined with excellent Python libraries will work great even for a large modular app. It is not true when you recommend don't use flask or bottle for large apps. On the contrary it will be good for large projects to use minimalist framework as they will act more like library. Also you can write code yourself for the parts in the system which outgrow the framework. My team has built large production level application for machine learning service initially in Django and then later ported completely to flask. Given we don't use templates and jinja2 as most of the front-end is in SPA, flask has been wonderful to work with. Django rest framework doesn't work that well when you just need to work directly with request/responses. Blueprints made it so easy to write large modular code that choice between monolith and micro-service, just a configuration setting coupled with either gunicorn or uwsgi in emperor mode. All Python framework under the hood are WSGI or ASGI, so a decent Python programmer can use excellent marshmallow, sqlalchemy, alembic, celery and flask (or others) with blueprints to write a performant large modular application and a service layer.
kjsbfkjbf 7y ago
I started learning Python web-development with Django, but it really didn't click until I learned with Flask and other "minimalist" frameworks first. It could have been the available material at the time, but understanding step by step what I got for "free" with Django was really helpful for me. I think it also helped me understand web frameworks (or at least the specific paradigm) in general. At times with learning Django I felt like I was _learning Django_. I have this same issue with ORMs. That said I still really like Django and use it now that I have a somewhat better understanding of what it's actually doing.
neetdeth 7y ago
Veering a bit off topic here, but I somewhat recently used MJPEG for a "live preview" type of application and found support on the browser side to cause no end of frustration. Details escape me now, but some browsers could never be made to stop streaming without closing the tab, certain versions of Chrome didn't work at all. It felt great to finally figure out the correct HTTP header incantations to get a working-ish solution with MJPEG... but if I had time to revisit it I would have tried instead encapsulating JPEG frames in WebSocket messages and blitting them to a canvas with JS. MJPEG seems to be firmly in legacy territory and while browser vendors have to keep supporting it for IP cams, it's probably going to keep getting hit with the regression stick. Meanwhile WebRTC is notionally the correct replacement technology but the complexity is high and support is still hit or miss.

dragonsh 7y ago

I have used Django a lot for applications where front-end is server generated HTML page with templates. For REST API or GraphQL minimalist framework like CherryPy, flask, bottle and others combined with excellent Python libraries will work great even for a large modular app. It is not true when you recommend don't use flask or bottle for large apps. On the contrary it will be good for large projects to use minimalist framework as they will act more like library. Also you can write code yourself for the parts in the system which outgrow the framework. My team has built large production level application for machine learning service initially in Django and then later ported completely to flask. Given we don't use templates and jinja2 as most of the front-end is in SPA, flask has been wonderful to work with. Django rest framework doesn't work that well when you just need to work directly with request/responses. Blueprints made it so easy to write large modular code that choice between monolith and micro-service, just a configuration setting coupled with either gunicorn or uwsgi in emperor mode. All Python framework under the hood are WSGI or ASGI, so a decent Python programmer can use excellent marshmallow, sqlalchemy, alembic, celery and flask (or others) with blueprints to write a performant large modular application and a service layer.

kjsbfkjbf 7y ago

I started learning Python web-development with Django, but it really didn't click until I learned with Flask and other "minimalist" frameworks first. It could have been the available material at the time, but understanding step by step what I got for "free" with Django was really helpful for me. I think it also helped me understand web frameworks (or at least the specific paradigm) in general. At times with learning Django I felt like I was _learning Django_. I have this same issue with ORMs. That said I still really like Django and use it now that I have a somewhat better understanding of what it's actually doing.

neetdeth 7y ago

Veering a bit off topic here, but I somewhat recently used MJPEG for a "live preview" type of application and found support on the browser side to cause no end of frustration. Details escape me now, but some browsers could never be made to stop streaming without closing the tab, certain versions of Chrome didn't work at all. It felt great to finally figure out the correct HTTP header incantations to get a working-ish solution with MJPEG... but if I had time to revisit it I would have tried instead encapsulating JPEG frames in WebSocket messages and blitting them to a canvas with JS. MJPEG seems to be firmly in legacy territory and while browser vendors have to keep supporting it for IP cams, it's probably going to keep getting hit with the regression stick. Meanwhile WebRTC is notionally the correct replacement technology but the complexity is high and support is still hit or miss.