The price to pay for this is it does not work offline. For quickly prototyping and app it is very fast.
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.
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.
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?
This is not obvious to me.
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.
> Parsing a protobuf is probably at least 10x faster
Faster than a browser rendering HTML? That would be quite a feat.
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.
> 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
You see it all the time in software dev.
Clean Html5 and css3 should achieve everything. Only use JS for specific interactivity.
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. 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.