13 ms·

Modern JavaScript for Django developers

240 points by rob 2y ago

giancarlostoro 2y ago
Having done Blazor with C#. I just want Django to have its own version of Blazor. You never have to touch JavaScript, and / or if you do, its very sparingly. Your front-end either runs AJAX style, or fully in WASM depending on your needs. I have built some wonderful UIs with Blazor in drastically less time than I would have spent building a JavaScript UI. HTMX and might be the closest thing to what I'm describing that is actually available for Django today, though minus the WASM capabilities.
- selecsosi 2y ago
  Typed view model bindings to templates was always amazing and 100000x more ergonomic than WPF (in my experience). That being said with so many things going to client apps, I'm less inclined to go w/ server side rendering and treat my backend as a data API so I'm not stuck building that twice.
- lowercased 2y ago
  Is unicorn close? https://www.django-unicorn.com/ https://www.django-unicorn.com/ Wouldn't be WASM based either, but most of these types of tech aren't (yet?). I'm in the livewire camp with Laravel. I found a bit discussion of a webassembly version of livewire, but I don't think it's on the cards any time soon.
- leetharris 2y ago
  Laravel has something like this called Livewire. It's excellent. Laravel is so much better than Django, but I just can't go back to PHP at this point. https://livewire.laravel.com/ https://livewire.laravel.com/
  - pier25 2y ago
    > I just can't go back to PHP at this point Same. During 2024 I evaluated multiple backend platforms/frameworks to get away from Node. Laravel is great and modern PHP (the language) is also surprisingly good but betting on PHP feels like betting on coal and the steam engine. The runtime and execution model are extremely outdated and resource hungry. There are some efforts like FrankenPHP and Swole that package a PHP app to have a persistent execution model. But IMO unless PHP officially adopts this model this will always feel like a hack to me.
    - rob 2y ago
      What did you end up going with if not PHP/Laravel?
      - pier25 2y ago
        Dotnet for backend and SvelteKit for frontend.
    - cjohnson318 2y ago
      I'm not sure why this has been downvoted so much, this guy states something that might upset some people, but then goes on to provide a pretty sober list pros and cons. This is the kind of content that we want to encourage on HN.
      - gjsman-1000 2y ago
        It’s downvoted because even if PHP has hacky behavior; he’s running with the assumption other frameworks don’t have their own hacky behavior, or other frameworks are worse. This is not necessarily warranted. Modern PHP is faster than Ruby in many benchmarks; and Rails is still running GitHub and Shopify. Square uses Laravel in a backend serving 100M+ requests per day, with no plans to rewrite. To compare it to a Steam engine and Coal; that’s unfair stereotyping. On that note, JavaScript’s amount of churn could be an entire discussion by itself. I’ll take some quirky behavior that just keeps working over mindless churn any day.
    - morbicer 2y ago
  - lawn 2y ago
    And Phoenix/Elixir has LiveView, also excellent.
  - adamrt 2y ago
    I've heard people complain about Django many time on HN. I started using it back in the 0.96 version, so maybe its just a familiarity thing. But I built 3 large successful applications in it in that time. I loved it. I don't use it regularly anymore since I mostly moved away from webdev, but I recently came back into contact with my largest project I build in 2018/2019 and its been running perfect this whole time and was a pleasure to dive back into. Django just felt logically organized, documentation was on point, core was very readable (at least then). I always just felt so productive in it. I know everyone has different opinions, experiences and products they are building, but I'm always surprised with the negative comments. I definitely prefer SSR with its reasonable though, so maybe thats part of it.
    - oooyay 2y ago
      Most of the complaints I've read about Django on HN have to do with ASGI support - which Django added. They're valid but outdated complaints.
      - airstrike 2y ago
        ASGI support for Django landed in 2019. Those comments are very outdated https://docs.djangoproject.com/en/5.1/releases/3.0/#asgi-support https://docs.djangoproject.com/en/5.1/releases/3.0/#asgi-sup...
        black3r 2y ago
        tbf it was borderline unusable until they added async DB query support in 4.1 (2022) - before that you had to wrap every DB query with sync_to_async, async_to_sync and it generated too much boilerplate code..., and even in 4.1 the DB queries themselves were still sync/blocking, not truly async because at that point they didn't yet rewrite their database "backends" to use async querying, and I believe that as of now the Django's DB engine still doesn't support natively async DB queries/cursors/transactions/... Also, lots of the "batteries included" into Django don't have async interfaces yet.., for example the default auth/permission system will get async functions like acreate_user, aauthenticate, ahas_perm only in 5.2 which is expected in April 2025, so as of now these still have to be wrapped in sync_to_async wrappers to work...
  - nop_slide 2y ago
    I thought the same. I evaluated the "big 3" (Laravel, Django, Rails) last year and decided to go all in on Rails for solo side web projects. Was really wanting to like Django since I'm a python dev for my day job, but it didn't have nearly the amount of DX and tools baked in as Laravel/Rails. Rails has been super fun, I hadn't touched it in 10 years and the additions that versions 7/8 have brought are awesome.
  - 7bit 2y ago
    I tried Latavel, but there were some points that made me want to drop it very fast. I work on Windows and I chose a PHP variant (don't remember, maybe one that supports threads or async) that did not work on Windows very well. Starting up a Latavel server took minutes. Took me hours to finally find that the PHP binary itself was the root cause. It should not be that way. Then installing Compose on Windows was horrible. I believe I had to install PHP and compose in C:\php or it just would not work. The compose "installer" did a bunch of stuff to my Windows which I did not want. Installing it manually was a pain in the ass. All in all, the experience was exactly the same as in the 2000's (horrible). After I setup my first Latavel project and had some question, it was really difficult to get answers. The docs are really good, but also fragmented as hell with all the approaches one could take to rendering content, depending on what you choose and how you approach it. The forums - although big - seemed dead when I stated my question. I don't know man, my experience with Django is so much better.
    - graemep 2y ago
      You are not likely to deploy it to Windows in production, so develop on Windows? Does WSL not solve this problem? Or a VM of any sort?
      - 7bit 2y ago
        I could solve these issues with the suggestions you made, but why? I can develop stuff in many languages directly in Windows just fine, and I frankly am not willing to jump through hoops so I can do the same stuff with PHP -- that I can conveniently with Python, JS, dotnet, Java, Elixir, Rust, C/C++ and many other languages. I never found anything so complex and buggy as PHP.
        graemep 2y ago
        Certainly if you do not like PHP. However, if you wanted to use it there is no real reason not to. My usage of PHP has been using software written by other people but customising - and there is a lot of useful stiff written in PHP. I prefer Python if doing something from scratch, but I would rather write a small amount of PHP to add a bit of functionality rather than write 10× the amount of Python because I need to write everything from scratch.
- neonsunset 2y ago
  If you liked Blazor (and it's interesting to hear perspective of someone "outside" the .NET bubble), is there a reason to prefer Python and Django?
  - giancarlostoro 2y ago
    I feel like I can build web apps drastically faster in Python than with C#. I find myself writing a lot less boilerplate and things, even when using a full stack framework like Django.
- runekaagaard 2y ago
  We've rolled our own liveview and have happily used it in production for several years now: https://hypergen.it/ https://hypergen.it/
  - giancarlostoro 2y ago
    Oooh I am working on a brand new Django based project, thanks for this!
grajaganDev 2y ago
Excellent article - thank you for posting.
yoyohello13 2y ago
BTW, this guy's Django templates are really good.
0xblinq 2y ago
Check out https://inertiajs.com/ https://inertiajs.com/. I've never used it with Django (there's an adapter here https://github.com/inertiajs/inertia-django https://github.com/inertiajs/inertia-django) but I did use it a lot with AdonisJS and Rails. It's wonderful. The best of both worlds. TL;DR you can use React/Vue as your "template" 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...
- DangitBobby 2y ago
  I eventually came to regret using Inertia and just wished we had used e.g. django-rest-framework and React Router. React Router is excellent. I feel pretty much the same way you do about Next.js, though.
  - 0xblinq 2y ago
    I have the exact opposite experience, but context is everything here I guess. > React Router is excellent. When you compare it to Next, etc... yes, I agree. The issue I have is the constant change of mind their devs have regarding how to do things, even when they say "it's stable"... it's not... every day they come up with "a better way" to do things which usually is not better, just different. But using it when you already have django/rails/laravel/adonis means you have to do a ton more work and reinvent a lot of things (such as authentication, validation, etc). Care to extend on what problems you found or what you didn't like about inertia?
    - DangitBobby 2y ago
      For me personally, the lack of hot-reloading is painful for portions of the app where it takes you a few steps to get to the UI state you are working on (e.g. rendering a model with tabs). Having to add custom code to for flash, their special form handling, and other Inertia specific parterns that only I really understood made it difficult for some collaborators. I don't remember the specific of the form handling either but from what I remember it would have been difficult to instrument client-side validation such as react-hook-form as well. > The issue I have is the constant change of mind their devs have regarding how to do things, even when they say "it's stable"... it's not... every day they come up with "a better way" to do things which usually is not better, just different. It is annoying. They are pushing people towards Remix as well, which I have tried and prefer to avoid unless I absolutely must have SSR. But their docs for older versions are still around so you can stick to what you like.
cdfuller 2y ago
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?
- czue 2y ago
  Author here. I would say the core principles still hold up well, though the tooling and libraries are constantly evolving. An incomplete list of things I'd add / change today (and are on my roadmap to cover in more detail): I would probably recommend Vite over Webpack as the main bundler/builder, as it's faster and rapidly taking over as the default tool to solve the same use cases. The other gap that is missing is a treatment of the "nobuild" options that exist today. Essentially things like ES modules and import maps and other stuff that lets you (if you want) run a lot of modern JavaScript libraries with zero toolchain directly in the browser. I'd also want to revisit the fully decoupled approach a bit more. With the advent of LLM-based tools that can generate complete front ends for you, as well as libraries like shadcn, there is a larger upside to adopting the complexity of the decoupled API set up, even if it definitely still is slower and more painful for anything that touches the backend. Django ninja has been gaining traction against DRF as an API library and the developer experience and performance are definitely better, though DRF still has way more batteries in terms of 3rd party library support for various use case. The Django + HTMX + Alpine stack has only gotten more widely adopted since I published Part 5, and I'd say that part has held up quite well in the "low to no JavaScript" ecosystem for Django, and is the default choice for many Django devs now.
  - bkovacev 2y ago
    Can you explain further on the performance aspect of Django Ninja vs DRF?
    - e-brake 2y ago
      It is built to fully support asynchronous endpoints, and uses pydantic models for validation and parsing - lightweight and nicely fast
  - 2y ago
chis 2y ago
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/django backend. The traditional split of a flask API and a react frontend consuming it, just feels like overkill. 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.
- morbicer 2y ago
  I don't understand the second sentence. As someone developing web apps for over 20 years, components ARE the better code organization.
  - fmnxl 2y ago
    Well there's a cost to that abstraction, e.g. you'd have to pass the context into the component, so every time you need to modify the component's schema/props you'd need to change it twice, both in the parent and the component. You must have seen some huge React components with 20 different props or even more, and you'd need to think about memoizing those props to prevent a re-render, etc etc. I've also been a web dev for over 20 years, and 10 years with React. I'd say that going back to native HTML APIs for handling stateful things like forms and form validation is a breeze, rather than writing components and endless abstractions. It's enough for the vast majority of the time.
    - morbicer 2y ago
      Those are just shitty codebases. I maintain a React app that's over 10 years old, almost milion lines of code and we have zero components with 20 props, no issues with performance or whatnot. I am an oponent of over-abstraction but components are very light abstraction and provide just sensible encapsulation and reusability.
      - fmnxl 2y ago
        Show me this amazing site of yours. With that amount of talent maybe you should go over to Next.js and solve their RSC issues.
fmnxl 2y ago
Having used HTMX and Unpoly with Django, for over 2 years now, I prefer using Unpoly more these days. 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. It covers 95% of the use-cases of a typical web app, with its layers and forms concepts. E.g. I love creating "subinteractions" with unpoly, where a complex process can be divided into smaller modal forms for creating the "related" 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.
- JodieBenitez 2y ago
  Same here... Unpoly is a perfect match for Django.
- SCUSKU 2y ago
  The one thing I couldn't get past when looking into Unpoly is that if you're in a deeply nested modal/layer, and then refresh the page, it just shows you the most recent modal as a full page. My expectation is that when you refresh, instead it would keep you on the base page, and then wipe all the modals.
  - spapas82 2y ago
    Unpoly by default changes the browser's history to the url of the modal. Thus when your refresh you'll get exactly that. You can modify that behavior with up-history, see here https://unpoly.com/history-in-overlays https://unpoly.com/history-in-overlays
  - fmnxl 2y ago
    You can set up-history="false" and there'd be no navigation when opening the modal, so when you refresh the page it'd refresh the parent layer not the modal. What's more arguable I think is how pressing the browser Back button doesn't preserve the layers, but opens the previous page as a full page. I think that can be changed in a config somewhere, though.
- spapas82 2y ago
mlamina 2y ago
Cory, your content is killing it :D
nilsbunger 2y ago
This is an excellent article, and SaaS Pegasus is a great solution for people starting a project. But some of the advice here is dated. The architectural patterns are still valid, but the specifics have changed: * Vite instead of create-react-app (which is unmaintained now) / webpack / babel / Parcel / etc. * Django-ninja as a lightweight API service. I think these are important to call out because they really simplify the frontend compared to the previous options.
- bkovacev 2y ago
  What seems to differentiate django-ninja over Flask or FastAPI or any Starlette derivative? You mention lightweight as well, can you expand further?
  - nprateem 2y ago
    Ninja lets you use django. There's less config vs DRF
    - bkovacev 2y ago
      Aside from the obvious that ninja let's you use django.
      - WD-42 2y ago
        The ability to use django is the main attractor. The other frameworks are great but make you reinvent Django if you require auth, orm, admin, etc
        globular-toast 2y ago
        Oh but you wouldn't reinvent Django, you'd build a properly architected, simple system.
        WD-42 2y ago
jilles 2y ago
I don't think Alpine.js and HTMX qualify as "Modern JavaScript". There is an approach that is rarely talked about: render templates in Django and hydrate using your favorite JavaScript framework. For example the Django template renders a <template id="abc"><button disabled>open modal!</button></template>. Then your JavaScript bundle can "hydrate". For example ReactDOM.render(<OpenModalButton />, '#abc''). You just have to be diligent to make sure that the template and your front-end have somewhat similar markup to not have layout shift. It's really not that hard and works for a lot of use-cases. 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/hydrate using whatever front-end framework. I built a Django app with very little JavaScript and only using HTMX and it was... alright. It works. I can say "no fancy build step!" but I totally miss the testability of modern frontend. Creating an image upload component was a pain. I don't think I would use HTMX again and instead go for the hybrid approach I described earlier.
- azemetre 2y ago
  Why wouldn't Alpine.js and HTMX be modern javascript? They're both written with modern javascript. React was created in 2013, Alpine in 2020, HTMX 2020. React is the elder of the bunch. React is the bloated tool nowadays.
  - drdaeman 2y ago
    Personally, I don't think the term "modern JavaScript" makes much sense - it's just a nice-sounding but mostly meaningless buzzword, but I can guess the reason about the disagreement. Alpine and HTMX are entirely different architectural approach to script webpages, as compared to React/Vue/Svelte/Elm/... approach to build SPA webapps. And the latter approach was very frequently called "modern JavaScript" (and that's why I think it's more of a buzzword now, and less of an actually meaningful term).
    - riskable 2y ago
      "Modern JavaScript" === "Whatever just came out in the past week to six months and has had several articles written about it on the front page of Hacker News"
singhrac 2y ago
I've tried several boilerplates like SaaSPegasus and one thing I can'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? I feel like I'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. If anyone sees this and has a minimal open source boilerplate to recommend I'd love to try it.
- tubs 2y ago
  Why do you need docker to run esbuild? It’s a static binary.
  - qwertox 2y ago
    Not everyone is aware of this fact. I include myself in the list of those who didn't know that. Most likely because I didn't bother to inform myself because my expectation of the JavaScript ecosystem is that you first need to install npm via node, and then have it pull a huge amount of files just to then have a tool with which you can bundle stuff without then understanding where you need to "install" it. It's a chaotic ecosystem, much worse than Python, and I know and love Python. ``` Major features: - Extreme speed without needing a cache - JavaScript, CSS, TypeScript, and JSX built-in - A straightforward API for CLI, JS, and Go - Bundles ESM and CommonJS modules - Bundles CSS including CSS modules - Tree shaking, minification, and source maps - Local server, watch mode, and plugins ``` No word of it being a single executable, on the landing page, in the "major features"-list. `npm install --save-exact --save-dev esbuild`. We have different expectations on how to download a binary. Edit: I found an instruction on how to get the binary [0], why is this so hidden? [0] https://esbuild.github.io/getting-started/#download-a-build https://esbuild.github.io/getting-started/#download-a-build
    - xdennis 2y ago
      Nothing is perfect but it's ridiculous to say Node is more chaotic than Python. What's the Python package manager of the month? uv? poetry? pipenv? conda? pip? pyenv? setuptools? virtualenv? venv? pdm? easy_install? pymgr? mamba? Some only create environments, some only install, some don't even resolve packages, some don't create lock files, some only install python, AND NONE OF THEM agree where to install! Where does npm install? node_modules and it's been that way from the start. *I added a fake one to see if people can spot it.
deleted 2y ago
[deleted]
cwales95 2y ago
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 / XSS safety benefits but I'd love to see how others tackle a fully decoupled Django stack e.g. oAuth, JWTs and how they do their CSRF / XSS security. It's an area I need to learn more about.
- lastofus 2y ago
  Decoupled Django usually means that you are providing a client SPA with a API, such as a DRF powered REST API. If you are using something like token auth (you mentioned JWT), then you are not using cookies, at which point CSRF is not needed. This is because the user's browser isn't automatically sending the cooking containing a session ID on every request to the server. That said, you can implement session auth with DRF REST APIs, which accept a session cookie on requests. For this, I believe you would receive/send CSRF tokens via HTTP headers. XSS is not something you would worry too much about in an API endpoint. It is something you should worry a lot about in your client side SPA though. If using something like React, your templates will be auto-escaped, and thus you have to go out of your way to make it a problem.
  - cwales95 2y ago
    Where I get confused is storing the tokens securely. There's a lot of conflicting information online. I've come across many examples where they suggest localStorage which is a horrible idea. A lot of the advice I see now is about http-only cookies but I think I'd probably look more into oAuth in the future.
    - skuxxlife 2y ago
      The current best practice is to keep the token in memory only and store a refresh token in an HTTP-only cookie. In my experience though, if you’re only doing web-based auth and don’t _need_ to use JWTs for a specific reason, just use regular session cookies, it’s way less hassle. Coordinating auth and refresh state across page refreshes and tabs is a pain, and using a refresh token means you’re using cookies and saved session state anyway, so you lose pretty much all of the unique benefits of using JWTs and still have all the downsides.
ggregoire 2y ago
I'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). [1] https://www.django-rest-framework.org https://www.django-rest-framework.org
- ryannevius 2y ago
  We use Django and django-ninja [1] and like it MUCH better than DRF. [1] https://django-ninja.dev https://django-ninja.dev
  - bkovacev 2y ago
    Care to elaborate further? I keep reading on this, but no one actually mentions anything specific that ninja does better than DRF.
    - anentropic 2y ago
      I haven't used django-ninja but to me it looks like the API is a bit nicer or more 'modern' looking (i.e. declarative via type annotations) and it's faster, both due to being based on Pydantic DRF is old and API looks more like Django forms or class-based views, more of an OOP hierarchy going on, and DRF serializers are slow
      - bkovacev 2y ago
        Old is a harsh word, maybe mature would be a better fit, not everything new and shiny is gold, and yet not everything old sucks. Not arguing here about types and Pydantic being faster than the built in ModelSerializers. However, for serializer speed improvements and performance in DRF I would advise dropping ModelSerializers and either going for Serializers or plain dict. Haki Benita has a beautiful article on that [0]. I was able to accomplish sub 200 response times on a fairly large response from tables that had tens of millions of records. I think you have no objective reason other than your styling and rather personal preference for function based views? [0] - https://hakibenita.com/django-rest-framework-slow https://hakibenita.com/django-rest-framework-slow
anentropic 2y ago
I've been working on a Django + Vite + HTMX + Alpine project for the past year or so Using django-htmx and django-vite libs (the latter forked to add Jinja support) Been pretty happy with it 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 Been using Jinja macros as 'components' which... works. The syntax is kinda ugly to read though, and haven't found any really great linter.
- andy800 2y ago
  Kotlin is an awesome back-end language with strong typing, tons of libraries and multiple HTTP frameworks (http4k, ktor, vert.x, many more) and templating options (jte is terrific, and fully typed). Guessing it's too late to switch now but worth checking out.
- mixmastamyk 2y ago
  > lack of type-safe templating in Python Try htpy. It moves templating into python where it can be linted/typed: https://htpy.dev/ https://htpy.dev/
  - anentropic 2y ago
    Yeah this is probably the way to go in future... The only thing putting me off currently is https://htpy.dev/faq/#how-does-htpy-performance-compare-to-django-or-jinja-templates https://htpy.dev/faq/#how-does-htpy-performance-compare-to-d... It would be awesome if Python community can get something with these ergonomics that also has performance of Jinja
    - mixmastamyk 2y ago
      I played with the benchmark and the extra delay was not significant, maybe 20ms for a substantial page? I profiled the code and did not find it doing anything particularly wrong. However it uses generators to build the page lazily from fragments at runtime, whereas jinja gets a boost from “compiling” them somehow. I believe one could prerender the static parts of the page and get most of the speed of jinja, but the improvement still won’t be noticeable unless the project is very performance sensitive.
sailfast 2y ago
I like this setup, but I had kinda thought "modern" javascript had mostly moved to server-side rendered at this point and I didn't see anything about that in the syllabus. Anyone know if this tutorial addresses that kind of thing? 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?
- omarspira 2y ago
  You can do essentially the same thing with Next or Nuxt.js With Next.js now it is very easy and elegant to load up data from your Django server in a React Server Component. You can also build entire static pages manually from the same API. Here is an excerpted example from the same simple template I posted in response to an earlier comment - https://github.com/ospira/docker-django-react-example/blob/main/react/src/app/page.tsx#L4-L6 https://github.com/ospira/docker-django-react-example/blob/m... If doing this as part of a production pipeline you would have to ensure some version of your Django API (hopefully the latest one) is present before deploying the Next.js app, so that the data is available for Next to do things like fully static pages.
jgord 2y ago
My opinionated view, based on the ancient katra of code practitioners - seek smaller code, fewer dependencies : When moving from PHP, better to ditch 'modern' 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. I live in hope that tomorrows code thought leaders choose vue.js over the byzantine-borg-machinery that is the modern react ecosystem. The good parts of Javascript [ which dont include prototype OOP ] make for a very productive language. The node.js ecosystem is incredible for getting stuff done, I just hope we dont kill it via forced 'modernization'. 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. 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/GPU ] While Im channeling my inner boomer, I have to say, hand on heart : callbacks are more elegant than async/await/promises/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?
openrisk 2y ago
The problem in this space is that a quarter of century(!) after Fielding's dissertation [1] we don't have a serious follow up on "Architectural Styles and the Design of Network-based Software Architectures". A blueprint of a class of well constrained designs that can optimized and adapted according to use case. 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. 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. [1] https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dis...
- skydhash 2y ago
  The solution is to design protocols, not software. MPD is a great example of networked software. You can select any client you like or develop one yourself. As long as you want to enforce restrictions on client, everything nice about networked software goes away.
adrianh 2y ago
Hi, I'm one of the creators of Django. For what it's worth, here's what I do for my product Soundslice (https://www.soundslice.com/ https://www.soundslice.com/). I've been working on it full-time for 12 years, so a lot of thought has gone into this. Soundslice is very complex in its front-end JavaScript. It has an entire sheet-music rendering engine, capable of "responsive" sheet music [1], plus an integrated audio/video player for music practice, a full-fledged sheet music/tab editor [2] and a ton more [3]. In short: we don't use any JS frameworks. It's just vanilla JS — and in this day and age, that is totally fine for building a quality product. We'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/DOM APIs (which are full-featured these days). Every web page on our site is served by Django — in other words, there's no single-page-app stuff. I've always found the idea of single-page apps to be "against the grain": it goes against how web browsers are optimized, and it goes against how HTTP/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). 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. The time-tested pattern of "serve the initial HTML (with Django or whatever), then add functionality with JavaScript" is solid and helps you build high-quality, maintainable websites. On a meta note: for years I've sat on the sidelines and rolled my eyes at the frontend JS world, knowing it doesn't affect me or my product. But I've come to realize all web developers — including those who don't choose to use frontend frameworks — do indeed have a vested interest in pushing back against the bullshit. That'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/buggy/non-standard, and the culture perpetuates (meaning it's harder to find developers who know "actual" JS instead of frameworks). [1] https://www.soundslice.com/help/en/player/basic/100/resizing-the-player/ https://www.soundslice.com/help/en/player/basic/100/resizing... [2] https://www.soundslice.com/notation-editor/ https://www.soundslice.com/notation-editor/ [3] https://www.soundslice.com/features/ https://www.soundslice.com/features/
- cynicalpeace 2y ago
  I basically agree with you, and I love developing a full stack via JS. Fortunately, with AI, coding with frameworks is a lot less necessary and even more of a hassle now.
mrweasel 2y ago
> A Crash Course in Modern JavaScript Tooling. Don't worry—it's not as bad as it sounds. Then proceeds to introduce the same confusing garbage JavaScript tooling that you find in all other modern JavaScript documentation. 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's what our internal framework uses). 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?
joshdavham 2y ago
Crazy that even this article is now dated. Many people have now moved on from webpack to vite.
deleted 2y ago
[deleted]
kerkeslager 2y ago
The best thing about Django is I don't have to write much Javascript. Introducing a whole JS build pipeline? I'm absolutely not doing that. The vanilla JS language is pretty capable these days. There are a few things that are still terrible, but if you're just writing a few lines here and there, they don't really bite you. I can just src a JS file I wrote and get everything I want from modern JS. What I don't 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.
sublinear 2y ago
Oh god not another plug for htmx
- recursivedoubts 2y ago
  Oh yeaaaaaaaaah

240 points by rob 2y ago

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

selecsosi 2y ago
Typed view model bindings to templates was always amazing and 100000x more ergonomic than WPF (in my experience). That being said with so many things going to client apps, I'm less inclined to go w/ server side rendering and treat my backend as a data API so I'm not stuck building that twice.
lowercased 2y ago
Is unicorn close? https://www.django-unicorn.com/ https://www.django-unicorn.com/ Wouldn't be WASM based either, but most of these types of tech aren't (yet?). I'm in the livewire camp with Laravel. I found a bit discussion of a webassembly version of livewire, but I don't think it's on the cards any time soon.
leetharris 2y ago
Laravel has something like this called Livewire. It's excellent. Laravel is so much better than Django, but I just can't go back to PHP at this point. https://livewire.laravel.com/ https://livewire.laravel.com/
- pier25 2y ago
  > I just can't go back to PHP at this point Same. During 2024 I evaluated multiple backend platforms/frameworks to get away from Node. Laravel is great and modern PHP (the language) is also surprisingly good but betting on PHP feels like betting on coal and the steam engine. The runtime and execution model are extremely outdated and resource hungry. There are some efforts like FrankenPHP and Swole that package a PHP app to have a persistent execution model. But IMO unless PHP officially adopts this model this will always feel like a hack to me.
  - rob 2y ago
    What did you end up going with if not PHP/Laravel?
    - pier25 2y ago
      Dotnet for backend and SvelteKit for frontend.
  - cjohnson318 2y ago
    I'm not sure why this has been downvoted so much, this guy states something that might upset some people, but then goes on to provide a pretty sober list pros and cons. This is the kind of content that we want to encourage on HN.
    - gjsman-1000 2y ago
      It’s downvoted because even if PHP has hacky behavior; he’s running with the assumption other frameworks don’t have their own hacky behavior, or other frameworks are worse. This is not necessarily warranted. Modern PHP is faster than Ruby in many benchmarks; and Rails is still running GitHub and Shopify. Square uses Laravel in a backend serving 100M+ requests per day, with no plans to rewrite. To compare it to a Steam engine and Coal; that’s unfair stereotyping. On that note, JavaScript’s amount of churn could be an entire discussion by itself. I’ll take some quirky behavior that just keeps working over mindless churn any day.
  - morbicer 2y ago
- lawn 2y ago
  And Phoenix/Elixir has LiveView, also excellent.
- adamrt 2y ago
  I've heard people complain about Django many time on HN. I started using it back in the 0.96 version, so maybe its just a familiarity thing. But I built 3 large successful applications in it in that time. I loved it. I don't use it regularly anymore since I mostly moved away from webdev, but I recently came back into contact with my largest project I build in 2018/2019 and its been running perfect this whole time and was a pleasure to dive back into. Django just felt logically organized, documentation was on point, core was very readable (at least then). I always just felt so productive in it. I know everyone has different opinions, experiences and products they are building, but I'm always surprised with the negative comments. I definitely prefer SSR with its reasonable though, so maybe thats part of it.
  - oooyay 2y ago
    Most of the complaints I've read about Django on HN have to do with ASGI support - which Django added. They're valid but outdated complaints.
    - airstrike 2y ago
      ASGI support for Django landed in 2019. Those comments are very outdated https://docs.djangoproject.com/en/5.1/releases/3.0/#asgi-support https://docs.djangoproject.com/en/5.1/releases/3.0/#asgi-sup...
      - black3r 2y ago
        tbf it was borderline unusable until they added async DB query support in 4.1 (2022) - before that you had to wrap every DB query with sync_to_async, async_to_sync and it generated too much boilerplate code..., and even in 4.1 the DB queries themselves were still sync/blocking, not truly async because at that point they didn't yet rewrite their database "backends" to use async querying, and I believe that as of now the Django's DB engine still doesn't support natively async DB queries/cursors/transactions/... Also, lots of the "batteries included" into Django don't have async interfaces yet.., for example the default auth/permission system will get async functions like acreate_user, aauthenticate, ahas_perm only in 5.2 which is expected in April 2025, so as of now these still have to be wrapped in sync_to_async wrappers to work...
- nop_slide 2y ago
  I thought the same. I evaluated the "big 3" (Laravel, Django, Rails) last year and decided to go all in on Rails for solo side web projects. Was really wanting to like Django since I'm a python dev for my day job, but it didn't have nearly the amount of DX and tools baked in as Laravel/Rails. Rails has been super fun, I hadn't touched it in 10 years and the additions that versions 7/8 have brought are awesome.
- 7bit 2y ago
  I tried Latavel, but there were some points that made me want to drop it very fast. I work on Windows and I chose a PHP variant (don't remember, maybe one that supports threads or async) that did not work on Windows very well. Starting up a Latavel server took minutes. Took me hours to finally find that the PHP binary itself was the root cause. It should not be that way. Then installing Compose on Windows was horrible. I believe I had to install PHP and compose in C:\php or it just would not work. The compose "installer" did a bunch of stuff to my Windows which I did not want. Installing it manually was a pain in the ass. All in all, the experience was exactly the same as in the 2000's (horrible). After I setup my first Latavel project and had some question, it was really difficult to get answers. The docs are really good, but also fragmented as hell with all the approaches one could take to rendering content, depending on what you choose and how you approach it. The forums - although big - seemed dead when I stated my question. I don't know man, my experience with Django is so much better.
  - graemep 2y ago
    You are not likely to deploy it to Windows in production, so develop on Windows? Does WSL not solve this problem? Or a VM of any sort?
    - 7bit 2y ago
      I could solve these issues with the suggestions you made, but why? I can develop stuff in many languages directly in Windows just fine, and I frankly am not willing to jump through hoops so I can do the same stuff with PHP -- that I can conveniently with Python, JS, dotnet, Java, Elixir, Rust, C/C++ and many other languages. I never found anything so complex and buggy as PHP.
      - graemep 2y ago
        Certainly if you do not like PHP. However, if you wanted to use it there is no real reason not to. My usage of PHP has been using software written by other people but customising - and there is a lot of useful stiff written in PHP. I prefer Python if doing something from scratch, but I would rather write a small amount of PHP to add a bit of functionality rather than write 10× the amount of Python because I need to write everything from scratch.
neonsunset 2y ago
If you liked Blazor (and it's interesting to hear perspective of someone "outside" the .NET bubble), is there a reason to prefer Python and Django?
- giancarlostoro 2y ago
  I feel like I can build web apps drastically faster in Python than with C#. I find myself writing a lot less boilerplate and things, even when using a full stack framework like Django.
runekaagaard 2y ago
We've rolled our own liveview and have happily used it in production for several years now: https://hypergen.it/ https://hypergen.it/
- giancarlostoro 2y ago
  Oooh I am working on a brand new Django based project, thanks for this!

grajaganDev 2y ago

Excellent article - thank you for posting.

yoyohello13 2y ago

BTW, this guy's Django templates are really good.

0xblinq 2y ago

Check out https://inertiajs.com/ https://inertiajs.com/. I've never used it with Django (there's an adapter here https://github.com/inertiajs/inertia-django https://github.com/inertiajs/inertia-django) but I did use it a lot with AdonisJS and Rails. It's wonderful. The best of both worlds. TL;DR you can use React/Vue as your "template" 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...

DangitBobby 2y ago
I eventually came to regret using Inertia and just wished we had used e.g. django-rest-framework and React Router. React Router is excellent. I feel pretty much the same way you do about Next.js, though.
- 0xblinq 2y ago
  I have the exact opposite experience, but context is everything here I guess. > React Router is excellent. When you compare it to Next, etc... yes, I agree. The issue I have is the constant change of mind their devs have regarding how to do things, even when they say "it's stable"... it's not... every day they come up with "a better way" to do things which usually is not better, just different. But using it when you already have django/rails/laravel/adonis means you have to do a ton more work and reinvent a lot of things (such as authentication, validation, etc). Care to extend on what problems you found or what you didn't like about inertia?
  - DangitBobby 2y ago
    For me personally, the lack of hot-reloading is painful for portions of the app where it takes you a few steps to get to the UI state you are working on (e.g. rendering a model with tabs). Having to add custom code to for flash, their special form handling, and other Inertia specific parterns that only I really understood made it difficult for some collaborators. I don't remember the specific of the form handling either but from what I remember it would have been difficult to instrument client-side validation such as react-hook-form as well. > The issue I have is the constant change of mind their devs have regarding how to do things, even when they say "it's stable"... it's not... every day they come up with "a better way" to do things which usually is not better, just different. It is annoying. They are pushing people towards Remix as well, which I have tried and prefer to avoid unless I absolutely must have SSR. But their docs for older versions are still around so you can stick to what you like.

cdfuller 2y ago

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?

czue 2y ago
Author here. I would say the core principles still hold up well, though the tooling and libraries are constantly evolving. An incomplete list of things I'd add / change today (and are on my roadmap to cover in more detail): I would probably recommend Vite over Webpack as the main bundler/builder, as it's faster and rapidly taking over as the default tool to solve the same use cases. The other gap that is missing is a treatment of the "nobuild" options that exist today. Essentially things like ES modules and import maps and other stuff that lets you (if you want) run a lot of modern JavaScript libraries with zero toolchain directly in the browser. I'd also want to revisit the fully decoupled approach a bit more. With the advent of LLM-based tools that can generate complete front ends for you, as well as libraries like shadcn, there is a larger upside to adopting the complexity of the decoupled API set up, even if it definitely still is slower and more painful for anything that touches the backend. Django ninja has been gaining traction against DRF as an API library and the developer experience and performance are definitely better, though DRF still has way more batteries in terms of 3rd party library support for various use case. The Django + HTMX + Alpine stack has only gotten more widely adopted since I published Part 5, and I'd say that part has held up quite well in the "low to no JavaScript" ecosystem for Django, and is the default choice for many Django devs now.
- bkovacev 2y ago
  Can you explain further on the performance aspect of Django Ninja vs DRF?
  - e-brake 2y ago
    It is built to fully support asynchronous endpoints, and uses pydantic models for validation and parsing - lightweight and nicely fast
- 2y ago

chis 2y ago

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/django backend. The traditional split of a flask API and a react frontend consuming it, just feels like overkill. 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.

morbicer 2y ago
I don't understand the second sentence. As someone developing web apps for over 20 years, components ARE the better code organization.
- fmnxl 2y ago
  Well there's a cost to that abstraction, e.g. you'd have to pass the context into the component, so every time you need to modify the component's schema/props you'd need to change it twice, both in the parent and the component. You must have seen some huge React components with 20 different props or even more, and you'd need to think about memoizing those props to prevent a re-render, etc etc. I've also been a web dev for over 20 years, and 10 years with React. I'd say that going back to native HTML APIs for handling stateful things like forms and form validation is a breeze, rather than writing components and endless abstractions. It's enough for the vast majority of the time.
  - morbicer 2y ago
    Those are just shitty codebases. I maintain a React app that's over 10 years old, almost milion lines of code and we have zero components with 20 props, no issues with performance or whatnot. I am an oponent of over-abstraction but components are very light abstraction and provide just sensible encapsulation and reusability.
    - fmnxl 2y ago
      Show me this amazing site of yours. With that amount of talent maybe you should go over to Next.js and solve their RSC issues.

fmnxl 2y ago

Having used HTMX and Unpoly with Django, for over 2 years now, I prefer using Unpoly more these days. 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. It covers 95% of the use-cases of a typical web app, with its layers and forms concepts. E.g. I love creating "subinteractions" with unpoly, where a complex process can be divided into smaller modal forms for creating the "related" 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.

JodieBenitez 2y ago
Same here... Unpoly is a perfect match for Django.
SCUSKU 2y ago
The one thing I couldn't get past when looking into Unpoly is that if you're in a deeply nested modal/layer, and then refresh the page, it just shows you the most recent modal as a full page. My expectation is that when you refresh, instead it would keep you on the base page, and then wipe all the modals.
- spapas82 2y ago
  Unpoly by default changes the browser's history to the url of the modal. Thus when your refresh you'll get exactly that. You can modify that behavior with up-history, see here https://unpoly.com/history-in-overlays https://unpoly.com/history-in-overlays
- fmnxl 2y ago
  You can set up-history="false" and there'd be no navigation when opening the modal, so when you refresh the page it'd refresh the parent layer not the modal. What's more arguable I think is how pressing the browser Back button doesn't preserve the layers, but opens the previous page as a full page. I think that can be changed in a config somewhere, though.
spapas82 2y ago

mlamina 2y ago

Cory, your content is killing it :D

nilsbunger 2y ago

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

bkovacev 2y ago
What seems to differentiate django-ninja over Flask or FastAPI or any Starlette derivative? You mention lightweight as well, can you expand further?
- nprateem 2y ago
  Ninja lets you use django. There's less config vs DRF
  - bkovacev 2y ago
    Aside from the obvious that ninja let's you use django.
    - WD-42 2y ago
      The ability to use django is the main attractor. The other frameworks are great but make you reinvent Django if you require auth, orm, admin, etc
      - globular-toast 2y ago
        Oh but you wouldn't reinvent Django, you'd build a properly architected, simple system.
        WD-42 2y ago

jilles 2y ago

I don't think Alpine.js and HTMX qualify as "Modern JavaScript". There is an approach that is rarely talked about: render templates in Django and hydrate using your favorite JavaScript framework. For example the Django template renders a <template id="abc"><button disabled>open modal!</button></template>. Then your JavaScript bundle can "hydrate". For example ReactDOM.render(<OpenModalButton />, '#abc''). You just have to be diligent to make sure that the template and your front-end have somewhat similar markup to not have layout shift. It's really not that hard and works for a lot of use-cases. 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/hydrate using whatever front-end framework. I built a Django app with very little JavaScript and only using HTMX and it was... alright. It works. I can say "no fancy build step!" but I totally miss the testability of modern frontend. Creating an image upload component was a pain. I don't think I would use HTMX again and instead go for the hybrid approach I described earlier.

azemetre 2y ago
Why wouldn't Alpine.js and HTMX be modern javascript? They're both written with modern javascript. React was created in 2013, Alpine in 2020, HTMX 2020. React is the elder of the bunch. React is the bloated tool nowadays.
- drdaeman 2y ago
  Personally, I don't think the term "modern JavaScript" makes much sense - it's just a nice-sounding but mostly meaningless buzzword, but I can guess the reason about the disagreement. Alpine and HTMX are entirely different architectural approach to script webpages, as compared to React/Vue/Svelte/Elm/... approach to build SPA webapps. And the latter approach was very frequently called "modern JavaScript" (and that's why I think it's more of a buzzword now, and less of an actually meaningful term).
  - riskable 2y ago
    "Modern JavaScript" === "Whatever just came out in the past week to six months and has had several articles written about it on the front page of Hacker News"

singhrac 2y ago

I've tried several boilerplates like SaaSPegasus and one thing I can'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? I feel like I'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. If anyone sees this and has a minimal open source boilerplate to recommend I'd love to try it.

tubs 2y ago
Why do you need docker to run esbuild? It’s a static binary.
- qwertox 2y ago
  Not everyone is aware of this fact. I include myself in the list of those who didn't know that. Most likely because I didn't bother to inform myself because my expectation of the JavaScript ecosystem is that you first need to install npm via node, and then have it pull a huge amount of files just to then have a tool with which you can bundle stuff without then understanding where you need to "install" it. It's a chaotic ecosystem, much worse than Python, and I know and love Python. ``` Major features: - Extreme speed without needing a cache - JavaScript, CSS, TypeScript, and JSX built-in - A straightforward API for CLI, JS, and Go - Bundles ESM and CommonJS modules - Bundles CSS including CSS modules - Tree shaking, minification, and source maps - Local server, watch mode, and plugins ``` No word of it being a single executable, on the landing page, in the "major features"-list. `npm install --save-exact --save-dev esbuild`. We have different expectations on how to download a binary. Edit: I found an instruction on how to get the binary [0], why is this so hidden? [0] https://esbuild.github.io/getting-started/#download-a-build https://esbuild.github.io/getting-started/#download-a-build
  - xdennis 2y ago
    Nothing is perfect but it's ridiculous to say Node is more chaotic than Python. What's the Python package manager of the month? uv? poetry? pipenv? conda? pip? pyenv? setuptools? virtualenv? venv? pdm? easy_install? pymgr? mamba? Some only create environments, some only install, some don't even resolve packages, some don't create lock files, some only install python, AND NONE OF THEM agree where to install! Where does npm install? node_modules and it's been that way from the start. *I added a fake one to see if people can spot it.

deleted 2y ago

[deleted]

cwales95 2y ago

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 / XSS safety benefits but I'd love to see how others tackle a fully decoupled Django stack e.g. oAuth, JWTs and how they do their CSRF / XSS security. It's an area I need to learn more about.

lastofus 2y ago
Decoupled Django usually means that you are providing a client SPA with a API, such as a DRF powered REST API. If you are using something like token auth (you mentioned JWT), then you are not using cookies, at which point CSRF is not needed. This is because the user's browser isn't automatically sending the cooking containing a session ID on every request to the server. That said, you can implement session auth with DRF REST APIs, which accept a session cookie on requests. For this, I believe you would receive/send CSRF tokens via HTTP headers. XSS is not something you would worry too much about in an API endpoint. It is something you should worry a lot about in your client side SPA though. If using something like React, your templates will be auto-escaped, and thus you have to go out of your way to make it a problem.
- cwales95 2y ago
  Where I get confused is storing the tokens securely. There's a lot of conflicting information online. I've come across many examples where they suggest localStorage which is a horrible idea. A lot of the advice I see now is about http-only cookies but I think I'd probably look more into oAuth in the future.
  - skuxxlife 2y ago
    The current best practice is to keep the token in memory only and store a refresh token in an HTTP-only cookie. In my experience though, if you’re only doing web-based auth and don’t _need_ to use JWTs for a specific reason, just use regular session cookies, it’s way less hassle. Coordinating auth and refresh state across page refreshes and tabs is a pain, and using a refresh token means you’re using cookies and saved session state anyway, so you lose pretty much all of the unique benefits of using JWTs and still have all the downsides.

ggregoire 2y ago

I'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). [1] https://www.django-rest-framework.org https://www.django-rest-framework.org

ryannevius 2y ago
We use Django and django-ninja [1] and like it MUCH better than DRF. [1] https://django-ninja.dev https://django-ninja.dev
- bkovacev 2y ago
  Care to elaborate further? I keep reading on this, but no one actually mentions anything specific that ninja does better than DRF.
  - anentropic 2y ago
    I haven't used django-ninja but to me it looks like the API is a bit nicer or more 'modern' looking (i.e. declarative via type annotations) and it's faster, both due to being based on Pydantic DRF is old and API looks more like Django forms or class-based views, more of an OOP hierarchy going on, and DRF serializers are slow
    - bkovacev 2y ago
      Old is a harsh word, maybe mature would be a better fit, not everything new and shiny is gold, and yet not everything old sucks. Not arguing here about types and Pydantic being faster than the built in ModelSerializers. However, for serializer speed improvements and performance in DRF I would advise dropping ModelSerializers and either going for Serializers or plain dict. Haki Benita has a beautiful article on that [0]. I was able to accomplish sub 200 response times on a fairly large response from tables that had tens of millions of records. I think you have no objective reason other than your styling and rather personal preference for function based views? [0] - https://hakibenita.com/django-rest-framework-slow https://hakibenita.com/django-rest-framework-slow

anentropic 2y ago

I've been working on a Django + Vite + HTMX + Alpine project for the past year or so Using django-htmx and django-vite libs (the latter forked to add Jinja support) Been pretty happy with it 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 Been using Jinja macros as 'components' which... works. The syntax is kinda ugly to read though, and haven't found any really great linter.

andy800 2y ago
Kotlin is an awesome back-end language with strong typing, tons of libraries and multiple HTTP frameworks (http4k, ktor, vert.x, many more) and templating options (jte is terrific, and fully typed). Guessing it's too late to switch now but worth checking out.
mixmastamyk 2y ago
> lack of type-safe templating in Python Try htpy. It moves templating into python where it can be linted/typed: https://htpy.dev/ https://htpy.dev/
- anentropic 2y ago
  Yeah this is probably the way to go in future... The only thing putting me off currently is https://htpy.dev/faq/#how-does-htpy-performance-compare-to-django-or-jinja-templates https://htpy.dev/faq/#how-does-htpy-performance-compare-to-d... It would be awesome if Python community can get something with these ergonomics that also has performance of Jinja
  - mixmastamyk 2y ago
    I played with the benchmark and the extra delay was not significant, maybe 20ms for a substantial page? I profiled the code and did not find it doing anything particularly wrong. However it uses generators to build the page lazily from fragments at runtime, whereas jinja gets a boost from “compiling” them somehow. I believe one could prerender the static parts of the page and get most of the speed of jinja, but the improvement still won’t be noticeable unless the project is very performance sensitive.

sailfast 2y ago

I like this setup, but I had kinda thought "modern" javascript had mostly moved to server-side rendered at this point and I didn't see anything about that in the syllabus. Anyone know if this tutorial addresses that kind of thing? 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?

omarspira 2y ago
You can do essentially the same thing with Next or Nuxt.js With Next.js now it is very easy and elegant to load up data from your Django server in a React Server Component. You can also build entire static pages manually from the same API. Here is an excerpted example from the same simple template I posted in response to an earlier comment - https://github.com/ospira/docker-django-react-example/blob/main/react/src/app/page.tsx#L4-L6 https://github.com/ospira/docker-django-react-example/blob/m... If doing this as part of a production pipeline you would have to ensure some version of your Django API (hopefully the latest one) is present before deploying the Next.js app, so that the data is available for Next to do things like fully static pages.

jgord 2y ago

My opinionated view, based on the ancient katra of code practitioners - seek smaller code, fewer dependencies : When moving from PHP, better to ditch 'modern' 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. I live in hope that tomorrows code thought leaders choose vue.js over the byzantine-borg-machinery that is the modern react ecosystem. The good parts of Javascript [ which dont include prototype OOP ] make for a very productive language. The node.js ecosystem is incredible for getting stuff done, I just hope we dont kill it via forced 'modernization'. 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. 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/GPU ] While Im channeling my inner boomer, I have to say, hand on heart : callbacks are more elegant than async/await/promises/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?

openrisk 2y ago

The problem in this space is that a quarter of century(!) after Fielding's dissertation [1] we don't have a serious follow up on "Architectural Styles and the Design of Network-based Software Architectures". A blueprint of a class of well constrained designs that can optimized and adapted according to use case. 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. 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. [1] https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf https://ics.uci.edu/~fielding/pubs/dissertation/fielding_dis...

skydhash 2y ago
The solution is to design protocols, not software. MPD is a great example of networked software. You can select any client you like or develop one yourself. As long as you want to enforce restrictions on client, everything nice about networked software goes away.

adrianh 2y ago

Hi, I'm one of the creators of Django. For what it's worth, here's what I do for my product Soundslice (https://www.soundslice.com/ https://www.soundslice.com/). I've been working on it full-time for 12 years, so a lot of thought has gone into this. Soundslice is very complex in its front-end JavaScript. It has an entire sheet-music rendering engine, capable of "responsive" sheet music [1], plus an integrated audio/video player for music practice, a full-fledged sheet music/tab editor [2] and a ton more [3]. In short: we don't use any JS frameworks. It's just vanilla JS — and in this day and age, that is totally fine for building a quality product. We'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/DOM APIs (which are full-featured these days). Every web page on our site is served by Django — in other words, there's no single-page-app stuff. I've always found the idea of single-page apps to be "against the grain": it goes against how web browsers are optimized, and it goes against how HTTP/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). 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. The time-tested pattern of "serve the initial HTML (with Django or whatever), then add functionality with JavaScript" is solid and helps you build high-quality, maintainable websites. On a meta note: for years I've sat on the sidelines and rolled my eyes at the frontend JS world, knowing it doesn't affect me or my product. But I've come to realize all web developers — including those who don't choose to use frontend frameworks — do indeed have a vested interest in pushing back against the bullshit. That'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/buggy/non-standard, and the culture perpetuates (meaning it's harder to find developers who know "actual" JS instead of frameworks). [1] https://www.soundslice.com/help/en/player/basic/100/resizing-the-player/ https://www.soundslice.com/help/en/player/basic/100/resizing... [2] https://www.soundslice.com/notation-editor/ https://www.soundslice.com/notation-editor/ [3] https://www.soundslice.com/features/ https://www.soundslice.com/features/

cynicalpeace 2y ago
I basically agree with you, and I love developing a full stack via JS. Fortunately, with AI, coding with frameworks is a lot less necessary and even more of a hassle now.

mrweasel 2y ago

> A Crash Course in Modern JavaScript Tooling. Don't worry—it's not as bad as it sounds. Then proceeds to introduce the same confusing garbage JavaScript tooling that you find in all other modern JavaScript documentation. 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's what our internal framework uses). 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?

joshdavham 2y ago

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

deleted 2y ago

[deleted]

kerkeslager 2y ago

The best thing about Django is I don't have to write much Javascript. Introducing a whole JS build pipeline? I'm absolutely not doing that. The vanilla JS language is pretty capable these days. There are a few things that are still terrible, but if you're just writing a few lines here and there, they don't really bite you. I can just src a JS file I wrote and get everything I want from modern JS. What I don't 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.

sublinear 2y ago

Oh god not another plug for htmx

recursivedoubts 2y ago
Oh yeaaaaaaaaah