Modern JavaScript for Django developers

> I agree with you on Django Ninja, so refreshingly simple compared to DRF. I think Django core needs to adopt something like it.

I was going to ask about this with respect to DRF, but you answered it. I am re-learning Django after having been away from it and Python for ~4 years now, and my previous experience was with DRF in a somewhat toxic group so I had less than ideal feelings about it. I know PTSD is a real thing and I don't mean to sound glib about it, but I think I actually had the beginnings of it from that experience.

So you’re living out the trope of reinventing Django but lower quality :-)

Maybe ask around about SQLModel. It sounds like the perfect solution, but I’ve never encountered someone that used it and didn’t have the opinion that it isn’t ready for production.

Ninja lets you use django. There's less config vs DRF

All the different configuration you need for Webpack is built-in to Vite. This includes built-in support for a lot of stuff that would come as separate plugins in Webpack (CSS loading, Typescript support, asset bundling, minification, autoprefix/browserslist-based downleveling, env replacement, etc). But more importantly, it includes fairly optimal configuration.

There's usually an optimal way to bundle your code, and one of the issues with Webpack was that finding that optimal way through a maze of documentation and third-party plugins. Vite does that work for you, because it's mostly a solved problem and it's not that hard. For example, rather than having a number of different CSS plugins that you need to enable and disable in different configurations — just use Vite, which will do hot-reloading of CSS in development and link to the CSS files as external files in production.

In my experience, there are typically two types of Webpack configurations: fairly basic ones that include some essentials but are fairly unoptimised (either while developing or in production), or complex ones that include everything but are brittle and painful to update. Vite gives you the power and optimisation of the latter with the configuration ease of the former.

Also, to be clear, I'm not trying to hype Vite up. There are other similar tools out there, and Vite isn't even the first tool to work like this — Parcel is older and also pretty good at doing zero/minimal-config builds that work how you expect out-of-the-box. Any of these tools are good, although Vite seems to be the most popular right now and so has the most support/documentation/information. But I would generally encourage any project using Webpack to migrate away from that where possible (and where time allows), because these low-config tools are such a timesaver in the long-run.

You must work on small projects or use top tier hardware exclusively because the development startup time of vite vs webpack is simply not comparable. The project I spend most of my time on maintained both build systems for a couple of years, and I used them interchangeably: under Webpack, the development build loaded in about two minutes (sometimes more), vite takes 3-5 seconds. Webpack configs have since been removed.

I also agree with everything MrJohz said about zero (or close to zero) configuration required to use vite.

Isn't Vite faster and less complex? That's my impression.

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

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.

Btw, two addendums:

1. I fixed some things in that repo, now it should work out of the box. Apologies if the initial version had some bugs, was taking it out of another project, and the first effort at cleaning it up was too hasty. Note it is still however just meant as an example.

2. You actually can run more than one container per window - see here https://code.visualstudio.com/remote/advancedcontainers/conn.... However, I opted for the double window method because I found that cleaner than toggling between in one window. In my template I assume the two windows method because it will load up the proper subfolder (django or react) of the workspace/monorepo depending on which dev container you connect to.

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

That’s a good question since usually these are built into the docker-compose by default. I think my answer would be that it’s to get the same build environment on my Mac as on prod (i.e. a Linux server), but in practice I don’t think platform-specific details matter.

If that’s the case, why not run Python/gunicorn locally as well, and drop docker entirely?

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.

> 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.

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.

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.

And Phoenix/Elixir has LiveView, also excellent.

Oooh I am working on a brand new Django based project, thanks for this!

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.

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.

It's outlined in the linked series here: https://www.saaspegasus.com/guides/modern-javascript-for-dja...

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).

Somewhat pedantic - Using HTMX represents a modern approach to building a web front-end. However, I'm confident that recursivedoubts (creator of HTMX) would agree HTMX is not itself written in modern Javascript. No Typescript, no modules, no functional programming, no async, etc.

https://htmx.org/essays/no-build-step/

Things aren’t that rigid. React is just a template library (it doesn’t have any franework stuff at all). You don't have to make an SPA with it.

In 2015 we were doing

$('[data-widget="colorpicker"]').each(() => ReactDOM.render(<ColorPicker />));

Basically what HTMX is trying to do but with jQuery + React. No SPA. Just static pages with dynamic elements.

This is often why people get frustrated switching HTMX for the first time. The idea isn't to "translate" the code, but to completely rethink concepts like state and pages and things like components. Not everyone is able to conceptualize their application outside the boundaries of a specific framework.

This implies that "hydration" exists exactly how it exists today in SSR. That's not the only way to hydrate a frontend client.

You could, for instance, as part of a server payload send back a JavaScript object full of state and the frontend will read from it and render accordingly. But that would require not using a framework and building it yourself, which I think developers nowadays aren't keen on doing.

[dead]

Care to elaborate further? I keep reading on this, but no one actually mentions anything specific that ninja does better than DRF.

I used to make my APIs with Starlette/FastAPI, didn't know it was the same author!

Nowadays I just use PostgREST for all my new APIs. It's a phenomenal piece of software, save me so much time.

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?

Well, something I do like about Inertia is that it's not tied to any specific framework, neither backend nor frontend ones. That's a big advantage in my opinion.