The Applescript/Hypercard script this is inspired by were created to resemble prose to make it easier to understand for non-technical people (and one can argue in hindsight that to be a misguided design goal)
There is no need for a light JS replacement to be as verbose as prose. The Venn diagram of engineers trying Hyperscript out on their side projects and people unfamiliar with code syntax are two distinct circles.
If you want to put logic in HTML attributes, it needs to be concise and expressive, not resembling English prose. Even APL would be a better choice.
I once had a Venn diagram to display the set of people who are fluent in APL-like languages but it was so small I needed a microscope to see it. Now I've no idea where it might be, I'm afraid I accidentally brushed it from the table along with some breadcrumbs
I do agree but am open to the idea that HyperTalk and COBOL are actually more understandable to masses of people who I don't relate to in really any way.
I see a visual language Node-RED with tunable parameters in nodes as the way but have kept up with this project a little... no reason user scripts need to be one or the other.
I guess developers will be valuable in implementing and supporting users in any case, I see these tools as reducing support and maintenance for doing variations from the day to day business use more than replacing the dev team.
Hyperscript is designed to be easy to read when embedded within html. The xtalk[1] syntax is more verbose and stands out. This is intentional and is made up for, to an extent, by more expressive features like relative position expressions, CSS literals and so on:
on click toggle .active on the next <div/>
Certainly not for everyone but it is being used in production in multiple applications.
What I like about your philosophy is that you don't try to solve the world's problems - you release useful tools that might work for some people, and you don't apologise for those that don't find them useful.
Hyperscript, from the same author as htmx, complements it well. For instance, Hyperscript maintains its state on an element when you swap something out in the DOM. It bridges the gap for changing the DOM without making a round trip to the server.
It looks like a shorter and more specific syntax for things you can already do with vanilla stuff. In theory more tricky but faster to develop for one person (something like tailwind for JS). I find tailwind makes me develop faster than css but is a bit more tricky to get started on existing tailwind components than in just CSS components.
I understand the fundamental motivation for this sort of thing. The web is a static document display that over many decades of augmentation and extension has morphed into an app development platform. And arguably, a lot of the mechanics of it are less elegant than in purpose build app-development environments.
But, I don't think another language that tries to abstract the fundamentals is the solution to that. I think this is true for Hyperscript - as much as it is for JSX and Co. JavaScript is the most widely known programming language, has the most extensive knowledge base and the biggest ecosystem. And there's no shortage of frameworks that make using it easier without reinventing the wheel.
I believe using anything else for a serious project severely limits the talent pool from which you can hire, the ecosystem you can draw from and the maintainability of your project in the long run.
Hey everyone I’m the creator of hyperscript (and htmx). I know the syntax for hyperscript is a bit jarring but it is designed to embed well directly in HTML for light scripting needs, as a complement to htmx. It isn’t designed to be a language for building a ton of logic in.
It is easier to read rather than to write by design and is inspired by HyperTalk, the scripting language for HyperCard. I don’t expect or recommend it to be a general replacement for JavaScript, but it can be nice for light scripting for the web.
As far as features go, besides the xtalk based syntax it has things like CSS literals and relative positional expressions that make scripting the DOM easier:
on click toggle .active on the next <div/>
probably the most interesting feature to most HN is that the runtime automatically resolves promises so script writers don’t have to:
this, coupled with event-based control flow can make for some interesting scripting patterns.
Anyway, not for everyone but it is a passion project of mine and is being used in production. I’m hoping to get it to 1.0 this summer after htmx 2 stabilizes. Happy to answer questions.
I know tcl also allows you to extend the language, but i have to admit I've never looked too much into it. Like tcl, hyperscript has strong start tokens for most statement-like things (we call them commands, as does tcl if i understand correctly).
I don't think it maps well to macros, it's just an open parser that you can plug new stuff into pretty easily by adding a keyword + some parsing and eval logic to dynamically.
Even though you’ve explicitly positioned it for light scripting, do you have concerns about de-“color”ing async (as in obscuring the fact that it’s infectious) as a potential footgun?
it can get you into trouble if you really want async behavior but promises are resolved at the expression level by the runtime (slow) so it's hard for them to leak out and, for scripting, it is usually a nicer experience:
May I ask: if it's intended to be used with HTML language, why not use legal HTML syntax? (Custom author-defined tag names, custom attributes for those custom tags, and data-* attributes on any element are all legal ways to extend HTML with new attributes)
you can use a data attribute if you want, data-script="on click log 'yay'"
i don't have strong opinions on that, i've been told by people who work on the browsers that, from a practical perspective, custom non-data attributes are supported and always will be, and the underscore attribute is a tribute to underscore.js, a library I always liked.
Some thoughts: Browser developers today can't speak for the way browser makers in the future may build standards-based browsers. Standards provide a level of future-proofing. Also browsers are not the only tools developers will use to interact with HTML. And most importantly, the custom extensibility built-in to the HTML language is supported by all browsers as well.
I'll never understand why people insist on making tools that depend on non-standard/illegal HTML when HTML is perfectly extensible. Authors are free to invent custom tag names (according to some rules) and free to create attributes (according to some rules) but this appears to break those rules and depends on people authoring invalid illegal HTML.
Why can't we extend standards-based languages using the built-in custom extensibility they already have?
34 comments
[ 2.9 ms ] story [ 42.9 ms ] threadFrontends do not need boilerplate, they need a simple, efficient and maintainable way of interacting with data and managing mutations.
There is no need for a light JS replacement to be as verbose as prose. The Venn diagram of engineers trying Hyperscript out on their side projects and people unfamiliar with code syntax are two distinct circles.
If you want to put logic in HTML attributes, it needs to be concise and expressive, not resembling English prose. Even APL would be a better choice.
I once had a Venn diagram to display the set of people who are fluent in APL-like languages but it was so small I needed a microscope to see it. Now I've no idea where it might be, I'm afraid I accidentally brushed it from the table along with some breadcrumbs
I see a visual language Node-RED with tunable parameters in nodes as the way but have kept up with this project a little... no reason user scripts need to be one or the other.
I guess developers will be valuable in implementing and supporting users in any case, I see these tools as reducing support and maintenance for doing variations from the day to day business use more than replacing the dev team.
1 - https://en.m.wikipedia.org/wiki/HyperTalk
Has anything improved since?
But, I don't think another language that tries to abstract the fundamentals is the solution to that. I think this is true for Hyperscript - as much as it is for JSX and Co. JavaScript is the most widely known programming language, has the most extensive knowledge base and the biggest ecosystem. And there's no shortage of frameworks that make using it easier without reinventing the wheel.
I believe using anything else for a serious project severely limits the talent pool from which you can hire, the ecosystem you can draw from and the maintainability of your project in the long run.
It is easier to read rather than to write by design and is inspired by HyperTalk, the scripting language for HyperCard. I don’t expect or recommend it to be a general replacement for JavaScript, but it can be nice for light scripting for the web.
As far as features go, besides the xtalk based syntax it has things like CSS literals and relative positional expressions that make scripting the DOM easier:
probably the most interesting feature to most HN is that the runtime automatically resolves promises so script writers don’t have to:https://hyperscript.org/docs/#async
this, coupled with event-based control flow can make for some interesting scripting patterns.
Anyway, not for everyone but it is a passion project of mine and is being used in production. I’m hoping to get it to 1.0 this summer after htmx 2 stabilizes. Happy to answer questions.
I don't think it maps well to macros, it's just an open parser that you can plug new stuff into pretty easily by adding a keyword + some parsing and eval logic to dynamically.
i don't have strong opinions on that, i've been told by people who work on the browsers that, from a practical perspective, custom non-data attributes are supported and always will be, and the underscore attribute is a tribute to underscore.js, a library I always liked.
i am not ideological about it
Some previous discussion from 2021: https://news.ycombinator.com/item?id=26873682
Why can't we extend standards-based languages using the built-in custom extensibility they already have?
No one wants to do that.
Do we have some htmx flavor ability to fetching raw html string and update elements with it?