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

Htmx Is the Future

quii.dev

Post reply on HN
Print view View original

511–520 of 875 posts

Re: Htmx Is the Future

#511

Post by nickisnoble »

MisterSandman wrote: post #183
brushfoot wrote: post #10

I use tech like HTMX because, as a team of one, I have no other choice. I tried using Angular in 2019, and it nearly sank me. The dependency graph was so convoluted that updates were basically impossible. Having a separate API meant that I had to write everything twice. My productivity plummeted. After that experience, I realized that what works for a front-end team may not work for me, and I went back to MPAs with J…

Angular is nototiously bad for single developers. React is much better, and things like Remix and Gatsby are even better.

Svelte is even betterer

Re: Htmx Is the Future

#512

Post by jonahx »

chrsjxn wrote: post #335

I love articles like these, because the narrative of "JS framework peddlers have hoodwinked you!" is fun, in an old-timey snake oil salesman kind of way. But I'll be honest. I'll believe it when I see it. It's not that htmx is bad, but given the complexity of client-side interactions on the modern web, I can't see it ever becoming really popular. Some of the specifics in the comparisons are always weird, too. > Inste…

> This is about client side apps fetching arbitrary JSON payloads, but your htmx backend needs to do the same work, right? You have to work with the raw data you get from your DB (or another service) and then render based on that data.

In your analogy, the client JS code is like the serverside code, fetching over the network instead of directly from the DB, and then doing essentially the same work from there... materializing html and a set of controls for the user to interact with.

In a sense, I see your point.

But there's a difference: When you materialize the html on the server and send that over the wire, the browser does all the work for you. When you take the SPA approach, you must re-implement much of what the browser does in JS, and hence the well-known trouble with routing, history, and so on. You can argue that React/Angular/whatever takes care of this for you at this point, and to some extent it's true, but you're still cutting against the grain. And even as mature as the frameworks are, you will hit weird edge cases sometimes that you'd never have to worry about with the browser itself.

Re: Htmx Is the Future

#513

Post by renerick »

synergy20 wrote: post #436

htmx is ajax wrapped in html to me. it does not work for resource restricted (i.e. embedded) devices where you just can't do server-side rendering, CSR SPA is the future there as the device side just need return some json data for browser to render.

Htmx actually can be used with these restrictions, there is an extension to do client side rendering from a JSON response [1]. And you can make htmx send JSON requests instead of form data [2].

The idea is easily extendable to any template engine, so you can keep your device response minimal while enjoying the simplicity of htmx. I will admit though, this approach gets funky much faster, than returning HTML fragments, so you probably shouldn't exclusively build your app with this client-side-templates

[1]: https://htmx.org/extensions/client-side-templates/ [2]: https://htmx.org/extensions/json-enc/

Re: Htmx Is the Future

#514

Post by ResearchCode »

PaulHoule wrote: post #277
v0idzer0 wrote: post #234

Earlier quoted context omitted.

It really wasnt about client side validation or UX at all. You can have great UX with an MPA or SPA. Although I do think it’s slightly easier in an SPA if you have a complex client like a customizable dashboard. Ultimately it’s about splitting your app into a server and client with a clear API bounday. Decoupling the client and server means they can be separate teams with clearly definied roles and responsibilities.…

Ouch! I’ve worked in two kinds of organizations. In one of them when there is a ‘small’ ticket from the viewpoint of management, one programmer is responsible for implementation but might get some help from a specialist (DBA, CSS god, …) In the other a small ticket gets partitioned to two, three or more sub teams and productivity is usually reduced by a factor more than the concurrency you might get because of overhe…

Sounds like the problem is having "sprints". As far as I know, most teams at Google and Meta don't.

Re: Htmx Is the Future

#515

Post by cromulent »

narag wrote: post #502
berkes wrote: post #376

Earlier quoted context omitted.

Even worse: Client-side validation and server-side validation (and database integrity validation) are all their own domains! I call all of these "domain logic" or domain validation just to be sure. Yes, they overlap. Sure, you'll need some repetition and maybe, indeed, some DSL or tooling to share some of the overlapping ones across the boundaries. But no! They are not the same. A "this email is already in use" is se…

A "this doesn't look like an email-address, did you mean... Stop right there. I'm tired of receiving mail from people that gave my email address as if it was their own. Never ever accept an email address unless you can instantly confirm it's valid sending an email and waiting for an answer . If the user can't access their email on the spot, just leave it blank and use another data as key. I wish they included that in…

I think this is the point of the client side check though - if the user makes a typo (e.g. gamil.com) then the client side validation can prompt them to check, before the server sends the validation email and annoys the owner of the typoed address.

Re: Htmx Is the Future

#516

Post by jonahx »

jdthedisciple wrote: post #397

This puts all the computational load on the server. Imagine 10s of thousands of clients requesting millions of HTML fragments be put together by a single server maintaining all the states while all the powerful high end computing power at the end user's fingertips goes completely to waste. Not convinced.

> by a single server maintaining all the states

HTTP is stateless. This is the whole point of the hypermedia paradigm.

If you have a page with many partial UI page changes over htmx, then yes, this paradigm puts increased load on the server, but your DB will almost certainly be your bottleneck before this will be, just as in the SPA case.

Re: Htmx Is the Future

#517

Post by Aeolun »

obpe wrote: post #3

It's kinda funny to me that many of the "pros" of this approach are the exact reasons so many abandoned MPAs in the first place. For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It's a pretty shitty client experience if you have to do a network request for each and every validation of user input. Also, there was a push to move the shitty code fro…

> SPAs have definitely become what they sought to replace.

Not sure about that. SPA’s load 4MB of code once, then only data.

Now look at a major news front page, which loads 10MB for every article.

Re: Htmx Is the Future

#518

Post by emodendroket »

yawaramin wrote: post #499
emodendroket wrote: post #273

Earlier quoted context omitted.

Presumably there are some features of the app that won’t work that way. Surely you’re not saying you prefer a Web app just for the sake of making calls.

No, I'm just taking your argument to its logical conclusion. If you manufacture enough criteria, you can steer any discussion so that your choice is the only possible choice left. That's not how things work in reality, there are many competing factors that go into technological choices.

Minimizing round trips is an optimization with improved UX and operational cost and no real downside except marginal implementation difficulty (which itself seems like an argument for being able to share validation between the backend and frontend).

Re: Htmx Is the Future

#519

Post by bigtunacan »

nsonha wrote: post #505
PaulHoule wrote: post #179

Earlier quoted context omitted.

I remember that all the web shops in my town that did Ruby on Rails sites efficiently felt they had to switch to Angular about the same time and they never regained their footing in the Angular age although it seems they can finally get things sorta kinda done with React. Client-side validation is used as an excuse for React but we were doing client-side validation in 1999 with plain ordinary Javascript. If the real…

Can you argue a bit more genuinely and not pick on such a minor point as validation? I think parent mentioned other points? How about the logical shift to let client do client things, and server do server things? Server concatting html strings for bilions of users over and over again seems pretty stupid.

No more stupid than concatting json for those same users

Re: Htmx Is the Future

#520

Post by emodendroket »

philderbeast wrote: post #498
emodendroket wrote: post #174

Earlier quoted context omitted.

I think a charitable reader could infer that this is often made a requirement out of UX concerns and therefore it “needs” to be done. Do you have a substantive objection to what I said?

a requirement that is solved by setting the length on your input field? or have we forgotten that plain hold HTML can validate much of this for us with no JS of any type required?

There are limitations to that, as you well know, since you hedged with “much of.” And this is, again, a nitpick around the edges and not really a comment that addresses my main point.
Post reply on HN