Hacker News Reader

Comment by recursivedoubts | Hacker News Reader

Hi there, I'm the creator of _hyperscript and htmx, happy to answer questions.

_hyperscript is much more speculative than htmx, but it is working out pretty nicely. One aspect of the language that HN readers might find interesting is that it is async-transparent: the distinction between synchronous and asynchronous code is largely hidden:

https://hyperscript.org/docs/#async

This allows for some pretty interesting programming techniques, such as event-driven control flow:

https://hyperscript.org/docs/#event-control-flow

One thing to be aware of with _hyperscript is that it is intended as a light weight, event oriented scripting language, I would not recommend a huge application being build out in it exclusively. It is designed to make it easy to plug into the event models of htmx and other libraries.

EDIT: I should also mention, it is still very early in development (0.0.9)

View on HN

Some people are writing an alternative, Twinspark, inspired by intercooler/htmx but without inheritance and with batching [1]. Avoiding inheritance seems especially good to me. I'm wondering what is your take on removing inheritance/providing an alternative to it?

[1] https://solovyov.net/blog/2020/a-tale-of-webpage-speed-or-th...

I don't have a strong opinion on it: I think inheritance has worked out pretty well when I've used it (e.g. if I want a bunch of links to target a specific div, I can hoist the hx-target to a parent.)

But I salute twinspark as well and if it dovetails better with your sensibilities I encourage you to use it.

Do you work alone by chance? Because it's pretty easy to avoid problems when you work alone, remember what exactly the code does. However, when working even in a small team (3-5 devs), it's becoming much harder to avoid such footguns.

It would be really cool to see two projects merge (htmx and twinspark) and join forces.

The async transparency aspect is very interesting from a design POV! What were your inspirations for that?

I just hated the way that callbacks look or that you had to color your functions:

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...

For light weight scripting I didn't want to have to think about that. I had implement a "wait" command in the old ic-action attribute from intercooler:

https://intercoolerjs.org/attributes/ic-action.html

And I wanted to generalize that.

(A motivation for creating _hyperscript was because I removed ic-action as well as a bunch of other event-based attributes when rewrote intercooler.js as htmx: https://hyperscript.org/docs/#history)

The async transparency stuff is really interesting, and reminds me of a comment[1] I made a couple of years ago here on HN about async/await and how I think it's backwards from what it ought to be. Really glad to see you exploring this further, I think you're on to something.

That post from Bob Nystrom's blog makes the point I was trying to make much more eloquently than I could, thanks for sharing!

[1]: https://news.ycombinator.com/item?id=21065806

Yeah, it's really annoying that if you want to introduce some async behaviour in a function, you end up having to deal with it at all the call sites

In the intro section I walk through adding a fetch to some code that jams text into a button and you can see how you don't end up having to change your code to do it: you just write the normal linear code with a fetch command in it:

https://hyperscript.org/docs/#introduction

  <button class='btn primary' _="on click fetch  /clickedMessage then transition opacity to 0
                                 put the result into me then transition opacity to 1
                                 wait 2s then transition opacity to 0
                                 put 'Click Me!' into me then transition opacity to 1">
    Click Me!
  </button>

The fetch, wait and transition commands are asynchronous (in javascript terms) but to hyperscript it's all just linear code.

Is this inspired by HyperTalk/AppleScript, which are also english-like?

yes, explicitly by hypertalk (I didn't use appletalk much and didn't like it when I did.)

Very cool! Just a heads up there's a bug with the event control flow example where it requires pressing the "stop pulsing" button the same number of times you've pressed the "start pulsing" button. I figured the behavior should be regardless of how many times I've clicked "start pulsing" the next time I press stop, it should stop.

Ah, you've stumbled on the event queuing behaviour of hyperscript:

If a triggering event is received while an event handler is executing, you can specify various behaviours:

https://hyperscript.org/features/on/#queueing

The default is queue last, which will queue the last event and trigger the event handler again once it completes. I agree that is wrong in this case, and so it should specify `queue none` in the handler. I will update the code.

Thank you for taking a close look at the example!

Have you any comparison with Turbo?

https://turbo.hotwire.dev/handbook/introduction

Reply on news.ycombinator.com