Actually, I've had the exact opposite experience. I like using Django for small and mid-sized projects, because with Flask I have to spend time adding all these extra libraries for universally required functionality on a quick app whereas, with Django it's plug and go.

However, the larger the project gets, the more I like Flask since I have near total control and understanding of the app. There's no digging into Django internals to make some obscure customization.

Then again, it's been several years since I last used Django, so it may have changed for the better here.

I haven’t seen a Flask code bass do this anywhere near as well. They all seem to end up becoming very different and tricky to onboard new devs onto because they are so custom.

Django hides some complexity, but we haven’t found many pets we can’t effectively customise, and the architecture at scale is great, something I haven’t seen in many other places.

While some Flask web applications may use different file organization schemes, any large app will use blueprints. Blueprints are fairly standardized and easy to understand. I personally find Flask blueprints easier to follow than Django apps, but they're pretty similar.

https://thread.engineering/scaling-django-codebases-pycon-uk...

Curated ecommerce, a CRM like system for stylist, order management, fulfilment and distribution.

(Other examples where the other two's solution feel rather lackluster to me include middleware vs. view derivers, view predicates, the routing system and the security area)

Any areas that Pyramid doesn't do well at?

Nowadays I use DRF for everything though. Serializers > Forms. And React > Templates.

As for the ORM, I long for a world where the ORM is replaceable by SQLAlchemy. Django's ORM is nice and simple, but as soon as you want typed complex queries, SQLAlchemy is really good.

Yes, there are valid reasons for SPAs, but many web applications and most classic web sites are still better served with plain old server-generated HTML, IMO.

First, because replicating even basic functionality in JavaScript comes at a cost, namely in bytes sent, bytes to be parsed, bugs introduced, etc. Second, because most projects don’t have unlimited development resources, so developers might just slap a few libraries together without necessary optimization, customization, or testing.

Third, because the well-known experience of browsing static web pages is already pretty darn good, and what developers will find exciting, users might just find irritating. Needlessly breaking conventions is simply bad UX.

Contrary to that, I keep reading that SPAs are the “new way”, as if classic server-rendered HTML enriched with some Ajax suddenly became a deprecated, inferior technology. It really isn’t. Unless you know what you’re doing, and why you need to, the classic way is still a sane default. If in doubt, I would always prefer a solid Django site over a half-baked SPA.

I haven't found any reason to use Flask in a project, except maybe for small, ad-hoc scripts that you want to run in a single file.

Examples: http://olifante.blogs.com/covil/2010/04/minimal-django.html https://stackoverflow.com/questions/1297873/how-do-i-write-a..., and also this interesting one: https://github.com/simonw/djng where the guy builds a microframework which uses Django.

Could not agree more. This is my number one reason for not moving away from Python for web stuff.

> The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs

This is certainly true for customer facing products, but for internal tools I've yet to see anything that beats the speed of development for server-side rendered basic HTML pages. 80% of the pages we have in our Django application are internal facing (we don't use the admin due to it being a poor fit for particular reasons).

I wouldn't be surprised if non-techies couldn't give a toss if you're using a traditional MPA with a sprinkling of ajax for the bits that really need to be responsive or a total SPA.

I'm beginning to suspect the only people who want a SPA are the programmers. Has anyone even got any proof that a SPA is better than a MPA in terms of customer satisfaction? It seems to have all originated from a technical need rather than a customer need. I still prefer doing most thing server-side and then sending snippets of html to update the bits on the page that need updating, occasionally using client-side view templates/JSON, depending on the case.

I think it's just web developers who like SPA's

With single page apps you have to do a lot more to get back to what server side pages give you, basic browser functionality, and as a result you can end up with worse experiences. However if you’ve got the development resources it can be a far better experience and enable applications that just wouldn’t be usable or even possible on server side rendered pages.

The only thing I can conceivably think of is an offline app, but they're so rediculously niche.

The Serverless documentation, an SPA, blew my mind in terms of how fast and clean it is: https://serverless.com/framework/docs/

(Single Page Applications arguably have their place. I'm just really confused why you think this is a particularly good example.)

HN is my baseline for how fast a site should be.

You can test the difference yourself by toggling JavaScript in your browser.

http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f...

The only reason that's faster as an SPA than static HTML is because they've disabled caching for static resources:

http://www.webpagetest.org/result/180628_AQ_c87264f303f9e72f...

If the site was optimized it'd perform very similarly either way since there's none of the complex logic or interactions where an SPA really starts to shine and the content is very cache-friendly.

Have you tried browsing the site...?

As a user I don't care about the developer's aesthetic preferences for tooling, only how long it takes to see the information I need. This feeds back to the question of why an SPA matters: for a rich application, there's more benefit to cancel out the runtime overhead.

For static docs, your timing is off by at least one order of magnitude: I have to wait a second or more — a LOT more on a high-latency connection where that initial page load is 15+ seconds worse[1] – and there doesn't seem to be much benefit to compensate for that. I mean, the animation is cool the first time I see it but I see it a lot because there's less information on each page so the novelty wears off pretty quickly.

Again, please note the last part of my comment: there is a place for SPAs but I'm not sure why a site this simple needs 500KB of JavaScript to deliver static documentation slower than Apache did two decades ago. I was expecting to see a selling point such as loading the content so that it was usable offline and search results were instantaneous but e.g. that nice search box (which is the one thing you couldn't have done in 1994) still takes 3+ seconds to load and render the new page on a well-peered gigabit connection.

1. http://www.webpagetest.org/result/180628_CF_db268e65de67002e...

Yes the initial pageload takes time. But afterwards I can click around the site and get immediate feedback. Immediate as in native app speeds. Images and such obviously still take time to load and render but they do not block loading. There's no whitescreen while I wait for new pages to load.

So as someone with shitty internet who often browses documentation, give me hundreds of sites like this. This is significantly faster to browse around than, say, the Python or Django documentation, both of which make very little use of Javascript. I'm sorry you're not getting the same experience, I can't speak to that.

To reiterate: An SPA will bloody obviously not faster on the first pageload. The whole idea behind it is that you load more machinery upfront but you don't load it again afterwards. Depending on how good the app is, you make up for it very, very quickly. And if you have any significant JS usage on your site at all, you make up for that too.

My point, which everyone seems to have completely missed, is that well-built SPAs do exist. They don't have to feel slower to use than other apps.

It's especially true for a documentation website.

Even if I browse a little, it will be swift clicks on 3 to 4 pages to get to what I'm looking for. The enormous initial loading time is far from amortized.

Bottom line, if your site is just displaying text like a doc, a wiki, etc., making it an SPA is ridiculous.

Just use old school techs, and offer a zip for download.

Thankfully, I'm not a frontend developer. Was just toying around here and there. Maybe it was just that I sucked at simple things.

Still, for now I believe many (not all, of course) fancy SPAs are a probably a waste of otherwise productive time. There is already a browser, and it does things well. Having something that would allow for smaller documents is a good idea, of course, and some eye candy for transitions between different documents would be neat to have, but every site doing this for themselves feels just plain wrong to me.

Exceptions - e.g. for heavily API-centered systems - apply, of course. If a webpage is one of half a dozen client applications that consume the same API, then SPA could be a sane way to do it.

The core issue being that you have no way of statefully going from one page to the next. State only exists within the page you're on. Hence the rise of SPAs.

Hacker news:

- first load: 6 seconds

- next loads: 3.5 seconds

Serverless:

- first load: 26 seconds

- next loads: 7.5 seconds

Why would you want to move away from something that works?

Yes you can write your raw SQL query but that means that your backend can't support MySQL and Postgresql (one of our prerequisites for on-premise deployment).

So we are ending with phoenix. Very sad that golang doesn't provide a very good ORM.

The issue is on the ability to provide code compatible with MySQL and Postgresql. Without ORM you have to duplicate your queries.

So looking at a framework with ORM we are doing a benchmark of Elixir/Phoenix/Ecto. This solution could simplify our architecture a lot: websocket with room shared between server etc.

Bad point is the lack of documentation on Phoenix 1.4

Each solution for Python/Django add complexity: - async -> celery/rabbitmq - websocket -> Channels, Daphne, asgiref, channels_redis, redid.

It's quite huge to manage.

Sure....

For old good stuff is still a good framework. It really depends on your usage.

But if you are migrating just to avoid spending a couple of days learning and migrating to Python 3 based on reading too much FUD I'm very saddened. Migrating from Python 2 to Python 3 is not much harder to handle than a Django migration. Though of course it depends on your codebase, but compared to moving to Elixir/Phoenix/Ecto it's a peace of cake.

Move to Elixir/Phoenix/Ecto because it fits your needs better than Python, be proud of it even. But please, learning Python 3 to write good Python 3 code coming from Python 2.7 is very easy, nothing like switching to a completely different paradigm...

While I didn’t downvote you, I suspect the people that did have done so because it sounds like you’re making quite a naive mistake in blaming the tool for your issues. Changing language is almost certainly the wrong thing to do, period. You should profile your existing code and figure out where the real issues are. If you don’t know how to do that effectively, no amount of rewriting from scratch in a new language will save you.

Sounds like you really care about the ORM (though if you’re using the Django one, it’s pretty basic). Python has hands down the best ORM (SQLAchemy), so if that’s such a priority, then why not start there?

Edit: This was removed in Play Framework 2

I've used Django, flask and Golang quite a bit. One thing the Golang community seems to do a good job with is building things around the http.HandlerFunc interface which in turn leads to many of the subcomponents from other OS projects fit well together through chaining handlers. For example check out the Gorilla toolkit.

Django hides much of it away from you and the magic can be annoying at times. Flask seems to have failed on being both modular and nice to use for bigger projects (this is likely because WSGI isn't conducive to that sort of chaining).

Basically, with go I feel like I get Flask level lightness and visibility with actual modularity -- "easy to add batteries" if you will.

But I generally agree, Django is awesome. And the Django Admin is a whole beast of its own that is very unique and has been very useful for small staff alliances and management operations.

Love the admin interface and logic though, and python>ruby IMHO