6 ms·

So much boilerplate and unnecessary keywords... Frontends do not need boilerplate, they need a simple, efficient and maintainable way of interacting with data

by mrcino 3y ago

So much boilerplate and unnecessary keywords... Frontends do not need boilerplate, they need a simple, efficient and maintainable way of interacting with data and managing mutations.

CharlesW 3y ago
If anything, this would allow you to omit a bunch of boilerplate that you'd otherwise need to do the same thing in React. (Example here: https://www.infoworld.com/article/3708109/intro-to-hyperscript-rethinking-javascript.html https://www.infoworld.com/article/3708109/intro-to-hyperscri...)
aidos 3y ago
It’s based on AppleScript so I think that’s by design.
sph 3y ago
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.
- DemocracyFTW2 3y ago
  > 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
harlanji 3y ago
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.
recursivedoubts 3y ago
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. 1 - https://en.m.wikipedia.org/wiki/HyperTalk https://en.m.wikipedia.org/wiki/HyperTalk

by mrcino 3y ago

So much boilerplate and unnecessary keywords... Frontends do not need boilerplate, they need a simple, efficient and maintainable way of interacting with data and managing mutations.

CharlesW 3y ago

If anything, this would allow you to omit a bunch of boilerplate that you'd otherwise need to do the same thing in React. (Example here: https://www.infoworld.com/article/3708109/intro-to-hyperscript-rethinking-javascript.html https://www.infoworld.com/article/3708109/intro-to-hyperscri...)

aidos 3y ago

It’s based on AppleScript so I think that’s by design.

sph 3y ago

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.

DemocracyFTW2 3y ago
> 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

harlanji 3y ago

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.

recursivedoubts 3y ago

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. 1 - https://en.m.wikipedia.org/wiki/HyperTalk https://en.m.wikipedia.org/wiki/HyperTalk