10 ms·

I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the f

I am burnt out (but recovering!) with web dev and htmx is what I am using for my project. Django, DRF, Postgres, tailwind and HTMX. I am so tired of all the front end frameworks and all the complexity that gets added. At some point I think you need it and you get returns from it but hearing more people in the industry recognize and talk about how JS everything isn't always the answer gives me hope. I like what HTMX has to offer and I am excited to see it continue to get air time.

dysoco 4y ago
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?
- leetrout 4y ago
  I still have some API things and I like the router and serializers.
  - TechBro8615 4y ago
    Does the server renderer call the API routes via HTTP, or does it have a more direct path to fetching the same data? If HTTP, 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?
- FlyingSnake 4y ago
  Web isn’t the only interface. DRF might also serve REST API to mobile or webhooks etc.
- iamgopal 4y ago
  HTMX can be used with templates and JSON with extensions.
zelphirkalt 4y ago
But HTMX is a JS library. Anything done with it is basically done with JS.
- mirekrusin 4y ago
  Kernel is done with C. Everything is basically done with C. Even JavaScript.
  - zelphirkalt 4y ago
    That doesn't address the implications of something only working with JS at all.
  - hirvi74 4y ago
    It's all binary at the end of the day.
    - nudpiedo 4y ago
      It’s all just energy moving around
      - dunno7456 4y ago
        On sand.
        I_complete_me 4y ago
        And those turtles that go all the way down lay their eggs in that sand.
  - TechBro8615 4y ago
    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).
colordrops 4y ago
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.
- recursivedoubts 4y ago
  or try htmx!
- kkapelon 4y ago
  > 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.
  - icedchai 4y ago
    Sure, if you ignore Dropwizard and tons of other less popular java frameworks out there.
    - kkapelon 4y ago
      Maybe I am missing something but Dropwizard is not a framework on its own but instead of collection of external and independently developed libraries
      - icedchai 4y ago
        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."
        kkapelon 4y ago
        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/ 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.
88913527 4y ago
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.
- scarmig 4y ago
  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.
runarberg 4y ago
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.
- wwweston 4y ago
  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.
  - runarberg 4y ago
    The guides and references on mdn is pretty good for grid: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Grids 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 https://developer.mozilla.org/en-US/docs/Web/Web_Components
    - fatboy 4y ago
codegeek 4y ago
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.
- deleted 4y ago
  [deleted]
- Quekid5 4y ago
  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.)
  - fatboy 4y ago
    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.
    - Quekid5 4y ago
      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.
      - 4y ago
lta 4y ago
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.
quickthrower2 4y ago
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
- spinningslate 4y ago
  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.
- devmunchies 4y ago
  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).
danielvaughn 4y ago
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?
- mathgladiator 4y ago
  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.
- joshlemer 4y ago
  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?
  - danielvaughn 4y ago
    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.
  - jp_sc 4y ago
    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.
qudat 4y ago
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.
chartpath 4y ago
Using the same here from https://www.saaspegasus.com/ https://www.saaspegasus.com/
powersnail 4y ago
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?
- julianwachholz 4y ago
  That's one way. Or you use something like slippers[0] or Tailwind components using @apply. [0] https://mitchel.me/slippers/docs/introduction/ https://mitchel.me/slippers/docs/introduction/
nuschk 4y ago
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 https://django-ninja.rest-framework.com edit: typo
aabbcc1241 4y ago
If you like the simplicity of html-based development, also try out https://github.com/beenotung/data-template https://github.com/beenotung/data-template
4m1rk 4y ago
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.

dysoco 4y ago

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?

leetrout 4y ago
I still have some API things and I like the router and serializers.
- TechBro8615 4y ago
  Does the server renderer call the API routes via HTTP, or does it have a more direct path to fetching the same data? If HTTP, 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?
FlyingSnake 4y ago
Web isn’t the only interface. DRF might also serve REST API to mobile or webhooks etc.
iamgopal 4y ago
HTMX can be used with templates and JSON with extensions.

zelphirkalt 4y ago

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

mirekrusin 4y ago
Kernel is done with C. Everything is basically done with C. Even JavaScript.
- zelphirkalt 4y ago
  That doesn't address the implications of something only working with JS at all.
- hirvi74 4y ago
  It's all binary at the end of the day.
  - nudpiedo 4y ago
    It’s all just energy moving around
    - dunno7456 4y ago
      On sand.
      - I_complete_me 4y ago
        And those turtles that go all the way down lay their eggs in that sand.
- TechBro8615 4y ago
  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).

colordrops 4y ago

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.

recursivedoubts 4y ago
or try htmx!
kkapelon 4y ago
> 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.
- icedchai 4y ago
  Sure, if you ignore Dropwizard and tons of other less popular java frameworks out there.
  - kkapelon 4y ago
    Maybe I am missing something but Dropwizard is not a framework on its own but instead of collection of external and independently developed libraries
    - icedchai 4y ago
      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."
      - kkapelon 4y ago
        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/ 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.

88913527 4y ago

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.

scarmig 4y ago
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.

runarberg 4y ago

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.

wwweston 4y ago
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.
- runarberg 4y ago
  The guides and references on mdn is pretty good for grid: https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Grids 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 https://developer.mozilla.org/en-US/docs/Web/Web_Components
  - fatboy 4y ago

codegeek 4y ago

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.

deleted 4y ago
[deleted]
Quekid5 4y ago
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.)
- fatboy 4y ago
  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.
  - Quekid5 4y ago
    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.
    - 4y ago

lta 4y ago

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.

quickthrower2 4y ago

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

spinningslate 4y ago
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.
devmunchies 4y ago
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).

danielvaughn 4y ago

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?

mathgladiator 4y ago
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.
joshlemer 4y ago
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?
- danielvaughn 4y ago
  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.
- jp_sc 4y ago
  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.

qudat 4y ago

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.

chartpath 4y ago

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

powersnail 4y ago

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?

julianwachholz 4y ago
That's one way. Or you use something like slippers[0] or Tailwind components using @apply. [0] https://mitchel.me/slippers/docs/introduction/ https://mitchel.me/slippers/docs/introduction/

nuschk 4y ago

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 https://django-ninja.rest-framework.com edit: typo

aabbcc1241 4y ago

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

4m1rk 4y ago

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.