

Flask is awesome - bluemoon
http://poincare101.blogspot.com/2011/08/flask.html

======
phamilton
Whenever I see Flask code, it just reminds me how unbelievably succinct
Sinatra is.

I imagine it's a limitation of Ruby vs Python for creating DSLs, but a basic
Flask app just seems so verbose. It's like seeing "Hello World" in Java vs
"Hello World" in a dynamic language like python or ruby.

~~~
psyklic
_Flask:_

    
    
      from flask import Flask
      app = Flask(__name__)
      
      @app.route("/")
      def hello():
          return "Hello World!"
    
      if __name__ == "__main__":
          app.run()
    
    

_Sinatra:_

    
    
      require 'sinatra'
    
      get '/hi' do
        "Hello World!"
      end

~~~
masklinn
Note that there is no need for the conditional if you just want to serve this
route (and there is no need for the conditional block at all if you're just
defining view functions), and that this whole block exists once _per project_.

And that a Flask app is a proper WSGI application (as opposed to a self-
running Sinatra handler which has to be quite significantly modified to be
Rack-compatible)

As a result, the _actual_ verbosity difference comes down to:

    
    
        @app.route("/")
        def hello():
            return "Hello World!"
    

versus

    
    
        get '/hi' do
            "Hello World!"
        end
    

So, as usual, Python not having multiline anonymous functions: for this very
case you could write

    
    
        app.route('/')(
            lambda: "Hello World!")
    

but that kind-of looks like shit and you're hosed if you want to add more
stuff.

(one could argue that the Flask version lets you formally write docstrings
which standard Python doc tools will understand)

(and if you're wondering, yes Flask could provide support for not needing to
define an app or run it for this trivial example, leaving named functions as
the only actual overhead over Sinatra. I don't think there's much value in it,
but it wouldn't be very hard)

~~~
mattyb
_as opposed to a self-running Sinatra handler which has to be quite
significantly modified to be Rack-compatible_

Huh? Here's the `config.ru` that you need:

    
    
      $: << File.dirname(__FILE__)
    
      require 'app' #assuming app.rb
      run Sinatra::Application
    

Note that I have no stake in the verbosity claims, as it's not something I
particularly care about. But I wouldn't consider this a significant
modification.

~~~
masklinn
> Huh? Here's the `config.ru` that you need:

Really? I remember it being significantly more work in the past, like having
to change the `require` and create a class around all the routing methods

If that's all which is required to make a Sinatra app into a good Rack
citizen, then consider my previous assertion wrong and rescinded.

------
heretohelp
Rather than quibbling over syntax, I'd like to comment on a real concern I
have about blogs, particularly ones that engage in hagiographies on things
they don't appear to rightly understand.

Nota bene: I am a user of Flask and have been one for quite some time. I am
incredibly fond of it and it has replaced Django for most things I do in web
dev. I am very familiar with it and its limitations/ugly corners. Familiarity
breeding contempt and all that. That said, little contempt has arisen from my
familiarity with Flask. It's that good.

Do we upvote these blog posts because we think they're constructive? This is
somewhere on the order of a press release in depth. The farthest this post
gets is in describing an app that uses hard-coded credentials to log an
administrator in.

This doesn't demonstrate the strengths of Flask, nor the weaknesses, nor why
it's necessarily better than Sinatra, Bottle, or any other micro web-
framework.

Since this post has failed to do so, I'll fill in that gap as quickly as I
can.

Flask is great because it _scales_ to your needs. It starts as painlessly as
any other micro web-framework, but what makes it nice is that it's so _easy_
and _clean_ to graft disparate ways of doing a web-app.

In my particular case, I'm in the process of building a service on Flask and
MongoDB. I'm in the process of making Flask, WTForms, and MongoEngine all play
nice together and Flask has done a wonderful job of making this painless
because it doesn't make any bizarre assumptions and it doesn't force any
strange contortions in my code like Sinatra or raw Rack apps do.

Having hacked on some Rack and Sinatra code, I can tell you right now that the
moment you want to make a "real" app with the typical complexity of a mature
service, even the bare basics get _painful_ really fast.

Flask hasn't done this to me yet, it's already breezed well past where I've
taken raw Rack and Sinatra+Rack apps before.

This blog post, however, does not come from experience. It does not attempt to
explain why Flask is better than the alternatives, it doesn't even demonstrate
any interesting aspects of Flask.

This is blogspam.

Please reconsider your upvotes, please reconsider promoting content like this
again.

Popularity for popularity's sake in the absence of knowledge, experience, and
data is simply "pop culture". (cf. Node.js)

Edit: Worse, the author even explicitly appeals to the quality of Flask on the
basis of "branding".

Engineering decisions shouldn't be made on the basis of pop culture.

Choose Flask because you know it suits the problem you're solving well, or
because you know it suits your style of programming.

Don't choose it because somebody showed you a "hello, world!" example.

~~~
Lazare
I think this is a very valid point, and it comes up quite frequently in
comparison of frameworks and libraries.

One example that was annoying me recently was in trying to select a Javascript
client-side MVC (MVVM, etc.) framework for a single-page application.

The internet is _full_ of people busily comparing, contrasting, arguing about,
and recommending JS frameworks. Problem: 95% of them are doing so based on a <
100 line demo app, usually implementing a todo list, often which makes
implausible simplifying assumptions. "Hm, that's nice, but check out the demo
todo list app for MagicJS! It's 57 characters shorter, and the code forms the
shape of a flower, and it would be quite easy to extend it to let you create
new items!""

No real world app is going to be solved in < 100 lines[1], and while it's
awesome to know that you've chosen a framework which can be used to create
incredibly elegant < 100 line demo apps, what I really care about is how the
framework works for large apps. Scale (in the sense of scaling up from the
example code on the frameworks homepage to a real app that actually handles
all the corner cases) matters _HUGELY_. And I don't think that gets nearly
enough recognition.

(In fact, on this very thread, I see someone comparing a "hello world" app in
Flask and Sinatra, and complaining about Flask's relative "verbosity". This is
utter nonsense of the precise kind you've identified. Implement a calendar app
in both that syncs with Google Calendar, and THEN compare line counts, and NOW
you have a some feel for verbosity. Sinatra might win handily, but you can't
tell that from a hello world app. Then again, off the top of my head, I can't
think of one actually useful thing a hello world app can tell you about a
framework.)

[1]: I'm speaking figuratively, obviously. Some of my proudest moments as a
programmer have involved solving problems in just a couple. Sadly, this does
not happen often. :)

~~~
heretohelp
You'd hit what I was talking about precisely on the head.

I feel your pain on figuring out which JavaScript SPA framework to use. I
don't think I've seen any particularly compelling examples in public of even
Backbone.js, which is currently the most popular one to use. The templating
and sync semantics aren't appealing.

And yes, some of my proudest moments, too, have been making a <100 line
solution to a problem. That having been said those are never the truly hairy
problems.

The hairy problems are when the rubber meets the road and whether or not the
solution I've built on is going to be appropriate or not. Those are going to
be >100 line of code problems.

I have to be able to build things of at least moderate complexity with a
framework without blood gushing my eyes and ears.

<100 line examples don't tell me if that's going to be the case or not.

The superficiality of this non-content makes my spleen rupture.

