Hacker News Reader

You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively.Then you can get rid of almost all your js code.

The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast.

> You can use the swap data attribute to update several fragments (imagine a saved icon) in several places declaratively.

Yeah, but why? The javascript snippet to accomplish the same is absolutely trivial and avoids a dependency.

> The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast.

The true price is that you've now rewritten your HTML code in a non-standard DSL and are forever dependent on a third party library, and all that to accomplish a goal that seems entirely aesthetic to me.

> absolutely trivial and avoids a dependency.

I disagree with this other than in a simple example. Updating something that depends on sth is far from trivial. It looks trivial.

> The true price is that you've now rewritten your HTML code in a non-standard DSL and are forever dependent on a third party library

So, like React. Prob also a build and scaffolding tool, and a linter were added in that case.

Regarding arsthetic I actually find htmx kind of ugly but it works so well I cannot ignore it. It simplifies everything a lot, but I am just discussing here.

> So, like React.

heh, that's exactly what went through my head when I read the other posters comment, how is that different from the current SPA frameworks?

> Just write HTML5. It's fine. Add javascript for the 2-3 bits of interactivity you actually need.

Why write any JS at all if you don't have to? Htmx extends HTML to replace the need for a lot of the JS that's out there. It gives you client/server interaction and dynamic page behaviours without a single line of code.

Sure you can do without it. You could always do it all in vanilla JS or jQuery, at the cost of debugging it yourself.

> 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 of HTML. It's also much slower to process because:

1) Network IO is CPU intensive, so sending more data is worse

2) HTML is not optimized for data interchange. Parsing a protobuf is probably at least 10x faster than parsing the same data out of an HTML microformat.

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.

Yes, I am implicitly assuming that eventually someone will connect to it as an API, not just to directly render the HTML but to machine-process it.

> 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 over.

Browsers are built to understand HTML. Whereas in the modern world we largely ignore that and write double the code we'd have to write otherwise passing arbitrary messages and it introduces a whole new set of problems making sure those codebases line up properly. Whereas HTML produced by the backend (properly) contains all the information someone could need.

This hits the nail on the head so hard that reading it feels like waking up from a bad dream.

> Browsers are built to understand HTML. Whereas in the modern world we largely ignore that and write double the code we'd have to write otherwise passing arbitrary messages and it introduces a whole new set of problems making sure those codebases line up properly.

This belongs in a manifesto. Put it on a shirt and I'll gladly wear it

yep, perfect example is the history API. People created the problem that the history API fixes by doing things they shouldn't have been doing in the first place.

You see it all the time in software dev.

This answer is exactly correct. You must really think about how this dramatically makes developing these types of applications simpler by a magnitude. You are literally killing significant complexity that causes time, effort, and bugs. And, no, this is not merely shifting the problems back to the server-side. This is how HTML should have evolved in the first place.

This is the philosophy I had when I coded Zedtopia.

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