Hacker News Reader

Comment by jtchang | Hacker News Reader

One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala.

I love the fact that you get an admin interface out of the box. And tons of documentation. The views/template stuff is a bit dated since everyone started moving to frontend/backend services and SPAs but we still have DRF which is incredible in the amount you get for "free".

I've had the "pleasure" of working with other large projects built on flask and ever time it gets to a certain size I wonder why we didn't just use Django. There is stuff you don't realize you need until some enterprise customer requires it for your product to even be considered. Auditing, session retries/timeouts, etc. With flask you can just add another library but it isn't as connected as Django is. And that matters a lot when you get bigger because it affects discussions about what the right way to do things is. You generally have discussions about what is the right Django way vs what is the right way in general.

View on HN

> I've had the "pleasure" of working with other large projects built on flask and ever time it gets to a certain size I wonder why we didn't just use Django.

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.

Similar experience for me. Django is pretty thick with quite a bit of (confusing, to me) magic. Flask comes without very basic components that are required for pretty much any website (user accounts, db access, etc).

Between Django and Flask, Pyramid is often forgotten. It seems like the only one of the three that has been genuinely designed to be extended (vs. Flask's approach of "here you have a magic-global variable (that's magically working like a stack of dicts), go put some stuff into it"); a good example would be renderers. In Django it's still kinda awkward to use other/multiple templating engines; Flask doesn't really help. Pyramid on the other hand has a simple and extensible interface to support multiple templates and other renderers ( https://docs.pylonsproject.org/projects/pyramid/en/latest/na... ). This is a common theme with Pyramid. Another is avoiding global state; they're quite successful at that (vs. "I declare my entire app/blueprint within a function"-Flask and "I don't know how this works, it's just like magic. I go to my model class and, BAM, suddenly I'm connected to some database"-Django).

(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)

I've been meaning to look into Pyramid, it does sound like it avoids some of the worst of both Flask and Django.

Any areas that Pyramid doesn't do well at?

It has nothing like the django admin and no forms handling is built into it. Creating a project from scratch is a bit cumbersome (like flask), but good cookiecutters exist (e.g. the pyramid-sqlalchemy one).

Wow, Pyramid even seems to pitch itself as the "Goldilocks Solution"! OK, will give it a try.

Maybe it's because I'm used to Rails, but there is really little magic in Django. One is even free to structure the code as one likes. Almost no mandatory directory structure. It's a beefier Flask but still straightforward. If I may come up with a criticism, there are too many complications that slow down development compared to Rails.

Agreed. Also, unless django has changed peaking under the hood is a nightmare. Forms and the ORM (and really the whole framework) is giant ball of mud.

It's not changed much. Some things are a bit better (model's Meta is now documented and not considered "private") but largely I have grown to enjoy the benefits of picking the right tools (SQLAlchemy, Jinja2) and luckily Django is doing a lot better at making things pluggable and you can use Jinja2 as a first class citizen now.

Forms are a nightmare to work with. It's a component in Django I systematically avoid, even when using actual forms.

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.

Agreed. Django Forms' hay-day was back in the Request/Response rendering of page state era of the web. They introduced the ability to bind data for validation, rendering in the Template, programmatic generation based on Model and sanitization of form input data. They still can be utilized loosey-goosey on the backend in the world of APIs. Why bother when better tooling now exists? The use-case of Forms now is the Admin side of the house where they can facilitate the CRUD of the Models.

Just wondering, what do you use instead of Forms for non-Javascript websites?

For what it's worth you can still use DRF serializers instead of forms on non-JS sites. DRF can take multipart/form-data

Personally I find Django's forms easier to work with, but maybe that's because i have spent more time with them.

Yep, forms smell of Java Struts. I was so happy to say goodbye to them when I started using Rails in 2006. Another Javism, templatetags, because they don't want we write Python in the templates. So every small customization takes x100 the time in the best tradition of early 2000 Java frameworks.

For what it’s worth, on a Django codebase of 180k lines, 100k lines of templates, 1000 URLs, 380 “apps”, 350 models, we have a nice coherent structure across the whole codebase that makes us really productive.

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.

What does that Django project do?

https://www.thread.com/

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

Do you mind explaining what that structure is? I always find the standard Django structure of everything is an "app" difficult to navigate once the codebase gets larger.

As much as I'd rather not plug my own talk, it's probably going to give you more information than I could ever get in a reply here.

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

> 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.

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.

> everyone started moving to frontend/backend services and SPAs

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.

This is exactly my view as well. Every time I've used Flask, I ended up regretting it, because I've invariably needed to fit something to it that would have worked out of the box with Django (or at least integrated much more easily).

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.

And its perfectly possible to write a one file/ten loc Django app. Everything is optional. Its just there by default, because 99% of projects will need it anyway.

> its perfectly possible to write a one file/ten loc Django app

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.

In your last example, "the guy" is one of the people who was on the team that originally created Django, back when it was an internal tool for building a news CMS.

> One of the things that makes me sad is there is no project even remotely close comparable to Django for say Golang or Scala.

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).

Personally, as a customer, the "new" way of doing it is irritating, usually somewhat broken, slow and usually unreliable.

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 depends on use case, of course. Gmail, Google Slides, or Figma would be poor MPAs I’d say.

Good SPAs are fantastic. It's just a lot of people suck when implementing them.

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

Really? Randomly clicking e.g. Providers > Azure, I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time. (Compare e.g. https://docs.python.org/3/library/weakref.html.)

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

On my awful connection, serverless is as fast as HN on new pageloads, and faster than HN when navigating to cached pages.

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

HN is typically how I determine no connection vs. crap connection.

HN is typically how I determine no connection vs. crap connection. I could `ping` I suppose, but in these circumstances I'm in the browser having just signed in to the crap/not connecting AP.

> "I see a significant loading animation (the grey lines) - likely slower than just loading a simple new page each time."

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

It takes ~2.5 seconds to load and the first ~1.5 of that won't display anything because it has to process ~600KB of JavaScript and CSS before it can render a few hundred words of text:

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.

Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference). You're optimizing against browsing the site.

Have you tried browsing the site...?

> Testing an SPA against a single pageload is absurd. You're not optimizing for a single page load (and if you are, a couple hundred milliseconds makes zero difference).

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...

I'm on a terrible high latency connection in Athens, Greece. The serverless SPA is one of the fastest sites I've ever visited. It's a ton faster than HN for me.

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.

When I look for an information I usually google it, then click on the first link, get what I need, and close the site.

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.

YMMV, but when I've dabbled with what I believe are good SPAs, I've noticed what I was essentially was essentially implementing a crude primitive web-browser inside my React app. I mean, I was neck-deep trying to code page transitions, load progress indicators, history states, all this sort of stuff.

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.

All a symptom of the browser being a document-first platform that's been reused to be app-centric. I agree with you it's a bummer that these things are getting reimplemented on top of a platform that already offers them, but the way the platform offers them hasn't changed much since the 90s and hasn't kept up with what apps need.

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.

Just tested it on an edge connection in the German country side:

Hacker news:

- first load: 6 seconds

- next loads: 3.5 seconds

Serverless:

- first load: 26 seconds

- next loads: 7.5 seconds

I think with server side pages, you’re limited in how much you can mess it up, but very limited in how far you can take the experience.

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.

Name me a single thing you can't do in a SPA that you can't do in a MPA with a bit of Ajax?

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

As a programmer, I absolutely hate SPA's. I've never used a good SPA, they're always slow, and behave strangely. I much prefer the traditional way. It's the same with Electron apps.

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

Agreed, logic usually ends up scattered between the front end and the back end. You need to start using JavaScript (I much prefer Python). The Angular app I ma maintaining just now would be so much simpler if it was server side rendered, instead we have an ajax call to load contents of every dropdown....

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

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

Indeed we are also looking for a framework to change our Django/python. We were looking at golang as half of our backend is in go but the lack of ORM make the choice impossibile. Gorm, xorm.. are not supporting Foreign Key...

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.

What’s the motivation for moving away from python?

We are in python 2.7 and we need to migrate the application to python 3.0 For me it's another language to learn if we want to make good python 3 code. Python/Django/DRF is a stack with very poor performance if you are dealing a lot with JSON. We already have API points in golang with very good performance. No need to deal with nginx/CGI etc. nightmare. Conclusion was that our code in golang has a lower downtime. (Typed etc.)

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

The changes from Python 2.7 to 3.x are hardly so dramatic that it's like learning a new language. I'm pretty sure your performance issues can largely be addressed after proper investigation where the bottlenecks are. I do understand how nice it is to have a simpler architecture, but make sure it's worth all the work.

Well we can migrate to python 3 but this will be more investment in a stack that is more and more obsolete (Django) for SPA. Developers need also to learn the new best practices for python 3. At the end this will result in short term with python 3 code base written in python 2 style without the benefits of typing etc. Investment without benefits except keep our stack up-to-date.

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

It's quite huge to manage.

Django obselete?

Sure....

For our usage that's my point of view. When you need to manage ws & asynchronous task, you are just ending stacking technologies to make Django enter in 2018 (remember tornado?). I would say that the framework didn't followed technology evolution and so our new requirements

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

You might want to try using Pypy as your interpreter as a potential drop-in fix.

Python 2.7 and 3 are hardly as different as you think. Migrating is a total breeze

Dude moving to Python3 is easy. It is an order of magnitude easier than moving over to a new language.

No new stuff on your resume though....

I'm surprised you are worried about JSON performance and not ORM performance. It seems like if you really needed better serialization/deserialization you could just call a c module from python.

Good point. Lost of performance in the query is acceptable a as we gain support of MySQL & Postgresql. Lost of performance in JSON serialisation is more difficult to accept.

Normally people use something like uWSGI to host python apps behind Nginx - in any case, it’s something you figure out once and pretty much never deal with again. So it shouldn’t be an ongoing nightmare.

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?

Well I don't blame python. It's just that the stack python/Django/DRF is not more efficient for us now as our requirements changed spa/ws/asynchronous tasks. Investing in this stack is more and more difficult as our requirements don't fit. But yes we can also check flask/sqlalchemy . I'm just afraid of the stuff needed for ws/asynchronous task. This will not simplify our architecture.

I love Elixir (more so than golang), so I would sincerely recommend using it. Erlang concurrency story is lightyears ahead of Python3 asyncio (despite being older by maybe 20 years). And OTP has no equivalent anywhere.

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...

The goal will be to take benefits of the elixir/OTP platform and the concurrency assets. Today we have a lot of asynchronous/background task distributed with rabbitMQ. If our investment provide better stack and simplify the architecture , this could be a better ROI than keep the current stack up-to-date.

Why wouldn't you be able to support both MySQL and PostgreSQL without an ORM?

This implies to create 2 queries each time you want to hit the database. One query for PostgreSQL and one query for MySQL. This is something we can't afford. Do you have some good tips to manage this ? To be honest the ORM is required only to support multiple database.

Scala / Play Framework does in fact have an out of the box solution for this: https://www.playframework.com/documentation/1.2.2/crud

Edit: This was removed in Play Framework 2

They dropped that in Play 2.x, as far as I can tell.

Looks like you're right. Comment withdrawn.

Yep. I just joined a company and what I could do in two months blew their minds. A lot of which was thanks to all the freebies by Django.

> no project even remotely close comparable to Django for say Golang

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.

what made me sad when trying Django was that it felt not remotely close to RubyOnRails. Did I miss some ORM magic, scaffolds, generators, migrations? Did they add those in the meantime?

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

What was the last version of Django that you used? There's build-in schema migrations since 1.7 version. Not sure what you mean by ORM magic.

I've used neither, but Qor looks like it's of the same family: https://github.com/qor/qor

Play! framework for Scala was pretty close to Django back in 2012, has something changed? Did they stop developing Play! ?

Reply on news.ycombinator.com