3 ms·

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 benef

by t8sr 4y ago

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 APIs then bye bye performance. It's probably fine for web pages, because you're competing with JS+JSON/REST frameworks that are written by people who have never heard the term "L2 cache", but I strongly suspect the right move is to drop the framework completely, not replace it with a new flavour-of-the-week thing. Just write HTML5. It's fine. Add javascript for the 2-3 bits of interactivity you actually need. If you hate JSON, use protobufs. Your web page will work forever, because it'll sit on the actual API provided by the browser, and it won't make my laptop overheat when I load your site.

mejutoco 4y ago
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.
- t8sr 4y ago
  > 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.
  - mejutoco 4y ago
    > 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.
    - P5fRxh5kUvp2th 4y ago
      > 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?
jrochkind1 4y ago
> Also if you build stuff on top of hypermedia APIs then bye bye performance. This is not obvious to me.
- t8sr 4y ago
  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.
  - yawaramin 4y ago
    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.
    - t8sr 4y ago
      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.
taolegal 4y ago
> 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.
- airstrike 4y ago
  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
  - P5fRxh5kUvp2th 4y ago
    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.
- silver-arrow 4y ago
  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.
- azeemh 4y ago
  This is the philosophy I had when I coded Zedtopia. Clean Html5 and css3 should achieve everything. Only use JS for specific interactivity.
naasking 4y ago
> 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.

by t8sr 4y ago

mejutoco 4y ago

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.

t8sr 4y ago
> 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.
- mejutoco 4y ago
  > 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.
  - P5fRxh5kUvp2th 4y ago
    > 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?

jrochkind1 4y ago

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

t8sr 4y ago
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.
- yawaramin 4y ago
  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.
  - t8sr 4y ago
    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.

taolegal 4y ago

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

airstrike 4y ago
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
- P5fRxh5kUvp2th 4y ago
  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.
silver-arrow 4y ago
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.
azeemh 4y ago
This is the philosophy I had when I coded Zedtopia. Clean Html5 and css3 should achieve everything. Only use JS for specific interactivity.

naasking 4y ago

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