Thought the exact same when I first started using it, then realised the benefits of the syntax:

1. It allows for the "async transparency" feature to work!

2. It enables first class event handling in a much less verbose way than Javascript. Unlocks the power of the native event system.

3. Less verbose ways to do Locality of Behavior.

You get a number of escape hatches, and hyperscript is capable of being mixed with javascript:

Call javascript directly

  _='on click call alert("Javascript called directly")'

Embed javascript directly

  _='on click js alert("Javascript mixed in hyperscript") end'

Next release will bring javascript comments to make learning and migrating blocks of code easier.

  // and /* ... */

Also I must say you do get used to the syntax relatively quickly.

I am thinking if it could be more hybrid. It seems to move too far to the "General English" spectrum.

If we could replace the most common syntax with 2 to 3 symbols to balance things out.

that's an understandable reaction to the language

but, I think you have to admit that the result is very readable, even if it might be hard to write at first. I programmed in HyperTalk as a kid and always missed how easy it was to read and, for small embedded things like toggling a class

  toggle .foo on #bar

i really like how it looks

AppleTalk was always kind of a mess because they didn't give you much syntactic support for working with apps, so you ended up guessing strings to pass around when what you really wanted was syntax. hyperscript has DOM-specific syntax (as well as an open, pluggable grammar) so it is more tightly focused on those operations and, I hope, less ugly than what AppleTalk ended up looking like

It definitely favors code read time over write time, though. We'll see if it goes anywhere.

HyperTalk and AppleTalk are both easy to read, but a little hard to write--AppleScript moreso than HyperTalk. I think it's a reasonable tradeoff to make. It may be too much of a pain form some, but I did some substantial work in HyperTalk and AppleScript (and its immediate ancestor, SK8Script), and found that I got used to it. I wouldn't say that I ever loved it, but I didn't mind it so much after I got used to it.

At the risk of veering into inside baseball (I worked on SK8Script, HyperCard, and AppleScript over the course of a few years), a problem with AppleScript was that it was really only the outline of a language with a pluggable grammar and pluggable semantics. One of my colleagues working on it characterized it as more like a network protocol than a programming language. It specified some fairly broad abstractions (containers, elements, documents, and so on), but left most of the details and the vocabulary up to applications, so the same nouns and verbs could mean wildly different things in different contexts. That made it even harder to write.

On the other hand, it was usually really easy to read and understand, which is handy. By the way, I'm finding htmx and hyperscript quite useful.

It certainly is subjective. This is where AppleScript really fell down--English is inverted, but typical programming starts with a noun then does a verb to it.

Given it's written <verb> <noun> (toggle a on x) rather than <noun> <verb> (x.toggle(a)), I don't see how you can know the space of verbs the noun will accept without perhaps starting with a guess and then seeing what the tool provides or something? I get it's more constrained than AppleTalk, but does that actually solve the issue in practice?

I think the fact that the language is designed to be embedded on elements makes it clear that the implicit subject and object is the current element (the "me" or "I" symbol in hyperscript

  <div _="on mousenter toggle .expand" ...>
    ...
  </div>

So the language comes across as imperative statements, with the current element being the default subject and object, as with english instructions. Most commands (statements) accept a noun target:

  <div _="on mousenter toggle .expand on the closest <section/>" ...>
    ...
  </div>

But, due to the embedded nature of the language it still comes across as you telling the diff to toggle the class on the other section.

There is also a tell command that allows you to switch the default object (which you can access explicitly in the "you" and "yourself" symbols:

  <div _="on mousenter 
            tell the closest <section/>
              toggle .expand" ...>
    ...
  </div>

Insanity, I know. There are also three, count'em three different ways to access properties:

   set x to arr.length
   set y to the arr's length
   set z to the length of the array

Fun! Also insane.

But also fun!

I wonder if it could have been more Logo/Rebol inspired instead of Hypertalk. I guess that would be like:

    put new date next <output/>

Assuming in that "then" is superfluous since there's nothing async about making a date. Though because "new Date()" can take arguments it's perhaps unclear how to parse this.

For events:

    on click [toggle .clicked]

That would imply that "click" is a defined object/variable. I'm not sure how _hyperscript is evaluated, maybe "on" gets to decide how to evaluate its arguments. You can also imagine "onclick" as a command.

Using another example from the page:

    on click [call aJavascriptFunction()
              then [wait 10s]
              then [call anotherJavascriptFunction()]]

"then" would be a reasonable command, though making it a special form is also reasonable. Though maybe "then" just means ";" – a statement terminator? And everything is async. That would be reasonable, the only trick is when you have a promise as an argument to a function, do you resolve the promise first or not? There are use cases for both.

Thinking through some other examples, I think _hyperscript syntax does make it easier to handle optional arguments. Like "on every click" or "on click queue all"... where these are kind of like flags. Logo-style syntax doesn't handle that well.