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

441–450 of 875 posts

Re: Htmx Is the Future

#441

Post by listenallyall »

dfabulich wrote: post #293
listenallyall wrote: post #264

Earlier quoted context omitted.

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

So actually React does not address your precious Optimistic UI, you as a developer rely on an separate 3rd party library to handle it. We all know that React, a decade old by now, has a wider ecosystem. If that's your argument, then I guess every developer using emerging or niche languages, libraries and frameworks is wrong in your eyes. However, you're a guy who relies on "State of JS" to decide what to use, as opposed to thinking for yourself.

Re: Htmx Is the Future

#442

Post by pier25 »

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

> simple client-side library based on HTML decorations has worked really well for us

What library are you using?

Re: Htmx Is the Future

#443

Post by halfcat »

willio58 wrote: post #364
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 falling off hard in the frontend frameworks race. And I totally agree about how the boilerplate and other things about Angular feels bad to work with. Other frameworks are far easier to build with, to the point where a 1-person team can easily handle them. React is being challenged but still has the biggest community, it's a much better place to start than Angular when evaluating frameworks like this. All…

> React is being challenged but still has the biggest community

jQuery and PHP have entered the chat

Re: Htmx Is the Future

#444

Post by KyeRussell »

ebiester wrote: post #332
wwweston wrote: post #283

Earlier quoted context omitted.

> "DO NOT USE YOUR BROWSER BACK BUTTON"? Yeah, state mutation triggered by GET requests is going to make for a bad time, SPA or MPA. Fortunately enough of the web application world picked up enough of the concepts behind REST (which is at the heart of all web interaction, not just APIs) by the mid/late 00s that this already-rare problem became vanishingly rare well before SPAs became cancerous. > going back to change…

It wasn't GET mutation... it was POSTs with multi-page forms that was the problem. It was such a pain to subdivide a form and create server and session state and intuit the return state. And what happens if you needed a modal with dynamic data? Did you pop open a new window and create a javascript call for the result? There was no great progressive answer to them. Oh, and then request scope wasn't good enough because…

Yeah. As someone that’s quite bearish on JS altogether, and as someone that’s worked on a few old-school multi-step forms recently, we can’t pretend that this was and still is anything other than a code and UX disaster. And…I’m not an idiot, I understand different HTTP request types and how browsers handle going back through history. I know that there’s not something obvious I’m missing. I’ve put the work in. The reality is that non-JS web technologies aren’t very good at some things that are quite common and that many people expect in anything more than a brochure site.

I’m just so miffed that it can end up necessitating roping in so much BS. Mind you, not necessarily in this example. Things like HTMX excite me. And, on the other side, things like Next.js and Remix that IMO are a breath of fresh air, even if they might not ultimately be heading in the right direction (I genuinely have no idea).

Re: Htmx Is the Future

#445

Post by recursivedoubts »

rmbyrro wrote: post #426
runlaszlorun wrote: post #145

Earlier quoted context omitted.

Just started using HTMX on a new project and have been a big fan. I’d go so far as to say that it’s the best practical case for the theory of hypermedia in general. Like others have mentioned, this is the sort of thing that prob _should_ be in the HTML spec but, given what I’ve personally seen about the standards process, I have little expectation of seeing that. Thx again!

How would this be in HTML standard if it requires JS to work?

it's implemented in js because that's what's available, but there's no reason this functionality couldn't be folded into HTML itself and then implemented in browsers without requiring js

Re: Htmx Is the Future

#446

Post by KyeRussell »

fridgemaster wrote: post #415
RHSeeger wrote: post #61

Earlier quoted context omitted.

> We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace. Plus we now get the benefit of people trying to "replace" built in browser functionality with custom code, either The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check. or They're changing things because they're already so far from def…

I fail to see how HTMX could be the "future". It could have been something useful in the 2000s, back when browsers had trouble processing the many MBs of JS of a SPA. Nowadays SPA's run just fine, the average network bandwidth of a user is full-HD video tier, and even mobile microprocessors can crunch JS decently fast. There is no use case for HTMX. Fragmented state floating around in requests is also a big big probl…

Really sounds to me like you’re speaking from your own professional context and are talking to consider the huge spectrum of circumstances in which web code is written.

Re: Htmx Is the Future

#447

Post by themaximalist »

I just started using HTMX in new projects and really like it.

The LivewView/Hotwire/LiveWire way of building applications make a really great tradeoff—the ease of building websites with the speed and power of webapp UX.

I wanted something simple to use with Express and it's been very productive.

There's a few things to get used to, but overall like it and plan to keep using it in my projects.

Re: Htmx Is the Future

#448

Post by pier25 »

pwpw wrote: post #248

What is the simplest way to host a website closer to barebones HTML, CSS, and a bit of JS with reusable components like nav bars? My experiences handling those manually leads to too much overhead as I add more pages. SvelteKit makes things fairly easy to organize, but I dislike how the user isn’t served simple HTML, CSS, and JS files. Ideally, I don’t want to use any framework.

Astro

Re: Htmx Is the Future

#449

Post by knallfrosch »

HTMX Solution to keeping client and server in sync: Remove the client.

Okay, now you have half the code base, but need a round trip to the server for every interaction.

You could also remove the server and let people download your blog, where they can only post locally. No server-side input validation needed!

Re: Htmx Is the Future

#450

Post by mixmastamyk »

jdthedisciple wrote: post #430
mixmastamyk wrote: post #412

Earlier quoted context omitted.

This avoids unnecessary computation at the client, it does not substantially add to the burden of the server. Which would need to be reconciled regardless of the markup format used over the pipe. Alpine is available for local flair.

I don't know but adapting UI to reflect the edit state of a todo seems like a classic client responsibility imho, not unnecessary. What's unnecessary to me however is sending bytes thousands of miles across the wire to some server to do the same.

Batching in a SPA could alleviate some work but could be done with alpine instead, as needed. With a significant cut in overhead, download size, developer ramp up, etc. Depends, but think the reduction in complexity is significant.
Post reply on HN