Modern JavaScript for Django developers

Original Article ↗ Hacker News Discussion ↗

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.