331–340 of 530 posts
Earlier quoted context omitted.
Using JSON over the wire means you can re-use your backend between multiple frontends (like with mobile apps).
You could use Hotwire Native for that. Also backends like Rails give you JSON APIs for free if you want them.
Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…
It feels like the worst of both worlds, what am I missing? I get server-side rendering. I can boot my server, and everything is there. If my model changes, I can update the view. It's cohesive. I get client-side rendering. The backend returns data, the frontend decides what to do with it. It's a clear separation. The data is just data, my mobile app can consume the same "user" endpoint. This seems like a worst-of-bot…
Not a problem with Jinja (or any server-side templating). Both the table and dropdown render from the same context variable in one template pass. One endpoint, one data fetch, two presentation formats. The "two endpoints" concern assumes you're fetching fragments independently. If you're composing a full page server-side, the data is already there
There's an example on their website where the header of a table is defined in the frontend, and the body is returned by the backend. If I wanted something as simple as switching the order of the columns, I'd actually need to create a new version of my backend endpoint, release it, change the frontend to use the new endpoint, then delete the old one. That sounds crazy to me.
Earlier quoted context omitted.
Honestly? I never think about it. I've never had to. What did you run into? Curious what the pain point was.
I had a site where the user can upload a file If it exceeds it, I returned 400. I had to add an event listener to check for the code (htmx:afterRequest) and show an alert(), but this gets difficult to manage if there's multiple requests to different endpoints on the page. Looking at it now, maybe I should have configured HTMX to swap for 4xx.
Allow the server to return a modal/toast in the response and, in your frontend, create a "global" listener that listens to `htmx:afterRequest` and check if the response contains a modal/toast. If it does, show the modal/toast. (or, if you want to keep it simple, show the content in an alert just like you already do)
This way you create a generic solution that you can also reuse for other endpoints too, instead of requiring to create a custom event listener on the client for each endpoint that may require special handling.
If you are on htmx's Discord server, I talked more about it on this message: https://discord.com/channels/725789699527933952/909436816388...
At the time I used headers to indicate if the body should be processed as a trigger, due to nginx header size limits and header compression limitations. Nowadays what I would do is serialize the toast/modal as a JSON inside the HTML response itself then, on `htmx:afterRequest`, parse any modals/toasts on the response and display them to the user.
I switched to Hotwire/Stimulus and found it to be a significantly better implementation of the same core concepts. I'd highly recommend checking them out.
Earlier quoted context omitted.
Yep. And that’s a good thing: https://htmx.org/essays/splitting-your-apis/
Splitting application API and generic data API is orthogonal to HTMX. You still have issues compared to plain JSON, don't you? Imagine you need firstName/email in once place, firstName/email in another, and firstName/D.O.B in another. In a plain JSON world, I'd craft a single "user" endpoint, returning those three datapoints, and I would let the frontend handle it. My understanding is with HTMX, I'd have to craft (an…
any factoring you do on the front end you can do on the back end too, there's nothing magic about it and you don't need different end points: that can be a query parameter or whatever (if it's even a request, in most hypermedia-based apps you'd just render what you need when you need it inline with a larger request)
it's a different way of organizing things, but there are plenty of tools for organizing hypermedia on the server well, you just need to learn and use them
Earlier quoted context omitted.
I had a site where the user can upload a file If it exceeds it, I returned 400. I had to add an event listener to check for the code (htmx:afterRequest) and show an alert(), but this gets difficult to manage if there's multiple requests to different endpoints on the page. Looking at it now, maybe I should have configured HTMX to swap for 4xx.
I have something similar on my website, and my solution was to make server driven modal/toast responses. Allow the server to return a modal/toast in the response and, in your frontend, create a "global" listener that listens to `htmx:afterRequest` and check if the response contains a modal/toast. If it does, show the modal/toast. (or, if you want to keep it simple, show the content in an alert just like you already d…
Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…
> Still prefer a chill vibe for htmx though. Said the horse with laser eyes (¬_¬)
Earlier quoted context omitted.
HTMX Sucks https://htmx.org/essays/htmx-sucks/
> No Jobs > Another practical reason not to use htmx is that there are, rounding off, zero htmx jobs. > I just did a search for htmx jobs on indeed and found a grand total of two: one at Microsoft and one at Oak Ridge National Laboratory. > A search for “react”, on the other hand, gives 13,758 jobs. > Seriously, developer, which of these two technologies do you want to hitch your career to? I do not advocated for htm…
And the frameworks are churned continuously and are also bug-ridden nightmares, so that continuous development and support is needed to keep websites functioning and secure.
Any reduction in framework complexity threatens the whole edifice.
Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…
You really need to shut this down dude. If HTMX becomes famous for having overbearing advocates that's a really bad look. Look at what happened with Rust.
The problem you've encountered is that people are annoying. I'm afraid that's not specific to any one technology or community. Fortunately, annoying blog posts are easily ignored and would never stop a useful tool from being adopted anyway.