[HN Gopher] _hyperscript - a small scripting language for the web
___________________________________________________________________
_hyperscript - a small scripting language for the web
Author : tsujp
Score : 97 points
Date : 2022-07-13 12:15 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| arispen wrote:
| 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!
| eterps wrote:
| Love the sync/async transparency in this language.
| recursivedoubts wrote:
| 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!
| ricardobeat wrote:
| 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
| geenat wrote:
| 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
| keb_ wrote:
| 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)`.
| ricardobeat wrote:
| 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.
| icermann wrote:
| 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
| ryanianian wrote:
| 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.
| geenat wrote:
| 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.
| recursivedoubts wrote:
| 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.
| ryanianian wrote:
| 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?
| recursivedoubts wrote:
| 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!
| mikelevins wrote:
| 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.
| richeyryan wrote:
| 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.
| JohnDeHope wrote:
| 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?
| richeyryan wrote:
| 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?
| JohnDeHope wrote:
| 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.
| SahAssar wrote:
| 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.
| mminer237 wrote:
| Not saying this directly applies, but under the Lanham Act,
| nonuse of a trademark for three consecutive years is prima
| facie evidence of abandonment.
| postalrat wrote:
| Or it has all the needed features and no bugs.
| [deleted]
| account-5 wrote:
| 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.
| recursivedoubts wrote:
| 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
| zagrebian wrote:
| 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.
| twicetwice wrote:
| 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>
| recursivedoubts wrote:
| 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.
| freewizard wrote:
| 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.
| voat wrote:
| 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.
| recursivedoubts wrote:
| 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.
| panphora wrote:
| 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.
| ducharmdev wrote:
| 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.
| pgt wrote:
| 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/
| rglover wrote:
| > 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.
| detritus wrote:
| 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.
| inopinatus wrote:
| > 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.
| rlawson wrote:
| Htmx and hyperscript make my life in Django much nicer. Thanks!
___________________________________________________________________
(page generated 2022-07-13 23:01 UTC)