5 ms·

> The Apple environment is absolutely _miles_ ahead of the web platform in several respects... Such as? In any case, I'd assume those miles are only gained on

> The Apple environment is absolutely _miles_ ahead of the web platform in several respects... Such as? In any case, I'd assume those miles are only gained on iOS where Apple has gimped the newer web APIs.

saagarjha 6y ago
Accessibility? Consistency? Performance?
matthewmacleod 6y ago
Such as? Picking some features I like entirely at random: libdispatch, Core Data, comprehensive accessibility support, SpriteKit, Core Video, ARKit… basically, there are lot of powerful and reasonably consistent APIs (with good performance) that really make a bunch of development much more tractable. Some of these can be replicated on the web platform; others can't. In any case, I'd assume those miles are only gained on iOS where Apple has gimped the newer web APIs. I'm sure you appreciate why that kind of attitude is a bit silly and serves to demonstrate the exact effect I was initially talking about.
- anoncareer0212 6y ago
  There's no way you think Apple is miles ahead on async programming and ORMs, the iOS community has been clamoring for replacements for both for years and there's _plenty_ of web libraries for both. The rest looks like it's focused on graphics/stuff you wouldn't do on the web anyway - yes, the fact it's impossible on the web _means by definition Apple is miles ahead_, but claiming Apple is overall miles ahead on dev experience because of AR and video bitstream manipulation APIs is a bit blinkered, given very few developers get to use those APIs.
  - rabenfrass 6y ago
    We’d like a swift version of Core Data (a graph of objects), not a ORM. For async programming we have GCD and reactive libraries, async await is on master already, a design document is expected this month.
- wayneftw 6y ago
  > Picking some features I like entirely at random: Yada1, Yada2, Yada3... Those are not features. Those are names of developer libraries. What do you think they can do that's so much better? > I'm sure you appreciate why that kind of attitude is a bit silly... Apple clearly nerfs the web on iOS and there's nothing silly about acknowledging that. It's actually kinda silly pretending that they don't xD > and serves to demonstrate the exact effect I was initially talking about. Hmm, that's not very clear at all. You said "platform-specific developers can often keep themselves far too isolated", but the web isn't "platform-specific" it's 100% cross-platform and that's why Apple hates it.
millstone 6y ago
Table views are the most striking example. Native table views were designed from the start to lazily load items, and so can trivially support very large lists. The web has no APIs for this. Instead laziness is tacked on through JS, and invariably breaks find, scrolling, etc. Try scrolling to the bottom of your Chrome history: the scrollbar jumps and it's often not clear if/when you reach the bottom.
- anoncareer0212 6y ago
  UITableView was a solved problem on the web by 2014 at the absolute latest. iOS has scrollbar jumps unless you know the rendered height of every list item and the complete count of list items in advance (which is why Chrome jumps, it doesn't know the entire length of your web history, it's loading it in batches) Funnily enough, _SwiftUI doesn't support lazy table views_. Seriously. It's nuts.
  - millstone 6y ago
    Of course Chrome knows the length of your web history: it's a trivial SQLite call. They just can't display it naturally, because there are no browser-provided APIs for lazy tables. I do not agree that the JS implementations have "solved" lazy tables: they're all invariably broken. For example if you hit cmd-A to Select All, Chrome history just selects what is faulted in. If you scroll down eventually you find unselected items. Safari doesn't have this problem and the main reason is its use of native tables instead of web tables. I agree this is a big hole in SwiftUI as well. A lazy table requires cooperation between the framework and the app, which is an awkward fit for declarative UI frameworks like SwiftUI and the web.
    - nmjenkins 6y ago
      While it's not built in, this is totally solvable in a performant way on the web. Fastmail's web UI lazy loads in mailbox lists of messages (which for some users can be 1,000,000+ items long). The scrollbar is correct and you can jump to an arbitrary point. You can select all. We've had this for, I dunno, 7+ years now?
Razengan 6y ago
Let's not forget accessibility. Apple seems to be the only major company who takes it seriously, and it shows. macOS accessibility features alone have generally been light years ahead of Windows, for over a decade.
- kitsunesoba 6y ago
  Also, just having a standardized way to do a lot of things. One such example is menus. Just about all Mac apps — even ported stuff using third party UI toolkits — hook into the standard menubar APIs, which means that every menu item of every app can have a key shortcut assigned (or reassigned) in System Preferences, even when the app's dev never bothered to add such configurability. Similarly, accessibility and scripting APIs can reliably grab the menu items of any app, improving automation and interoperability. One could probably even write a full replacement for the macOS global menubar without much fuss. Compare this to Windows and Linux where it's quasi-normal for apps to implement menus their own way or eschew them altogether — there is no single way to grab menu items, just a ton of different possible ways, and if an app dev has decided to do their own thing you're just SoL.

saagarjha 6y ago

Accessibility? Consistency? Performance?

matthewmacleod 6y ago

Such as? Picking some features I like entirely at random: libdispatch, Core Data, comprehensive accessibility support, SpriteKit, Core Video, ARKit… basically, there are lot of powerful and reasonably consistent APIs (with good performance) that really make a bunch of development much more tractable. Some of these can be replicated on the web platform; others can't. In any case, I'd assume those miles are only gained on iOS where Apple has gimped the newer web APIs. I'm sure you appreciate why that kind of attitude is a bit silly and serves to demonstrate the exact effect I was initially talking about.

anoncareer0212 6y ago
There's no way you think Apple is miles ahead on async programming and ORMs, the iOS community has been clamoring for replacements for both for years and there's _plenty_ of web libraries for both. The rest looks like it's focused on graphics/stuff you wouldn't do on the web anyway - yes, the fact it's impossible on the web _means by definition Apple is miles ahead_, but claiming Apple is overall miles ahead on dev experience because of AR and video bitstream manipulation APIs is a bit blinkered, given very few developers get to use those APIs.
- rabenfrass 6y ago
  We’d like a swift version of Core Data (a graph of objects), not a ORM. For async programming we have GCD and reactive libraries, async await is on master already, a design document is expected this month.
wayneftw 6y ago
> Picking some features I like entirely at random: Yada1, Yada2, Yada3... Those are not features. Those are names of developer libraries. What do you think they can do that's so much better? > I'm sure you appreciate why that kind of attitude is a bit silly... Apple clearly nerfs the web on iOS and there's nothing silly about acknowledging that. It's actually kinda silly pretending that they don't xD > and serves to demonstrate the exact effect I was initially talking about. Hmm, that's not very clear at all. You said "platform-specific developers can often keep themselves far too isolated", but the web isn't "platform-specific" it's 100% cross-platform and that's why Apple hates it.

millstone 6y ago

Table views are the most striking example. Native table views were designed from the start to lazily load items, and so can trivially support very large lists. The web has no APIs for this. Instead laziness is tacked on through JS, and invariably breaks find, scrolling, etc. Try scrolling to the bottom of your Chrome history: the scrollbar jumps and it's often not clear if/when you reach the bottom.

anoncareer0212 6y ago
UITableView was a solved problem on the web by 2014 at the absolute latest. iOS has scrollbar jumps unless you know the rendered height of every list item and the complete count of list items in advance (which is why Chrome jumps, it doesn't know the entire length of your web history, it's loading it in batches) Funnily enough, _SwiftUI doesn't support lazy table views_. Seriously. It's nuts.
- millstone 6y ago
  Of course Chrome knows the length of your web history: it's a trivial SQLite call. They just can't display it naturally, because there are no browser-provided APIs for lazy tables. I do not agree that the JS implementations have "solved" lazy tables: they're all invariably broken. For example if you hit cmd-A to Select All, Chrome history just selects what is faulted in. If you scroll down eventually you find unselected items. Safari doesn't have this problem and the main reason is its use of native tables instead of web tables. I agree this is a big hole in SwiftUI as well. A lazy table requires cooperation between the framework and the app, which is an awkward fit for declarative UI frameworks like SwiftUI and the web.
  - nmjenkins 6y ago
    While it's not built in, this is totally solvable in a performant way on the web. Fastmail's web UI lazy loads in mailbox lists of messages (which for some users can be 1,000,000+ items long). The scrollbar is correct and you can jump to an arbitrary point. You can select all. We've had this for, I dunno, 7+ years now?

Razengan 6y ago

Let's not forget accessibility. Apple seems to be the only major company who takes it seriously, and it shows. macOS accessibility features alone have generally been light years ahead of Windows, for over a decade.

kitsunesoba 6y ago
Also, just having a standardized way to do a lot of things. One such example is menus. Just about all Mac apps — even ported stuff using third party UI toolkits — hook into the standard menubar APIs, which means that every menu item of every app can have a key shortcut assigned (or reassigned) in System Preferences, even when the app's dev never bothered to add such configurability. Similarly, accessibility and scripting APIs can reliably grab the menu items of any app, improving automation and interoperability. One could probably even write a full replacement for the macOS global menubar without much fuss. Compare this to Windows and Linux where it's quasi-normal for apps to implement menus their own way or eschew them altogether — there is no single way to grab menu items, just a ton of different possible ways, and if an app dev has decided to do their own thing you're just SoL.