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.
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.
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.
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 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 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.
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.
What actually needs to happen is for wasm to get good enough that everything else is just implemented on top of it. Not that it'll save us from the flame wars over which language is better to compile to wasm, but at least you could actually pick your poison then...
I think it's good that HTML serves a narrow purpose. What's problematic is that we want every other purpose to be served by just one or two things (CSS, JS). It shouldn't be a struggle to differentiate between "script that makes buttons work" and "script that browses cat videos and downloads them to your hard drive". We can call it "minJS" and "maxJS" or something, and make it so users can disable "maxJS" without disabling "minJS". Or wait, why even mandate JS at that point? The biggest problem with the Web is not particular design decisions (although of course they have many problems), but the fact that we won't change them fundamentally and instead just keep piling things on.
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.
> 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.
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.
> 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.
"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 :)
>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
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.
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.
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.
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.