_hyperscript – a small scripting language for the web(github.com)
github.com
_hyperscript – a small scripting language for the web
https://github.com/bigskysoftware/_hyperscript
43 comments
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
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")'
_='on click js alert("Javascript mixed in hyperscript") end'
// and /* ... */
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.
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
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.
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
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.
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?
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
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:
But also fun!
<div _="on mousenter toggle .expand" ...>
...
</div>
<div _="on mousenter toggle .expand on the closest <section/>" ...>
...
</div>
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>
set x to arr.length
set y to the arr's length
set z to the length of the array
But also fun!
I wonder if it could have been more Logo/Rebol inspired instead of Hypertalk. I guess that would be like:
For events:
Using another example from the page:
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.
put new date next <output/>
For events:
on click [toggle .clicked]
Using another example from the page:
on click [call aJavascriptFunction()
then [wait 10s]
then [call anotherJavascriptFunction()]]
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.
Hi there, glad to see hyperscript on HN again.
I started the project because I wanted an event-oriented scripting language that embedded well in the DOM, and I always missed HyperTalk, the old scripting language for HyperCard.
hyperscript isn't designed to be a general purpose programming language: it's designed for simple, client side DOM scripting. It has thinks like class literals (.foo) and so forth, and takes a lot of inspiration functionally from jQuery. It'd designed also to dovetail well with htmx, which triggers a bunch of events.
Happy to answer questions.
I started the project because I wanted an event-oriented scripting language that embedded well in the DOM, and I always missed HyperTalk, the old scripting language for HyperCard.
hyperscript isn't designed to be a general purpose programming language: it's designed for simple, client side DOM scripting. It has thinks like class literals (.foo) and so forth, and takes a lot of inspiration functionally from jQuery. It'd designed also to dovetail well with htmx, which triggers a bunch of events.
Happy to answer questions.
Great work! Love htmx and hyperscript. Do you plan to add hyperscript to CDNJS? I know it’s already on JSDELIVR, but somehow cloudflare fits one of my use cases better.
It’s an interesting idea but I don’t appreciate the name hijacking. Hyperscript has been around for a long time: https://github.com/hyperhype/hyperscript
To be fair I don't think we're going to see a resurgence of that collection of projects. hyperhype hasn't seen updates since 2019 and was not that big to begin with.
Hyperscript here makes a lot of sense as it's the companion project to http://htmx.org
Hyperscript here makes a lot of sense as it's the companion project to http://htmx.org
If you care about dates, don’t look at NPM, the latest version was published six years ago. Some software is just kinda finished and doesn’t need updates.
It still has a huge ecosystem of consumer libs, some updated recently, and 55k downloads a month - about 20x more than “_hyperscript”.
Since _hyperscript is not that big, am I entitled to naming my next project “_hyperscript_” next week? This is not how this is supposed to work.
It still has a huge ecosystem of consumer libs, some updated recently, and 55k downloads a month - about 20x more than “_hyperscript”.
Since _hyperscript is not that big, am I entitled to naming my next project “_hyperscript_” next week? This is not how this is supposed to work.
By NPM do you mean the Node Package Manager?
Last release was a few hours ago according to the github release page https://github.com/npm/cli/releases/tag/v8.14.0
Last release was a few hours ago according to the github release page https://github.com/npm/cli/releases/tag/v8.14.0
The last release of hyperscript on NPM, not NPM itself.
The name "hyperscript" is still used commonly among libraries to refer to the syntax originated by dominictarr's project, e.g., `h(tag, props, ...children)`.
Hyperscript isn’t in need of a resurgence, it’s the default transform for JSX. That’s React and Preact, and most other JSX libraries/frameworks (including, I’ve heard, Solid despite its preferred JSX transform). It’s also commonly in usage in equivalent ClojureScript syntax. If one were defining a pure-JS DSL for a DOM-like structure, I think you’d be hard pressed to find something more suitable.
The naming of this project clashes horribly with https://github.com/hyperhype/hyperscript. It's not like it's in a different ecosystem or something. It is a web project that is guaranteed to cause confusion.
I think if your project goes dormant for years, and was never really that big of a thing to begin with, that you kind of give up naming rights, don't you?
The original Hyperscript still gets talked about, at least in the React and Solid communities and if only in conversations about the relative merits of different rendering methods. I wouldn't feel comfortable naming a project Zepto today. Why muddy the waters unnecessarily?
I'll admit those aren't my circles, so if I'm wrong to say the older project never hit critical mass, I'm sorry.
Hyperscript still has mindshare as a syntax even though it doesn't as a project. It is often an (sometimes indirect) inspiration for syntaxes used by microframeworks.
Not saying this directly applies, but under the Lanham Act, nonuse of a trademark for three consecutive years is prima facie evidence of abandonment.
Or it has all the needed features and no bugs.
[deleted]
Htmx and hyperscript make my life in Django much nicer. Thanks!
I had the exact same idea for a programming language. So happy to see someone actually made it happen! Good job and keep up the work!
After looking through the docs it has grown on me, even with the quirkiness of the Hypertalk-style syntax. Personally I tend to write stuff code-up (instead of template-down), which is a good match for React. But I can imagine using this with my daughter, who has learned to write some static HTML and this could be a fairly easy way to add some fun interactivity to those pages.
I wish there was something that could put it all together though. Replit and Glitch handle some of the editing and hosting, but not much else... no tools for content creation or asset management, only minimal linting, and not much help in tracing the rendered page back to the original source. Like moving towards that Hypercard experience of taking an element, flipping it over, and adding code to it. It's doable! But I haven't seen it done. Or at least I'd like to see something that's taken a few more steps in that direction...
I wish there was something that could put it all together though. Replit and Glitch handle some of the editing and hosting, but not much else... no tools for content creation or asset management, only minimal linting, and not much help in tracing the rendered page back to the original source. Like moving towards that Hypercard experience of taking an element, flipping it over, and adding code to it. It's doable! But I haven't seen it done. Or at least I'd like to see something that's taken a few more steps in that direction...
I'll be bold and say it: it's stupid that the web has 3 main front-end technologies (HTML, CSS, and JS)
There's state, visual representation, and behavior. Why can't all of those be contained in one language?
Sure, let proficient programmers override defaults and break out of the 1 language model, but 99% of apps/website look & behave the same anyways, why can't we have nice defaults?
I'm concerned because I have a 1.5 year old son and I plan to introduce him to the internet (this wonderful, globally distributed, infinite potential platform that anyone can contribute to) as soon as I can.
But it's absurd to me that computers haven't been optimized well for his mind yet, but instead he'll have to spend years of his life optimizing his mind to understand and work with them.
I wish I could show him the magic & power of putting something app-like on the internet faster than that.
This project helps move in the direction of optimizing computers for human minds and I'm 100% excited about that.
There's state, visual representation, and behavior. Why can't all of those be contained in one language?
Sure, let proficient programmers override defaults and break out of the 1 language model, but 99% of apps/website look & behave the same anyways, why can't we have nice defaults?
I'm concerned because I have a 1.5 year old son and I plan to introduce him to the internet (this wonderful, globally distributed, infinite potential platform that anyone can contribute to) as soon as I can.
But it's absurd to me that computers haven't been optimized well for his mind yet, but instead he'll have to spend years of his life optimizing his mind to understand and work with them.
I wish I could show him the magic & power of putting something app-like on the internet faster than that.
This project helps move in the direction of optimizing computers for human minds and I'm 100% excited about that.
I'm not sure I'd agree that having one language would be 'optimized' for the human mind. People often create DSLs due to the limitations of general-purpose languages that are constrained by the large number of use-cases they must support; sometimes a DSL actually makes things less ambiguous, and therefore easier on our minds.
To give a more concrete example: in Xamarin apps, you can technically do all UI in nothing but C#, just writing in the code-behind rather than in XAML. But as any Xamarin developer will tell you, this is a nightmare to work with. It becomes less clear what code is responsible for structure vs logic, and can be a real pain to test.
Now that's not to say I completely disagree. For example, I think Tailwind gives you a sense of what it would be like if HTML & CSS were one and the same; keeping structure and style together makes a lot of sense to me. But I'd be wary of a one language to rule them all.
To give a more concrete example: in Xamarin apps, you can technically do all UI in nothing but C#, just writing in the code-behind rather than in XAML. But as any Xamarin developer will tell you, this is a nightmare to work with. It becomes less clear what code is responsible for structure vs logic, and can be a real pain to test.
Now that's not to say I completely disagree. For example, I think Tailwind gives you a sense of what it would be like if HTML & CSS were one and the same; keeping structure and style together makes a lot of sense to me. But I'd be wary of a one language to rule them all.
> Why can't all of those be contained in one language?
Because they all serve a distinct purpose. I don't need CSS or JS to have HTML, nor do I need JS to have HTML or CSS. This keeps things fairly lightweight and removes a lot of overhead in the form of compilers and other tooling just to put a document online.
I've never understood the freak out around these technologies. They're simple, relatively pure, and easy to pick up. And for all intents and purposes, quite enduring as they've powered the greatest advancement in human communication ever.
Most of the failure around these technologies comes in relation to the foolishness and shortsightedness of browser vendors (cough Microsoft) and the hubris of tool builders building on top of these technologies.
Because they all serve a distinct purpose. I don't need CSS or JS to have HTML, nor do I need JS to have HTML or CSS. This keeps things fairly lightweight and removes a lot of overhead in the form of compilers and other tooling just to put a document online.
I've never understood the freak out around these technologies. They're simple, relatively pure, and easy to pick up. And for all intents and purposes, quite enduring as they've powered the greatest advancement in human communication ever.
Most of the failure around these technologies comes in relation to the foolishness and shortsightedness of browser vendors (cough Microsoft) and the hubris of tool builders building on top of these technologies.
I suspect you are yearning for a shared syntax that supports distinct constructs for declarative structure (layout), composable functions for inheriting/overriding style and imperative/functional glue for behaviour.
For me, Reagent still reigns supreme because it is ClojureScript on top of React which compiles to JavaScript, renders to HTML & CSS but with the full power of a high-level programming language that hasn't changed since it was designed 15 years ago: https://reagent-project.github.io/
For me, Reagent still reigns supreme because it is ClojureScript on top of React which compiles to JavaScript, renders to HTML & CSS but with the full power of a high-level programming language that hasn't changed since it was designed 15 years ago: https://reagent-project.github.io/
> There's state, visual representation, and behavior. Why can't all of those be contained in one language?
They are. It’s called HTML. The other two are for extending it. The fundamental principles of HTML have never included a separation of concerns.
> 99% of apps/website look & behave the same anyways, why can't we have nice defaults?
We do. See above.
They are. It’s called HTML. The other two are for extending it. The fundamental principles of HTML have never included a separation of concerns.
> 99% of apps/website look & behave the same anyways, why can't we have nice defaults?
We do. See above.
I suspect you might be overthinking it. I will never forget the first times I uploaded content to the internet, as a student; as a worker.
There's a world of creativity to be had before complex interactivity.
There's a world of creativity to be had before complex interactivity.
Love the sync/async transparency in this language.
i think that's the most technically innovative aspect of the language, for sure
script writers shouldn't need to think about asynchronicity unless absolutely necessary
glad you like it!
script writers shouldn't need to think about asynchronicity unless absolutely necessary
glad you like it!
I love the idea. But I wish I didn't have to ship the entire runtime to the client, and was instead compiled to efficient DOM operations.
Because of the size of the runtime, I'd rather use something like Solid.js which is smaller and faster.
Because of the size of the runtime, I'd rather use something like Solid.js which is smaller and faster.
A custom runtime is necessary due to the async transparancy feature of the language:
https://hyperscript.org/docs/#async
It is dependency free and a bit under 30kb gz'd, which is roughly where jQuery is, and hyperscript is intended as a jQuery replacement. That's 35ms on emerging 4g, and in the browser cache after that. Probably not noticable for most situations.
https://hyperscript.org/docs/#async
It is dependency free and a bit under 30kb gz'd, which is roughly where jQuery is, and hyperscript is intended as a jQuery replacement. That's 35ms on emerging 4g, and in the browser cache after that. Probably not noticable for most situations.
Standard code for the first and third examples, for comparison:
<button Toggle the "clicked" class on me </button>
<div setTimeout(anotherJavascriptFunction, 10000)"> Do some stuff </div>
The second example (triggering mouseover on #foo) cannot be that easily inlined in an HTML attribute. I think you’d have to create a synthetic event and dispatch it.
<button Toggle the "clicked" class on me </button>
<div setTimeout(anotherJavascriptFunction, 10000)"> Do some stuff </div>
The second example (triggering mouseover on #foo) cannot be that easily inlined in an HTML attribute. I think you’d have to create a synthetic event and dispatch it.
Third example only works if aJavascriptFunction is sync. If it's async you'd have to do
<div => setTimeout(anotherJavascriptFunction, 10000)">Do some stuff</div>
<div () => { await aJavascriptFunction(); setTimeout(anotherJavascriptFunction, 10000) })()">Do some stuff</div>Can someone confirm that this and htmx are JavaScript libraries, for to novice?
I'm just confused why you'd not just use JavaScript? What's the benefit? From my very limited experience these seem to mess up the html and make that harder to reason about. Fully aware I am showing my ignorance, but genuine questions.
I'm just confused why you'd not just use JavaScript? What's the benefit? From my very limited experience these seem to mess up the html and make that harder to reason about. Fully aware I am showing my ignorance, but genuine questions.
they are libraries written in javascript
htmx extends HTML as a hypermedia, staying as close as it can to the original, REST-ful model of the web while allowing you to achieve more from a UX perspective: https://htmx.org/examples
_hyperscript is an event-oriented scripting language designed to embed cleanly in HTML and that complements htmx, which fires a lot of events
the vision is htmx for syncing w/ a server and hyperscript for light front end work to augment it. the reason to use them over JavaScript is that, arguable, htmx is closer to the intended networking model for the web (REST, HATEOAS) and hyperscript allows higher level scripting than JavaScript (e.g. async-transparency eliminates the need to deal w/ promises, CSS literals directly in the language eliminates the need to work w/ gronky DOM APIs, etc.)
this vision will not speak to everyone, which is fine
htmx extends HTML as a hypermedia, staying as close as it can to the original, REST-ful model of the web while allowing you to achieve more from a UX perspective: https://htmx.org/examples
_hyperscript is an event-oriented scripting language designed to embed cleanly in HTML and that complements htmx, which fires a lot of events
the vision is htmx for syncing w/ a server and hyperscript for light front end work to augment it. the reason to use them over JavaScript is that, arguable, htmx is closer to the intended networking model for the web (REST, HATEOAS) and hyperscript allows higher level scripting than JavaScript (e.g. async-transparency eliminates the need to deal w/ promises, CSS literals directly in the language eliminates the need to work w/ gronky DOM APIs, etc.)
this vision will not speak to everyone, which is fine
The syntax is based on xTalk (reminds me heavily of AppleScript). As much as I like to say languages don't matter that much, this style of "almost english" for programming feels so broken and misguided that it sours the whole (really cool) concept for me.
One of their examples includes the attribute text
Like..what? Make a Date how? How do you "put" a Date? Put it in what? String formatted or something? How is "next" determined? I'm sure these are well-defined concepts in the language and can be learned quickly, but this awkward contortion of English makes me mentally double-parse every statement and question my basic understanding of English (as a native speaker), the underlying JS and framework, and how the language will map between them.
Even if their developer tooling lets you learn, write, explore, and debug the language, there is always going to be a mismatch in contorting awkward english sentences to communicate intention to the framework.
I wish the project success and perhaps this is a good evolution of this syntax and paradigm, but I personally would be hesitant to invest in it without clear escape-hatches for the syntax.