Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Discover Flask

discoverflask.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Discover Flask

#61

Post by pbreit »

ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

This is mostly my experience as somewhat of a newbie. Every project I contemplate needs user accounts and admin. And db access & migrations make development so much easier. I guess if there was a solid recommendation on what Flask components/addons would be good to use for a "regular" web site, Id be OK. Otherwise, it ends up being so much more comfortable to go "full stack".

Re: Discover Flask

#62

Post by mekoka »

After reading some comments pinning Flask and Django for "big" projects, I feel compelled to write my own experience.

Flask is a micro-framework, but it's not a toy framework (anymore). I've used it professionally for all web related projects big and small for the last 4 years with great success. I wholeheartedly recommend it. It's not for everybody though, as one can attest by various comments lamenting its minimalist approach. Things that attract someone like me who likes a certain degree of control on how my tools are set up and work, may be the same that repulse someone else more concerned with having everything available in the kitchen sink.

When I moved to Python for web development Django was the most common recommendation. I had toyed with it a bit previously and considered settling for it. Amid the raves though were a few complains that gave me pause, most coming from experienced Python programmers. A common remark was that as time went and as they evolved with the framework, it wasn't uncommon to swap parts out of it for external libraries. SQLAlchemy, WTForms, Jinja2. In some case basically ending with only the routing module and the admin. Which raised the question of the relevance of using a full-stack framework not necessarily designed with interchangeability in mind, if you end up just using it like a glue mini-framework. Having worked with full-stack frameworks before I identified with the highlighted pain points and Flask became very attractive. I picked it up for a first project and never looked back. It's been over 4 years now. It's entirely possible that I'm missing out by not working with something more like Django, although I doubt it very much.

Flask itself is small, made of bits of the Werkzeug WSGI toolkit and the Jinja2 template engine. It's simple in concept, simple to set up, and simple to use, but anyone who's been developing with it for anything more than basic projects (static sites, microblogs, etc) knows that to do more complicated stuff than displaying template pages you will need to add some dependencies (as it should be). You can do it the old-fashion Python way, by simply importing modules and working with them, or you can install an extension. There's currently a great variety of extensions, the official list is here http://flask.pocoo.org/extensions/, with lots more available from Github and PyPI. Furthermore it's dead simple to make your own if you're not satisfied with the offering. All of this is probably the reason why 5+ years after its creation you see a good number of guidelines on how to work with it for ambitious web projects.

Re: Discover Flask

#63

Post by mekoka »

After reading some comments pinning Flask and Django for "big" projects, I feel compelled to write my own experience.

Flask is a micro-framework, but it's not a toy framework (anymore). I've used it professionally for all web related projects big and small for the last 4 years with great success. I wholeheartedly recommend it. It's not for everybody though, as one can attest by various comments lamenting its minimalist approach. Things that attract someone like me who likes a certain degree of control on how my tools are set up and work, may be the same that repulse someone else more concerned with having everything available in the kitchen sink.

When I moved to Python for web development Django was the most common recommendation. I had toyed with it a bit previously and considered settling for it. Amid the raves though were a few complains that gave me pause, most coming from experienced Python programmers. A common remark was that as time went and as they evolved with the framework, it wasn't uncommon to swap parts out of it for external libraries. SQLAlchemy, WTForms, Jinja2. In some case basically ending with only the routing module and the admin. Which raised the question of the relevance of using a full-stack framework not necessarily designed with interchangeability in mind, if you end up just using it like a glue mini-framework. Having worked with full-stack frameworks before I identified with the highlighted pain points and Flask became very attractive. I picked it up for a first project and never looked back. It's been over 4 years now. It's entirely possible that I'm missing out by not working with something more like Django, although I doubt it very much.

Flask itself is small, made of bits of the Werkzeug WSGI toolkit and the Jinja2 template engine. It's simple in concept, simple to set up, and simple to use, but anyone who's been developing with it for anything more than basic projects (static sites, microblogs, etc) knows that to do more complicated stuff than displaying template pages you will need to add some dependencies (as it should be). You can do it the old-fashion Python way, by simply importing modules and working with them, or you can install an extension. There's currently a great variety of extensions, the official list is here http://flask.pocoo.org/extensions/, with lots more available from Github and PyPI. Furthermore it's dead simple to make your own if you're not satisfied with the offering. All of this is probably the reason why 5+ years after its creation you see a good number of guidelines on how to work with it for ambitious web projects.

Re: Discover Flask

#64

Post by jkarneges »

siddhant wrote: post #41
ryannevius wrote: post #22

It's interesting (exciting) to see all of the excitement about Python frameworks on HN lately. I've used both Flask and Django extensively, and highly recommend them. I used to be on the Flask "micro-framework" bandwagon...until I realized that almost everything I was integrating into Flask was already included in Django (e.g. a test suite, an ORM, database migrations, authentication, an admin interface, etc.). Don't…

Django is cool, and has been my choice for a fair number of projects. Although recently I had an interesting experience with it when I wanted to use websockets (yes, I know it's not written for that use case). It was stunning that most of the solutions out there rely on some sort of a hack to get it working. I ended up porting over my project to Tornado, because I need websockets for a lot of the features I'm working…

I prefer to split a server app into a connection management layer and a backend logic layer. This way the backend can remain stateless which makes for easier maintenance. I use Django as the backend piece in most of my realtime apps (for example WebhookInbox) and it works great.

Of course, native support for long-lived connections in Django would be cool, if only because it would mean the connection management layer could be built with Django too.

Re: Discover Flask

#65

Post by lucian1900 »

ivoras wrote: post #56
lucian1900 wrote: post #44

Earlier quoted context omitted.

If Django replaced their very limited ORM for SQLAlchemy, I'd agree. There are just so many apps that end up requiring queries complex enough that with the Django ORM you have to resort to raw SQL. With SQLAlchemy, you can express any SQL you want without giving up composition.

Can you give an example for a thing where with the Django ORM you have to resort to raw SQL?

Arbitrary explicit joins make a lot of data reporting much easier.

Re: Discover Flask

#66

Post by mixmastamyk »

nawitus wrote: post #60
ianamartin wrote: post #53

Earlier quoted context omitted.

So, write data-backed applications without calling a database? Not sure what you are getting at here. If you are talking about the raw scalability of your database, yes, you are correct. The speed with which you are able to get info from your DB will be a limiting factor. But that's a totally different point than the one I was making, which was about how to scale Python , not your database. If I understand you correc…

Node.js can asynchronously make multiple (i.e. hundreds) database requests without locking the instance.

Why do you believe four requests from python would lock a database but hundreds from js wouldn't?

Re: Discover Flask

#67

Post by dorfsmay »

drdaeman wrote: post #51
dorfsmay wrote: post #37

Earlier quoted context omitted.

Because of legacy, but these days there is no reason not to use python 3 on new projects. Note that Python 2.x will no longer be supported in 2020.

New projects depends on that legacy - in form of existing libraries. So, one may find themselves writing somewhat more code than they had expected, either as a new libraries or patching the existing ones to work with Python 3. Well, not that doing so is a bad thing - it's the contrary, esp. if the patch goes to the upstream - but still this may be frustrating to some. (Most common libraries are actually work pretty w…

This used to be an issue, but, in the past 2 years pretty much all the most used libraries have added a python 3 version.

Re: Discover Flask

#68

Post by dorfsmay »

nawitus wrote: post #48
dorfsmay wrote: post #36

Earlier quoted context omitted.

Wait, in PROD, you don't use Python as the server, you stick uWSGI in front of python/flask, that will deal with the network I/O limitation.

How does uWSGI help here? The OP recommended running 4 instances of Flask/Python, and with uWSGI you still have 4 instances. It doesn't help with I/O.

Because with uWSGI you can mix a number of threads and processes (recommended because more processes than cores wastes time with context switches, and a low number of threads per process is a waste of cycle. uWSGi is an event loop (not unlike node) which makes dispatching requests to threads and processes very easy.

Re: Discover Flask

#69

Post by devishard »

auvrw wrote: post #23
devishard wrote: post #12

Earlier quoted context omitted.

I would choose Flask over Meteor any day. JavaScript is the unholy union of various browsers introducing hacks which are then standardized by committee. Considering that's the design process, it actually is pretty well done. But there's no reason to inflict JavaScript on yourself when you can use a language with a coherent design. I haven't used meteor, but I have used a few other JS frameworks and libraries on the b…

reframing the question to "python vs. node" on the server-side, the answer seems very dependent on the use-case. there's not (to my knowledge?) much agreement in the python community about how to compile to javascript, much less regarding an ecosystem of client-side libraries. if a rich client-side that shares logic with the server-side is part of the story, i don't think python is a good choice. i wonder if the Djan…

I don't think many python devs are espousing Python for the client side. I use react/underscore/Jasmine/sinon with ES6 run through Babelify for the client side.

Sharing logic between client and server side means that your client and server side don't have clearly-defined responsibilities. The one exception to this might be input syntax validation, but generally that's a place where you don't want to roll your own anyway.

Re: Discover Flask

#70

Post by devishard »

nawitus wrote: post #49
devishard wrote: post #43

Earlier quoted context omitted.

It has not been my experience that web applications are I/O bound using typical architectures in Python. I think you would have a very hard time arguing that Node.JS is more performance than nginx.

"It has not been my experience that web applications are I/O bound using typical architectures in Python." Okay, my experience differs. Most modern web applications are relatively lightweight, and are mostly "proxies" or thin wrappers between the load balancer and the database.

That's exactly the kind of apps I usually write, and nginx is fast enough that the DB is typically the bottleneck. In rare cases I've run into CPU as the bottleneck for computationally intensive tasks. If I/O is your bottleneck, then that indicates to me that Node.JS is actually performing worse for you on I/O than nginx is for me.
Post reply on HN