Curious at why are you using DRF with HTMX; isn't DRF more common when you need to return JSON for example and render in the frontend? Wouldn't returning Django templates to use with HTMX be the best option? Or is it for POST requests?

I still have some API things and I like the router and serializers.

Does the server renderer call the API routes via HTTP, or does it have a more direct path to fetching the same data? If so, what interface does it use - loopback or the public address of the server?

In my experience this distinction has been a source of complexity in server-rendered apps that consume the same API as the client but at a different address, leading to problems like untrusted self-signed certificates, mismatching hostnames, and leaky proxy routes.

Or perhaps none of your server rendered pages even call the API directly, and you just expose it for other clients?

Web isn’t the only interface. DRF might also serve REST API to mobile or webhooks etc.

HTMX can be used with templates and JSON with extensions.

But HTMX is a JS library. Anything done with it is basically done with JS.

I'd say it's not about what can be done, it's about how it's defined. HTMX is a abstraction layer on top of an existing abstractions that you still have to know, because it's defined in terms of those abstractions.

So when you write something like `hx-trigger="click" hx-put="/api/my"` you're actually actively thinking of an `addEventListener("click", ...)`, `this.innerHTML` assignment and `fetch("/api/my", { method: "PUT" }))`. Can't use HTMX without knowing the underlying principles and primitives.

And then you still have to do JS because how else you're supposed to handle `htmx:responseError` and stuff. And maybe I'm wrong but it feels risky because the logic could end up all around the place and not in a single nice function/code block.

So, basically, it's a nice DSL providing a bunch of shortcuts, but it doesn't magically alleviate knowing any underlying principles and nuances of JS and DOM. Again, it's even defined in terms of those systems (`hx-swap="outerHTML"` being a very clear indicator example).

Kernel is done with C. Everything is basically done with C. Even JavaScript.

It's all binary at the end of the day.

It’s all just energy moving around

On sand.

And those turtles that go all the way down lay their eggs in that sand.

That doesn't address the implications of something only working with JS at all.

The most popular JavaScript engine (V8) is written mostly in C++. Same with WebKit. Other JS engines are written in Rust, like Deno or Servo (used in parts of Firefox).

I'm not aware of a major Javascript engine which is written in C, except for QuickJS, which is not "major" in any sense of popularity but is an efficient engine for embedded use cases (and anything from Fabrice Bellard is always work a look).

I suppose C++ is written in C. In similar relationships like Typescript and Javascript.

Not really, no.

The point you're missing here is that if you use HTMX, you often don't need to write any JS. You just write HTML with some special tags, and the library handles everything for you.

Spoiler warning: it doesn't.

Unless you only consider the happiest path, as in "I develop on localhost with zero latency, 100% uptime, and my backend validation logic perfectly matches my frontend policies" (and probably a lot more other "if"s and "only"s).

this is an interesting comment. so it has been sold to me like that. Could you talk about where it fails.

alpinejs does make the claim that it is a "better jquery". What is the development experience here?

especially for backend teams (python, java, whatever) who are now also building HTMX.

> Could you talk about where it fails

If the HTTP request that htmx has made returns a status code >= 400 or times out then the response will not be swapped into the body.

There are several events that htmx fires, once of which can catch `responseError` [1] and you can write some Javascript to handle it according to your requirements (throw a toast, swap anyway by setting `evt.detail.shouldSwap = true`.

In a project I'm working on we use htmx to load the content for modals, so we have small handlers on htmx events to display the modal whilst the request is being made, put a spinner indicator in the modal body to show the user something is happening and then swap the body in once the request has completed.

We've also used `HX-Trigger` response header [2] which htmx helpfully catches and allows us to easily hook onto, we've got ones to display a toast notification, hide open modals, refresh content divs, untick bulk action checkboxes, etc.

All in, our project probably has around 200 lines of Javascript for the different event handlers we do, so it doesn't eliminate the need to write any JS, but it's significantly reduced and is pretty much all event handlers.

1 - https://htmx.org/events/#htmx:responseError

2 - https://htmx.org/headers/hx-trigger/

this was super duper useful!

so would you say that one of the first things a htmx based project should do is handle all the error conditions ? like all the 40x and 50x ? and stuff like your modal thinggy ?

how do you develop the js here ? do you setup a different nodejs/npmjs toolchain. or do the jqueryish development of edit->browser reload ?

> so would you say that one of the first things a htmx based project should do is handle all the error conditions ? like all the 40x and 50x ? and stuff like your modal thinggy ?

IMO yeah, but different pages and actions will (probably) want different things. For example clicking a button that makes a POST request may make more sense to have a red toast notification if it fails, however a tab that dynamically loads its content in using htmx might want a dummy placeholder saying "Sorry, try again later" or something like that. Functionality around the modals were done as and when we needed them and then expanded on over time so I don't think you need to write/know everything up front. It's honestly been a joy to use based on how simple it is once embrace server side rendering.

> how do you develop the js here ? do you setup a different nodejs/npmjs toolchain. or do the jqueryish development of edit->browser reload ?

For my projects it's just 1 or 2 JS files that are included in my base template that contain the event handlers, so it's quite old school of edit and refresh. I use Django mostly now so I can use that to collect and minify static files so it's low effort/complexity.

The only down side is for the few JS packages I do need (e.g. Select2 for nice dropdowns) I either vendor the package in (no automatic updates) or use NPM (but it's a pain). Again, depends on what you want because htmx doesn't care either way.

+100 for alpinejs.

Alpinejs is indeed the successor to Jquery.

React forces you to think like how its designers view the world.

While alpinejs does not really interfere with your workflow. That's a huge sell for team like mine where we are working with legacy projects and devs of various levels of XP. We can get a jnr dev up and running in a week flat.

hey thanks for that. any particular opinions on hyperscript vs alpinejs ?

hyperscript is said to be "made for htmx". But alpinejs is generally more popular standalone. so im wondering about the choices here if we're starting a htmx project.

Sorry mate. Have not used hyperscript so any comparison from me would be less than objective.

Accessibility requires work with JavaScript.

What accessibility requires more than aria tags on your content?

It’s almost like htmx is a byte code target that you feed to the htmx JavaScript library. It’s easy to generate htmx markup with any backend language.

So instead of a backend language transpiling to JavaScript (like clojurescript), I can just generate htmx markup.

Well, I hope someday HTMX will be HTML6.

I am so tired of everyone complaining about complexity in front end frameworks, as if this sort of thing doesn't exist in other languages and stacks, and as if frontend dev isn't as complex as other domains. Just ignore them or do something else.

There is a reason we complain about front end frameworks. The fatigue is real. The npm and node_modules hell is real. The constant quirks with JS to make it work with our backend is real. I have been programming professionally for 18+ years and even though I can do anything, JS frameworks give me the most anxiety. Just this other day, something broke with an npm package and the error messages require me to hire a cryptography expert. I am half joking.

I am all in for something that keeps us on server side templates/HTML with dynamic capabilities.

I’m tired of everyone talking about the frontend as if it’s a monolith. In a world where web uses span all the way from a blog with a contact form to an entire app like Gmail it’s silly to pretend there’s only one answer.

I think we’re still suffering from “everything with React” syndrome, I’ve never used htmx but if it can help as an antidote I’m all in.

This is so true. I have two real hobbies - web dev and wood working. One thing that makes me chuckle is the different takes the communities have on tools. In the web dev people constantly argue about how there is one best tool!!! The wood workers make an art form out of collecting the most tools possible, because each tool has a job and the person who dies with the most tools wins.

(Edited for typos)

> as if this sort of thing doesn't exist in other languages and stacks

It doesn't.

For example in the Java world and in the last 10 years there were only two "frameworks". Just Spring and Oracle/Java EE

Now two more have appeared (Quarkus and Micronaut) bringing the total number of frameworks to 4.

Is the argument here that there are too many JS frameworks, or that the complexity of the frameworks themselves tends to grow over time?

If the former, totally agree. If the latter, Java frameworks are plenty complicated.

Also not sure how you've missed a lot of other frameworks; Spring and J2EE are certainly not the only ones that have been around for 10+ years. Dropwizard, Vert.x, akka-http, GWT, Play... just to name a few.

The argument is that I could learn Spring in 2002, find a Job then I could learn Spring in 2008 and find a job and then I could learn Spring in 2013 and find a job and then learn Spring in 2018 and find a job and then learn Spring in 2023 and find a job.

Spring IS complex, but you learn it once and you are done with it.

Or learn Cobol in 1965, find a job. Learn Cobol in 2022, find a job. Or Fortran - which I started using in 1983. Or C# (2000 for me)

I think the key distinction is that these languages and libraries evolve over time.

this is really useful if you know in advance which framework is going to stay around twenty years. If you invested in GWT...

I'm not a java man but a quick google leads to a lot of "10 java frameworks you should know", "17 popular java frameworks", and a "list of java frameworks" on Wikipedia that's dozens long.

Frontend wise it seems similar at a glance, in that you could use react for the last 10 years and be fine. Or you could jump from react to vue to svelte and make life hard for yourself.

I looked at some of the articles you mention and they are completely clueless

They include stuff like

- Hibernate - this is just an ORM

- JHipster - this is just opinionated Spring

- mybatis - again ORM

- Grails - > This is Groovy and not Java

- Play -> This is Scala primary

- Primefaces -> an implementation of Oracle/JavaEE

I think you get the idea. I am actually amazed at who is the target audience of this kind of blog posts.

Makes sense, probably just ad click driving spam page, appreciate the info :)

I wonder how much of people being burnout on "front end frameworks" is because of "17 must know javascript frameworks" articles akin to the JAVA stuff at the top of google.

Sure, if you ignore Dropwizard and tons of other less popular java frameworks out there.

Maybe I am missing something but Dropwizard is not a framework on its own but instead of collection of external and independently developed libraries

Maybe you are? Yes, it integrates existing frameworks and libraries. In fact, the home page says "Dropwizard is a Java framework for developing ops-friendly, high-performance, RESTful web services."

While I would love to argue whether DropWizard is a framework or not there is no need for that.

Just go to google trends and compare Spring and Dropwizard. Or look at https://www.jetbrains.com/lp/devecosystem-2021/java/. Dropwizard doesn't even appear in the list of web frameworks.

I mean, if you still believe that Java has as many frameworks as Javascript has (and had in the past) there is nothing I can say that will convince you.

I've been using Java on and off since 1996. It absolutely has had a ton of frameworks over the years. Yes, I realize many of them are niche or no longer in use, but that doesn't mean there isn't a legacy application where you have to maintain 10 or 20 year old garbage.

FYI, I despise both J2EE and Spring. (Maybe Spring Boot is okay.)

Spring Boot is recapitulating the worst parts of old (like, 3.0-era) Spring. It's the biggest step backwards in programming history since... I actually can't think of anything worse.

Vaadin? GWT? Not a java guy, may miss some distinctions.

As someone who came into webdev only recently with a long experience in just-development, it feels like there is no problem with frontend at all. The problem is that the frontend industry chose the worst perverted defaults and those defaults pay the most money. That’s the whole drama. It’s just a “five monkeys experiment” sort of situation.

or try htmx!

It's tiring, but for those of us that have the humility to know, for example, that we aren't experts in implementing every last detail of WCAG-spec compliant accessibility --and the application I'm building requires it-- it's better to build on top of someone else's solution. There's so many pitfalls to quite easily writing un-semantic, incorrect HTML. Browsers are forgiving, but a screen reader won't be.

IME, HTML-driven web applications (to say nothing of simple pages) in the field are generally more screen reader friendly than SPAs, though you can certainly achieve good accessibility with the right team and resources.

If you are burned out because of tooling, but trying to recover, I do recommend throwing out tailwind and just use pure CSS for your styling. Modern CSS is plenty fun, there is no need for an external framework to do a complex layout. CSS grid is the simplest way to do layout even if you include CSS frameworks. Custom properties (CSS variables) are more powerful then reusable styles from frameworks.

The final peace of the puzzle is getting component scoped styles, which you can do by packaging your components into a web component and using the shadow DOM. CSS custom properties actually penetrate the shadow boundaries so it is a nice catch-all. If web components scare you (which is reasonable, they are scary) then there are other systems (as simple as class naming conventions) which you can use to reach component scoped styles without tailwind.

Do you have any specific suggestions for resources for exercising grid & shadow dom knowledge/chops?

I'm updating my CSS understanding after having left the front end for ~6 years (but having done a lot of front-end work for the previous 10), loving custom properties and am intrigued with some of the systems built around them (e.g. Pollen), trying to figure out where else I should be directing attention.

The guides and references on mdn is pretty good for grid: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...

As for the shadow DOM, it is pretty advanced, I don’t recommend going there unless you really want to learn it. Using web components without understanding can cause way more problems then it solves. And at the end of the journey you get a very verbose system with a lot of boilerplate just to get component scoped styles, which is not worth it. But if you still want to learn it, this is a good place to start: https://developer.mozilla.org/en-US/docs/Web/Web_Components

I've just done a small project using web components. I didn't use the shadow dom at all (please note I have no idea what I'm doing).

This was after reading a single hacker news comment saying not to bother with it, after days of research where everything I read spoke about web components and the shadow dom as if they were inextricably linked.

I didn't want the styles to be encapsulated. I wanted the css to cascade in like it does everywhere else. I don't really see many use cases where you would actually want to style a component from the inside and not have the user of the component be able to style it themselves.

All the blogs I read spoke about exposing a styling api using css variables. But by doing that, are you not going to great lengths to recreate what already exists in the normal dom?

Am I missing the point?

I completely agree with you and I felt the same way when using Angular and styling Angular components.

Not really, the shadow DOM is an opt in choice for that reason. Only a subset of cases do you actually want the styles to be encapsulated. The shadow DOM is actually harmful for form components as interactive relations are voided if there is a shadow barrier between them (which has implications on both UX and accessibility; I think there is an effort in WHATWG to fix this). But when there is a usecase, the shadow DOM can be really nice. As you get nice things like component scoped styles and unique idref, among others.

> All the blogs I read spoke about exposing a styling api using css variables.

This might be an outdated advice. You are supposed to use a mix of CSS variables and ::part()[1]. CSS variables should cover the most basic styling while you are supposed to expose style-able elements of your components with the part attribute.

1: https://developer.mozilla.org/en-US/docs/Web/CSS/::part

I had good results doing the exact same thing.

I bought Tailwind UI and am using all their components (or as much as I can). I don't disagree with anything you said but I do like the tailwind features and design philosophy.

I have completely ignored web components and need to learn all about them.

Can I ask you how long you have been using this stack for and what are your findings ? Do you have a complex UI heavy application and can you deterministically say that this stack can replace frameworks like React/Vue for JS heavy frontend ?

Is HTMX really mature and stable for production and massive UI heavy apps ?

I am asking because we are starting a big project in Django, Postgres, Tailwind and for frontend, still trying to use VueJS and we hate SPAs so curious what our options are.

I’m more curious what made your team hate SPAs?

I have seen most preferred Quasar framework and able to integrate TailwindCSS.

Not sure what you mean by "heavy" frontend, but you might want to look into LiveViewJS (and/or similar) if there's a lot of frontend iteractivity, but you still want to do most of the logic/interaction on the backend.

I don't have much experience with HTMX, but it seems to be aimed at sites with a little bit of interactivity, especially if you want to be "forced" to maintain compatibility with no-js. (I mean "forced" in the positive sense. It keeps you honest.)

Can you speak of your experience with liveviewjs? I've been looking at it, and htmx, and everything else, over the past few months for a heavily-interactive frontend project I need to start.

I'm an experienced ios dev, but in at the deepens with all this js frontend stuff. There are so many options! The one thing I'm sure of is I don't want to use react.

The only real advice I can offer is:

Try to implement an example of the most complicated UI interaction that you have in your (conceptual) application in both and then decide.

Development-by-random-recommendation is usually a recipe for disaster.

That is sound advice and I take it to heart. I was mainly wondering if you'd hit any roadblocks whose existence might not have been obvious from the outset?

Nothing in particular that I wouldn't have predicted (from a detailed reading of the tech). I guess one thing to always keep in mind that these are frameworks that are limited by the client<->server interaction as a critical path. If you're doing a full SPA-type-thing you have to option to do optimistic updates and that sort of thing, but IME that's advanced stuff that only major orgs should even attempt to do.

This is the best advice in the entire discussion.

Everyone's definition of 'complicated UI' is different, as is the amount of reactivity you have in your app (e.g. when this data changes, what else in the UI needs to change?).

There is one caution I will give: try and predict where you will be in 2-5 years. 5 years ago I built an app with complicated screens server-rendered with a smattering of Vue to enhance them. We are now moving more and more of the screen into Vue because the reactivity has increased. It would've been better to decide to build _this section of the app_ in Vue from the start, though situational constraints (aka the budget) would have prevented us from doing so anyhow.

For extra credit look for places in your UI where you need to work with as much data as possible from as many different places as possible. One of places that justifies heavier front end frameworks and SPAs is when you can precompute things on the client side that make it more performant.

Things like efficient updates of large tables of data in the browser that was constructed out of multiple database tables… things like order + shipping status + customer shipping address… lots of day to day business stuff is like this and while you can manage to do it with just HTML and forms with or without JavaScript … it’s very easy to fall into performance traps between big form data submissions, potentially tricky JavaScript loops to shrink the data submission and backend N+1 query updates… it gets pretty tricky sometimes.

The point is the most complicated part of your UI may not be the most visually complex part. It can be just a simple data grid or html table… it can be the intersex of your requirements around the data being handled, the workflow/interactions on the data, and the performance/usability requirements of the users (offline editing + sync on reconnect basically requires a SPA)

This is such sage advice! Pick the hard UI/UX bits and prototype to de-risk and see how it feels once it’s working. Bravo Quekid5!

As for htmx, my team and I have been very happy with a Go + Fiber backend with Go templates and some htmx and Alpinejs for the more heavily interactive parts of a moderately complex application. Not having to deal with NodeJS, React, thousands of JS packages and overly complex configurations has been a blessing. Our system is insanely fast, plays nice with browser history, and is super cache friendly.

We make “component”-like parts such as toolbars, footers, menus, data tables, etc. with Go templates (partials called by a main template) with appropriate htmx. (Edit: we use/love Bulma for CSS.) High degree of reuse, great performance, and low complexity.

Have you considered https://inertiajs.com? It's still SPA-ish, but keeps server-side routing and controllers. To me it sort of looks like templates rendered in the browser with almost no need to keep state and juggle xhr calls, the app component just re-renders with new props whenever something is submitted to the server.

This comment chain:

"HTMX is great."

"I'm burnt out on frontend frameworks. HTMX has been a good change to JS heavy alternatives."

"Can you give more thoughts on it for heavy interactions?"

"You might try LiveViewJS."

"Can you tell me about your experience with LiveViewJS?"

"Have you considered InertiaJS?"

I have no intent here other than I found this circular chain amusing. Let it go on long enough and someone will without a doubt recommend HTMX as if it's something they don't expect the parent has heard of.

Is it any wonder the OP was burnt out on web dev?

Positive experience with Phoenix LiveView here. I don't know what you mean when you say heavily interactive but I've got: via JS hooks: drag and drop and charts; and hand built with live view: data tables with filter+sort, query builder and a simple report builder. It's pretty easy to hand off to JS when the need arises.

https://htmx.org/essays/when-to-use-hypermedia/ addresses your first question. The tl;dr is "probably not" as htmx is not really designed to handle complex browser-based UIs, but I have seen people in this thread and elsewhere discuss more complex use cases, so YMMV.

https://htmx.org/essays/a-real-world-react-to-htmx-port/ is about porting a serious production Django application from React to htmx.

If you hate SPAs and are chafing against Vue for building your app, it's probably worth considering if your app absolutely needs to be a JS/frontend-heavy product, or if it would be viable using a more traditional HTML+AJAX design.

After going through a fever swamp project involving React, I am definitely in the camp of getting back to basics.

SvelteKit just hit 1.0. Out of all the 'modern' meta frameworks, it's the one that feels most like just writing HTML.

I'm not sure why you're posting this on a thread about HTMX. HTMX is almost certainly more like "just writing HTML"

Svelte lets you keep HTML, JS, and CSS all together, so that's nice, but it's typical use case involves writing a fair bit of Javascript/Typescript

Wait till you end up on a fever swamp project involving templated HTML generation. Or even a fever swamp project involving jQuery.

I’ve built those sorts of apps for 20+ years. For me, the Rails / Flask type approach is much easier to work with.

I invite you to work on a Java Server Faces project sometime. Or anything with "Portlets".

Anything you have 20 years of experience with is going to be pretty easy for you, no surprise there.

Any sufficiently complex state is going to develop edge cases that your framework of choice is going to develop sharp edges.

The question is then: has some other developer provided a useful salve/balme to this?

Highly recommend the post and video mentioned above! The SaaS application shown in the video is non-trivial and appears to be very well done using htmx. Worth a close study https://htmx.org/essays/a-real-world-react-to-htmx-port/

Quasar framework seems to fit UI heavy and supported wide range of UI components. I have manage to integrate Tailwind.

I default to using Vue.js imported via a script tag inside static html pages styled on bootstrap. It’s perfect for basic apps and you don’t really lose a lot on interactivity. Backend, current fav is FastAPI.

I hear you loud and clear ! <3

I wish I had known about it when I started my most recent project a yard and a half who.

I played with HTMX and I think it just pushes complexity into the back end that now needs to render full and partial pages. Granted on the back end you get to do traditional programming and pick your language

Not sure I agree. Yes, it requires more work on the back end: rendering templates for whole pages and parts of pages, then integrating them. I've done it with Python (FastAPI/Jinja2 & htmx). My only SPA experience is with dotnet on the back end and Angular on the front. Based on that experience:

1. Python with htmx has less accidental complexity. It doesn't get rid of intrinsic complexity of the domain, but it does reduce technology-induced overhead.

2. Dotnet/Angular tech split has organisational implications, tending to encourage a division between front end and back end developers. Communication and coordination overhad goes up correspondingly (Conway's law).

3. htmx is stable. There's a lot less churn than with Angular. I haven't measured this, but subjectively, there's less time spent updating packages and re-testing. Keeping FastAPI/Django/Python update is approximately equivalent keeping the dotnet back end up to date.

4. State management is simpler. There's no front end caching to deal with, and so no corresponding cache invalidation questions.

I'm not building tech unicorn sites, so can't comment on whether the technical overhead is justified at that scale. I _have_ been pleasantly surprised at the level of UI sophistication that can be achieved with server side rendering and htmx.

I'm not a big javascript fan generally, so definitely have bias. I also have an increasingly allergic reaction to accidental complexity, so am constantly looking for ways to minimise it.

Based on those biases and experiences, my default starting point is SSR+htmx. In my experience the accidental complexity is lower, productivity higher, and intra-team communication better. YMMV obviously.

I imagine that by moving this to the backend you could guarantee (at compile time) that all Ajax calls on the client have an associated backend endpoint. This eliminates dead urls, and gives you more opportunities for code generation or IDE-style autocomplete when creating Htmx views.

Do this in a static functional language and your whole app will more “deterministically pure”.

So yes, it causes more work on backend but, given more tooling, it can provide more opportunities for less code written overall via code-generation (like how creating a model in Rails generates lots of helpers).

In a lot of cases you can go a long way without having to adapt the backend at all - just request the full page at the existing url and pick which part you want to replace. Works well enough with a page that presents paginated items for example.

I'm a huge proponent of Tailwind. What I tell people is to ignore their gut impression and just try it out.

Equivalently, my first impression of HTMX is that I kind of hate it. But I could see it being similar to Tailwind, where you just need to try it out and then it'll click. Is that fair to say?

I second Tailwind as I can't stand complexity, so I'm trying to simplify the entire stack down for _just_ my needs. Tailwind is a big part of simplifying my life.

The other part is that I'm trying to simply "fix HTML", and I believe HTMX is pretty great. I'm taking a different approach as I have a reactive backend, and I can make the HTML simply be a template of a streaming JSON object. It's like mustache with reactive data binding.

I'm enjoying, but I'm not a consultancy so I don't need to push the framework for every usecase.

I've tried Tailwind, and as a back end dev who only really understands the basics of CSS I find it a bit overwhelming and open ended. Seems it's designed for people with already a really deep knowledge of CSS who can could create beautiful components with it if they wanted but for whom hooking up the CSS to the components is painful. If you aren't good enough to create components with CSS in the first place, seems better to stick with things like bootstrap/bulma no?

100%, absolutely. It’s not an abstraction of CSS; if you don’t know the language already then it won’t help. But if you do, then it improves your productivity dramatically.

If you’re in a scenario where you’re tasked with building out UI, but don’t have design or FE skills, my recommendation would be something like bootstrap or MUI.

Or you can use tailwind-ui components that look way more polished.

Another big advantage of the Tailwind approach is that you can copy any component you see on the web, paste it in your project, and it will look the same (unless custom classes are used). No need to hunt down and adapt the whole cascade of styles for each tag.

In that sense, Tailwind has some of the earlier-Internet charm where you learned by seeing what others were doing.

True, it does cost money but it's by far the most flexible approach long term. I've been on the fence about buying it, but I'm super tempted.

Agree. The idea of Tailwind just feels wrong because it goes at the opposite of everything we can believe regarding content/style separation. But the fact is, it's amazing to use.

Maybe it's not for everyone, but it really is worth a try, with an open mind.

It’s such a cool experience - actively disregarding well-established principles that have been in place for 20 years…only to have it fix nearly everything that I hate about CSS.

For me, it clicked immediately. It is a simple way to partial updates of the UI, without having to worry about a ton of tooling. It also pushes most of the logic to the backend, which is nice. It also constrains some of the UX decisions, leaving less room for useless craziness.

I’m pretty burned out by devops and backend solutions. I think the number of cloud native services and tools is similar if not more exhausting than FE in terms of depth and complexity.

Using the same here from https://www.saaspegasus.com/

How do you integrate tailwind and django? As far as I know (which isn't very much), tailwind encourages the use of "components" which comes very naturally with other frontend frameworks. But with django, do you put each component into a template, like `<button class="rounded xxx"></button>` and `{% include "button.html" %}` when you use a button?

That's one way. Or you use something like slippers[0] or Tailwind components using @apply.

[0] https://mitchel.me/slippers/docs/introduction/

As long-time (and happy) DRF user of more than 7 years I've recently switched to django-ninja [1]. It's like FastAPI, but for django. Granted, I've only used it for a couple of months now, and also not in production yet. But I think it's pretty nice and a breath of fresh air for django. The thing you get from using it is full typing and IDE support (autocomplete!). It's using pydantic instead of DRF's serializers. Can definitely recommend so far.

[1] https://django-ninja.rest-framework.com

edit: typo

If you like the simplicity of html-based development, also try out https://github.com/beenotung/data-template

About 2 decades of software development and today I would choose the same stack. I've coded in PHP, C#, Java, Scala (Play framework), Rails, NodeJS, a bit Go. Django, DRF, and something like HTMX will be my default choice today, unless there's a specific requirement or the project is something unusual.