Introducing command And commandfor In HTML
developer.chrome.com
developer.chrome.com
But not too polite. The compiler wouldn't like that.
Let's bring back pronominal adverbs! You may already be familiar with such classics as "therefore" or "whereas". Why not revive all of them? No longer are "hereunder" and "thereinafter" the sole domain of lawyers. That alone would be an epic meme indeed, but we must go therebeyond. It is difficult to believe that anyone ever actually used words like "therethroughout" or "wherewithin", but we can make sure someone does.
You can even make up your own!
Just take any demonstrative (this/that/these/those), interrogative (what/which/who/where), or third-person personal pronoun, and turn it into the corresponding locative adverb, depending on whether you want to indicate being at, coming from, or going to something:
This -> Here/Hence/Hither;
That -> There/Thence/Thither;
What/who/which -> Where/Whence/Whither;
Him/Her/Them -> There/Thence/Thither; etc.
Makes sense? No questions? Great!
Now pick your favorite preposition and stick it on the end. Don't forget to experiment with some archaic prepositions like "anighst", "overthwart", and -- here's a really good one -- "withinside". That one means "within / inside" and I'm sure you can already see the potential.
"What place should I go into?" Nope! "Whitherwithinside should I go?" Now we're talking.
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.
for (let i = 1; i <= 4; i++) {
woman.getOn(floor);
try {
getDown();
} catch (e) {
if (e instanceof NotUpError) {
getUp();
getDown();
}
}
}Of course, COMEFROM's grown up (and very real) sibling is ALTER GOTO in COBOL.
https://www.cs.virginia.edu/~asb/teaching/cs415-fall05/docs/...
- 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.)
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.
with its grammar feature, it well might, or might as well.
TeX will also allow you to embed and force fonts.
Final step: Use something like Lyx, that will let you write and see the embedded font.
intro:
you are talking to an Indian who lives in India, and who knows Hindi (a language derived from Sanskrit) fluently (and has been complimented multiple times for his Hindi speaking ability by native Hindi speakers), and who has studied Sanskrit for 3 years in high school and then 2 years in college, and Hindi for 4 years in high school, including grammar, vocabulary and literature (both poetry and prose) in both languages), and also essay-writing in Hindi. and got a high score in class in both those languages, over all the years that he studied them.
and who has spoken Hindi for much of his adult life.
both those languages are written in Devanagari.
>Sanskrit is written in Devanagari script which is used by nearly a billion people, so any language that groks Unicode identifiers should handle it fine.
whether the (programming) language can grok Unicode, has nothing to do with the number of people who use either Sanskrit or Devanagari, so your statement lacks logic, overall.
you said:
>Sanskrit is written in Devanagari script which is used by nearly a billion people
that statement shows ignorance of actual facts.
here is why:
I had an idea about these points informally, already, being an Indian who lives in India, but I still did a few quick googles, to verify:
List of languages by number of native speakers in India:
https://en.m.wikipedia.org/wiki/List_of_languages_by_number_...
Demographics of India:
https://en.m.wikipedia.org/wiki/Demographics_of_India
https://www.google.com/search?q=number+of+people+who+use+dev...
top paragraph of the results of the above search:
>Today, the Devanagari script is used to write three major languages: Hindi (over 520 million speakers), Marathi (over 83 million speakers) and Nepali (over 14 million speakers).
even if you add the number of people in the Indian diaspora, such as in Fiji, the Caribbean, etc., you will not come to nearly a billion.
you made a wrong assumption:
> You want to pose a challenge, maybe try something like Rongorongo or Klingon.
you assumed that I was posing a challenge. I was not.
you seem to have not recognised that my comment was made in jest:
>b-b-but ... does Perl support Sanskrit?
first of all, I am posting again one of my earlier comments in reply to you:
https://news.ycombinator.com/user?id=fuzztester
let the whole world see it, and know you for the kind of guy you are, chuckadams, you creep, fake, ignoramus and liar.
acting (faux) scholarly and trying to tell me things (which are totally wrong) about my own country and culture, you jackass. you are laughable.
fool. everyone here noticed that you "cleverly" avoided replying to any of my above points, and instead tried to divert the topic by trying to insult me, you fuckhead and fucktard:
>I don't think you're capable of jest. Get some therapy.
hee hee hee.
not just me, no sane or decent person is interested in the opinions of a retard like you, except other retards like you, of which I know there are many, so some are sure to downvote my comment, but who the bloody fuck cares for votes or opinions of others, except losers like you and your friends, who I am sure you will encourage to waste their unvaluable time in downvoting, because laid off and no work and little money left, right? There are tons of recent posts on HN about all the people feeling the pain of no jobs and no money, which situation is partly if not largely due to the brain-dead shenanigans of jokers like you, who kept on demanding unsustainable raises, for years (which is why your jobs went to India and Ukraine and Mexico and ...), and job hopping for the same, which has now finally ended in so many of you guys being kicked out of your comfy, highly overpaid jobs, so that now you are on the street, scrabbling to make ends meet.
you are not capable of anything good, only of rotten shit! :)
I am fine. You need much more than therapy. you need a life, and to have interest in it. until then you will be as unhappy as you are now.
now, fuck off, you pathetic excuse for a human being.
don't waste your time insulting others gratuitously.
:) Google the double meaning (1 and 2) of that last word, or if you are unable to do it, swallow this crumb, dog:
https://www.dictionary.com/browse/gratuitously
and I don't give a flying shit if I am banned for this comment, because you started it, with your 2 ugly comments above, and because who gives a shit about hn in the real world anyway. let the whole world know how discriminatory HN is, with a very western-favoring slant, if not outright racism, towards Indians, Asians, etc., by comment posters, voters and moderators.
i'll repeat what i have quoted here a few times before; it's by Amy Hoy:
Fuck HN.
But still, so long as it’s a script in Unicode, it should all work fine.
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?
They are perplexing until they aren't. Model stack frames as independent state. When you return from a function the stack frame can stick around. Now later, place your stack pointer back in the frame that you returned from earlier.
Add a convention for passing arguments when you update the stack pointer as above. Now you have continuations.
Of course modern LLVM already breaks it up into chunks anyway (given certain flags at least) so it likely isn't contiguous regardless.
they make it cumbersome to use by hand, but not impossible
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.
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
Not if you want to be pedantic. At least, if you want to follow the rules, GET requests should never change visible state on the server.
So the interactivity would be limited to searching/filtering existing content, but you wouldn't be able to add new content.
For that, you'd need POST requests, i.e. buttons.
(Nothing stops you in practice from ignoring that requirement, but it can lead to ugly surprises, such as a crawler triggering a mass deletion because it crawled the /delete links)
Sorting in a GET request param doesn't alter the server's state. It only changes the data representation, not the underlying resources.
This fits "safe" method def (RFC 9110) https://www.rfc-editor.org/rfc/rfc9110.html#safe.methods
But I agree sorting feels like it’s doing “something”… which is where I got stuck thinking about this.
But are you saying that the client view state (example of the sorted data) should not be handled by the server via GET?
If that’s what your are thinking, I’d like to learn more on this rule.
But changing the "default" sort order of a resource (either by physically shuffling the rows on disk or by setting some server-side global variable) would not.
I think it's the difference between making a sorted copy of a list (while leaving the original list untouched) and inline-sorting the list.
Same applies to filtering.
Even storing the processed results in a cache does not validate idempotency, because from a client's POV, the behavior of the next request would be the same, whether the server calculates the result fresh or pulls it from the cache.
(Edit: Realized, I mixed up "idempotent" and "safe" methods there. I was talking about "safe" methods - but those are what applies to GET requests and what can be represented by a hyperlink)
No server processing needed: the page returned can be identical with an onload function that grabs the GET parameters and does the processing on the client to, for example, reorder the rows of a table.
Not suggesting to use these patterns liberally, but they do work for light interactivity.
Now we can of course talk about client-only interactivity (as in thick clients like paint apps) but that's not the topic.
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.
If it's Turing-complete, non-opinionated and doesn't use templates, I can put away the Epipen.
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'.
> 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.
Still appreciate the new features though.
Although, the buttons are very interesting.
Even something like close will wind up being --my-close, and several additional checks will be run before dialogEl.close() is called.
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() { /* ... */ }`
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 ...
To what end?
LadyBird is now using some Swift, but most of the code is still C++. The browser, while extremely impressive (and I’m very thankful it exists), has a ways to go before it’s a true replacement for Chromium/Blink, Firefox/Gecko or Safari/WebKit, and rewriting all the existing code in Swift would be a massive undertaking.
Chromium and Firefox also use some Rust, but re-writing those browsers entirely in it would be an even larger undertaking.
In contrast, a simpler browser spec would make it far easier to create a brand new browser in a memory safe language. Not only would this massively improve security on all operating systems as the browser is a huge vector for exploits, it’d also allow for the creation of new, more secure operating systems. Currently, arguably the biggest blocker for using something like RedoxOS (an OS written in Rust) is that it doesn’t have a web browser that can actually work for a lot of the web. But if the web browser spec were simpler, it’d be much easier to create one and then use that OS.
Obviously we can’t go back in time and make a simpler web-spec, and removing features is a terrible idea as it’d break existing websites. I do think, though, that it’s fair to think very hard before adding new features. I think a complete feature freeze would be overkill — some new features could legitimately make web development simpler and cleaner for many webdevs. I do think there needs to be some thought as to what the end-goal for web browsers is. Is there one? Or will we forever continue to add new features at the current pace? If so, the hopes of building a new, more secure browser are dim. And personally I’d prefer a more secure browser to one with more features.
As a comparison, C++ has been adding plenty of new features, but nearly no devs are aware of the full feature set, and despite the goal of making things simpler, I think many devs are as lost as ever with it, as they still have to interface with code written in old and different manners. On the web dev side, some JS and CSS features do legitimately simplify development and make things easier, but I think it’s fair to say that’s not the case for all new features added.
Is command and commandfor actually a good idea? I understand the point of it, but it seems like yet another layer of cognitive load.
Instead why not just apply the same principle to CSS? If I could make a CSS selector for one element but have the result target other elements, then one could achieve the same results and more. It would require only a few more pseudo-selectors. And while it probably isn’t necessary, I think it might be prudent to mark the properties that undergo state changes. Something like:
#my-popover { display:= none; }
#my-button:click {
|> #my-popover {
display:= block;
}
}
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
This explains why they decided to work on HTML dialogs out of the blue. In their mind, dialog is popup, and an ad popup that you cannot block equals more money for them.
Probably they are creating an area in specification for them to exploit in the future. In a twisted way of course, via extension manifest V4 or something like that.
It is, unfortunately, the least I can do to respect the user, since I have no control over the decision to load horrible tracking scripts onto their browser.
Take a JS dialog or pop-up menu, for example. You would think it would be easy for everyone to use, but a screen reader user might not even be aware that it’s there in the first place. Even when they do, they still need to find it in a linear and possibly very cluttered representation of the page. It could be right next to the "open menu" button, at the bottom of the page, or somewhere else entirely. The menu/dialog could also disappear as soon as they move the focus in an attempt to find it!
These are all things I put up with regularly.
I think anything that makes accessibility easier for developers is a good thing, especially if it just works without having to think about accessibility.
I was just working on an app where this exact pattern would have been useful. The app mixes serverside html with some sprinkles of React for a checkout flow. Command and commandfor would have made the linking of the two much nicer. Apps following the islands pattern will also benefit from this feature.
Sidenote: I think the web's biggest problem in the future will be how hard it is to deprecate functionality.
Maybe we need Html6 to be about removing/simplifying features from the browsers?
[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
document.addEventListener('click', ...
someButton.addEventListener('click', ...
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?
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.
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');
}
});
});
Nailed it.
And the sibling comment got at it but the "magic phrase" to Google for this technique is "event delegation." Two more phrases: delegation relies on "event bubbling," bubbling can be interrupted with "event capturing." (You will rarely want to capture events, it's JS's `!important` equivalent)
One decent overview: https://javascript.info/bubbling-and-capturing
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/
We've learned a lot about security, DX, and UX since those times. A new platform can apply all those.
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.
[0] https://news.ycombinator.com/item?id=34612696
[1] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC... (actual doc to read)
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.
Called for it: https://news.ycombinator.com/item?id=40888664
What's a butfor?
also I sort of expected this feature to interact with CSS somehow, you could implement a lot of behavior by just adding and removing styles
Chrome 37, Aug 2014 Safari 15.4, Mar 2022
popover attribute
Chrome 114, May 2023 Safari 17, Sep 2023
Dialog in Firefox 98 , 2022-03-08 Also, using a poly fill works even on IE 12
popover in Firefox 125, 2024-04-16
https://en.wikipedia.org/wiki/Comefrom
speaks to the history and rightly credits larry clark
<label for="toggle" id="my-button">Toggle Popover</label> <input type="checkbox" id="toggle" style="display: none;"> <div id="my-popover">My content!</div>
</body> Wont this work a toggle popup with html+css only no js yet interactive with label
If I still need js to then submit the form it feels like this falls quite a bit short.
Also what do I do if I want to fire analytics even and open the modal. Correct, use onClick.
Could you elaborate on that? I don't understand how this leads to more XSS vectors.
What is to prevent command and commandfor from being included in future CSP rules for the same reason onClick is?
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’.
Less javascript the better, plus it allows to impute dynamic behavior from HTML tags, without parsing JS code
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.
WTF. Is this for real? This attribute has been around for decades. It used to be the only way to handle events. Can't believe what I'm reading here. All frameworks use a similar construct. What is the actual problem with onclick attribute?
It's a string, so it's basically eval(), and eval gets disabled for all kinds of legit reasons. It often gets disabled along with inline script tags, which shuts down a whole class of XSS attacks -- which maybe your code isn't vulnerable to, but who knows what some random third party markdown renderer might enable?
The alternative to on* attributes is addEventListener, which has also been a thing for decades.
With that kind of logic, why not disable fetch() calls and all other calls to any backend service? You know, the backend might respond with some untrusted user input which might end up executed as a script (e.g. in a template or something, some frameworks use eval or a dynamic Function)... We need to protect the developer from that risk... All webpages should be static web pages; no untrusted remote data!
I mean these arguments don't quite make sense. You can't remove useful functionality which could potentially be misused under the pretext of adding security. By the time you remove all such features, there will be no features left to use at all! You will end up with a very secure brick which does nothing.
It's a habit in certain large companies to just ban any tool which might potentially be misused.
I see the utility but it's disappointing. I hope they don't force it on everyone because the risk vs solution tradeoff is not relevant to most entities who use it.
I'm surprised they're still keeping this convention of kabob-to-camelCase function name transcribing. I've never been a fan.
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?
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.
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.
Browsers will have to implement support for three PL runtimes. Everything will be complicated and confused.
JavaScript Style Sheets (JSSS) alternative to CSS, a "Programmable CSS"
Never got spotlight because stubborn people werent ready to let go of css
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
I would love this. As a Tailwind user the last few years, it’s really been refreshing to have my styles both readable and inline on the elements instead of filed away in SCSS I’ll never see again. Even with scoped styles, some components get large enough that it feels unwieldy
Html should be powerful enough on its own to provide basic web page functionality to majority of use cases and only then the user should give explicit permission for the server to rum unrestricted code.
My favorite experience of shifting logic is writing a template engine in PHP. PHP is a template engine. I soon discovered I tried to replicate more and more PHP feestures, like control flow etc. I realize PHP did a way better job being a template engine. (This does not disqualify all use of said things, just that all seemingly good use cases aren't motivated, and may not turn out as expected.)
> Very well said. This is the problem.
It is a problem. Counterintuitively, it is also a solution.
Lifting some complexity out of JS and into HTML solves some problems. Lifting all complexity out of JS and into HTML creates new problems.
For example, I have a custom web-component `<remote-fragment remote-src='...'>`. This "shifts" the complexity of client side includes from "needing a whole build-step with a JS framework" into directly writing a plain html file in notepad that can have client-side includes for headers, footers, etc.
This results in less overall complexity in the page as a whole.
Shifting the "for" loop and "if" conditionals from JS to HTML, OTOH, results in more overall complexity in the page as a whole.
I believe declarative should stay purely declarative to describe data/documents in a static state (e.g. HTML, JSON) and an imperative “layer” can be used to generate or regenerate it, if needed.
// popovers have light dismiss which influences our state
> "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-...
I’ve been trained that modals are ephemeral, and I have to take a sec of “ugh I have to close this to look stuff up…wait, no I don’t” when using Jira
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.
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.
The UI framework in iOS is a direct descendant of the NeXT one I’m talking about.
- 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)
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
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.
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.
> 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 :)
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.
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.
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.
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.
I can't find the Wayback Machine address, but I was going to link to one of the redacted Jerkcity comics where "Johnny from Arkansas" asks the exact question and Rands is happy to help the "American Taliban." Its title was something like "Clean the Dead Moose out of Panel 1"
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)
_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.
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.
I can't imagine this would be that complicated in vanilla js. Maybe just make a web component and use it in React.
Are we back to the IE-era mess then?
If so, let's bring <marquee> back.
No, of course not. Web standards are whatever google decides they are.
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.
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.
It's in Firefox and Safari
In principle this declarative approach goes in the right direction, but without an overarching concept and vision of the web UI of the future, this feels like adding just another wrinkle to the stack.