5 ms·

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 us

by pavlov 2y ago

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.

naasking 2y ago
> It required several screenfuls of obscure and brittle code I can't imagine this would be that complicated in vanilla js. Maybe just make a web component and use it in React.
gear54rus 2y ago
> 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 2y ago
  Mobile absolutely uses “shit from 1994”. The UI framework in iOS is a direct descendant of the NeXT one I’m talking about.
  - mattl 2y ago
    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)
- deleted 2y ago
  [deleted]
- deergomoo 2y ago
  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 2y ago
  >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 2y ago
  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 2y ago
    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 2y ago
> 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 2y ago
  > 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 2y ago
  "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 2y ago
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 2y ago
  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 2y ago
    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 2y ago
      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 2y ago
gavinray 2y ago
> 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_attributes/contenteditable 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_ 2y ago
  contenteditable is incredibly painful to use, not standardized and different across browsers, and buggy in firefox
  - gavinray 2y ago
    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 2y ago
> 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.
deleted 2y ago
[deleted]

by pavlov 2y ago

naasking 2y ago

> It required several screenfuls of obscure and brittle code I can't imagine this would be that complicated in vanilla js. Maybe just make a web component and use it in React.

gear54rus 2y ago

> 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 2y ago
Mobile absolutely uses “shit from 1994”. The UI framework in iOS is a direct descendant of the NeXT one I’m talking about.
- mattl 2y ago
  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)
deleted 2y ago
[deleted]
deergomoo 2y ago
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 2y ago
>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 2y ago
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 2y ago
  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 2y ago

> 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 2y ago
> 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 2y ago
"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 2y ago

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 2y ago
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 2y ago
  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 2y ago
    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 2y ago

gavinray 2y ago

> 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_attributes/contenteditable 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_ 2y ago
contenteditable is incredibly painful to use, not standardized and different across browsers, and buggy in firefox
- gavinray 2y ago
  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 2y ago

> 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.

deleted 2y ago

[deleted]