Htmx in a Nutshell • Hacker News Board

Re: Htmx in a Nutshell

#311

Post by AmpsterMan » Thu, Dec 15, 2022, 3:13 AM UTC

t8sr wrote: post #101

xmonkee wrote: post #86

Earlier quoted context omitted.

Consider the case of calling your backend with a POST call and then updating your app in response. Typically, for a SPA: your backend would return some data, and your frontend would then figure out how to update your html in response to it. For a multi-page-app: your backend will redirect the user to a whole new page with new HTML. This is somewhere in between: Your backend will send just a little bit of HTML and you…

Yeah, that I understand. I am not a huge fan of sending JSON that's not backwards compatible. Sending HTML is probably a good choice for some applications, but that was already well supported 20 years ago. Why is htmx better than one line of javascript saying `onload = function() { e.innerHTML = response.body` } ?

One of the stated goals is to make html a true hypermedia language right? That's really pretty much it.

A lot of these objections sound like "why bring these functions into JavaScript if JQuery already exists? Why do we need CSS Grid if bootstrap already exists?" Because those are arguably add-ons meant to deal with the deficiencies of the original technology. Fixing that technology is a better place to be.

Re: Htmx in a Nutshell

#312

Post by yawaramin » Thu, Dec 15, 2022, 3:22 AM UTC

t8sr wrote: post #145

jrochkind1 wrote: post #119

Earlier quoted context omitted.

> Also if you build stuff on top of hypermedia APIs then bye bye performance. This is not obvious to me.

This idea used to be called microformats. The premise was that you send an HTML snippet, and all the semantic attributes plus a protocol definition will let you parse it as either data or a part of the UX. It's self-documenting in the sense that, if you do it right, the snippet has clear semantic meaning. However, it's not backward and forward compatible as either UI or data, because that was never an explicit goal o…

Um, 'parsing...data out of an HTML microformat' sounds like a fancy way and obscure way of saying 'the browser renders HTML, something it has been optimized to the gills for'.

> Parsing a protobuf is probably at least 10x faster

Faster than a browser rendering HTML? That would be quite a feat.

Re: Htmx in a Nutshell

#313

Post by tsaixingwei » Thu, Dec 15, 2022, 3:23 AM UTC

I still remember a time when recursivedoubts posted about intercooler.js which is the predecessor to htmx, and almost every comment was dismissive and a varition of “what’s the point of this?”.

It seems now the majority of commenters are positive about htmx now and I feel happy for recursivedoubts.

Most web applications today would benefit from using htmx more than JavaScript-heavy frameworks with the exception of applications like Figma and the like of it.

Re: Htmx in a Nutshell

#314

Post by yawaramin » Thu, Dec 15, 2022, 3:24 AM UTC

spjwebster wrote: post #176

donatj wrote: post #4

Makes me smile because everything old is new again. This is very similar to features MooTools had like 10+ years ago before JSON took off big.

Makes me smile too. Around 2008 while I was at Yahoo! I built a standalone library called Dhaka (literally stuck a pin in a map and used the place name as the project name) that did almost exactly this. It was used on a few of the EU sites but I left before I got chance to open source it. The problem I was trying to solve was eliminating a bunch of duplicate JavaScript that was essentially sending/fetching data to/fr…

As someone born and (mostly) raised in Dhaka, that's pretty funny to me.

Re: Htmx in a Nutshell

#315

Post by drudru » Thu, Dec 15, 2022, 3:25 AM UTC

Funny - top stories right now are Sveltekit 1.0 and htmx. At their heart, each is fundamentally going in a different direction. I wonder how many people are upvoting both.

Re: Htmx in a Nutshell

#316

Post by yawaramin » Thu, Dec 15, 2022, 3:26 AM UTC

spion wrote: post #167

recursivedoubts wrote: post #2

howdy, I'm the creator of htmx, happy to talk about it

I've never used htmx, primarily because I like the concept of "components" so much. (They serve two needs - standardizing larger blocks of UI and encapsulating them with an alternative interface, and providing islands of rich interactivity) Is there any material on successfully combining htmx with web components? It doesn't look to me like the original design takes this possibility into consideration... (note: at a s…

Why wouldn't htmx work with web components? It just does asynchronous fetches and DOM swaps. Web components are just pieces of DOM. There should be absolutely no issue with them working together?

Re: Htmx in a Nutshell

#317

Post by azeemh » Thu, Dec 15, 2022, 3:32 AM UTC

taolegal wrote: post #214

t8sr wrote: post #97

Earlier quoted context omitted.

Replying to myself: I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON. I can see the benefit of doing that, although I have a bone to pick with the condemnation of all data APIs because JSON is awful. Protocol buffers, for example, are trivially forward and backward compatible and mostly self-describing. Also if you build stuff on top of hypermedia…

> I guess the main point of this library is to use HTML as the protocol payload between serve and client, instead of JSON HTTP is named Hypertext Transfer Protocol after all. Exchanging schema-less JSONs is conceptually pretty lame. It's plain old RPC architecture. That's why we end up needing to write API docs to line up the frontend and backend, or otherwise inspect backend code to figure out what's being handed ov…

This is the philosophy I had when I coded Zedtopia.

Clean Html5 and css3 should achieve everything. Only use JS for specific interactivity.

Re: Htmx in a Nutshell

#318

Post by andreygrehov » Thu, Dec 15, 2022, 3:40 AM UTC

Oh. My. God. This is amazing. I absolutely hate all the complexity of the modern front-end development. I hate it so much that I use `` for status pages waiting for the result from the server. Just by looking at htmx, this is a breath of fresh air. Love the simplicity and how they managed to abstract all the complexity away. IMHO, this should become the HTML standard.

Re: Htmx in a Nutshell

#319

Post by stickfigure » Thu, Dec 15, 2022, 3:58 AM UTC

rgrieselhuber wrote: post #211

czx4f4bd wrote: post #198

Earlier quoted context omitted.

https://htmx.org/essays/when-to-use-hypermedia/ addresses your first question. The tl;dr is "probably not" as htmx is not really designed to handle complex browser-based UIs, but I have seen people in this thread and elsewhere discuss more complex use cases, so YMMV. https://htmx.org/essays/a-real-world-react-to-htmx-port/ is about porting a serious production Django application from React to htmx. If you hate SPAs a…

After going through a fever swamp project involving React, I am definitely in the camp of getting back to basics.

Wait till you end up on a fever swamp project involving templated HTML generation. Or even a fever swamp project involving jQuery.

Re: Htmx in a Nutshell

#320

Post by doodlesdev » Thu, Dec 15, 2022, 4:28 AM UTC

drudru wrote: post #315

Funny - top stories right now are Sveltekit 1.0 and htmx. At their heart, each is fundamentally going in a different direction. I wonder how many people are upvoting both.

They serve different purposes though. SvelteKit is a great full stack framework using Svelte for the frontend, which is great for SPAs, PWAs, and any other kind of WAs you might want. HTMX serves essentially as an extension to HTML itself, allowing you to make web PAGES which are interactive. Not talking about Alpine or Hyperscript though since those two start mudding the water a bit.