Hacker News Reader

Comment by zeemonkee3 | Hacker News Reader

This is one of the best things about Django - outside the admin interface it's not opinionated about your frontend setup.

View on HN

Of course "not opinionated" in this case is an euphemism and really means that Django doesn't help you at all and so you have to suffer the incomplete and abandoned middleware of others to have something that resembles an asset pipeline. And that's actually odd, because both Rails and Django are frameworks born for building frontends to MySQL databases, which means these frameworks really are about HTTP 1.1 frontend stuff.

For building backends and web APIs, especially web APIs that do constant streaming of data, maybe through WebSocket, there are actually much better options, so this raises the question, why use Django at all?

Right. The frontend story of Django is non-existent and it is a pain to reinvent the wheel each time. Need AJAX to work with CSRF protection? Just copy this snippet of code. Want to use SASS? Try to find a django app that provides an asset pipeline, or copy some django snippets, or do it yourself by bringing grunt/gulp/whatever is the latest hyped js build tool.

Now the remaining part of your comment is unfair. Pure frontend is just one small part of webapp development: templating, controller, ORM, i18n, user and session management, security, testing, etc.

You can do a lot of web backend stuff without websocket. Django is ok for that and if you combine it with Django Rest Framework, you get powerful tools at your disposal.

Take away templates and add Django Rest Framework and you have a very capable platform for building large CRUD APIs complete with models, permissions, serializers and so forth.

Is it the best solution when you just want to stream data down a socket? No. That doesn't mean it's useless for many other things.

If I'm going down the SPA route I'd just build the frontend separately using ember-cli or webpack or some other "native" solution and forget any asset pipeline.

> If I'm going down the SPA route I'd just build the frontend separately using ember-cli or webpack or some other "native" solution and forget any asset pipeline.

It's a good approach. There is no need to treat front and back-ends as a single application, bound by the same rules - they use completely different stacks and completely different tooling.

Re: websockets/push, another thing you can do is run two frameworks side by side. A load balancer like HAProxy can be used to unify the two, if needed.

For example, at my previous job we used Django for our main request/response API and Tornado for our push API. Later on, the Tornado part was rewritten in Java. Given the Django experience of the team, this architecture proved to be easier to maintain than having to rewrite the entire API, since there were far more request/response endpoints than push endpoints.

Nowadays there's Pushpin, which I created after the above experience.

Django wants to provide solutions that will stick around for longer than the attention span of the js community ;-)

Getting opinionated about js stacks at the moment could backfire hugely and alienate a chunk of their userbase. The policy is basically "Stuff should be left as 3rd party apps until a de facto winner emerges."

Not sure if that's likely to happen any time soon in anything related to front end code so keeping the core framework neutral seems like the best option. Mini-ecosystems can arise where neccesary.

Django models and migrations are very nice to work with. The Django Rest Framework and new Channels (aka sockets) functionality are quite nice. Getting usable, free user accounts and admin is a pleasure. Why not use Django?

> why use Django at all?

I like Django to build "hybrid" apps where e.g. public sites, registration form, etc. are rendered by the backend using only a couple of lines of js (not even using jQuery or similar) to enhance user expirience and another part of the app being a fullblown SPA using Django as a REST api.

I've found this problematic in Django: How to integrate a good JS frontend that isn't at odds with the built-in templating system. Offloading the templating to React (eg. node / JSX) seems like a good bet -- but then your Django app is little more than a REST API.

I'd love to see some good, practical examples of a full-featured (ie. integrated) Django app with a js frontend. Pointers welcome!

Python is a good language for writing glue code. Django abstracts a lot away with its ORM. If you stick to just providing an API, you'll still get some help from it.

Now is it better than assembling a little stack yourself with an ORM + a micro web framework? Well, perhaps not - though you still got the admin which can be handy. But next time you're going to need do to a project that won't benefit at all from being a SPA, Django will be helpful.

You can turn the question on its head - if you're just providing a relatively thin API, whatever you choose probably won't be terribly important as long as it is not something fragile that will be gone in 2 years. So don't invest too much thought into it.

Same thing with Grails, though they've improved support for Angular lately. I prefer vanilla js anyway, its what I used 15 years ago, and it is what I will continue to use the next 15 years and hopefully a lot longer.

OTOH Grails 2 invites people to use the awful formRemotes, which apparently are an idea lifted from old versions of Rails, and are a mishmash of html and javascript. Seems quite an opinionated approach on how you should build your frontend.

Luckily Grails 3 dropped it, but the project I'm working on at the moment is stuck on Grails 2... and Grails 3 is a complete rewrite of the framework

Django models are nice and easy to work with for the most part, and the template inheritance is great for building out front-ends. But there's a lot of "Django magic" that goes on behind the scenes so I tend to think of Django as an opinionated front-end. Django forms and how they are handled give me nightmares.

Reply on news.ycombinator.com