Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

321–330 of 530 posts

Re: Please just try HTMX

#321

Post by epolanski »

perardi wrote: post #60

I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…

So first you choose a nicher solution you didn't fully understand and now you jump into another one (full of issues but popular) you likely don't understand the trade offs too?

Re: Please just try HTMX

#322

Post by epolanski »

krzyk wrote: post #191
perardi wrote: post #60

I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…

> Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. Well, frontend and backend always need to agree on every scenario, that's why I prefer to do validation on backedn and frontend to just display it and not do any validation.

That makes for some nasty debugging and unsafety. Both sides should parse both times, unless you're encountering real (not imaginary) performance issues.

As someone who's been parsing everything entering the system from 2018, I don't believe you can have performance issues by parsing the data entering the system, the only exception I can name in a decade was real time trading app where the data coming in all time was just gargantuan that parsing it all the time was impacting UX and even then there should be an argument for the backend insisting on sending whole data instead of the latest value.

Re: Please just try HTMX

#324

Post by chaosharmonic »

> Honor obliges me to admit this is not literally true. bettermotherfuckingwebsite.com is a fucking pedagogical masterpiece and reshaped how I built my own site. But let's not spoil the bit...

> Inspired by (and in joyful dialogue with) motherfuckingwebsite.com, justfuckingusehtml.com, bettermotherfuckingwebsite.com, and justfuckingusereact.com. Extremism in defense of developer experience is no vice! This site made by me. Does this all sound a bit like shallow slop? Yup, please help make it better.

I agree with you, and wrote a similar one for Markdown that you might enjoy. Same overall naming scheme. (Note: open the comments before you judge the use of a Web Component for rendering purposes.)

Re: Please just try HTMX

#326

Post by Lio »

ChocolateGod wrote: post #178
mrinterweb wrote: post #166

HTML over the wire frameworks like HTMX, Hotwire (rails), LiveView (phoenix), Livewire (laravel), LiveView (django), etc. They all have the same basic idea with differences in how they achieve it. I feel this approach is overlooked, and it drives me crazy. There is a huge complexity cost attached with JS frontend app + backend that everyone seems to have accepted as reality. HTML over the wire (really need a catchy a…

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.

Re: Please just try HTMX

#327

Post by lbreakjai »

recursivedoubts wrote: post #276
lbreakjai wrote: post #270

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…

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 (and maintain/test) three different endpoints, one per component.

I feel like you would quickly end up in a combinatorial explosion for anything but the simplest page. I really don't get the appeal at all. Of course everything can be very simple and lightweight if you hide the complexity under the bed!

Re: Please just try HTMX

#328

Post by mrinterweb »

ChocolateGod wrote: post #178
mrinterweb wrote: post #166

HTML over the wire frameworks like HTMX, Hotwire (rails), LiveView (phoenix), Livewire (laravel), LiveView (django), etc. They all have the same basic idea with differences in how they achieve it. I feel this approach is overlooked, and it drives me crazy. There is a huge complexity cost attached with JS frontend app + backend that everyone seems to have accepted as reality. HTML over the wire (really need a catchy a…

Using JSON over the wire means you can re-use your backend between multiple frontends (like with mobile apps).

I have lost track of the number of times I have heard that argument, and implemented the API only to never have other API clients, or the API clients that do come later have very different needs and I need to create another API for that. I don't think API re-use is a strong argument unless the other client will be consuming the API imminently. I've heard the of "course we will have a native mobile app" argument enough times to often identify it as wishful thinking. Many clients are often satisfied with with a good web app.

Re: Please just try HTMX

#330

Post by moregrist »

azangru wrote: post #162
librasteve wrote: post #103

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…

I think the number of job postings is pretty related to factors that I do consider valid when selecting a piece of technology (eg: language, framework, etc):

- How easy is it to hire people with experience in this?

- Relatedly, how easy will it be for the org to maintain this software after I (or the original team) leaves?

Post reply on HN