7 ms·

hello, I'm the creator of htmx (and originally intercooler) I just released 0.0.4, so htmx is still very young, but it's got a decent test suite: https://htmx.

hello, I'm the creator of htmx (and originally intercooler) I just released 0.0.4, so htmx is still very young, but it's got a decent test suite: https://htmx.org/test/0.0.4/test/ https://htmx.org/test/0.0.4/test/ there is a nice extension mechanism: https://htmx.org/extensions/ https://htmx.org/extensions/ and some very rough docs on how to pull off pure HTML animations: https://htmx.org/examples/animations/ https://htmx.org/examples/animations/ happy to answer questions

yepthatsreality 6y ago
What development challenges do you see ahead on the road to v1.0?
- recursivedoubts 6y ago
  Well, I'd like to buff the test suite out, and I really don't know if I got the web socket API right. Using HTML w/ ajax is natural enough, but using it with web sockets? We'll see. I guess the hardest thing is getting the word out, but thankfully oftenwrong has done that for me. :)
digitaltrees 6y ago
Amazing work. Thanks for pushing it forward. The name is great too.
mishu2 6y ago
Thank you for your work, I've been a happy intercooler user for a while now. It's great to see the jquery dependency going away.
gavinray 6y ago
I've heard of Intercooler before and saw htmx on Github trending a few weeks ago. A question about this example: https://htmx.org/examples/inline-validation/ https://htmx.org/examples/inline-validation/ This paradigm revolves around sending validation requests to server-side endpoints, is there any reason to put that load on the server rather than validate it on the page prior to submit with JS? Or scalability issues? Not being antagonistic, genuinely curious because I've not seen inline validation done this way.
- recursivedoubts 6y ago
  I'm not dogmatic about it. Some validation has to be done on the server side (e.g. unique emails) and any validation has to be redone on the server anyway since the client side isn't a trusted computing environment, but I can see doing both.
  - gavinray 6y ago
    Ahh got it, yeah in this case that makes a ton of sense. No way to know with emails about uniqueness constraints until it hits the backend anyways. I've been playing around with local demo, is it possible through extensions to make a wrapper that can perhaps compose GraphQL query inputs from forms?
    - recursivedoubts 6y ago
      yeah, you could use the json encoding extension as a starting point: https://htmx.org/extensions/json-enc/ https://htmx.org/extensions/json-enc/
      - gavinray 6y ago
        I was just trying that, it seemed not to be working for some reason. I manually copy-pasted the source code into my app, and got: htmx.min.js:1 TypeError: Cannot set property 'Content-Type' of undefined at Object.encodeParameters ((index):11) at htmx.min.js:1 The code for it is: xhr.requestHeaders['Content-Type'] = 'application/json' But I believe it should be xhr.setRequestHeader('Content-Type', 'application/json') When I do this, it seems to work https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/setRequestHeader https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...
        recursivedoubts 6y ago
        looks like there's a bug in the json-enc extension: it's relying on the test mock which has a requestHeaders property that a real xhr won't. so the tests passed but it doesn't work irl... good catch! want to submit a pull request fix?
digitaltrees 6y ago
I like the name htmx better than kutty. Easier to remember and feels more official.
- recursivedoubts 6y ago
  i liked kutty a lot, but it just meant too many things in too many other languages lookin' at you, dutch
  - edko 6y ago
    I am sure you must be referring to someone from the Katholieke Universiteit Tilburg.
    - himlion 6y ago
      it's a funny meme, but it was never called that. See from wikipedia: >Omdat Katholieke Universiteit Tilburg tot een ongewenste afkorting zou leiden, werd het Katholieke Universiteit Brabant (KUB).
      - andybak 6y ago
        Ah - like the old University of North Texas gag: https://www.chemicalcode.com/litmus-week-29-2/cunt-mug-university-of-north-texas-1_465_571_int/ https://www.chemicalcode.com/litmus-week-29-2/cunt-mug-unive...
  - JGM_io 6y ago
    Dutchies represent! Kut-zooi zeg
antman 6y ago
Does it have the same features with intercooler or are there any features of intercooler that will not be on the scope of this project? Edit: Main concern is whether to start a new project now with intercooler or htmx
- recursivedoubts 6y ago
  htmx is a lot more tightly focused. With intercooler I was trying to replace all javascript everywhere, but with htmx I'm really trying to focus in on the request/response stuff and make it an extensible base for other things. I am planning on supporting both intercooler and htmx for the forseeable future. I have a large app written in intercooler and I'm not porting it over any time soon. If I were starting a new project I'd use htmx, but then I know the developer pretty well if there are problems. :)
combatentropy 6y ago
I have a lot of respect for intercooler and wish something like it had become the go-to, with more complicated things like React reserved for apps that really need it. I'm curious why you are starting over. What is different from intercooler besides no need for jQuery? Why HTMX instead of Intercooler 2.0?
- recursivedoubts 6y ago
  I wanted the freedom to completely reimplement things and drop ideas that didn't work out in intercooler I also wanted to stress that htmx isn't just another javascript library, competing with react and the rest. It is focused on HTML and extending HTML to make it a powerful and complete hypertext. I think that the name htmx captures that idea pretty well.
  - fsateler 6y ago
    What ideas do you think didn't work out? Btw, I'm currently a very happy user of intercooler. Thanks for the awesome lib.
    - recursivedoubts 6y ago
      I think the implicit dependency system is a good example that ended up confusing people as much as it helped: http://intercoolerjs.org/docs.html#dependencies http://intercoolerjs.org/docs.html#dependencies The fact that intercooler didn't have an extension mechanism meant I had to heap a lot of stuff into the core (e.g. ic-action) that was interesting and useful, but made the code base messy and unfocused. htmx has an extension mechanism, so you can pull in stuff like this (or write your own extension): https://htmx.org/extensions/ https://htmx.org/extensions/ that will take pressure off me to keep adding stuff to htmx and simply add more extensions. The dependencies idea from intercooler, for example, ended up as this extension: https://htmx.org/extensions/path-deps/ https://htmx.org/extensions/path-deps/
      - spyckie2 6y ago
dzonga 6y ago
intercooler looked cool. never got to try it due to jquery dependency. but will definitely give htmx a try. my current project will either be htmx or alpine.js. Thank you for your work, in preventing SPA bloat ie providing an alternative
- m-localhost 6y ago
  htmx looks like the perfect thing between UnpolyJS and AlpineJS. In Unpoly I miss the optional clientside templating which htmx seems to support as extension. AlpineJS lacks the http stuff (headers, requests). Really exciting times for using old school html without downloading 5000 js files via npm.
  - wysewun 6y ago
    What about using alpine and htmx together? So you get the front end reactivity as well
arkis22 6y ago
thank you
politelemon 6y ago
On the click-to-load example https://htmx.org/examples/click-to-load/ https://htmx.org/examples/click-to-load/ I see no network traffic when I click the 'load more agents' button. Am I missing something, where are the requests going?
- andybak 6y ago
  For the docs they are faking server side (view source starting line 138 )
- zo1 6y ago
  There is a "Server Requests" slide-up at the bottom of the page. If you expand it it has a nice interface to show requests and responses that are "happening" behind the scenes.
SrslyJosh 6y ago
What about accessibility? It'd be great to see the docs and examples put more focus on accessibility, both for non-JS clients and for clients that may be better served by not replacing elements, like screen readers. And, based on some of the comments here, it seems like some people may have forgotten how to do anything that doesn't depend on AJAX. ;-)
- RyanGoosling 6y ago
  The folks around these parts give me a great sense of job security.
BiteCode_dev 6y ago
This is super cool, and you probably have a business model here: create a proxy, allow people to pay you for it, and use it transparently with htmx. This way they can create entire products with zero backend code by simply calling 3rd party API. This is probably also some very nice static blog engine concept to imagine around this. And some mix with VueJS as well.
deleted 6y ago
[deleted]

yepthatsreality 6y ago

What development challenges do you see ahead on the road to v1.0?

recursivedoubts 6y ago
Well, I'd like to buff the test suite out, and I really don't know if I got the web socket API right. Using HTML w/ ajax is natural enough, but using it with web sockets? We'll see. I guess the hardest thing is getting the word out, but thankfully oftenwrong has done that for me. :)

digitaltrees 6y ago

Amazing work. Thanks for pushing it forward. The name is great too.

mishu2 6y ago

Thank you for your work, I've been a happy intercooler user for a while now. It's great to see the jquery dependency going away.

gavinray 6y ago

I've heard of Intercooler before and saw htmx on Github trending a few weeks ago. A question about this example: https://htmx.org/examples/inline-validation/ https://htmx.org/examples/inline-validation/ This paradigm revolves around sending validation requests to server-side endpoints, is there any reason to put that load on the server rather than validate it on the page prior to submit with JS? Or scalability issues? Not being antagonistic, genuinely curious because I've not seen inline validation done this way.

recursivedoubts 6y ago
I'm not dogmatic about it. Some validation has to be done on the server side (e.g. unique emails) and any validation has to be redone on the server anyway since the client side isn't a trusted computing environment, but I can see doing both.
- gavinray 6y ago
  Ahh got it, yeah in this case that makes a ton of sense. No way to know with emails about uniqueness constraints until it hits the backend anyways. I've been playing around with local demo, is it possible through extensions to make a wrapper that can perhaps compose GraphQL query inputs from forms?
  - recursivedoubts 6y ago
    yeah, you could use the json encoding extension as a starting point: https://htmx.org/extensions/json-enc/ https://htmx.org/extensions/json-enc/
    - gavinray 6y ago
      I was just trying that, it seemed not to be working for some reason. I manually copy-pasted the source code into my app, and got: htmx.min.js:1 TypeError: Cannot set property 'Content-Type' of undefined at Object.encodeParameters ((index):11) at htmx.min.js:1 The code for it is: xhr.requestHeaders['Content-Type'] = 'application/json' But I believe it should be xhr.setRequestHeader('Content-Type', 'application/json') When I do this, it seems to work https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/setRequestHeader https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...
      - recursivedoubts 6y ago
        looks like there's a bug in the json-enc extension: it's relying on the test mock which has a requestHeaders property that a real xhr won't. so the tests passed but it doesn't work irl... good catch! want to submit a pull request fix?

digitaltrees 6y ago

I like the name htmx better than kutty. Easier to remember and feels more official.

recursivedoubts 6y ago
i liked kutty a lot, but it just meant too many things in too many other languages lookin' at you, dutch
- edko 6y ago
  I am sure you must be referring to someone from the Katholieke Universiteit Tilburg.
  - himlion 6y ago
    it's a funny meme, but it was never called that. See from wikipedia: >Omdat Katholieke Universiteit Tilburg tot een ongewenste afkorting zou leiden, werd het Katholieke Universiteit Brabant (KUB).
    - andybak 6y ago
      Ah - like the old University of North Texas gag: https://www.chemicalcode.com/litmus-week-29-2/cunt-mug-university-of-north-texas-1_465_571_int/ https://www.chemicalcode.com/litmus-week-29-2/cunt-mug-unive...
- JGM_io 6y ago
  Dutchies represent! Kut-zooi zeg

antman 6y ago

Does it have the same features with intercooler or are there any features of intercooler that will not be on the scope of this project? Edit: Main concern is whether to start a new project now with intercooler or htmx

recursivedoubts 6y ago
htmx is a lot more tightly focused. With intercooler I was trying to replace all javascript everywhere, but with htmx I'm really trying to focus in on the request/response stuff and make it an extensible base for other things. I am planning on supporting both intercooler and htmx for the forseeable future. I have a large app written in intercooler and I'm not porting it over any time soon. If I were starting a new project I'd use htmx, but then I know the developer pretty well if there are problems. :)

combatentropy 6y ago

I have a lot of respect for intercooler and wish something like it had become the go-to, with more complicated things like React reserved for apps that really need it. I'm curious why you are starting over. What is different from intercooler besides no need for jQuery? Why HTMX instead of Intercooler 2.0?

recursivedoubts 6y ago
I wanted the freedom to completely reimplement things and drop ideas that didn't work out in intercooler I also wanted to stress that htmx isn't just another javascript library, competing with react and the rest. It is focused on HTML and extending HTML to make it a powerful and complete hypertext. I think that the name htmx captures that idea pretty well.
- fsateler 6y ago
  What ideas do you think didn't work out? Btw, I'm currently a very happy user of intercooler. Thanks for the awesome lib.
  - recursivedoubts 6y ago
    I think the implicit dependency system is a good example that ended up confusing people as much as it helped: http://intercoolerjs.org/docs.html#dependencies http://intercoolerjs.org/docs.html#dependencies The fact that intercooler didn't have an extension mechanism meant I had to heap a lot of stuff into the core (e.g. ic-action) that was interesting and useful, but made the code base messy and unfocused. htmx has an extension mechanism, so you can pull in stuff like this (or write your own extension): https://htmx.org/extensions/ https://htmx.org/extensions/ that will take pressure off me to keep adding stuff to htmx and simply add more extensions. The dependencies idea from intercooler, for example, ended up as this extension: https://htmx.org/extensions/path-deps/ https://htmx.org/extensions/path-deps/
    - spyckie2 6y ago

dzonga 6y ago

intercooler looked cool. never got to try it due to jquery dependency. but will definitely give htmx a try. my current project will either be htmx or alpine.js. Thank you for your work, in preventing SPA bloat ie providing an alternative

m-localhost 6y ago
htmx looks like the perfect thing between UnpolyJS and AlpineJS. In Unpoly I miss the optional clientside templating which htmx seems to support as extension. AlpineJS lacks the http stuff (headers, requests). Really exciting times for using old school html without downloading 5000 js files via npm.
- wysewun 6y ago
  What about using alpine and htmx together? So you get the front end reactivity as well

arkis22 6y ago

thank you

politelemon 6y ago

On the click-to-load example https://htmx.org/examples/click-to-load/ https://htmx.org/examples/click-to-load/ I see no network traffic when I click the 'load more agents' button. Am I missing something, where are the requests going?

andybak 6y ago
For the docs they are faking server side (view source starting line 138 )
zo1 6y ago
There is a "Server Requests" slide-up at the bottom of the page. If you expand it it has a nice interface to show requests and responses that are "happening" behind the scenes.

SrslyJosh 6y ago

What about accessibility? It'd be great to see the docs and examples put more focus on accessibility, both for non-JS clients and for clients that may be better served by not replacing elements, like screen readers. And, based on some of the comments here, it seems like some people may have forgotten how to do anything that doesn't depend on AJAX. ;-)

RyanGoosling 6y ago
The folks around these parts give me a great sense of job security.

BiteCode_dev 6y ago

This is super cool, and you probably have a business model here: create a proxy, allow people to pay you for it, and use it transparently with htmx. This way they can create entire products with zero backend code by simply calling 3rd party API. This is probably also some very nice static blog engine concept to imagine around this. And some mix with VueJS as well.

deleted 6y ago

[deleted]