_hyperscript – a small scripting language for the web | Hacker News Reader

_hyperscript – a small scripting language for the web

github.com

111 pointstsujp41 comments

This is really cool, but...

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

    make a Date then put it into the next <output/>

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.

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

  toggle .foo on #bar

i really like how it looks

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.

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?

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

  <div _="on mousenter toggle .expand" ...>
    ...
  </div>

So the language comes across as imperative statements, with the current element being the default subject and object, as with english instructions. Most commands (statements) accept a noun target:

  <div _="on mousenter toggle .expand on the closest <section/>" ...>
    ...
  </div>

But, due to the embedded nature of the language it still comes across as you telling the diff to toggle the class on the other section.

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>

Insanity, I know. There are also three, count'em three different ways to access properties:

   set x to arr.length
   set y to the arr's length
   set z to the length of the array

Fun! Also insane.

But also fun!

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.

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

  _='on click call alert("Javascript called directly")'

Embed javascript directly

  _='on click js alert("Javascript mixed in hyperscript") end'

Next release will bring javascript comments to make learning and migrating blocks of code easier.

  // and /* ... */

Also I must say you do get used to the syntax relatively quickly.

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.

I wonder if it could have been more Logo/Rebol inspired instead of Hypertalk. I guess that would be like:

    put new date next <output/>

Assuming in that "then" is superfluous since there's nothing async about making a date. Though because "new Date()" can take arguments it's perhaps unclear how to parse this.

For events:

    on click [toggle .clicked]

That would imply that "click" is a defined object/variable. I'm not sure how _hyperscript is evaluated, maybe "on" gets to decide how to evaluate its arguments. You can also imagine "onclick" as a command.

Using another example from the page:

    on click [call aJavascriptFunction()
              then [wait 10s]
              then [call anotherJavascriptFunction()]]

"then" would be a reasonable command, though making it a special form is also reasonable. Though maybe "then" just means ";" – a statement terminator? And everything is async. That would be reasonable, the only trick is when you have a promise as an argument to a function, do you resolve the promise first or not? There are use cases for both.

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.

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

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.

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

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.

Or it has all the needed features and no bugs.

Not saying this directly applies, but under the Lanham Act, nonuse of a trademark for three consecutive years is prima facie evidence of abandonment.

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'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.

> 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.

> 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.

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.

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/

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.

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!

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.

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.

Standard code for the first and third examples, for comparison:

<button onclick="this.classList.toggle('clicked')"> Toggle the "clicked" class on me </button>

<div onclick="aJavascriptFunction(), 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 onclick="aJavascriptFunction().then(r => setTimeout(anotherJavascriptFunction, 10000)">Do some stuff</div>

but if you don't know ahead of time whether or not it's async (or don't want to have to care, like hyperscript allows), then you'd need

  <div onclick="(async () => { 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.

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

Reply on news.ycombinator.com