231–240 of 414 posts
howdy, I'm the creator of htmx, happy to talk about it
Earlier quoted context omitted.
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.
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?
Htmx isn’t everything I want it to be, but it lets me program python back end with a mostly python api. I use it for http://golfcourse.wiki and I’d recommend it to others who prefer to avoid JS when they can.
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 h…
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?
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.
Earlier quoted context omitted.
But HTMX is a JS library. Anything done with it is basically done with JS.
Kernel is done with C. Everything is basically done with C. Even JavaScript.
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).
Htmx isn’t everything I want it to be, but it lets me program python back end with a mostly python api. I use it for http://golfcourse.wiki and I’d recommend it to others who prefer to avoid JS when they can.
Interesting! Is it open source?
I'm not sure if that's the best course of action, but I'm just a guy who's a bit embarrassed to really like to programming in python and playing golf.
However, I believe in a better way if you have a better backend. This is what I'm working on as I build a "vertically integrated online board game studio" where I own the infrastructure, the clients, the frameworks, and now gaming runtimes.
I've been working on a HTMX Playground! https://lassebomh.github.io/htmx-sandbox/ It runs a small mock server inside the browser which is very Django inspired, so it should be very familiar if you have experience with it. The mock server runs using PollyJS and Nunjucks as the templating engine. There is sadly no mobile support or the ability to save yet, but it's still a great place to start tinkering without needing…
very cool! you should post this in the #showcase channel on the htmx discord! and submit it to the /r/htmx! https://htmx.org/discord
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 h…
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
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 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 h…
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
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).