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

Flask 1.0 Released

palletsprojects.com

Post reply on HN
Print view View original

161–170 of 184 posts

Re: Flask 1.0 Released

#161

Post by mixmastamyk »

creeble wrote: post #153
mixmastamyk wrote: post #30

Love Flask in theory. My biggest complaint was trying to do user management with it. Flask-Security was good, but the developer skipped town a few years ago. Did they come back? :D Basically you are left to your own devices, which sounds great, but user+auth is pretty fundamental to be left to a random absentee third-party in my opinion.

Check out Flask-User. It's a lot like the user auth in Django. Developer still around.

Believe it is a part. I mentioned user+auth, but there is commonly a lot more around that for a typical sass app. Registration, password-reset, just to name two.

Re: Flask 1.0 Released

#162

Post by rrcaptain »

mundanevoice wrote: post #115
yen223 wrote: post #48

Earlier quoted context omitted.

In my experience, Django is less suitable for large projects than Flask. The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer. This is manageable in the small, but when you hit scale, this tight coupling adds a whole bunch of unnecessary complexity to…

This is a false statement that Django is unsuitable for large projects. I have been working on a fairly large Django Project for 5 years now and it has been a pleasure using Django to build good and stable features that actually scale. > The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations,…

Some frameworks however are much better at forcing you to make good design decisions.

PHP is absolute garbage at that for example.

Re: Flask 1.0 Released

#163

Post by ekovarski »

stuaxo wrote: post #70
ageofwant wrote: post #39

Earlier quoted context omitted.

I have worked on several Python code bases exceeding 500k lines. Not sure why you think that's uncommon.

There are a lot of different types of software being made in python. I've managed to do python for 10 years only working on one codebase that size, and I'm not sure it counts - it was made by low skilled devs (we were encouraged not to do anything "clever", like use the language features) mostly cutting and pasting existing code.

You've got to love companies that have the don't be "clever" attitude... Whats the point of hiring skilled workers to just dumb them down. I've stopped counting the companies that openly stated, "we don't pay you to think," only to see them stuck in an endless loop of mediocrity.

Re: Flask 1.0 Released

#164

Post by rrcaptain »

no_wizard wrote: post #97
yen223 wrote: post #48

Earlier quoted context omitted.

In my experience, Django is less suitable for large projects than Flask. The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations, business logic and the interface layer. This is manageable in the small, but when you hit scale, this tight coupling adds a whole bunch of unnecessary complexity to…

Might want to tell instagram https://m.youtube.com/watch?v=lx5WQjXLlq8

I mean Facebook uses PHP and that doesn't mean it's any more scalable.

I suppose they call it hack now though.

Re: Flask 1.0 Released

#165

Post by hultner »

ekovarski wrote: post #163
stuaxo wrote: post #70

Earlier quoted context omitted.

There are a lot of different types of software being made in python. I've managed to do python for 10 years only working on one codebase that size, and I'm not sure it counts - it was made by low skilled devs (we were encouraged not to do anything "clever", like use the language features) mostly cutting and pasting existing code.

You've got to love companies that have the don't be "clever" attitude... Whats the point of hiring skilled workers to just dumb them down. I've stopped counting the companies that openly stated, "we don't pay you to think," only to see them stuck in an endless loop of mediocrity.

A company that doesn't pay it's engineers to think is surely doomed from achieving any significant innovation.

Doesn't seem like viable strategy at all, I'd run the other way if I were approach by such a company.

Re: Flask 1.0 Released

#166

Post by kstrauser »

JoshMnem wrote: post #156
kstrauser wrote: post #53

Earlier quoted context omitted.

Django is great for building Django apps. That is, if you're starting a greenfield project and don't have to integration with an existing database schema, and you like the Django ORM, and you like Django templates, and your data model maps cleanly onto a relational DB, and you can use the admin site more or less as-is without having to customize much, then it's lovely! I'm not being sarcastic: it really is. We've suc…

You don't need Django's ORM, templates, and admin section to build a Django app. Check out this example of a single-file Django project: https://www.safaribooksonline.com/library/view/lightweight-d... It's from a good book called Lightweight Django .

But if you’re not using those things, why Django?

Re: Flask 1.0 Released

#167

Post by weberc2 »

mixmastamyk wrote: post #160
scaryclam wrote: post #123

Earlier quoted context omitted.

They only improve speed from an initial "get it working" point of view. That's part of the reason flask is rarely taken seriously as a production solution. Not having natural separation between views and urls is a real PITA for anyone trying to create a long term solution or larger project. For what it's worth, I also hate the argument that bad design increases Dev speed. That's only true until you need find somethin…

True in a very large project, false on the rest. Congrats on your one-true-way argument. ;)

I'm a professional Python dev, I have no reason to believe that decorators save any time for any size of project. They're harder to reason about for developers of all experience levels and their is no obvious advantage--some argue that the syntax is more pleasant, but I don't perceive an increase in readability; certainly not one that makes up for the increased cognitive burden. The following is super straightforward, testable, and it doesn't depend on globals for shared resources or request state:

    def hello_handler(r: Request) -> Response:
        return Response.ok("Hello!")

    def goodbye_handler(r: Request) -> Response:
        return Response.ok("Goodbye!")

    if __name__ == "__main__":
        router = Router("/")
        router.register_route("/hello/", "GET", hello_handler)
        router.register_route("/goodbye/", "GET", goodbye_handler)

Re: Flask 1.0 Released

#168

Post by donarb »

rrcaptain wrote: post #162
mundanevoice wrote: post #115

Earlier quoted context omitted.

This is a false statement that Django is unsuitable for large projects. I have been working on a fairly large Django Project for 5 years now and it has been a pleasure using Django to build good and stable features that actually scale. > The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations,…

Some frameworks however are much better at forcing you to make good design decisions. PHP is absolute garbage at that for example.

PHP is a language, not a framework.

Re: Flask 1.0 Released

#169

Post by kstrauser »

ekovarski wrote: post #163
stuaxo wrote: post #70

Earlier quoted context omitted.

There are a lot of different types of software being made in python. I've managed to do python for 10 years only working on one codebase that size, and I'm not sure it counts - it was made by low skilled devs (we were encouraged not to do anything "clever", like use the language features) mostly cutting and pasting existing code.

You've got to love companies that have the don't be "clever" attitude... Whats the point of hiring skilled workers to just dumb them down. I've stopped counting the companies that openly stated, "we don't pay you to think," only to see them stuck in an endless loop of mediocrity.

Our policy is to avoid cleverness - think "code golf" - that is going to be opaque and hard to reason about at 2AM when things are on fire. We don't shy away from language features, but if you have a PR with multiply-nested generator expressions, for instance, someone will usually ask you to unroll that into a set of explicit loops.

Re: Flask 1.0 Released

#170

Post by mundanevoice »

rrcaptain wrote: post #162
mundanevoice wrote: post #115

Earlier quoted context omitted.

This is a false statement that Django is unsuitable for large projects. I have been working on a fairly large Django Project for 5 years now and it has been a pleasure using Django to build good and stable features that actually scale. > The nature of Django encourages tight coupling between unrelated parts of the system - Models intertwine database operations and business logic, ModelViews intertwine db operations,…

Some frameworks however are much better at forcing you to make good design decisions. PHP is absolute garbage at that for example.

I agree some frameworks enforce good design decision but none can guarantee it. That's my argument here.

There are good frameworks in PHP too and not all PHP code is garbage.

Post reply on HN