Hacker News Reader

Hacker News

Comment by recursivedoubts | Hacker News Reader

Parent Full thread

recursivedoubts

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/

there is a nice extension mechanism:

https://htmx.org/extensions/

and some very rough docs on how to pull off pure HTML animations:

https://htmx.org/examples/animations/

happy to answer questions

View on HN

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?

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.

What ideas do you think didn't work out?

Btw, I'm currently a very happy user of intercooler. Thanks for the awesome lib.

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

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/

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/

Interesting.

I was a fan of intercooler and used it in production more than once but for some reason I could never get my head round the dependency functionality and ended up just ignoring it.

Intercooler works beautifully alongside Django and Django Rest Framework and I look forward to trying out htmx.

thank you andy, i have always appreciated your positive feedback on intercooler :)

really cool to hear insights from package creators, thanks for sharing

Do you believe in equal access for no-JS?

as much as is practical

https://htmx.org/attributes/hx-boost/

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/

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.

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.

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?

Front-end validations should always be viewed as a suggestion. the server is the real gatekeeper

I should have rephrased it haha, I more meant the act of sending each set of keystrokes validation as a server-side request. No doubt that the backend is going to be the ultimate judge when "submit" is pressed.

yeah, you could use the json encoding extension as a starting point:

https://htmx.org/extensions/json-enc/

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

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?

Sure =D

Done!

Also this extension API is pretty straightforward, the element reference and parameters are right in the args so it's an easy mapping to GraphQL query strings from there. Awesome!

I was able to get a minimal version working using just this (with json-enc extension patch):

    <input
      type="text"
      name="query"
      hx-ext="json-enc"
      hx-post="http://localhost:8080/v1/graphql"
      hx-trigger="keyup changed delay:500ms"
      hx-target="#search-results"
      placeholder="<GRAPHQL QUERY TEXT HERE>"
    />
    <div id="search-results"></div>

Pretty cool

i'd love a graphql extension for the next release, if you are interested

Yeah, definitely game to help out there =)

Hell yea

The idea behind libs like htmx is that you get to have some of the niceties of a SPA, without writing any JS and requiring minimal computational power from the client.

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

The folks around these parts give me a great sense of job security.

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

i liked kutty a lot, but it just meant too many things in too many other languages

lookin' at you, dutch

I am sure you must be referring to someone from the Katholieke Universiteit Tilburg.

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

Ah - like the old University of North Texas gag: https://www.chemicalcode.com/litmus-week-29-2/cunt-mug-unive...

Dutchies represent!

Kut-zooi zeg

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

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

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.

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

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

On the click-to-load example

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?

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.

For the docs they are faking server side (view source starting line 138 )

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

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.

What about using alpine and htmx together? So you get the front end reactivity as well

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.

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

thank you

Reply on news.ycombinator.com