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.
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.
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.)
with its grammar feature, it well might, or might as well.
But still, so long as it’s a script in Unicode, it should all work fine.
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.
snarky / slimy, discriminatory comment, much? not to mention highly ignorant, as I said in my sibling comment.
I took a look at your comment history.
seems to prove what I said about your attitude.
creeped out by it.
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?
for (let i = 1; i <= 4; i++) {
woman.getOn(floor);
try {
getDown();
} catch (e) {
if (e instanceof NotUpError) {
getUp();
getDown();
}
}
}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.
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.
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.
Not suggesting to use these patterns liberally, but they do work for light interactivity.
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.
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)
(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)
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.
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?
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.
> 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.
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
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.)
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
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.
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.
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.
> 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.
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.
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.
Although, the buttons are very interesting.
Still appreciate the new features though.
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() { /* ... */ }`
Even something like close will wind up being --my-close, and several additional checks will be run before dialogEl.close() is called.
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.
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
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.
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.
[0] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
[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.
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.
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?
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
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.
<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
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?
If I still need js to then submit the form it feels like this falls quite a bit short.
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/
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’.
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
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.
I'm surprised they're still keeping this convention of kabob-to-camelCase function name transcribing. I've never been a fan.
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;
}
}
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.
// 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-...
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.
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.
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.
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.
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.
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.
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
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)
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.
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 :)
> The React/JS code is far simpler and less clunky than the Objective-C equivalent.
Are we back to the IE-era mess then?
If so, let's bring <marquee> back.
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.
No, of course not. Web standards are whatever google decides they are.
It's in Firefox and Safari
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.
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.