[jilles]

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]

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]

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]

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

[andy800]

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/

[azemetre]

That's poppycock. A library that doesn't require several dozen unrelated libraries to use is a good thing and something we should actually hold up as good engineering.

I'm also confident that recursivedoubts wouldn't like you calling his library not modern. That's just insulting.

[andy800]

As a CEO of HTMX, I'm qualified to say that recursivedoubts is best described as a grug-brained developer.

https://grugbrain.dev/

[harrall]

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.

[evantbyrne]

I can't speak for HTMX specifically, but going to progressively enhanced server-rendered HTML from React requires a certain amount of mental deprogramming. I've been using Turbo lately for side projects (e.g., Pocket SQL) and found it involves working much more closely with browser APIs, but also writing way less UI code. Pocket SQL required writing about 50 lines of JS and people probably wouldn't notice that it's not a SPA unless they looked under the hood.

[andy800]

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.

[dimgl]

I was doing with this Knockout back when I was using ASP.NET MVC! I'm surprised it's not a more common pattern.

[rob]

That's "Part 4" I believe:

https://www.saaspegasus.com/guides/modern-javascript-for-dja...

[65]

Wouldn't this throw hydration errors if your SSR HTML does not exactly match your client side HTML?

[dimgl]

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.