Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

I'm the creator of htmx, glad to see this make HN.

Happy to answer questions.

I only wanna to say thanks for this project. I make a ecommerce platform on Rust (not yet public) and it become one of the main reason I could do this as fast as it have. Combining with tailwindcss I think is near the holy grail for backend-first web apps :)

fantastic to hear, good luck!

I'm also grateful for HTMX and the excellent development community that the project owner has grown. Like the parent, I'm also using HTMX + tailwindcss; rather than Rust, I'm using Julia.

Why is interacting with the examples slow? https://htmx.org/examples/delete-row/

I added a 300ms delay in the ajax mock library that I'm using (sinon):

https://htmx.org/js/demo.js

to better simulate real network latency for things like progress indicators, etc.

Congratulations! I've been using Intercooler for a while now and haven't tried htmx yet, but am looking forward to switching over. I really appreciate that you're continuing to work on tools that make this approach to webdev easier.

I know the post says not to do it, but I'm planning to convert an existing project from Intercooler. Anything specific that I should watch out for while doing it, or recommendations for new capabilities that I could take advantage of as part of the switch?

Shouldn't be too hard unless:

- you got deep into the custom headers

- you used ic-action heavily

- you used the path-dependency mechanism heavily

On a sibling comment I mentioned some new features in htmx:

- no jQuery dependency

- trigger filters: https://htmx.org/attributes/hx-trigger/

- HTML validation integration: https://htmx.org/docs/#validation

- Out of band swaps: https://htmx.org/docs/#oob_swaps

- htmx has a more advanced swapping mechanism (swap and settle, not documented well yet) that makes it easier to use CSS transitions

Happy to help out with the transition if you jump on the discord:

https://htmx.org/discord

The code examples look like this[1] on Firefox with Enhanced Tracking Protection enabled. I had to disable ETP for it to render correctly.

[1] https://i.imgur.com/lIiQuE6.png

huh, ETP must be blocking unpkg...

I'll move that into the /js directory instead, thanks for the heads up

I really, really, really enjoyed working with intercooler.js on a previous project... I understand there’s no immediate need to upgrade, but what new features does this provide for new projects?

By the way, thanks!

Some things I can think of:

- no jQuery dependency

- trigger filters: https://htmx.org/attributes/hx-trigger/

- HTML validation integration: https://htmx.org/docs/#validation

- Out of band swaps: https://htmx.org/docs/#oob_swaps

- htmx has a more advanced swapping mechanism (swap and settle, not documented well yet) that makes it easier to use CSS transitions

Can you please explain how to build a "larger" app with HTMX?

The way I understand htmx, it will replace the tag itself with an ajax response from the server. This is great for submit feedback and flash messages.

What if you want to click a htmx-button and replace something else outside of the tag with htmx?

You can use the hx-target to target other elements in the DOM:

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

You can also use Out of Band swaps to replace arbitrary DOM content:

https://htmx.org/docs/#oob_swaps

htmx sounds great! I am interested in this from the security angle. If browsers were to natively support htmx (or something similarly declarative), it might reduce the need for Javascript and hence improve security.

It definitely helps improve your security complexity over things like, say, GraphQL, where row-level security is necessary to prevent people from firing off random queries from the browser console.

There are a couple of places in the code where eval()/Function code are fire off which require some security-thinking:

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

hx-trigger evaluate expressions for the event filter. This typically isn't an issue since you would be unlikely to use user input in this context.

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

hx-vars evaluate expressions to include in the request. This is a bit more dangerous, because you might try to pass values through with this mechanism. If this includes user input then you should use hx-vals instead:

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

Congratulations! What are the next directions for the scripting language?

I know htmx is a good idea, still waiting to see if hyperscript pans out. :)

It still needs some pretty basic stuff like for loops and so forth. The goal is for it to be a embeddable, DOM-friendly & transparently asynchronous scripting language so you don't need to deal w/ callbacks:

  on click 
    add .throb to me
    wait 3s
    remove .throb from me
  end

I'd like to make ajax and web workers trivial to use from it. I hope to have a lot more time for it in the next year, now that htmx is stable. We'll see. Suggestions welcome!

edit: one thing I'm pretty sure about is that I'm going to go back to an interpreted runtime over the transpilation I'm doing now

What are the advantages of switching to an interpreted runtime?

Btw I used htmx for a small project a few months ago and it was super easy to get working. Definitely recommend it, and looking forward to trying out 1.0 as soon as I have a chance!

more flexibility and easier to make it async-transparent since the interpreter runtime is basically a built in continuation system :)

This is very similar to Stimulus which i don’t find much difference from. Who’s your target developer?

Reference: https://stimulusjs.org/

:) It's very different than stimulus.

htmx extends HTML as a hypertext, it isn't tied to any particular backend and doesn't have any binding concepts. It's really a complete different concept.

I'd recommend reading the docs:

https://htmx.org/docs/

Sure okay, the DSLs are different.

So who’s the target audience? I’m curious to know the typical developer attracted to libraries like this.

That is t saying it’s bad or anything. It’s different enough I have a genuine curiosity

The target audience is all of them. :)

I think htmx scales up and down pretty well: web developer newbs who don't want to sink a ton of time into a JS framework, as well as veteran web developers who want to stick with hypertext for the majority of their web apps.

HTMX encodes server interaction in hypertext rather than in Javascript. For those with intensive back-end logic and only light interface needs, HTMX offers a incremental way to add front-end interactivity without having to take the deep dive into Javascript frameworks. Longer term, the concept of encoding server interaction in hypertext seems rather novel to me. Perhaps this approach may be one of many missing pieces towards an ecosystem of interoperable hypertext-based web components?

In our agency augmented HTML (Htmx/Intercooler, AlpineJS, etc.) is very useful for web designers, they can go further with interactions and behaviors while staying in a HTML/CSS environment. Also it helps a lot in the communication between the design and developer teams, because there is a lot more understanding of what's going on.

That's great to hear and one of the big benefits to an HTML-first architecture: it's much easier to understand the entire stack, for feature development as well as optimization.

Thanks for mentioning it!

Reply on news.ycombinator.com