Having a BASIC of web programming seems cool. If that’s “all” this became it would be tremendous. Most folks here might not finding themselves reaching for it often if at all. But that’s also true of BASIC.
I try to be open-minded, but frankly this looks awful. It seems to combine (wishful thinking about English-like syntax being an improvement), with (tight coupling of logic and presentation), and (a new half-baked non-standard DSL). It's hard to imagine this being anything but a nightmare to maintain, or ever surpassing the minimum threshold of adoption that leads to a real ecosystem or even decent tooling needed to solve any but the most trivial use cases.
I wish HN supported markdown for code fragments but the 1st example of code in the post looks something like this:
div _="init fetch https://stuff as json then put result into me">Using fetch() API...
/div>
I think Hyperscript is easy to bash on due to it's _very_ different syntax than what programmers are normally used to. That said, I think it's a really nice way to add little pieces of functionality without needing to bring out the JS frameworks.
It should be remembered that Hyperscript is meant to be paired with a technology like HTMX. I don't think the creator of Hyperscript would be suggesting to anyone that someone attempt to create a web application out of pure Hyperscript.
I’m the creator of hyperscript and I’m happy to answer questions. I know it isn’t going to be everyone’s cup of tea, it’s probably even more divisive than htmx, which I designed it to complement.
The big idea is a higher level and more expressive scripting language than js that embeds cleanly inline in html. It has integrated css query literals, relative location expressions (e.g. add .foo to the next .bar) and probably its most interesting feature, it resolves promises in the runtime so script writers don’t have to:
What are your thoughts on error handling? The examples seem happy-path only. I find that code gets verbose once you handle errors, and things like backoff and retry.
hyperscript is designed for light, event-based scripting so we don't have a huge focus on error handling, but we do support a single catch/finally block per event handler or method:
I feel like this wouldn't be necessary if we didn't throw the baby out with the bath water with XHTML, which had that nifty property of XML documents known as namespaces. HTMx strikes me as what should've happened if we had a namespace for behavioral tags, tags with behavioral attributes that accept light scripting, etc. And because they're namespaces, they're opt-in by default. Browser engines could've even gone further and provided different render primitives than the DOM via namespace'ing so we don't wind up with HTML5 that does a bit more but not enough to keep up with advancing needs in the frontend. I dunno, I'm kinda yapping on that last one, but at bottom something felt lost that HTMx is recovering.
This article claims that Hyperscript is "Something you could just type out from memory, without referencing anything".
I don't understand this assertion at all. There is a grammar that must be learned, and it is different from existing solutions, which means most humans will need to reference something until they become familiar enough to work without documentation. I don't see how this is different than React, vanilla JS, or others. The benefits of this do not shine through for me.
I prototyped a UI with hyperscript web components and it was a lot of fun. If anything it helped me make design decisions because I was slowing down, thinking out of the box, and genuinely entertained by reading the end code.
Once you get the hang of it, its pretty fun and a little surreal to write effective front end logic in what appears to be a natural language.
Highly recommend it for a prototype and think it was genuinely motivating because it made frontend logic more novel and fun.
I'm not a huge fan of languages that are too close to English - I think it's a bit of a leaky abstraction. There's still a strict formula you need use, just like any other programming language, but it seems to the programmer like it should work with slightly changed wording just like in English when in fact minor changes cause huge differences in the way the code is interpreted. It also gets pretty verbose depending on what it's doing.
We’re used to English being an abstract grammar, where mistakes minor don’t end up drastically changing the observer’s perception of what was said. Hyperscript allows some of that flexibility, ”my”, ”me”, and ”I” are pronouns used in place of ”this”. This should presumably let you build better (English) sentences that still works. Until someone decides that they want to use ”mine” instead, and something altogether different happens.
Expanding the reliance on ”plain english” also risks hampering future development, since you’re mixing user-defined words with keywords in the same namespace. Taking ’mine’ as an example, would adding it to the language to fill out the first-person pronouns break existing scripts?
That critique aside, I really like it when people try ideas like this and fiddle with our expectations of what programming should look like. Erlang use a combination of commas, semicolons, and dots for defining a single line, the end of a block, and the end of a function. I personally prefer that to our more common curly bracket or indentation-based control flows. Go’s upper- and lowercase visibility modifiers also come to mind. Whatever you personally end up thinking about things like that, to me it’s sort of the hacker mindset at play. I end up liking that playfulness even when the result is not my cup of tea.
is there any hope for all browser vendors to come together and add a new saner language to the browser to veeery slowly phase out javascript? like is this even in the horizon for the next couple decades?
Compile to js languages tend to include a huge runtime which is a non-starter. The ones that don't, don't generally play well with existing js libraries anyways. I don't think WebAssembly will be the "scripting" solution for the web, is it aiming to be that? I don't think so. It is very performant and that is its thing but you don't tend to write bare wasm, and it is not a scripting solution for the web to interact with the dom.
I'm talking about the language for building and adding interactivity to the webpages.
I think google tried to make Dart that language but it did not gain traction for whatever reason (I don't know the language) - maybe it coming from a single vendor had something to do with it.
What I was curious is that is this something that is even being discussed by the powers that be?
I'll take javascript with macros as a compromise. We could at least build DSLs with it.
26 comments
[ 6.7 ms ] story [ 81.2 ms ] threadI wish HN supported markdown for code fragments but the 1st example of code in the post looks something like this:
div _="init fetch https://stuff as json then put result into me">Using fetch() API... /div>
and, IMHO, it's just gross. Worse in ~every way.
:blush:
It should be remembered that Hyperscript is meant to be paired with a technology like HTMX. I don't think the creator of Hyperscript would be suggesting to anyone that someone attempt to create a web application out of pure Hyperscript.
The big idea is a higher level and more expressive scripting language than js that embeds cleanly inline in html. It has integrated css query literals, relative location expressions (e.g. add .foo to the next .bar) and probably its most interesting feature, it resolves promises in the runtime so script writers don’t have to:
https://hyperscript.org/docs/#async
The syntax is based on HyperTalk, the scripting language for HyperCard, which was one of the first programming environments I used when I was young.
Again, not for everyone but I enjoy using it and intend on getting it to 1.0 this summer after I get htmx 2 out the door.
https://hyperscript.org/docs/#exceptions
I don't understand this assertion at all. There is a grammar that must be learned, and it is different from existing solutions, which means most humans will need to reference something until they become familiar enough to work without documentation. I don't see how this is different than React, vanilla JS, or others. The benefits of this do not shine through for me.
Once you get the hang of it, its pretty fun and a little surreal to write effective front end logic in what appears to be a natural language.
Highly recommend it for a prototype and think it was genuinely motivating because it made frontend logic more novel and fun.
Expanding the reliance on ”plain english” also risks hampering future development, since you’re mixing user-defined words with keywords in the same namespace. Taking ’mine’ as an example, would adding it to the language to fill out the first-person pronouns break existing scripts?
That critique aside, I really like it when people try ideas like this and fiddle with our expectations of what programming should look like. Erlang use a combination of commas, semicolons, and dots for defining a single line, the end of a block, and the end of a function. I personally prefer that to our more common curly bracket or indentation-based control flows. Go’s upper- and lowercase visibility modifiers also come to mind. Whatever you personally end up thinking about things like that, to me it’s sort of the hacker mindset at play. I end up liking that playfulness even when the result is not my cup of tea.
Blazor lets you write C# that runs on the frontend. I’d expect to see more of that pattern before browser vendors replace JavaScript.
I'm talking about the language for building and adding interactivity to the webpages.
I think google tried to make Dart that language but it did not gain traction for whatever reason (I don't know the language) - maybe it coming from a single vendor had something to do with it.
What I was curious is that is this something that is even being discussed by the powers that be?
I'll take javascript with macros as a compromise. We could at least build DSLs with it.