I'm always interested in and supportive of novel languages (especially for the web) With that said: on click repeat until event stop add .pulse then set

I'm always interested in and supportive of novel languages (especially for the web) With that said: on click repeat until event stop add .pulse then settle remove .pulse then settle end There's a trait that you sometimes see with languages that are trying to be... very "human-readable"[1] where they do things like: 1) Remove as many "delimiting characters" as possible 2) Introduce a lot of bespoke keywords so that code reads as much "like english" as possible The thing is... this does read very much like human language, but that doesn't necessarily mean it's more readable. It's very hard to mentally decompose the above code into its parts, for one thing. What can come after "on click"? Any arbitrary code? Only a certain subset, of which "repeat" expressions (?) are one member? Can you use "add" and "remove" on anything other than CSS classes? Is ".pulse" the only "argument" being passed to add and remove, or are "then" and "settle" further arguments? Or are they special-case keywords that can come after any statement? Or only after "add" and "remove"? Why is a "then" clause needed when we're already in an imperative context? Is "settle" another keyword, or a function we're calling? I'm sure all of these questions are answered in the docs. But as a new user of the language there's going to be a much bigger learning curve compared to other languages, because you have to go through and re-learn the very most fundamental language constructs and the rules around their usage, instead of leaning on your existing knowledge (or what can be inferred based on syntax alone, because not much can be). Adding that up-front cost isn't intrinsically wrong, but it is a cost, so you've have to have a good reason for it. In a language like this, where the major value-proposition seems to be "minimum overhead to just jump in and start wiring simple UI constructs in a readable way", that cost seems to directly sabotage the main purpose of the language. And the main benefits I can see are typing fewer characters and having code read "like english". Compare this with Elm, which goes out on a similar syntactic limb (minimal punctuation, radically different syntax constructs than what people are used to (it'd be familiar to Haskellers, but alien to JS programmers, its primary market)). But in Elm's case: 1) It's a language built specifically for very large and scalable projects (that is the benefit of super-strict types and purity, after all), so there's the assumption that an up-front learning investment is worth it 2) The unusual syntax choices are, for the most part, central to achieving the language's goals at a deeper level (not just achieving a certain aesthetic) This is all speculative on my part when it comes to Hyperscript itself; I haven't tried it out myself, maybe it's not as much a problem in practice as it seems like it could be. But I feel like people often go unaware when they're introducing these sorts of costs in a new language, so I wanted to take the opportunity to raise the point for discussion. [1] This is a very loaded term, but we'll set that aside