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

291–300 of 875 posts

Re: Htmx Is the Future

#291

Post by jbergens »

dfabulich wrote: post #56

People were making this prediction ten years ago. It was wrong then, and it's wrong now. This article makes its case about Htmx, but points out that its argument applies equally to Hotwired (formerly Turbolinks). Both Htmx and Hotwired/Turbolinks use custom HTML attributes with just a little bit of client-side JS to allow client-side requests to replace fragments of a page with HTML generated on the server side. But…

Of course there are some challenges and some use cases where Htmx is not the best solution but I think it can scale pretty far.

You can split a large app into pages and then each page only has to care about its own parts (sub components). If you want some component to be used on multiple pages you just create it with the server technology you use and include it. The other components on the page can easily target it. You may have some problem if you change a shared component in such a way that targeting stops working. You may be able to share the targeting code to make this easier.

Re: Htmx Is the Future

#292

Post by jonomacd »

koromak wrote: post #241
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…

My app would crash and burn without optimistic UI. For simple CRUD applications sure, but most products these days aren't CRUD apps anymore.

You can make use of htmx-indicator to show that the request is ongoing. From my perspective you have to be careful here. If you are _too_ optimistic and imply a request has been successfully sent to the DB when it really hasn't then users are not going to like that as their requests disappear.

Re: Htmx Is the Future

#293

Post by dfabulich »

listenallyall wrote: post #264
dfabulich wrote: post #217

Earlier quoted context omitted.

> 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…

In the case of bad internet connection, "optimistic UI" is the worst solution. User thinks the data he entered has persisted, but in fact it has not. Big surprise months later when he realizes his boss's birthday reminder never got saved to his calendar.

The fix is to save data to client-side storage (IndexedDB) before attempting a network connection, and retries when connectivity is restored.

Optimistic UI probably isn't necessary for a web site, but you'll certainly want it for a web app (which is what Htmx claims to be good for).

In the real world on the mobile web we actually have, TODO apps (which is what TFA is about), calendars, notes apps, etc. all work better with client-side state synchronized to the server in the background.

React has a bunch of good libraries for this, especially TanStack React Query.

Htmx doesn't.

Re: Htmx Is the Future

#294

Post by marcosdumay »

hirako2000 wrote: post #76
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…

I have no love for unnecessarily bloated dependency graphs, but we can't have the cake and eat the cake too. Next.js for example, comes packed with anything and everything one might need to build an app. Sitting on the promise of hyperproductivity with "simplicity". Plus, is made of single responsability principles set of modules, kind of necessary to build a solve-all needs framework. And it does that. A bit like An…

Back in the late 90's and early 00's, armed with the experience of C, C++, Bash, and Perl, everybody knew it very clearly that "batteries included" is the correct way to create development tools.

I don't know about the current fashion of minimalism comes from. It doesn't bring simplicity.

Re: Htmx Is the Future

#295

Post by replygirl »

dtagames wrote: post #130
pphysch wrote: post #111

Earlier quoted context omitted.

HTML gives very limited tools for tracking what a (potentially JS-less) user is doing. There are various tricks, like "link shorteners" and "magic pixels" that allow some tracking. But if you want advanced tracking, like tracking what a user is focusing on at a particular instant, you need to wrap the whole document in a lot of JS. SPA frameworks came out of AdTech companies like Meta, and I assure you it wasn't beca…

This is not correct. SPAs and web components were pioneered by Google with the introduction of Angular. Later, Vue was invented by a previous Google employee who had worked on Angular. Finally, Facebook came up with React (it's a "reaction" to Angular) because they could not be seen using a Google product. If anything, SPAs make metrics harder because they hide the real behavior of the page in local JS/TS code and do…

your timeline is a bit off. facebook had react in production (mid-late 11) less than a year after angularjs went public, open-sourced it 18-24 months later (early 13), then evan started working on vue a few months after that (mid 13) and released early the following year

Re: Htmx Is the Future

#296

Post by jcmontx »

I am very fond of MPAs. Glad to see them make a comeback.

The one single strong point of the front/back split is the famous Strangler Fig Pattern which takes away a lot of stress when making decisions.

Re: Htmx Is the Future

#297

Post by tored »

obpe wrote: post #19
zelphirkalt wrote: post #8

Earlier quoted context omitted.

> 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. Node does not absolve from this. Any important verification still needs to be done on the server side, since any JS on the client side cannot be trusted to not be manipulated. J…

>Node does not absolve from this. Any important verification still needs to be done on the server side, since any JS on the client side cannot be trusted to not be manipulated. JS on the client side was of course possible before NodeJS. NodeJS did not add anything there regarding where one must verify inputs. Relying on things being checked in the frontend/client-side is just writing insecure websites/apps. Yeah, tha…

SPAs transfers large amounts of data to the frontend to be able to do HTTP JOIN and then tosses most of it away.

Re: Htmx Is the Future

#298

Post by karaterobot »

jksmith wrote: post #132

You know, nobody likes this argument, but desktop is still just better. Yeah, yeah, the updates, security issues, I get it, but the tools are simple better, render faster, better functionality/complexity ratio, less gnashing of teeth.

There are lots of great desktop apps, sure. And, for a specific task (like text editing, or watching videos, or playing music) a desktop app is usually better than a web app. However, I expect the ecosystem of desktop apps required to replace every website I use would be worse than the web.

What I mean is, different websites work differently, and do different things. For example, you might imagine a single desktop app that replaces multiple news aggregators, like Reddit or HN. It would ignore the style of both sites, and replace it with a single, uniform way of displaying posts and threads. But, what features from each does it implement? Does it have both upvoting and downvoting, like Reddit, or just upvoting, like HN? Does it support deeply nested threads, like Reddit, or only a couple levels, like HN? You'd run into limitations like this when trying to have a single app do everything, so you'd end up having to have n applications, one for each website you were replacing...

I'm also not with you on the "gnashing of teeth" point. I've never struggled to install, uninstall, or upgrade a website I was browsing.

Re: Htmx Is the Future

#299

Post by vosper »

redonkulus wrote: post #286

We've been using similar architecture at Yahoo for many years now. We tried to go all in on a React framework that worked on the server and client, but the client was extremely slow to bootstrap due to downloading/parsing lots of React components, then React needing to rehydrate all the data and re-render the client. Not to mention rendering an entire React app on the server is a huge bottleneck for performance (can'…

> We've been using similar architecture at Yahoo for many years now.

At all of Yahoo? I imagined such a big company would have a variety of front-end frameworks and patterns.

Re: Htmx Is the Future

#300

Post by withinboredom »

elliottinvent wrote: post #104
danielvaughn wrote: post #94

Earlier quoted context omitted.

100%. Saying that [technology x] will remove complexity is like saying that you've designed a house that can't get messy. All houses can be messy, all houses can be clean. It depends on the inhabitants.

True, but well designed houses that have natural places for the things a well functioning home needs, are far easier to keep clean and tidy.

natural to whom?
Post reply on HN