Fun idea, but inline scripting only works for the simplest things. I could write my handlers inline with JS as well, but I really would rather not.
Maybe a bigger question is why not have this as a JS library, but its own language. Because it's kind of almost there (here using jQuery):
<button _="on click toggle .big-text">
Toggle the "big-text" class on me on click
</button>
<button onclick="$(this).toggleClass('big-text')">
Toggle the "big-text" class on me on click
</button>
Hyperscript is a cool attempt at providing declaration to HTML and UI development in general. 90% of what happens in a UI is ubiquitous across software. Buttons are clicked, images are positioned.
Not going to wax on, but recently spent some time on boarding a new hire. Level 1 developer. The amount of time I spend explaining things like async processes, prototypal inheritance vs class structure, how to debug anything, etc. are all problems because our documents aren’t explicit enough. I think a more declarative language (in respect to UI) that maintains simplicity will cut through the cruft of a lot Of modern JavaScript exhaustion.
> 90% of what happens in a UI is ubiquitous across software. Buttons are clicked, images are positioned.
Thing is, there are countless fun ways to reimagine basics like "buttons are clicked, images are positioned". But that's not an app. And the long tail of everything you need in order to get from clicking buttons to a useful app is what makes a "real" language like JS (and in bigger projects TS) necessary.
Unfortunately a lot of what is presented is already enabled by JS, if you don't get hung up on things like do you separate tokens with spaces or dots.
Happy to see HyperTalk-inspired innovation on the web! It looks cool. How did you decide what verbs and nouns to support? Also, thanks for the twinge of HyperCard nostalgia you gave me!
the verbs are largely ad-hoc, using HyperTalk as a jump off and then trying to think about how to modify the language for the DOM (e.g. CSS literals) and simplify things for script writers (e.g. async transparency)
* the runtime is async-transparent, so you (mostly) don't need to worry about asynchronous code (the runtime works everything out) https://hyperscript.org/docs/#async
While hyperscript is designed for small, embedded functionality like toggling classes, we are experimenting with ways to add more complex behavior with, er, behaviors: https://hyperscript.org/docs/#behaviors
The language is very young and speculative compared with htmx, but we've been happy with how it's turned out so far...
That name is unfortunate because there's already a hyperscript: https://github.com/hyperhype/hyperscript which is completely different (which I am quite enjoying for constructing virtual dom in pure js)
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
I guess it's the other way around as in "does the world really need to learn a programming language for making plain old web pages"? Tbh I don't know if hyperscript is the answer though, adding yet another language construct (with hard-coded, opinionated semantics) into the mix when we have already HTML/SGML, CSS, and lots of microsyntax. I guess the ship has sailed when JavaScript entered the scene at which point HTML has basically stalled, but the basic vision - that regular users or at least prosumers should be able to make generic content documents without resorting to a Turing-complete language - is as old as markup languages and SGML itself. SGML with HyTime in particular is able to deliver generic or project-specific behaviors of the kind demo'd on the hyperscript page (plus much more) through extension vocabularies and HTML templating without introducing new ad-hoc syntax at all.
"Why not just make it a Java Framework? Does the world really need to learn another separate language just for making web pages?"
-- someone in 199x when hearing about how we were going to have JavaScript for the front-end.
If you aren't writing your backend in JavaScript (and most projects aren't), then you have to learn another language anyway (until WebAssembly can sweep me off my feet, anyway), so it might as well not be JavaScript. Although hyperscript isn't production ready yet, for making things move around on a template-generated web page, JS seems to add a ton of complexity compared to something like this.
[+] [-] dang|4 years ago|reply
also
Show HN: _hyperscript – an async-transparent scripting langauge for the web - https://news.ycombinator.com/item?id=26475376 - March 2021 (3 comments)
[+] [-] ksec|4 years ago|reply
>hyperscript is a companion project of htmx
html: https://htmx.org
Previous Discussions
Htmx – high power tools for HTML https://news.ycombinator.com/item?id=23330881
Htmx 1.0.0 Release https://news.ycombinator.com/item?id=25232719
Htmx 1.2.0 Release https://news.ycombinator.com/item?id=26128229
[+] [-] slver|4 years ago|reply
Maybe a bigger question is why not have this as a JS library, but its own language. Because it's kind of almost there (here using jQuery):
[+] [-] czechdeveloper|4 years ago|reply
[+] [-] recursivedoubts|4 years ago|reply
then I realized I didn't want to deal w/ async/await or setTimeout, and off I went...
[+] [-] yepthatsreality|4 years ago|reply
Not going to wax on, but recently spent some time on boarding a new hire. Level 1 developer. The amount of time I spend explaining things like async processes, prototypal inheritance vs class structure, how to debug anything, etc. are all problems because our documents aren’t explicit enough. I think a more declarative language (in respect to UI) that maintains simplicity will cut through the cruft of a lot Of modern JavaScript exhaustion.
Very cool project from the HTMX crew.
[+] [-] slver|4 years ago|reply
Thing is, there are countless fun ways to reimagine basics like "buttons are clicked, images are positioned". But that's not an app. And the long tail of everything you need in order to get from clicking buttons to a useful app is what makes a "real" language like JS (and in bigger projects TS) necessary.
Unfortunately a lot of what is presented is already enabled by JS, if you don't get hung up on things like do you separate tokens with spaces or dots.
[+] [-] drunkpotato|4 years ago|reply
[+] [-] recursivedoubts|4 years ago|reply
the verbs are largely ad-hoc, using HyperTalk as a jump off and then trying to think about how to modify the language for the DOM (e.g. CSS literals) and simplify things for script writers (e.g. async transparency)
[+] [-] rntksi|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] recursivedoubts|4 years ago|reply
some aspects of the language that HN might find interesting:
* events are really easy to work with (both responding to or sending them)
* there are DOM-specific literals in the langauge: https://hyperscript.org/expressions/#css
* the runtime is async-transparent, so you (mostly) don't need to worry about asynchronous code (the runtime works everything out) https://hyperscript.org/docs/#async
* event-based control flow: https://hyperscript.org/docs/#event-control-flow
* a debugger, written in hyperscript of course: https://hyperscript.org/docs/#debugging
While hyperscript is designed for small, embedded functionality like toggling classes, we are experimenting with ways to add more complex behavior with, er, behaviors: https://hyperscript.org/docs/#behaviors
The language is very young and speculative compared with htmx, but we've been happy with how it's turned out so far...
[+] [-] fouc|4 years ago|reply
hyperscript is a companion of htmx (which is the successor of intercoolerjs)
[+] [-] insraq|4 years ago|reply
[+] [-] cosmotic|4 years ago|reply
[+] [-] brundolf|4 years ago|reply
With that said:
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
[+] [-] hutrdvnj|4 years ago|reply
[+] [-] mastrsushi|4 years ago|reply
[+] [-] tannhaeuser|4 years ago|reply
[+] [-] j4yav|4 years ago|reply
[+] [-] easton|4 years ago|reply
-- someone in 199x when hearing about how we were going to have JavaScript for the front-end.
If you aren't writing your backend in JavaScript (and most projects aren't), then you have to learn another language anyway (until WebAssembly can sweep me off my feet, anyway), so it might as well not be JavaScript. Although hyperscript isn't production ready yet, for making things move around on a template-generated web page, JS seems to add a ton of complexity compared to something like this.
[+] [-] blacktriangle|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]