3 ms·

My take: the fundamental problem is that HTML was never completed as a hypertext. - Why should only anchors and forms be able to make HTTP requests? - Why sho

My take: the fundamental problem is that HTML was never completed as a hypertext. - Why should only anchors and forms be able to make HTTP requests? - Why should only click and submit events trigger them? - Why should only GETs and sometimes POSTs be available? - Why should you have to replace the entire screen every time? htmx tries to complete HTML as a hypertext, removing each of these limitations, so you can write advanced interfaces using plain ol' markup: https://htmx.org https://htmx.org

digitaltrees 6y ago
I love it
obiefernandez 6y ago
This looks super interesting, thanks for posting. Can't help but wonder how much cooler it would be if only the attributes were not hx- namespaced. Is that not done for some technical reason?
- recursivedoubts 6y ago
  I just followed other frameworks on it, feels a little presumptuous and dangerous to use unqualified top level attributes. I could make it pluggable so you could do away with the hx- if you wanted to. Most people want to go the other way and use data- prefixes (which is supported out of the box)
imtringued 6y ago
I always am irritated when people insist on disabling javascript. The fundamental problem is that HTML on its own is flawed and unusable. Even the most basic features that users expect will require a few lines of javascript. Half of the webapps I make are just digitalizing existing paper forms. There is barely any javascript but the javascript that is there is absolutely essential. If the noscript warriors actually thought about ways of making plain HTML good enough that a JS free site was possible then I'd have sympathy for them. As it is right now they are asking the impossible. They would even complain about htmx even though it is exactly what they want.
SahAssar 6y ago
I don't see any reasonable way for htmx to do error handling without writing your own JS, it has an example of 'ic-post-errors-to', but that only seems to be for error tracking and requires writing a whole other dialect of js (hyperscript). Examples like https://htmx.org/events/#htmx:validation:validate https://htmx.org/events/#htmx:validation:validate also seem weird. Basically it replaces JS with it's own scripting dialect that is written inline in a attribute and that dialect does not even have syntax highlighting on their own site. Is it actually more simple than writing the equivalent html+js when you add on all the real-world requirements?
- recursivedoubts 6y ago
  Validation, as with the normal html request/response cycle, is done on the server side. Here is an example: https://htmx.org/examples/inline-validation/ https://htmx.org/examples/inline-validation/ It's the normal web 1.0 thing: validate your data server side and render an error message/flagged input which is returned as html. The latest dev version plugs into the HTML5 validation API so that client side validations are respected, but that doesn't require any scripting. Htmx does fire a lot of events that you can hook into if you wish, and hyperscript is an experimental mechanism for doing so, but neither are the focus or a requirement for using htmx. From experience, yes, it is much simpler than the javascript-framework based approach, at least for many use cases.
  - SahAssar 6y ago
    So how do you propose to do error handling? I mean proper error handling where you can show the user a meaningful message and that can handle normal stuff like timeouts, 500's 400's and so on.
    - recursivedoubts 6y ago
      Ah, you mean system errors, not application-level errors. App errors are handled the normal way. I usually try to avoid 500 and 400 errors in my applications, but for something like a network error, that obviously has to be handled client-side since, well, the server isn't available. So you can write a three liner to handle it: htmx.on("htmx:onLoadError", function(evt) { htmx.find("#error-div").innerHTML = "A network error occured..."; // or whatever } This isn't code that would be hit regularly, unless your application or the network is in pretty bad shape.

digitaltrees 6y ago

I love it

obiefernandez 6y ago

This looks super interesting, thanks for posting. Can't help but wonder how much cooler it would be if only the attributes were not hx- namespaced. Is that not done for some technical reason?

recursivedoubts 6y ago
I just followed other frameworks on it, feels a little presumptuous and dangerous to use unqualified top level attributes. I could make it pluggable so you could do away with the hx- if you wanted to. Most people want to go the other way and use data- prefixes (which is supported out of the box)

imtringued 6y ago

I always am irritated when people insist on disabling javascript. The fundamental problem is that HTML on its own is flawed and unusable. Even the most basic features that users expect will require a few lines of javascript. Half of the webapps I make are just digitalizing existing paper forms. There is barely any javascript but the javascript that is there is absolutely essential. If the noscript warriors actually thought about ways of making plain HTML good enough that a JS free site was possible then I'd have sympathy for them. As it is right now they are asking the impossible. They would even complain about htmx even though it is exactly what they want.

SahAssar 6y ago

I don't see any reasonable way for htmx to do error handling without writing your own JS, it has an example of 'ic-post-errors-to', but that only seems to be for error tracking and requires writing a whole other dialect of js (hyperscript). Examples like https://htmx.org/events/#htmx:validation:validate https://htmx.org/events/#htmx:validation:validate also seem weird. Basically it replaces JS with it's own scripting dialect that is written inline in a attribute and that dialect does not even have syntax highlighting on their own site. Is it actually more simple than writing the equivalent html+js when you add on all the real-world requirements?

recursivedoubts 6y ago
Validation, as with the normal html request/response cycle, is done on the server side. Here is an example: https://htmx.org/examples/inline-validation/ https://htmx.org/examples/inline-validation/ It's the normal web 1.0 thing: validate your data server side and render an error message/flagged input which is returned as html. The latest dev version plugs into the HTML5 validation API so that client side validations are respected, but that doesn't require any scripting. Htmx does fire a lot of events that you can hook into if you wish, and hyperscript is an experimental mechanism for doing so, but neither are the focus or a requirement for using htmx. From experience, yes, it is much simpler than the javascript-framework based approach, at least for many use cases.
- SahAssar 6y ago
  So how do you propose to do error handling? I mean proper error handling where you can show the user a meaningful message and that can handle normal stuff like timeouts, 500's 400's and so on.
  - recursivedoubts 6y ago
    Ah, you mean system errors, not application-level errors. App errors are handled the normal way. I usually try to avoid 500 and 400 errors in my applications, but for something like a network error, that obviously has to be handled client-side since, well, the server isn't available. So you can write a three liner to handle it: htmx.on("htmx:onLoadError", function(evt) { htmx.find("#error-div").innerHTML = "A network error occured..."; // or whatever } This isn't code that would be hit regularly, unless your application or the network is in pretty bad shape.