We have been working on an experimental front
end programming langauge, hypescript, as a companion project for htmx. Its
syntax is based loosely on HyperTalk, the scripting language for HyperCard.
It has some feature that the HN crowd might find interesting:
Async-transparency - as much as possible, the runtime tries to hide the
distinction between synchronous and asynchronous code
There's a fair bit of other stuff too, SSE and Websocket support, a slew of
useful commands for working with the DOM, etc.
This is very early, 0.0.6, so please be gentle, but it is being used in a few
places in production. I used it to make the / key jump to the search box
on htmx.org, for example.
Minor Hyperscript contributor here! English-like syntax may odd to many current front-end developers. We’ve been shaped in the mold of C for decades, and its hard to break away. That’s understandable.
But to me, the real value in hyperscript is that it’s crafted for the specific needs of a client-side browser application. Using hyperscript, I can get things done in a fast and maintainable way, using a very-high-level language that everyone understands. Sure, I could do it in Javascript too, but the price is significantly more code that is much harder to maintain.
Oddly, I’m building hyperscript into the front-end my current web app for the same reason that I chose Go (over Node.JS) for the app back-end: the end of callback hell. What’s listed above as simply “async transparency” and “event driven flow control” are complete game changers for a web-based front-end — No more callbacks. No more promises. Orchestrate complex animations like they’re “hello world.” And start using events like they were meant to be used, but in ways that you simply never would have thought of if you had to do it in Javascript.
That’s my $0.02. I hope hyperscript works out as well for you as it does for me. Cheers :)
Hyperscript (especially in combination with htmx) is as ridiculously useful as it is fun to use.
Biggest wins are the concise, natural-language-like syntax which is applied directly in context and is very readable and easy to understand, along with the way it turns callback hell into a “smooth like butter” experience which is so simple and intuitive that it feels like cheating.
I’ve been in the development game long enough to appreciate the value of easy-to-understand, maintainable code. Absolute bonus when it’s actually fun and productive to write as well!
3 comments
[ 6.5 ms ] story [ 19.4 ms ] threadWe have been working on an experimental front end programming langauge, hypescript, as a companion project for htmx. Its syntax is based loosely on HyperTalk, the scripting language for HyperCard.
It has some feature that the HN crowd might find interesting:
Async-transparency - as much as possible, the runtime tries to hide the distinction between synchronous and asynchronous code
https://hyperscript.org/docs/#promises
https://hyperscript.org/docs/#async
Event driven - events are treated as first class citizens, including event-based control flow
https://dev.hyperscript.org/docs/#event-control-flow
CSS Literals - you can refer to elements in the DOM directly with syntax like #foo, .bar and <button/>
Extendable language - the parser is pretty open and flexible, allowing you to add new "commands" (statements) to the languagehttps://dev.hyperscript.org/docs/#extending
Integrated Debugger - the language has a (very alpha) integrated debugger
https://dev.hyperscript.org/docs/#debugging
Inline Web Workers - the ability to define a web worker directly in your page
https://dev.hyperscript.org/docs/#workers
There's a fair bit of other stuff too, SSE and Websocket support, a slew of useful commands for working with the DOM, etc.
This is very early, 0.0.6, so please be gentle, but it is being used in a few places in production. I used it to make the / key jump to the search box on htmx.org, for example.
But to me, the real value in hyperscript is that it’s crafted for the specific needs of a client-side browser application. Using hyperscript, I can get things done in a fast and maintainable way, using a very-high-level language that everyone understands. Sure, I could do it in Javascript too, but the price is significantly more code that is much harder to maintain.
Oddly, I’m building hyperscript into the front-end my current web app for the same reason that I chose Go (over Node.JS) for the app back-end: the end of callback hell. What’s listed above as simply “async transparency” and “event driven flow control” are complete game changers for a web-based front-end — No more callbacks. No more promises. Orchestrate complex animations like they’re “hello world.” And start using events like they were meant to be used, but in ways that you simply never would have thought of if you had to do it in Javascript.
That’s my $0.02. I hope hyperscript works out as well for you as it does for me. Cheers :)
Biggest wins are the concise, natural-language-like syntax which is applied directly in context and is very readable and easy to understand, along with the way it turns callback hell into a “smooth like butter” experience which is so simple and intuitive that it feels like cheating.
I’ve been in the development game long enough to appreciate the value of easy-to-understand, maintainable code. Absolute bonus when it’s actually fun and productive to write as well!