Modern JavaScript for Django developers

This is an excellent article, and SaaS Pegasus is a great solution for people starting a project.<p>But some of the advice here is dated. The architectural patterns are still valid, but the specifics have changed:<p>* Vite instead of create-react-app (which is unmaintained now) &#x2F; webpack &#x2F; babel &#x2F; Parcel &#x2F; etc.<p>* Django-ninja as a lightweight API service.<p>I think these are important to call out because they really simplify the frontend compared to the previous options.

Having used HTMX and Unpoly with Django, for over 2 years now, I prefer using Unpoly more these days.<p>Unpoly feels just like Django, it is a more of a framework than a thin layer, but that means it comes with a lot of productive features built-in, albeit opinionated.<p>It covers 95% of the use-cases of a typical web app, with its layers and forms concepts. E.g. I love creating &quot;subinteractions&quot; with unpoly, where a complex process can be divided into smaller modal forms for creating the &quot;related&quot; objects of a model, which then updates the main form of the model itself. Unpoly makes these simple, and its documentation caters for exactly these scenarios.

The problem in this space is that a quarter of century(!) after Fielding&#x27;s dissertation [1] we don&#x27;t have a serious follow up on &quot;Architectural Styles and the Design of Network-based Software Architectures&quot;. A blueprint of a class of well constrained designs that can optimized and adapted according to use case.<p>The missing abstraction gap goes beyond Django (on the server side), and beyond Javascript on the client side. With the hardware and network capabilities of today it should be much easier to create wonderful networked software and mind blowing experiences but the appification of the Web is denying its very essence. The Web has become in essence a conduit for delivering proprietary apps.<p>What would a worthy follow up look like? It needs to take into account the mobile revolution that happened in the meantime, which sort of requires taking into account clients of very diverse capabilities. It needs to take into account WASM, GPU etc.<p>[1] <a href="https:&#x2F;&#x2F;ics.uci.edu&#x2F;~fielding&#x2F;pubs&#x2F;dissertation&#x2F;fielding_dissertation.pdf" rel="nofollow">https:&#x2F;&#x2F;ics.uci.edu&#x2F;~fielding&#x2F;pubs&#x2F;dissertation&#x2F;fielding_dis...</a>

I&#x27;ve tried several boilerplates like SaaSPegasus and one thing I can&#x27;t really get around is that I feel like the experience of developing in a docker-compose with two build-and-serve containers (e.g. one with gunicorn auto-reload and the other running something like esbuild for the frontend) is very clunky in VSCode?<p>I feel like I&#x27;m doing something crazy, this must be a problem many other people have, but things like language server integration on the JS and Python side separately do not mesh well.<p>If anyone sees this and has a minimal open source boilerplate to recommend I&#x27;d love to try it.

Having done Blazor with C#. I just want Django to have its own version of Blazor. You never have to touch JavaScript, and &#x2F; or if you do, its very sparingly. Your front-end either runs AJAX style, or fully in WASM depending on your needs.<p>I have built some wonderful UIs with Blazor in drastically less time than I would have spent building a JavaScript UI.<p>HTMX and might be the closest thing to what I&#x27;m describing that is actually available for Django today, though minus the WASM capabilities.

Hi, I&#x27;m one of the creators of Django. For what it&#x27;s worth, here&#x27;s what I do for my product Soundslice (<a href="https:&#x2F;&#x2F;www.soundslice.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.soundslice.com&#x2F;</a>). I&#x27;ve been working on it full-time for 12 years, so a lot of thought has gone into this.<p>Soundslice is very complex in its front-end JavaScript. It has an entire sheet-music rendering engine, capable of &quot;responsive&quot; sheet music [1], plus an integrated audio&#x2F;video player for music practice, a full-fledged sheet music&#x2F;tab editor [2] and a ton more [3].<p>In short: we don&#x27;t use any JS frameworks. It&#x27;s just vanilla JS — and in this day and age, that is totally fine for building a quality product.<p>We&#x27;re disciplined in how the JS logic is structured, trying to find the right abstractions for the concepts of our app, and we use native JS&#x2F;DOM APIs (which are full-featured these days).<p>Every web page on our site is served by Django — in other words, there&#x27;s no single-page-app stuff. I&#x27;ve always found the idea of single-page apps to be &quot;against the grain&quot;: it goes against how web browsers are optimized, and it goes against how HTTP&#x2F;HTML were designed. Plus it adds a ton of complexity that mainly benefits the maintainers of front-end JS frameworks (it gives them power over you).<p>I think an entire generation of web developers has been misled into assuming JS frameworks are table stakes for building high-quality web apps — and that is 100% wrong.<p>The time-tested pattern of &quot;serve the initial HTML (with Django or whatever), then add functionality with JavaScript&quot; is solid and helps you build high-quality, maintainable websites.<p>On a meta note: for years I&#x27;ve sat on the sidelines and rolled my eyes at the frontend JS world, knowing it doesn&#x27;t affect me or my product. But I&#x27;ve come to realize all web developers — including those who don&#x27;t choose to use frontend frameworks — do indeed have a vested interest in pushing back against the bullshit. That&#x27;s because the JS frameworks are making the web crappier, and that affects us all by giving the web a worse reputation. Sites load slower, UI is weird&#x2F;buggy&#x2F;non-standard, and the culture perpetuates (meaning it&#x27;s harder to find developers who know &quot;actual&quot; JS instead of frameworks).<p>[1] <a href="https:&#x2F;&#x2F;www.soundslice.com&#x2F;help&#x2F;en&#x2F;player&#x2F;basic&#x2F;100&#x2F;resizing-the-player&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.soundslice.com&#x2F;help&#x2F;en&#x2F;player&#x2F;basic&#x2F;100&#x2F;resizing...</a><p>[2] <a href="https:&#x2F;&#x2F;www.soundslice.com&#x2F;notation-editor&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.soundslice.com&#x2F;notation-editor&#x2F;</a><p>[3] <a href="https:&#x2F;&#x2F;www.soundslice.com&#x2F;features&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.soundslice.com&#x2F;features&#x2F;</a>

I think this is a great resource but wish it had not chosen a hybrid architecture. All the guides on decoupled Django seem to choose hybrid. It makes sense because you get the CSRF &#x2F; XSS safety benefits but I&#x27;d love to see how others tackle a fully decoupled Django stack e.g. oAuth, JWTs and how they do their CSRF &#x2F; XSS security. It&#x27;s an area I need to learn more about.

I don&#x27;t think Alpine.js and HTMX qualify as &quot;Modern JavaScript&quot;. There is an approach that is rarely talked about: render templates in Django and hydrate using your favorite JavaScript framework.<p>For example the Django template renders a &lt;template id=&quot;abc&quot;&gt;&lt;button disabled&gt;open modal!&lt;&#x2F;button&gt;&lt;&#x2F;template&gt;. Then your JavaScript bundle can &quot;hydrate&quot;. For example ReactDOM.render(&lt;OpenModalButton &#x2F;&gt;, &#x27;#abc&#x27;&#x27;).<p>You just have to be diligent to make sure that the template and your front-end have <i>somewhat similar markup</i> to not have layout shift. It&#x27;s really not that hard and works for a lot of use-cases.<p>Not saying this is a golden bullet, but you should be able to figure out which parts are static and just render them using Django templates. The dynamic parts you can render&#x2F;hydrate using whatever front-end framework.<p>I built a Django app with very little JavaScript and only using HTMX and it was... alright. It works. I can say &quot;no fancy build step!&quot; but I totally miss the testability of modern frontend. Creating an image upload component was a pain. I don&#x27;t think I would use HTMX again and instead go for the hybrid approach I described earlier.

I&#x27;ve seen some companies using React with Django REST Framework [1], to keep the benefits of Django while having a strong separation between front and back (separate projects, teams, deploys, etc).<p>[1] <a href="https:&#x2F;&#x2F;www.django-rest-framework.org" rel="nofollow">https:&#x2F;&#x2F;www.django-rest-framework.org</a>

BTW, this guy&#x27;s Django templates are really good.

Check out <a href="https:&#x2F;&#x2F;inertiajs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;inertiajs.com&#x2F;</a>.<p>I&#x27;ve never used it with Django (there&#x27;s an adapter here <a href="https:&#x2F;&#x2F;github.com&#x2F;inertiajs&#x2F;inertia-django">https:&#x2F;&#x2F;github.com&#x2F;inertiajs&#x2F;inertia-django</a>) but I did use it a lot with AdonisJS and Rails.<p>It&#x27;s wonderful. The best of both worlds. TL;DR you can use React&#x2F;Vue as your &quot;template&quot; layer and keep everything in your batteries included backend framework of choice, avoiding all the bull**t and madness going on with Next, Remix, React Router, etc, etc...

The best thing about Django is I don&#x27;t have to write much Javascript.<p>Introducing a whole JS build pipeline? I&#x27;m absolutely not doing that.<p>The vanilla JS language is pretty capable these days. There are a few things that are still terrible, but if you&#x27;re just writing a few lines here and there, they don&#x27;t really bite you. I can just src a JS file I wrote and get everything I want from modern JS. What I <i>don&#x27;t</i> want from modern JS is a quarter million 0.x versioned unaudited dependencies for every minor thing that make breaking changes for no reason. The situation with Python packages is already tricky enough.

I like this setup, but I had kinda thought &quot;modern&quot; javascript had mostly moved to server-side rendered at this point and I didn&#x27;t see anything about that in the syllabus. Anyone know if this tutorial addresses that kind of thing?<p>EDIT: Nevermind I guess this is the HTMX example? But how would this compare to manually building something with next.js as part of your front-end build and incorporating those assets into your templates?

I&#x27;ve been working on a Django + Vite + HTMX + Alpine project for the past year or so<p>Using django-htmx and django-vite libs (the latter forked to add Jinja support)<p>Been pretty happy with it<p>The main wart I find is the lack of type-safe templating in Python, feels primitive and clunky compared to what you have with TSX in a React project<p>Been using Jinja macros as &#x27;components&#x27; which... works. The syntax is kinda ugly to read though, and haven&#x27;t found any really great linter.

I wish there was some way to just get react-style data bindings, html generation from JS, and code organization, while still hosting from purely a flask&#x2F;django backend. The traditional split of a flask API and a react frontend consuming it, just feels like overkill.<p>Plus native JavaScript+html is just so close to a complete solution these days. I don’t miss components at all. I just want better code organization.

This guide is a bit over two years old. Can someone comment on whether it still holds up and the tools recommended are still being recommended today?

Excellent article - thank you for posting.

Crazy that even this article is now dated. Many people have now moved on from webpack to vite.

&gt; A Crash Course in Modern JavaScript Tooling. Don&#x27;t worry—it&#x27;s not as bad as it sounds.<p>Then proceeds to introduce the same confusing garbage JavaScript tooling that you find in all other modern JavaScript documentation.<p>In all seriousness, this is a really nice write up, I like the structure and it actually makes me want to give want to give VueJS and Django another go (being sort of locked in on VueJS because that&#x27;s what our internal framework uses).<p>One thing that always have me a bit concerned is how to do localization. Django have built in localization support, but how well will that carry over to the JavaScript part of the code?

My opinionated view, based on the ancient katra of code practitioners - seek smaller code, fewer dependencies :<p>When moving from PHP, better to ditch &#x27;modern&#x27; over-engineered compiled javascript, and instead use javascript at first procedurally to get acquainted, then gradually use functional idioms from a good example library such as Ramda.js to reap language and productivity benefits over PHP-the-language.<p>I live in hope that tomorrows code thought leaders choose vue.js over the byzantine-borg-machinery that is the modern react ecosystem.<p>The good parts of Javascript [ which dont include prototype OOP ] make for a very productive language.<p>The node.js ecosystem is incredible for getting stuff done, I just hope we dont kill it via forced &#x27;modernization&#x27;. We have a generation of javascript developers who have only known javascript as a compiled language.. and the current will use LLMs to spew out react apps, not apps that use standard web apis. The react+build+bundle ecosystem is so verbose that you almost need an LLM AI assistant frontend to do the grunt work.<p>Its a sad quirk of history that python has become the lingua franca for AI .. javascript is a better language, and great at all that wrangling of data before you pass it to the matmull compiler [ a case where you actually need compilation to better fit the lower level NPU&#x2F;GPU ]<p>While Im channeling my inner boomer, I have to say, hand on heart : callbacks are more elegant than async&#x2F;await&#x2F;promises&#x2F;then .. and they are a better conceptual match for the underlying reality. The future has been here for some time and it is multicore - perhaps our sequential mindset is preventing us from adapting as an industry to software that makes use of very many cheap cores?

Cory, your content is killing it :D

Oh god not another plug for htmx