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

391–400 of 875 posts

Re: Htmx Is the Future

#391

Post by michaelchisari »

Everybody's arguing about whether Htmx can do this or that, or how it handles complex use case x, but Htmx can do 90% of what people need in an extremely simple and straight-forward way. That means it (or at least its approach) won't disappear.

A highly complex stock-trading application should absolutely not be using Htmx.

But a configuration page? A blog? Any basic app that doesn't require real-time updates? Htmx makes much more sense for those than React. And those simple needs are a much bigger part of the internet than the Hacker News crowd realizes or wants to admit.

If I could make one argument against SPA's it's not that they don't have their use, they obviously do, it's that we're using them for too much and too often. At some point we decided everything had to be an SPA and it was only a matter of time before people sobered up and realized things went too far.

Re: Htmx Is the Future

#392

Post by afavour »

robertoandred wrote: post #358
afavour wrote: post #356

Earlier quoted context omitted.

I don't understand why this point is so complicated. Yes, bad SPA developers mess it up all the time. Bad MPA developers do not mess it up because it doesn't require reimplementation by said bad developer, it works out of the box.

It works out of the box on SPAs too. It doesn't require reimplementation by said bad developer.

We’re way too far into a thread for me to have to restate the original point I made in the first post. If what you’re saying is true we’d never see bad implementations of history in SPAs yet we do all the time.

But look, whatever. It’s Friday afternoon, I’m out of here. Have a good weekend.

Re: Htmx Is the Future

#393

Post by jdthedisciple »

doodlesdev wrote: post #328
tsuujin wrote: post #326

Earlier quoted context omitted.

> Please just use the damn fullstack JS frameworks, they make life simpler Strongest possible disagree. I’ve been doing web dev for a long time, and the last 10 years has seen a massive, ridiculous increase in complexity across the board. I personally took my company back to good old server rendered apps with a turbolinks overlay because I was sick of dealing with the full stack frameworks, and we saw a huge increase…

Hotwire is appropriate (I imagine you're not using actual Turbolinks which has been deprecated) with RoR or whatever stack you want, I agree it's great developer experience (despite Ruby and Rails being painfully slow haha). I wonder which full-stack JS framework you used that you thought made life harder? One of the things that gets me mad is the idea of putting it all in one single box, as React is indeed very (nee…

Well which JS framework(s)/librar[y|ies] are you then using/advocating for, if you agree that React is needlessly complex?

Re: Htmx Is the Future

#394

Post by mdaniel »

dalmo3 wrote: post #257
0x445442 wrote: post #136

Earlier quoted context omitted.

When do you want the browser to be anything more than a hypertext document viewer and why?

Roughly every time I can use something by just typing some words instead of downloading a .exe.

Or its close friend: when I want to use the data or customize the UI via `document.querySelectorAll`

Re: Htmx Is the Future

#395

Post by recursivedoubts »

dlisboa wrote: post #383
recursivedoubts wrote: post #86

Earlier quoted context omitted.

if you read the article, you will see that you can use htmx as progressive enhancement quite easily since it is consonant with the vanilla HTML approach. what makes htmx a hypermedia framework is the exchange of hypermedia with the server, this satisfies the hypermedia constraint (HATEOAS) of REST. there are other libraries that are also hypermedia oriented, such as unpoly. it is a different approach to building web…

I don't really see how progressive enhancement works if every element is a hypermedia control. Without JS/HTMX you just have a page that does nothing: Get Some HTML This will never do anything without HTMX because the semantic of that markup is wrong. You'd really have to write everything in a vanilla HTML approach to begin with, and never make use of the idea of adding hypermedia to other elements.

you do have to structure things properly to make progressive enhancement work with htmx

for your example, you wouldn't have a div, you'd use an anchor:

      Get Some HTML
or, more likely, just boost it:

      Get Some HTML
and then on the server side you'd need to check the `HX-Request` header to determine if you were going to render an entire page or just some partial bit of HTML

if you go down the progressive enhancement route you need to think carefully about each feature you implement and how to make it compatible w/ no-js. Some patterns (e.g. active search) work well. Others (drag and drop) don't and you'll have to forgo them in the name of supporting noJS

nb: unpoly is a more seamless progressive enhancement experience due to its design goals

Re: Htmx Is the Future

#396

Post by doodlesdev »

jdthedisciple wrote: post #393
doodlesdev wrote: post #328

Earlier quoted context omitted.

Hotwire is appropriate (I imagine you're not using actual Turbolinks which has been deprecated) with RoR or whatever stack you want, I agree it's great developer experience (despite Ruby and Rails being painfully slow haha). I wonder which full-stack JS framework you used that you thought made life harder? One of the things that gets me mad is the idea of putting it all in one single box, as React is indeed very (nee…

Well which JS framework(s)/librar[y|ies] are you then using/advocating for, if you agree that React is needlessly complex?

I personally enjoy Svelte.

Re: Htmx Is the Future

#397

Post by jdthedisciple »

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.

Re: Htmx Is the Future

#398

Post by mixmastamyk »

dfabulich wrote: post #217
jgoodhcg wrote: post #186

Earlier quoted context omitted.

I've spent almost my entire career working on react based SPAs and react native mobile apps. I've just started playing around with HTMX. > no good story for what happens when one component in a tree needs to update another component in the tree HTMX has a decent answer to this. Any component can target replacement for any other component. So if the state of everything on the page changes then re-render the whole page…

> Do we actually need optimistic UI? Some apps need to work in offline mode sure, like offline maps or audiobooks or something. The HTMX author agrees, this is not the solution for that. Most of the stuff I have worked on though ... is useless without an internet connection. > It's basically the speed of the network. Does your stuff work on mobile web? Mobile web requests can easily take seconds, and on a dodgy conne…

> a single small request can often take 10+ seconds.

Hah! Good luck getting React even to start up in that environment. Meanwhile oldschool HN will still be snappy. Speaking from experience.

Re: Htmx Is the Future

#399

Post by traverseda »

dtagames wrote: post #227
pphysch wrote: post #170

Earlier quoted context omitted.

A lot of misconceptions here. Google is an AdTech company par excellence. You don't need to do hacky URL tracking with SPAs. That's the point. >Also, fewer server interactions means fewer opportunities to capture user behavior or affect it at the server level. SPAs certainly do not have "fewer server interactions". What do you think an API call is? "React" comes from "reactive web app", not "reaction to a competitor'…

I work with SPAs with API calls every day. It definitely reduces the server interactions over computing everything on that side, and it gives fewer points of contact with the server about the user's behavior. For example, many clicks and other actions will not result in any server contact at all. I'm aware that they call it "reactive" but I'll stick with my rationale. There is no way they would use a Google product l…

I... don't believe you? Like looking at the network request of any SPA I've ever seen there's just tons of requests for even simple page loads. One for main content, one for profiles, one for comments, etc.

In theory stuff like graphql helps but in the reality I'm living in SPA's hit multiple endpoints to get render even simple pages.

Re: Htmx Is the Future

#400

Post by IshKebab »

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.

Most users these days are probably using phones, not high end computers.
Post reply on HN