Modern JavaScript for Django developers

Original Article ↗ Hacker News Discussion ↗

Modern web apps built on Django are increasingly torn between heavy JavaScript frontends and lighter “HTML-first” approaches. Commenters weigh stacks like React, Vite and Django REST Framework against HTMX, Unpoly, Alpine and vanilla JS, debating trade‑offs in complexity, performance, developer experience and long‑term maintainability. Many favor Django plus minimal or no-build JavaScript (often with tools like Django‑Ninja for APIs) over fully decoupled SPAs, arguing that this pattern scales well while avoiding the churn and overhead of modern JS tooling.

Overall sentiment on Django & “modern JS”

  • Many like Django because it minimizes mandatory JavaScript; some explicitly reject introducing a heavy JS build pipeline.
  • Others argue Django’s “batteries included” are less relevant when frontend and backend are split, and are moving toward API-first stacks.
  • There’s praise for Django’s organization, documentation, and long-term stability, but complaints about async support maturity and difficulty integrating with legacy databases.

Server‑side rendering vs SPAs

  • Strong current running in favor of SSR + sprinkles of JS (HTMX, Unpoly, Turbo-like approaches, vanilla JS).
  • Several describe large, complex apps built with Django‑rendered HTML and vanilla JS, no SPA framework, with good results.
  • Others prefer fully decoupled SPAs (React/SvelteKit/Next) backed by Django/DRF or Django‑Ninja, valuing “modern frontend” testability and componentization.

HTMX, Unpoly, Inertia, Bridge, Livewire‑style stacks

  • HTMX + Alpine + Django is widely cited as a popular “low‑JS” stack; some say it’s become a default.
  • Unpoly is praised as “feeling like Django” and covering most CRUD workflows, especially multi-step/modal form flows; some quirks around browser history and overlays are noted.
  • Inertia.js is seen by some as “best of both worlds” (SPA feel, server MVC routing); others report frustration (hot reload, custom form patterns, collaborator confusion).
  • Django‑Bridge aims for a Django backend with JS-rendered UI.
  • People reference similar paradigms in other ecosystems: Livewire (Laravel), LiveView (Phoenix), Blazor, Django‑Unicorn, custom “liveview‑like” solutions.

APIs: DRF vs Django‑Ninja vs alternatives

  • Django‑Ninja is repeatedly praised: lighter than DRF, async-friendly, Pydantic-based, less boilerplate, good DX and performance.
  • DRF is seen as mature with rich ecosystem but more abstract, slower serializers, and a steeper mental model.
  • Some teams are gradually replacing more of Django with FastAPI/SQLModel/authlib-style compositions, though others warn this can end up “reinventing Django.”

Tooling: Vite, Webpack, esbuild

  • Consensus that the article’s original Webpack/Cra guidance is dated; Vite (and to some extent esbuild, Parcel, rspack) are preferred for speed and low config.
  • There’s debate: some see Webpack as fine/mature; others report multi‑minute dev builds vs seconds with Vite/rspack and argue migration is worth it.
  • Some advocate “no-build” ES modules/import maps when JS needs are modest.

Security & auth in decoupled setups

  • With token/JWT auth in SPAs, CSRF is often unnecessary; with session auth, CSRF must be handled via headers.
  • Token storage is contentious: localStorage is criticized; suggested pattern is access token in memory + refresh token in HTTP‑only cookie, though many say simple server sessions are easier if JWTs aren’t strictly needed.

Templating, components, and typing

  • Complaints about lack of type‑safe templating in Django/Jinja compared to TSX; people experiment with Jinja macros as components, htpy, JinjaX, and even alternative languages (e.g., Kotlin + typed templates).
  • Ongoing debate on whether React-style components are essential organization or unnecessary abstraction for many apps.

Dev experience & environment

  • Some struggle with Dockerized Django+frontend workflows in editors (e.g., multiple language servers across containers); workarounds include multiple VS Code windows or more minimal containerization.
  • There’s broad fatigue with JS ecosystem churn and heavy dependency trees; several advocate smaller, simpler stacks and more direct use of web platform APIs.