Hacker News Reader

Comment by bliti | Hacker News Reader

This is great news. Django is a great web dev tool and having websockets support is icing on the cake. I guess this adds more weight to the thought I've been having: That Web applications are moving away from MVC and more into messaging layers. Front end JS frameworks have pushed things to be this way. Which brings the Web into a pseudo native environment of sorts. Anyhow, will be happily tinkering with this from today onwards.

View on HN

For building clustered backend services, messaging is great. And Django Channels looks awesome.

However, in the context of the web (the client/server boundary), I think we need to be careful about how messaging is used. The web is made up of resources with URLs. HTTP is typically used for data transfer, and for good reason.

I sometimes see webapps communicating entirely over WebSockets. I don't mean just the realtime push part, I mean everything, request/response traffic and all. I understand that HTTP is suboptimal in certain contexts, but let's not throw the baby out with the bathwater.

Same as with Single Page Apps - websockets have their place but shouldn't be abused.

I can imagine a large Django app that uses mostly plain request/response but needs, say, a small customer service bot or occasional real time notifications. This new feature is perfect for that.

> However, in the context of the web (the client/server boundary), I think we need to be careful about how messaging is used. The web is made up of resources with URLs. HTTP is typically used for data transfer, and for good reason.

"Careful" == do not break urls, use pushState and make sure equivalent document is returned for GET.

Sounds good to me. :)

Could you elaborate on specific issues you see with the use of web sockets over http/s for request response? I see this argument from time to time and I have a hard time with it when you take resource hogging out of the equation, which isn't much of a factor in many situations.

The issues with WebSockets are more political than technical. WebSockets are the superior technical solution with wide availability. However, at present, HTTP has better tooling (e.g. debug tools, devops tools) and developers are more familiar with it. HTTP is the de-facto standard for APIs as well.

If you're the sole developer of a Single Page App with no API, then this difference may not be important. But if you're working with a team, or across teams, then building a WebSocket-only app will bring pain. As another commenter mentioned, as long as equivalent actions are possible via HTTP then some of the issues are alleviated.

upvoted for being a nuanced response, thanks!

yea, of course. It's a new option to build good systems not a tool to build shitty ones

I'm not sure we're moving that far out quite yet. For starters, most of the very big sites that do stuff (PayPal, Ebay, Airbnb, etc) are still mostly request/response, which works pretty well.

And even the newer stuff isn't so much Websockets as it is serving JSON to single-page apps.

I've wanted to like Django (because Python is my preferred language) but it still feels so crufty from its origins as a newspaper server.

> but it still feels so crufty from its origins as a newspaper server.

Care to elaborate?

One small but big example: still, or until recently, it was hard to use email addresses as usernames. Usernames are useful for sites with discussion but none other.

"Django was born in the fall of 2003, when the web programmers at the Lawrence Journal-World newspaper, Adrian Holovaty and Simon Willison, began using Python to build applications. It was released publicly under a BSD license in July 2005. The framework was named after guitarist Django Reinhardt."

Source: https://en.wikipedia.org/wiki/Django_(web_framework)#History

Right, but any examples of it feeling crufty?

Personally I think the templating system is less and less useful because I'm serving single page apps that I don't really benefit from serving from Django any more (or are Angular and the variable syntaxes conflict with each other)

Django has outgrown its humble beginnings. I am building a fairly sophisticated single-page business application using Django along with Django REST Framework, and have yet to run into a situation that made Django feel "crufty."

So as a Scala Play dev... Trying to get the user stuff to work with email as username and still work on the admin page? Super crufty.

Overall very good docs though :)

That's not been an issue for several years (since Django 1.5(?) introduced custom user models). Drop in a custom admin form and you're done.

That is not true with current (1.9).

Drop in a custom user model and

a) Better be a brand new project at all

b) You need to muck with the user manager also

c) How do you fix up the admin module? I have yet to see a fully fixed up admin module for the custom user.

I am not a Django pro so happy to be proved wrong. But take a default app, and record all steps to make the user model work (including password reset, login, logout, admin page). If that doesn't feel crufty to you I am not sure what cruft is.

Fair enough. Here's some code I wrote for a side project a couple of years ago - it was a side project, not meant for real world production, and it's a couple Django versions behind, so no guarantees as to quality, but should give you an idea:

https://github.com/danjac/ownblock/blob/master/ownblock/ownb...

Not my experience either. And in 2016, email-as-username should be default and work flawlessly out of the box.

Django REST Framework is excellent.

And quite slow

I can't even begin to imagine what your doing with it that makes you think it's slow.

Links or references to documented slowness?

Well, obviously an SPA would not run into any of the cruftiness since you're just using Django as a "dumb pipe" to the DB.

Not all SPAs are based on the DB+"dumb pipe"+SPA stack, sometimes you need to process things on the server, based on your business requirements and/or performance considerations. Sometimes the processing done in that layer can be quite significant. If that is your need, both Django itself (using JsonResponse and serialization objects) and Django REST Framework allow you to do so much more than dumb piping.

My point is Django is not limited by the fact that it was initially conceived as a framework for serving static web pages.

all successful software is crufty. django os not perfect but it's a very solid option. the fact that it's taken websockets seriously means that building real time apps became easier.

The good news is that it's "real-time Django". The bad news is that it's Django.

So "bad news" is that they added a feature to a framework you don't use?

Why?

Python is a language that gives us a lot of liberty in how we solve problems, but Django is a set of cookie cutters for doing things a certain way. Django's cookie cutter patterns and extensions don't lend themselves well to doing things outside the way that Django intended them to. It's why a lot of us prefer Flask or Pyramid as framework of choice.

http://nando.oui.com.br/2014/04/04/why_i_sort_of_dislike_dja...

Haha.

It's nice to dabble around Pyramid and/or Flask, but everytime I use, or someone I know uses them for not completely trivial microservices, they are always reinventing those 'cookie cutters' from scratch on their own (or choose a set of 'cookie cutters' made by someone else).

Django can work as a 'microframework', i.e. 'hello world' in one file and in ~10-15 LOC.

Not to mention Django's 'stability', i.e. stable releases at known time, with known ahead roadmap and forthcoming changes, great documentation, etc., whereas Flask has not been released for 2years and 9months (!!!), master is 900 commits ahead (2400 commits in total) of latest version, documentation is not the best (especially for current `master`)... Pyramid is made by true rockstar programmers, though it did not stand against hip image of flask and it suffers from the fact that I must reinvent all the 'cookie cutters'. IMHO this 'microframework' approach is good only for trivial microservices and/or completely non-trivial, crazy custom apps, where overriding Django would be just too much.

>Python is a language that gives us a lot of liberty in how we solve problems, but Django is a set of cookie cutters for doing things a certain way.

Actually a core tenet of Python is: "There should be one-- and preferably only one --obvious way to do it".

So Django couldn't be more Pythonic in this regard.

Then there is only 1 Python framework? Dumb comment. I was talking about architectures not syntax.

"Dumb comment" isn't the kind of language HN prefers.

>Then there is only 1 Python framework?

No, there are several. But all of them should strive to be Pythonic, including in the sense of offering "one, and preferably only one, obvious way to do something".

>Dumb comment.

Oh, the irony.

>I was talking about architectures not syntax.

And the Zen of Python is about architecture and APIs too, not just the syntax of the language. They are generic guidelines about how to write Pythonic programs.

I think the objection is referring to Django unequivocally as "bad news", rather than saying that your personal preference is for Flask.

(I work in a shop which has used both, and generally try to avoid claiming one or the other is objectively better; they're not quite at the apples-and-oranges level, but pretty close)

I just get tired of seeing the same thing play out time and time again. Developer A picks Django because business described a project that can easily be handled by CRUD and thinks the Admin will be perfect for product owners and users to manage their data. 6 months go by, Product owners go off the rails of the original requirements, request changes to the admin and/or changes to the data source and/or changes that require a fundamentally different data model. Developer A bails and Developer B, C, and D get stuck with this mess that should be been developed with a more flexible solution. The more people use Django without recognizing this, the more I want to not even look at Python shops.

Flask and Pyramid don't help in that situation either...In fact, I switched from Flask (after years of being an avid Flask proponent) because I ran into too many projects that were a mess due to the lack of constraints / standard ways of doing things. After 5 years of solid Django use, I have yet to run into a situation where Django is too inflexible for a client's needs. No, the Admin isn't for everything (and that's even outlined in the docs); but it's not difficult to roll a custom dashboard (just like you would when using Flask or Pyramid).

The flask community really needs to rally around a project layout/boilerplate set-up; it took me a lot of trial and error to really nail scalable, intelligent flask projects and that is the #1 issue people run into with it.

Over the years I've used Flask for smaller projects with very specific requirements and simple web GUI requirements. Its my de-facto tool to prototype and/or deploy JSON APIs. It works perfectly for that because it does not impose anything on me. For more complex projects, or projects that use a web GUI (even if they are rendered with client side frameworks) Django proves to be more effective. It has a standard toolset that takes care of a lot of the edgecases one would face. For example, Flask lacks a default CSRF implementation whereas Django makes explicit use of one. Logging is also very simple with Django, something that gives some people grief. In Flask you have to setup logging from the bottom up. Both are quite different but good for what they were meant for. In fact, I tend to look for the Django or Flask of other languages to try and see how a specific type of application with look in that language. Not long ago someone posted a project that mimics flask in Rust. It was a very nice codebase and it made Rust very approachable because I could map what I know about Flask over to Rust and make a connection between language constructs and patterns.

If "product owners go off the rails" you have a management and process problem, not a Django problem.

That's not to say there are projects where another framework/language would have been better but no solution is going to save you from poor project management.

I've been working with Django for years and I can't think of any way in which it is not flexible.

I wrote a CMS for a large newspaper where I deployed new code on almost a daily basis using Django(uWSGI)-redis-PostgreSQL-Celery. 4 developers were active at the time. Requirements were not set in stone, we tested tons of stuff out and iterated every aspect of the site both on the development and operations side. Django was never the problem during those 18 months.

Django is like any other framework/language. Bad programmers can make a hash of it with ill-conceived ideas.

This isn't a problem with Django. This is simply how software business works. No matter how well architected your solution and no matter what platform you will always have the request to do something it wasn't designed to do. If you're lucky you don't have a manager who says "can't we just put an if statement in."

Yeah, right..

There is no boilerplate or constraint how those 'flexible' solutions should be created, thus every developer writes however he wants and if those developers have not made constraints for themselves you will have a total mess, written in so many styles as there were developers. Jeez, I've even seen messed up Django apps, where you usually must follow some patterns.

Patterns, constraints, models, architecture are for a reason and if a framework/language/library makes you use some specific styles, it's much easier to maintain such projects when there is more than 1 person working on them.

This isn't a Django problem. Just don't customize the admin. Ever. If the admin can't do what you want, pull out React and Django REST Framework and build something that does what you want.

I work with various languages and frameworks. Django is great for general web CRUD systems. It being opinionated and somewhat inflexible is a blessing and a curse. No framework is perfect.

Flask provides the basics to build Web apps. It's low on opinions and flexible. I mostly use flask for systems that are very specific about their functinality and use case.

I've never understood this criticism of Django.

It's a batteries included framework, but at the end of the day it's just Python. You can integrate with whatever library is best for the job.

I've worked on Django apps that use SQLAlchemy instead of the Django ORM, Django apps that use Mako instead of the Django template language, and I'm currently exploring using Marshmallow instead of Django forms for some cases.

Is there anything in particular that you feel you can use with Flask or Pyramid but you couldn't use with Django?

I view it from the other direction. If you aren't using the ORM, or the templating engine, or the admin interface, why would you choose Django? If your answer is for a plug-n-play RESTful api or authentication, you might want to check out PostgREST with PostgreSQL 9.5's row level security features, it's just plain better.

Because at that point, Django is a superset of Flask. It can do everything Flask can do, but it also has additional access to the Django ecosystem of tools and libraries.

I really like Django, but you're right that if you for whatever reason needs to make Django do something that's it's not exactly designed for, you're going to have a bad time.

What I found is that if you can manage stay within the confines of Django, you will be rewarded and can avoid writing a ton of code. There really isn't to many situation where you can't just to things "The Django Way". If you find one, then maybe rethink your solution. I had a ton of code where I tried to fight the Django Rest Framework, when I stopped and just accepted that Django and the Rest Framework is opinionated I was able to reduce complexity and line count.

Of cause there are problems where Django is simply the wrong solution.

You can use as little of Django as you need. I like flask also, but to get it at all functional for larger apps you have to bring in dependencies.

That's one of the reasons I recently made a pared-down Django project, to highlight that you don't need to use all of the tools Django offers: https://github.com/rnevius/minimal-django

Nice example; thanks for posting a link. I didn't have anything handy when I posted my comment.

Reply on news.ycombinator.com