Hyperscript is an experimental scripting language designed for the web
hyperscript.org
hyperscript.org
also
Show HN: _hyperscript – an async-transparent scripting langauge for the web - https://news.ycombinator.com/item?id=26475376 - March 2021 (3 comments)
>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
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> <button onclick="this.classList.toggle('big-text')">
Toggle the "big-text" class on me on click
</button>then I realized I didn't want to deal w/ async/await or setTimeout, and off I went...
for async transparency the hyperscript runtime looks at the results of every expression and, if it is a promise, resolves the promise before allowing the parent expression to continue evaluating
so you don't actually need to think about (or know) if an expression returns a promise or not, the runtime takes care of it for you, a very unique feature that does require a runtime. And if I'm gonna make a runtime, I'm gonna make a language too
it's also slow as molasses, if you are trying to write a bitcoin miner, for example
but for front end scripting, it usually doesn't matter and the convenience is worth the runtime costs
at least that's the theory
lets find out
set the window's location to the target's href
hyperscript is a funky language, for sure :)
Can you link me to some docs on the lua's transparent concurrency model? All my searches are turning up explicit concurrency stuff. Hyperscript is unique (as far as I know) in that it resolves asynchronicity (Promises) at the expression level, without explicit syntax.
"set window location to target href"
And this is even clearer:
"window.location = target.href"
Adding the flourishes of human language is kinda cute, It can also be useful in speech recognition when we can't help but speak like we normallt speak. But code is a written specification, and specifications benefit from being clear, succinct, and for there to be "one clear & right way" of doing something.
Just my take.
https://stackoverflow.com/questions/49764681/how-exactly-doe...
so, a step in the right direction, but not a fully async-transparent runtime like hyperscript
thank you for the link
But in practice there's nothing explicit about it, because any function can yield and you don't have to explicitly know it did.
Lua is heavily used to script games, and you can see scripts like this there:
walkTo(desk)
pause(3);
turn(180);
say("I changed my mind, can I come with you?")
response = promptPlayer("OK, come", "No, stay");
...
...
All of this is happening async. But you don't have to do anything about it. You're writing a function, and the API for it yields where it has to. For you, all that's implicit.
It's literally identical to yours in practice, but it doesn't return promises. It yields natively.
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.
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.
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)
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...
<div _="on click transition opacity to 0 then remove me">Remove Me</div>
hyperscript is a companion of htmx (which is the successor of intercoolerjs)
With that said:
on click repeat until event stop
add .pulse then settle
remove .pulse then settle
end
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
If the project lives in HTML, it doesn't matter what language it's written in. So it would be reasonable to choose one that developers are already familiar with.
There's simply no reason for what's done here.
Also, reminder, one reason why we like external assets is because they don't change (as often) while the HTML document is often dynamic (and hence not cacheable).
-- 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.