While programming language theorists have been speculating about “goto”’s more powerful cousin “comefrom” since the 80s, it was only implemented in intercal. Intercal, while clearly superior in safety, performance, and ergonomics to languages like C, has struggled to break into the commercial market (likely because worse is better). It’s exciting to see javascript integrate this feature from intercal- hopefully this leads to a surge in polite programming, analogous to how javascript’s embrace of closure based objects has driven functiOOPnal programming into the mainstream
Haha, I had completely forgotten about intercal and "comefrom".
Such genius. It anticipates and neatly summarizes the problems I've had maintaining and supporting code written using reactive programming design patterns by a good 40 years.
Maybe I'm lost about the greater theory here. As a non-js dev it looks like they're just adding some OO sugar to events. I hesitate to call it sugar because it seems a lot more verbose than "my-menu.show-popover()" but its better than a global listeners I suppose.
That’s a reasonable analogy, but I think the more novel and interesting thing about this is that it’s:
- A declarative mechanism to relate one element to another
- With a range of semantics for declaring interactivity invoked through their relationship
- At a high level, with explicit guarantees of consistent accessibility and UX
In a lot of ways, this looks a lot like what people describe when they wish for more HTML and less JS. (Except for the extreme-minimalist version of that which rejects web interactivity altogether.)
cough I hereby propose two new language constructs and corresponding keywords, which can be applied (sounds more functional than implemented,) widely across many languages, at least procedural / imperative ones:
goto and comefrom
with optional synonyms:
leave to and return from
the above can be shortened to as little as two letters each:
> Buttons ... provide the foundation of interactivity on the web.
This is a very neat way to sum up the difference between the 'old' and 'new' web. Because, of course, it's the hyperlink that provides the foundation of interactivity on the web.
Hyperlinks aren’t interactive. They’re bookmarks. When I click on a link have I interacted with the page? In a sense I have. But have I changed its state? No. I’ve just moved from one static place to another static place.
The author probably mean hypermedias. Buttons and links are just means, but no interactivity even happens without the user clicking or moving their mouse.
Now we can of course talk about client-only interactivity (as in thick clients like paint apps) but that's not the topic.
I am not sure if the author actually put any thought into the foundation of interactivity on the web, or if they just asked the AI to write a nice-sounding introduction to their article about new button capabilities.
Is this really the action/messaging pattern that Next, Be and then Apple and probably others used about 30 years ago, or did I miss something here.
It was useful in a way but basically evolved into interface-based controller patterns due to the needed complexities and the whish to keep the basic underlying design pattern. So I'd expect to see lots of enhanvement requests once that box was opened :)
There was an early Java UI toolkit by some browser vendor (IFC by Netscape, probably) that allowed to string action elements together like that.
You thought web was 15 years behind, but it quickly catches up to 30 years old tech!
News like this make me feel sick. I thought it could become something usable in my lifetime, but I’m knee osteoarthritis years old and it still reinvents poor man’s target-action. Sad clownage.
> the new command and commandfor attributes, enhancing and replacing the popovertargetaction and popovertarget attributes.
Didn't these just become baseline available? What does it mean, replace them? Will they remove them some day like with import assertions/attributes?
Sometimes things like these make me wonder if the people in charge are conscious about that everything they are putting in will stay there forever. You can't just release an update and remove stuff you ("you" as in: the web devs at your company that happen to be in the same company that builds a browser) don't need any more.
I thought that was odd, too. It would have made more sense if they'd implemented this for media controls first, and then consolidated the popover attributes into it later. This feels like a record for fastest deprecation of a web feature ever.
I don't know if it's the way my brain works, or just an aesthetic thing, but I am completely allergic to programming with strings. Totally get the reasoning behind this, especially the accessibility wins, but I'm not particularly excited about using element IDs for yet another layer of web app behavior.
Stringy code is my go-to example of a code smell. You can do it, it works and yes, as long as you write it correctly it will work correctly, but you're just kicking the can down the road, at best.
HTML elements are naturally stringy and that makes sense -- when the HTML describes a document. But in the context of complex applications it leaves a lot to be desired.
It's a hack.
This isn't to say the feature being discussed is a bad thing. It's obviously a hack. On such an established platform, there's suprisingly little room between 'throw it all out' and 'just one more patch'.
I agree, but at least it is consistent. This is also how `for`, `list`, `aria-labelledby`, `aria-describedby`, and probably many other attributes work.
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
2033:
> While HTML offers command and commandfor handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
Readit News
they make it cumbersome to use by hand, but not impossible
Such genius. It anticipates and neatly summarizes the problems I've had maintaining and supporting code written using reactive programming design patterns by a good 40 years.
But not too polite. The compiler wouldn't like that.
https://en.m.wikipedia.org/wiki/Boo_(programming_language)
They seem similar to goto to me. With goto, the trigger specifies what to do. That's what command and commandfor do.
With comefrom, what to do specifies the trigger. That seems similar to the existing document.addEventListener() in Javascript.
with its grammar feature, it well might, or might as well.
https://en.m.wikipedia.org/wiki/Raku_(programming_language)
https://en.m.wikipedia.org/wiki/Sanskrit
Of course, COMEFROM's grown up (and very real) sibling is ALTER GOTO in COBOL.
- A declarative mechanism to relate one element to another
- With a range of semantics for declaring interactivity invoked through their relationship
- At a high level, with explicit guarantees of consistent accessibility and UX
In a lot of ways, this looks a lot like what people describe when they wish for more HTML and less JS. (Except for the extreme-minimalist version of that which rejects web interactivity altogether.)
wowza, oops, i mean, wow, sir.
you inspired me to respire more deeply.
from which comes an irreversible desire to learn, deeply, about deep learning.
Deleted Comment
goto and comefrom
with optional synonyms:
leave to and return from
the above can be shortened to as little as two letters each:
go and co
le and re
for fans of succinctness / conciseness.
PRs are open.
Leave I follow, but doesn't "return from" rightly describe a continuation as opposed to "come from" which is a nonlocal goto?
This is a very neat way to sum up the difference between the 'old' and 'new' web. Because, of course, it's the hyperlink that provides the foundation of interactivity on the web.
Hyperlinks aren’t interactive. They’re bookmarks. When I click on a link have I interacted with the page? In a sense I have. But have I changed its state? No. I’ve just moved from one static place to another static place.
For example, sorting a table could be achieved by having the column headers be a link to the same url with ?sort_by={colname}
And then the server sees that and sorts and returns.
Same with "dynamic" number of input fields. When the add field link is clicked you reload with ?num_fields=2
Now we can of course talk about client-only interactivity (as in thick clients like paint apps) but that's not the topic.
Not suggesting to use these patterns liberally, but they do work for light interactivity.
Deleted Comment
button element, commandfor armttribute: https://html.spec.whatwg.org/multipage/form-elements.html#at...
button element, command attribute: https://html.spec.whatwg.org/multipage/form-elements.html#at...
It was useful in a way but basically evolved into interface-based controller patterns due to the needed complexities and the whish to keep the basic underlying design pattern. So I'd expect to see lots of enhanvement requests once that box was opened :)
There was an early Java UI toolkit by some browser vendor (IFC by Netscape, probably) that allowed to string action elements together like that.
News like this make me feel sick. I thought it could become something usable in my lifetime, but I’m knee osteoarthritis years old and it still reinvents poor man’s target-action. Sad clownage.
Didn't these just become baseline available? What does it mean, replace them? Will they remove them some day like with import assertions/attributes? Sometimes things like these make me wonder if the people in charge are conscious about that everything they are putting in will stay there forever. You can't just release an update and remove stuff you ("you" as in: the web devs at your company that happen to be in the same company that builds a browser) don't need any more.
Deleted Comment
HTML elements are naturally stringy and that makes sense -- when the HTML describes a document. But in the context of complex applications it leaves a lot to be desired. It's a hack.
This isn't to say the feature being discussed is a bad thing. It's obviously a hack. On such an established platform, there's suprisingly little room between 'throw it all out' and 'just one more patch'.
If it's Turing-complete, non-opinionated and doesn't use templates, I can put away the Epipen.
> While HTML offers onclick handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.
2033:
> While HTML offers command and commandfor handlers to buttons, these are often disallowed outside of demos or tutorials due to Content Security Policy (CSP) rules.