[HN Gopher] Introducing command And commandfor In HTML
___________________________________________________________________
Introducing command And commandfor In HTML
Author : Kerrick
Score : 209 points
Date : 2025-03-07 17:24 UTC (5 hours ago)
(HTM) web link (developer.chrome.com)
(TXT) w3m dump (developer.chrome.com)
| alterom wrote:
| Is that a proprietary HTML extension?
|
| Are we back to the IE-era mess then?
|
| If so, let's bring <marquee> back.
| Frederation wrote:
| Man, that brought back memories.
| finnthehuman wrote:
| >Is that a proprietary HTML extension?
|
| No, of course not. Web standards are whatever google decides
| they are.
| shermantanktop wrote:
| Have you been following how HTML has evolved over the past 20
| years? Your comment suggests not.
|
| It's not entirely a standards-driven process. It's common for
| browser vendors to just build stuff. That's been a mixed
| blessing but it has definitely been faster than some W3C
| consortium debating "ergonomics" for years.
|
| Successful additions get backported into the spec, slowly.
| jdiff wrote:
| Doesn't appear to be.
|
| https://github.com/whatwg/html/pull/9841
|
| https://github.com/whatwg/html/issues/9625
|
| Seems to have been in the works since 2023, out in the open,
| with support from all major browser engines.
| anamexis wrote:
| TFA links to the spec -
| https://html.spec.whatwg.org/multipage/form-elements.html#at...
|
| It's in Firefox and Safari
| hennell wrote:
| Marquee still works, we just don't tell marketing.
|
| https://caniuse.com/mdn-html_elements_marquee
| slt2021 wrote:
| Chrome is the new IE. Whatever google decides will become a
| standard (both defacto due to them controlling the market and
| just shipping new version just in time and de-jure due to them
| financing W3C consortium and other standard bodies)
| ykrishnan wrote:
| Is there an RFC for this?
| teh_klev wrote:
| Start here I think:
|
| https://github.com/WebKit/standards-positions/issues/264
| jt2190 wrote:
| The specifications
|
| 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...
| msub2 wrote:
| Invokers are not just a Chrome thing for those wondering, it's
| already in Firefox nightly as well
| https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonE...
| Kerrick wrote:
| WebKit has taken a "support" position.
| https://github.com/WebKit/standards-positions/issues/264
| QuadmasterXLII wrote:
| 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
| alterom wrote:
| _> hopefully this leads to a surge in polite programming_
|
| But not _too_ polite. The compiler wouldn 't like that.
| SAI_Peregrinus wrote:
| Of course not. Sycophantic code is quite grating.
| esafak wrote:
| _Demure_ is the fashion these days, I 'm told.
| mock-possum wrote:
| Very.
| fuzztester wrote:
| Well, at least the Boo compiler would not.
|
| https://en.m.wikipedia.org/wiki/Boo_(programming_language)
| DonHopkins wrote:
| Not to mention reversible computing's "gofrom" and "cometo".
| toomim wrote:
| comehither
| jayd16 wrote:
| 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.
| gmueckl wrote:
| COMEFROM is one of the many great jokes that form the
| Intercal language. I recommend reading the language
| specification.
|
| Of course, COMEFROM's grown up (and very real) sibling is
| ALTER GOTO in COBOL.
| bunderbunder wrote:
| 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.
| stonogo wrote:
| Perl has supported comefrom for decades!
| https://metacpan.org/pod/Acme::ComeFrom
| fuzztester wrote:
| _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:
|
| go and co
|
| le and re
|
| for fans of succinctness / conciseness.
|
| PRs are open.
| darth_avocado wrote:
| My dyslexic self got excited for command and conquer in HTML
| netghost wrote:
| I definitely read about buttons waiting to see how this would
| unlock the ability to transpile Command and Conquer in some
| novel way.
|
| Still appreciate the new features though.
| k6hkUZtLUM wrote:
| Me too. I was reading about buttons ... and wondering where was
| the game?
|
| Although, the buttons are very interesting.
| DeathRay2K wrote:
| Just today I discovered there's a Red Alert port to Three.js in
| the works: https://github.com/chongdashu/CnC_Red_Alert-ThreeJs
| TIPSIO wrote:
| So basic click events without JS.
|
| Seems to only work with popups?
|
| Maybe a push for Google Ads on that super tiny bit of ad market
| who don't use JS
| error9348 wrote:
| Would make interaction easier for ai agents on the web.
| badc0ffee wrote:
| And screen readers.
| vFunct wrote:
| Seems like they shouldn't have implemented this without a full
| API. Instead the 5 or so commands, it looks like it's possible to
| implement ALL JavaScript functionality through HTML, including
| high level APIs. That could be thousands of commands..
| ericyd wrote:
| This is my thought too, I'm having trouble envisioning a case
| where a reasonably complex UI wouldn't still need JS. I guess
| it provides a roadmap to incremental adoption.
| Someone1234 wrote:
| The real power is custom commands and a standard way to
| implement them. The built-in commands will always be just
| conveniences that many convert to a custom version as
| complexity increases.
|
| Even something like close will wind up being --my-close, and
| several additional checks will be run before dialogEl.close()
| is called.
| PokestarFan wrote:
| I don't see how it should be too hard to implement, you could
| abstractly have a system where the command string is translated
| as such:
|
| 1. Split the string by dashes into an array
|
| 2. Make the first character of the first array item lowercase,
| make the first character of the rest uppercase
|
| 3. Concatenate the pieces together
|
| 4. Do
| `document.getElementById(element.commandfor)[concatenated]()`
|
| Obviously this doesn't have the myriad number of checks to make
| sure that the element exists, the method exists, the method
| takes no parameters, etc.
|
| This would also allow custom commands easily, since you could
| do `document.getElementById(element.commandfor).myCustomMethod
| = function() { /* ... */ }`
| gatinsama wrote:
| It's good they are improving and extending HTML, but still a long
| way to go. The HTMX guys have a few good ideas.
| rsync wrote:
| No, it is _terrible_ that "they" continue to extend and
| "improve" HTML.
|
| This is the reason it seems impossible for an independent web
| browser to be created and maintained: because what should be a
| simple and predictable spec over the last twenty years is a
| rapidly moving target that takes significant resources just to
| track.
|
| We could have ten different open-source web browsers (like
| Konqueror) if we weren't cramming the HTML spec full of bloat
| that nobody wants and that we all install extensions to disable
| anyway ...
| hoc wrote:
| 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.
| dartos wrote:
| It's not that the idea is brand new, just that it's now
| implemented in chrome and in the web specs.
| Starlord2048 wrote:
| Thanks for sharing
|
| The idea of declarative UI actions without JS is appealing
|
| The good:
|
| * Killing boilerplate for popovers/modals (no more aria-expanded
| juggling).
|
| * Built-in commands like show-modal bake accessibility into
| markup.
|
| * Custom commands (e.g., --rotate-landscape) let components
| expose APIs via HTML.
|
| My doubts:
|
| * Abstraction vs. magic: Is this just shifting complexity from JS
| to HTML? Frameworks already abstract state--how does this
| coexist?
|
| * Shadow DOM friction: Needing JS to set .commandForElement
| across shadow roots feels like a half-solved problem.
|
| * Future-proofing: If OpenUI adds 20+ commands (e.g., show-
| picker, toggle-details), will this bloat the platform with niche
| syntax?
| SamBam wrote:
| > Abstraction vs. magic: Is this just shifting complexity from
| JS to HTML? Frameworks already abstract state--how does this
| coexist?
|
| The same way React or other frameworks can hook into things
| like CSS animations. If CSS animations didn't exist, the JS
| framework would have to write all the code themselves. With
| them existing, they can just set the properties and have it
| work.
|
| Even if you're writing a basic menu popup directly in React,
| having these properties to use directly in your JSX means less
| code and less room for error.
|
| Then if you need to do something special, you may need to do it
| by hand and not use these properties, just like if you needed a
| special animation you might have to do it without using the CSS
| animation properties.
| fitsumbelay wrote:
| agreed, my sense is that frameworks will update to take
| advantage as they've done in the past
| toomim wrote:
| > Is this just shifting complexity from JS to HTML?
|
| Very well said. This is the problem.
|
| There's an old adage that every "scripting" language starts out
| small, but then ultimately needs all the features of a full
| programming language. If we start putting programming features
| into HTML, we'll eventually turn it into a full turing-complete
| programming language, with loops, conditionals, variables, and
| function calls. We'll have recreated javascript, outside of
| javascript.
| satvikpendem wrote:
| CSS is now getting functions as well [0].
|
| [0] https://news.ycombinator.com/item?id=43236126
| toomim wrote:
| Horrible. We're going to end up with three separate
| languages: CSS, HTML, and Javascript, which will each be
| turing-complete programming languages with completely-
| overlapping featuresets, and there will be no clear reason
| to use one over the other.
|
| Browsers will have to implement support for three PL
| runtimes. Everything will be complicated and confused.
| xg15 wrote:
| Everything will be _even more_ complicated and confused.
| someothherguyy wrote:
| The sky isn't falling, and nearly everything is trending
| better, not worse. You can use whatever features of
| browsers that you want.
| metadat wrote:
| There are tradeoffs. Further increasing the barrier to
| entry for new web browsers benefits the entrenched
| players and hurts end users by yielding fewer
| alternatives.
| AlienRobot wrote:
| Maybe in ten years they will finally add enough languages
| to each one of these 3 languages to make them good enough
| to compete against Delphi.
| pphysch wrote:
| It's not just shifting complexity. It improves locality of
| behavior (LoB). You can look at a <button> element and
| immediately know what it does (within the limited domain of
| "command"s). This is a dramatic improvement to readability.
| jauntywundrkind wrote:
| My long-shot hope is that the page can come to embody most
| of the wiring on the page, that how things interact can be
| encoded there. Behavior of the page can be made visible!
| There's so much allure to me to hypermedia that's able to
| declare itself well.
|
| This could radically enhance user agency, if
| users/extensions can rewire the page on the fly, without
| having to delve into the (bundled, minified) JS layers.
|
| There's also a chance the just-merged (!) moveBefore()
| capability means that frameworks will recreate HTML
| elements less, which is a modern regression that has
| severely hampered extensions/user agency.
| https://github.com/whatwg/dom/pull/1307
| xg15 wrote:
| My prediction: In a few iterations this will have turned into
| an inferior reinvention of HTMX.
| tomrod wrote:
| I'm not a web dev, so I apologize if my questions are naive.
| Does this mean its a chrome-only thing or does it become a web
| standard? I ask because I would like to imagine the future
| isn't tied to Google's whims, graveyard of initiatives, and
| requirements.
| cratermoon wrote:
| I'd gladly give up this if I could get ublock origin and other
| pre v3 extensions back
| ulrischa wrote:
| HTML seems to incubate some htmx things
| lelandfe wrote:
| Random aside. Their code snippet has this comment:
| // popovers have light dismiss which influences our state
|
| And I hadn't heard of that phrase before! Turns out it means
| "clicking elsewhere closes the thing:"
|
| > _" Light dismiss" means that clicking outside of a popover
| whose `popover` attribute is in the auto state will close the
| popover._[0]
|
| Like what, say, a `<select>` does when open.
|
| Strikes this dev as a pretty unintuitive way to phrase that. At
| first I thought it was "light" as in "light DOM," but I guess
| it's "light" as an antonym of "explicit?" Looks like there was
| some back and forth on this, and it was even proposed as an
| attribute: https://github.com/openui/open-ui/issues/834
|
| [0]
| https://html.spec.whatwg.org/multipage/popover.html#popover-...
| Izkata wrote:
| I think "light" is used as in "light touch" (soft touch),
| something that includes brushing against a surface by accident.
| efortis wrote:
| I'd guess it stands for highlight. For example a modal is
| often highlighted by dimming and blurring the background.
| david422 wrote:
| Also random aside. I dislike this pattern for modal dialogs.
| Often times I will need to gather information from somewhere
| else, and in the process of attempting to get focus back to the
| dialog I've touched/tapped/clicked on something that dismisses
| the dialog. Very annoying.
| dylan-m wrote:
| I'm okay with modal dialogs working that way as long as
| people get the message: dialogs are supposed to be
| _ephemeral_. If closing the dialog loses important state, or
| you need information from something under the dialog in order
| to use the dialog, what you have shouldn 't be a modal
| dialog. And you can tell, because in most UI frameworks that
| widget is just begging to be closed. Unfortunately, a lot of
| teams don't get the message.
| jazzyjackson wrote:
| Just noticed this bug in Simplifi expense tracking web app.
| The drop down to update the category of a transaction has
| multiple levels (e.g. Business:Travel:Lodging) and as soon as
| I hover over a nested drop down the whole thing disappears.
| victorbjorklund wrote:
| Most of the times that would be better solved with not using
| a modal.
| bartkappenburg wrote:
| Light is the opposite of hard (ie hard close). It makes more
| sense (to me!) to use explicit vs implicit close? Clicking
| outside the popover means an implicit close.
| hatthew wrote:
| Anecdotally, when I read the first two lines of your comment I
| immediately thought "that probably means you can click
| elsewhere to close it"
| prmph wrote:
| We need a proper rich UI application execution environment, and
| if HTML, being a primarily document oriented platform can't be
| retrofitted to provide that, then we need a new one
| skydhash wrote:
| Flash? Silverlight? Swing?
| prmph wrote:
| I see you are skeptical, but the failure of those
| technologies does not mean a new HTML-like platform cannot
| succeed.
|
| We've learned a lot about security, DX, and UX since those
| times. A new platform can apply all those.
| nullpoint420 wrote:
| +1. The Web Platform is this interesting blend between
| declarative and imperative, but with the benefits of neither.
|
| IMO, the web platform needs a retained mode UI model like Qt
| Widgets, AppKit, or UIKit. Then desktop-like applications like
| Figma wouldn't need to compile to WASM and render WebGL for
| their UI. They could just treat <divs> as views or layers.
| satvikpendem wrote:
| Ian Hickson, who authored the HTML5 spec and leads Flutter, has
| written about exactly this, _Towards a Modern Web Stack_
| [0][1], to create a new stack that can handle modern web
| applications. Flutter is a part of it but he talks about a more
| general (and generalizable) stack. He 's on the HN thread as
| well expanding on the rationale behind it. Interestingly, it
| seems like specific people on HN don't exactly like it, a bit
| funny to witness their crash outs.
|
| [0] https://news.ycombinator.com/item?id=34612696
|
| [1]
| https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...
| (actual doc to read)
| prmph wrote:
| I have gone through Hickson's proposal, interesting.
|
| I notice though that he is proposing to address the problem
| from the opposite direction to mine, though I think his
| approach is also viable. I dream of an HTML-like platform
| built to support rich UI apps, with much higher-level
| configurable primitives that eliminate the need for massive
| amounts of scripting and dependencies. He talks about
| providing properly configurable low-level primitives.
|
| Both approaches can work if built properly to support what
| developers actually want to do. One thing that put me off
| WASM was the dependence on JS to bootstrap it. I just did not
| want to have JS in pipeline again whatsoever if I was taking
| that approach. The advantage of high-lvel primitives is that
| there will be much more of what developers want to build that
| is already built into the platform.
| satvikpendem wrote:
| Have you tried Flutter? It works well although web
| performance leaves some to be desired.
| mappu wrote:
| Joey Hess had this suggestion recently -
| https://news.ycombinator.com/item?id=43202773
| SoftTalker wrote:
| It's been some years since I coded any front-end HTML. Sure looks
| like it's gotten messy.
| flowerthoughts wrote:
| Oh, this seems like a nice generalization of the popover specific
| attributes. Could replace <button type="submit"> with <button
| command="submit"> and default commandfor to the ancestor form.
| fitsumbelay wrote:
| more builtin behavior, less JS to ship. pretty dope
| fngjdflmdflg wrote:
| >the new command and commandfor attributes, enhancing and
| replacing the popovertargetaction and popovertarget attributes.
|
| At first I was worried because they just added the popover API
| recently, which itself replaced <dialog>, but this is still using
| the same API, just calling it from HTML differently. Still, I'm
| not fully clear on what the long term goal here is? Replacing UI
| toolkits? Simplifying state frameworks by removing js from
| certain functions? For example, the play/pause functionality.[0]
| For a simple website, you don't need to add any such
| functionality because browsers have built in video players that
| allow you to play, pause, mute etc. So this isn't necessary for
| simple websites. But then for websites that are more complex, you
| would already be using js presumably?
|
| I do mostly like what is written here about the project in
| general, which seems to answer the above question:
|
| >But another 15 years have gone by since the last major revision
| to form and UI interfaces. Most complex web projects today need
| far more than what HTML5 form and UI controls provide. And so,
| all-too-often today's web developers turn to heavy JavaScript
| frameworks to build the user interfaces their designers are
| asking for. These custom interfaces are rarely fully accessible.
| They slow down the page, consume power, open security
| vulnerabilities and exclude people.
|
| >Additionally, today's projects often reject existing built-in
| form and UI controls because they require more agency over the
| look and feel of the interface. Web designers demand the ability
| to express their project's branding across every element on the
| page, including all user interfaces. Current form and website-
| level UI controls do not allow for this.[1]
|
| So the goal is to remove JS from UI components for UIs that
| already exist natively in HTML. Still, at least for the above
| video example, some sites want different behavior when the user
| taps on the screen. Some will bring up the video playback bar and
| settings, others will immediately pause, others will pause if the
| playback bar is hidden and remove the bar if visible, etc. I
| don't see how you can do that without JS, at which point
| el.playing = false seems much better than using a button command
| attribute. Or is this just a bad example?
|
| [0] linked in the article: https://open-ui.org/components/future-
| invokers.explainer/
|
| [1] https://open-ui.org/charter/
| werdnapk wrote:
| The popover API is not a replacement for <dialog>. It's an
| alternative to some dialog like functionality if the use case
| is right.
| slt2021 wrote:
| Very good innovation - to eliminate all standard boilerplate
| javascript and code it into the HTML in declarative manner.
|
| Less javascript the better, plus it allows to impute dynamic
| behavior from HTML tags, without parsing JS code
| naikrovek wrote:
| it looks clean, now.
|
| web devs will get ahold of this and demand that they have the
| ability to change the size, the animations of appearance and
| disappearance, specify a sound that plays when the menu is
| opened or closed, etc. I'm saying that this, like all other web
| things, will be bastardized and mutilated until it is just as
| complex and unworkable as the existing solutions which this is
| intended to replace.
| slt2021 wrote:
| I am fine if structural stuff can be coded in HTML, while
| animations and bells and whistles will still have to be
| JS/CSS based
| Tarucho wrote:
| I like how they present it as a novel idea, when this is as old
| as it gets. This is not new of course but it seems it won't stop.
| Ever.
| karol wrote:
| That looks like more XSS vectors.
|
| Also what do I do if I want to fire analytics even and open the
| modal. Correct, use onClick.
| kflgkans wrote:
| > That looks like more XSS vectors.
|
| Could you elaborate on that? I don't understand how this leads
| to more XSS vectors.
| nikeee wrote:
| > 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.
| pavlov wrote:
| It's just like the target / selector pattern from NeXT AppKit
| over thirty years ago... Except that the syntax is clunkier and
| less type-safe than what they did using 1994 Objective-C.
|
| It's not exaggeration to say that the web has set UIs back by
| decades.
|
| The other day I was trying to make editable table cells in a
| leading "enterprise-grade" React component framework. It required
| several screenfuls of obscure and brittle code. The same
| operation used to require implementing a single delegate method
| in 1990s AppKit.
| gear54rus wrote:
| > set UIs back
|
| Oh that's why 90% of online interactions are now on the web now
| ... stupid me thinking because it's a superior solution.
|
| And before you say '90% are actually on mobile', well mobile
| doesn't use shit from 1994 also. Wonder why.
| pavlov wrote:
| Mobile absolutely uses "shit from 1994".
|
| The UI framework in iOS is a direct descendant of the NeXT
| one I'm talking about.
| mattl wrote:
| Yep. All of the main 5 operating systems for consumers are
| from the late 80s and early 90s.
|
| - Windows 11 is Windows NT
|
| - macOS is NeXTSTEP/OPENSTEP
|
| - Linux is a free Unix like from the era where that was a
| new thing with both BSD and GNU working on it
|
| - Android is Linux + Java (inspired by OpenStep)
|
| - iOS/iPadOS is NeXTSTEP/OPENSTEP for phones.
|
| (OPENSTEP is an OS. OpenStep is a framework)
| deergomoo wrote:
| The web is the best application distribution mechanism the
| world has ever seen. Even though things have improved
| _enormously_ in the last decade and a half, the ceiling is
| still miles below native (though the floor is far more
| accessible). None of that matters though, because all someone
| needs to do to get your app in front of their eyeballs is
| type a URL.
| ChrisClark wrote:
| >stupid me thinking because it's a superior solution.
|
| You think your snarky sarcasm fits, but it really doesn't.
| "Oh, everyone uses it, so it must not actually be bad?"
| That's not a good argument at all. :D
| diegof79 wrote:
| The main feature of the web is ubiquity. Doing a native app
| requires installation, update handling, etc.
|
| That's why the "web won." But, when it comes to UIs, it is
| not technically superior.
|
| The most popular technology is usually not exceptional in
| every aspect but is the most convenient for popular use
| cases. For example, LISP predates C by decades. Technically,
| C is inferior in abstraction, but ATT used it for Unix,
| quickly becoming the de facto standard for systems
| programming. That makes C a better option than LISP, only
| because you'll need to go into extra layers of complexity to
| do a system call designed for C. For the web, you can only
| use HTML/CSS/JS (even with WASM).
|
| "Mobile doesn't use shit from 1994"... well all the iOS apps
| are based on Next frameworks created in the 80s.
|
| You probably have never used a native UI framework or tried
| to create an accessible component library for the web, to say
| something like that. Try to create an accessible select
| component that shows an icon in its options using a native
| framework and HTML, and you'll quickly see what I mean.
| withinboredom wrote:
| Please don't be creating select components. The native one
| is just fine and works 100% of the time. For those of us
| using translation tools and trying to navigate the shit
| designers came up with because they want to make it
| "pretty" is just ... annoying and full of grief. Just say
| no.
| hombre_fatal wrote:
| > It's not exaggeration to say that the web has set UIs back by
| decades.
|
| These claims always seem to break down once you ask for
| concrete examples.
|
| 1. The React/JS code is far simpler and less clunky than the
| Objective-C equivalent.
|
| 2. The HTML commandfor/command is declarative and simple unlike
| Objective-C target/selector
|
| Paste the HTML commandfor snippet from TFA and ask an LLM what
| the Objective-C equivalent. If you think it's less clunky, go
| ahead and paste it here for us to judge. ;)
|
| > It required several screenfuls of obscure and brittle code.
|
| Yet still better than the brittle, obscure horrors of the
| procedural Objective-C Cocoa apps I used to have to work on.
| thesz wrote:
| > The React/JS code is far simpler and less clunky than the
| Objective-C equivalent.
|
| How does it compare to Tcl/Tk? Especially canvas with tags
| over elements, with tags having their own bindings.
| DannyBee wrote:
| "1.1. The React/JS code is far simpler and less clunky than
| the Objective-C equivalent.
|
| Hard disagree - in objective C, I never had to worry about
| making sure I (and every library I use) calls hooks in the
| exact same order on every single render, for example. It does
| this for 'brittle" reasons - it associates state with the
| order of hooks.
|
| (For any react folks - this isn't meant as judgement as much
| as an explanation :P)
|
| Since i'm semi-retired, and only do this for fun, i spent a a
| week last month chasing down react hook usage bugs in
| libraries my app depended on and sending patches. I think i
| got up to 23. Because the ecosystem in javascript is so deep
| on dependencies, you often depend on an amazing amount of
| people getting everything correct. This was much less true in
| Obj-C as well.
|
| Some of them had also made 'the error go away' by moving code
| to useCallback's inside setTimeouts so they wouldn't be
| noticed by the hook checker (but this in turn has no
| guarantee of ordering wrt to react effects, of course),
| leading to even more subtle bugs.
|
| I won't even get into things like async in react vs
| objective-C (though to be fair, bad integration with async
| afflicts a lot of popular JS frameworks)
|
| In the end: React is fine once you learn it. Obj-C is fine
| once you learn it.
|
| But acting like react is not clunky or brittle is, and obj-c
| is, is definitely a stretch.
|
| All of the things here are clunky and brittle, just in
| different ways :)
| deergomoo wrote:
| I find it remarkable that despite the massive improvements to
| CSS and JS in the last 15-ish years, additions to HTML are
| glacial. I mean we only just got _popovers_ for christ 's sake.
|
| It's like JS and CSS are fully on board with being an app
| platform and HTML is digging its heels in insisting that
| everything be a document. There is maybe something to be said
| for that argument, but if I'm gonna have to interact with web
| apps I'd rather the list of stuff every developer needs to
| hand-roll in varying-quality JS be a lot smaller than it
| currently is.
| bunderbunder wrote:
| I think that the root of the problem here is that, just like
| the acronym says, HTML really is, at its core, just a markup
| language for writing hypertext documents.
|
| Using it as a domain specific language for user interface
| layout is a horrible kludge that only continues to exist
| because natural selection doesn't give a damn about sensible
| design.
| AlienRobot wrote:
| Absolutely.
|
| What's mindboggling to me is that when HTML5 came out
| people were swearing Flash (and Java applets) would be
| obsolete. Years later the replacement has been the most
| horrid spaghetti imaginable because no matter what
| framework or engine you use, it's going to become HTML+JS!
|
| They should just start supporting Java in the browser
| again. Java. Javascript. Nobody is even going to notice.
| dgfitz wrote:
| I always thought it would be neat if python had been used
| instead of JavaScript.
|
| I have written web apps in c++ (wt framework) and it's
| really neat to be able to leverage c/c++ libs we already
| had, which was what tipped the scales in choosing it.
|
| No it's not the bees knees, but I can be productive, and
| new folks can jump on board and also be productive, very
| quickly.
| AlienRobot wrote:
| I love python, but I don't think Python is the solution
| to Javascript. I mean, Python is much better than
| Javascript, but Python's type hints are much worse than
| Typescript. A modern language needs to be something like
| Java, but with null types.
| mpalmer wrote:
| My sense is that JS and CSS have an easier time with building
| gracefully degraded experiences than HTML might. On top of
| that, changes to HTML either have to be isolated (no
| accompanying changes to JS in the browser), or they have to
| be coordinated with the updates to JS.
| gavinray wrote:
| > The same operation used to require implementing a single
| delegate method in 1990s AppKit.
|
| I find that hard to believe.
|
| And not to "uhm, ackshually" you, but what you're describing is
| possible via the native HTML "contenteditable" property.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
|
| (Actually doing something useful with edits is another story,
| but that's not what the comment is about)
| pfg_ wrote:
| contenteditable is incredibly painful to use, not
| standardized and different across browsers, and buggy in
| firefox
| gavinray wrote:
| Sure, though the question was about "making a table cell
| editable" requiring pages of obscure code.
|
| _Technically_, it requires a single HTML attribute.
|
| If you want to build some sort of reactive, spreadsheet-
| like experience with cells and calculations, then yeah
| there's some inherent complexity in that.
| sangnoir wrote:
| > It's not exaggeration to say that the web has set UIs back by
| decades.
|
| The trade-offs for the UI setback are unbeatable cross-platform
| compatibility, ease of distribution and a decent security model
| with sandboxing. MacOS only introduced desktop app sandboxing
| in the last 10 years, most desktop run software with user
| permissions which is not great.
| roon_shady wrote:
| am I the only one annoyed by the fact that they do not have
| syntax highlighting on most of their code examples?
| garganzol wrote:
| I do not understand why they did it now when JavaScript already
| does it. The thing just adds entropy without a clear value.
| webnoob wrote:
| I'm curious, as a noob in web programming. That first example
| does document.addEventListener('click', ...
|
| Instead of someButton.addEventListener('click',
| ...
|
| And in fact, all the framework example show button onClick not
| document onClick
|
| I know some situations where adding the event listener to the
| document is correct but I've never seen it in this button type
| situation.
|
| Is that pattern for buttons common? What does it solve?
| zerocrates wrote:
| Generally you do it the "document" way (often called a
| "delegated" listener) when you have lots of elements you want
| to listen to, or particularly elements that will be dynamically
| added and removed.
|
| If you listen directly to every target element, you have to
| find the elements and loop through them all, they have to exist
| at the time you set the listener, and you have to make sure to
| add the listener every time you add a new element that has the
| same behavior. If you listen at the document (or some
| appropriate parent element) and then check if the element that
| fired the event matches what you're trying to handle, you can
| have one listener that will apply to all the matching children
| regardless of where/when/how they're added.
| irjoe wrote:
| Using document.addEventListener means it will work even if the
| DOM is updated without having to add new event listeners. If
| I'm not expecting the DOM to change I would be more inclined to
| do something like:
| document.querySelectorAll('.menu-wrapper')).forEach(menuWrapper
| => { const button = menuWrapper.querySelector('.menu-
| opener'); const content =
| menuWrapper.querySelector('.menu-content'); if
| (!content || !button) { return; }
| button.addEventListener(() => {
| button.setAttribute('aria-expanded', 'true');
| menu.showPopover(); });
| content.addEventListener('toggle', e => { // reset
| back to aria-expanded=false on close if (e.newState
| == 'closed') { button.setAttribute('aria-expanded',
| 'false'); } }); });
|
| The React example seems a little odd as well, if the "open"
| callback actually called "showPopover()" instead of only
| calling "setIsOpen" then the "useEffect" could be entirely
| redundant. The resulting code would be a lot clearer imo.
| luismedel wrote:
| One more case of Fire and Motion[0] in the industry.
|
| [0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
| jandrese wrote:
| > While HTML offers onclick handlers to buttons, these are often
| disallowed outside of demos or tutorials due to Content Security
| Policy (CSP) rules.
|
| What is to prevent command and commandfor from being included in
| future CSP rules for the same reason onClick is?
| jameshart wrote:
| The reason onclick is disallowed is because it permits full
| JavaScript execution. An onlick attribute is 'eval'd on click.
| If you can inject one into a page you get JavaScript execution.
| Hence, content security blocking - a rule served up on the page
| saying 'nothing in this page is supposed to have onclick
| attributes. If you see one ignore it'.
|
| These command attributes are not arbitrary JavaScript hooks.
| They tell inbuilt components to do inbuilt things. It doesn't
| make sense for a content security policy to say 'nothing on
| this page has commands, if you see something that does ignore
| it', any more than it would make sense for a content security
| policy to say 'nothing in this page is in bold, if you see
| something that says it wants to be displayed in bold ignore
| it'.
| mpalmer wrote:
| 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.
| hdjrudni wrote:
| I don't like it either, but at least we can pave over it with a
| framework, unless you're allergic to those. It makes a good
| building block.
| mpalmer wrote:
| True, and don't get me wrong, I think events are great and
| this will be a decent simplification, even with existing
| frameworks.
|
| If it's Turing-complete, non-opinionated and doesn't use
| templates, I can put away the Epipen.
| CodeCompost wrote:
| This is basically HTMX. Why don't they just integrate it natively
| into the browser?
| jl6 wrote:
| Since it's all about buttons, it's a shame they missed the
| opportunity to call it butfor.
___________________________________________________________________
(page generated 2025-03-07 23:00 UTC)