3 ms·

I second this. Further, the number of times I’ve tried to get into native development is about ten, and every time I’ve done it the APIs are completely differen

I second this. Further, the number of times I’ve tried to get into native development is about ten, and every time I’ve done it the APIs are completely different as the OSes have moved on to new ways of doing things. Meanwhile, the DOM APIs have been more or less the same since I learned them 15 years ago, with the oddball world-changing addition of querySelector or enhancements that people rarely use like Shadow DOM and filesystem API.

PaulDavisThe1st 5y ago
The APIs for cross-platform native GUI development haven't changed in any significant ways in 20 years or more. If you insist on using the new hotness being offered for any platform (web, native, whatever), then sure, you're doing to see this. But in the web context, you reference the DOM APIs that are stable ... in the same way that Qt, GTK (or even Cocoa) have been. New APIs for web dev show up monthly, but you apparently manage to not keep switching from one to the other. Why would you do the same thing for native dev?
- ironmagma 5y ago
  Qt isn’t a native API. It’s true that there are stable libraries like GTK or WxWidgets which allow you to write native-looking apps (or for Linux, I spose that is native, and granted, Linux probably has the best native dev experience), and those exist in the form of React et. al. for the web world. But the number of Windows native app APIs is insane, and every year I try to learn how to create an XCode basic app and it’s different. Creating a simple app with HTML and JS however is the same as it’s always been.
  - PaulDavisThe1st 5y ago
    I use the term native to mean "an application that runs on the metal and has direct access to system calls, not in a VM of any kind, including a browser". Qt is native in that sense, just as much as any other toolkit designed for the same purpose.
  - PaulDavisThe1st 5y ago
    > every year I try to learn how to create an XCode basic app and it’s different. https://ardour.org https://ardour.org was first ported to then-OSX in 2006. Almost nothing in the codebase that relates specifically to now-macOS has changed in that time. XCode is a tool, not a platform. Cocoa is the platform, and it changes very little and very infrequently.
    - ironmagma 5y ago
      This is irrelevant in terms of developer experience. I’m sure it’s possible to maintain an existing app for years and years, but if every blog post in existence is written for a different version of the development environment (which are vastly different from each other) and the OS Vendor (Apple in this case) is deleting or never even producing documentation on these APIs, which definitely happens, the rot is too much to keep up with for people trying to learn the system.
      - PaulDavisThe1st 5y ago
        One of the jobs of a software developer is to understand that companies that produce proprietary systems (such as Apple) have their own incentives that do not always align with the desires and needs of those creating software. Put simply, this means that you do not trust those companies to do the right thing for you, and instead you need to identify what level of their technological offerings seem most likely to represent the correct entry point for you/the project. When we first ported Ardour to OSX/macOS, it was abundantly clear that XCode was a non-starter in terms of technology, partly because it was single platform, and partly because its scope was too large - as Unix-based developers we understood the merits (and occasional pain) of more modular toolsets. So I found a handy guide to writing "nibless applications" that completely removed XCode from the picture (along with some Cocoa boilerplate code that isn't actually required). As a result, we've continued to interact with the stable API core of Cocoa, even as Apple dither around the edges. Apple (and Microsoft and .... ) are not your friends. They want you to build software for their platforms, but beyond making that possible in some way, their incentives do not align with yours in any substantive way (partly because they make software too, and have their own API goals and needs that may/will conflict with yours). If you don't understand this, you're inevitably going to have the sort of experience you describe above.
- kitsunesoba 5y ago
  Cocoa is quite stable, I can vouch for that. So much so that I was able to resurrect an open source Mac app originally written in the early 2000s over the course of a weekend. Some changes were required and there were a bunch of deprecation warnings, but it worked and could’ve been cleaned up pretty easily.

PaulDavisThe1st 5y ago

The APIs for cross-platform native GUI development haven't changed in any significant ways in 20 years or more. If you insist on using the new hotness being offered for any platform (web, native, whatever), then sure, you're doing to see this. But in the web context, you reference the DOM APIs that are stable ... in the same way that Qt, GTK (or even Cocoa) have been. New APIs for web dev show up monthly, but you apparently manage to not keep switching from one to the other. Why would you do the same thing for native dev?

ironmagma 5y ago
Qt isn’t a native API. It’s true that there are stable libraries like GTK or WxWidgets which allow you to write native-looking apps (or for Linux, I spose that is native, and granted, Linux probably has the best native dev experience), and those exist in the form of React et. al. for the web world. But the number of Windows native app APIs is insane, and every year I try to learn how to create an XCode basic app and it’s different. Creating a simple app with HTML and JS however is the same as it’s always been.
- PaulDavisThe1st 5y ago
  I use the term native to mean "an application that runs on the metal and has direct access to system calls, not in a VM of any kind, including a browser". Qt is native in that sense, just as much as any other toolkit designed for the same purpose.
- PaulDavisThe1st 5y ago
  > every year I try to learn how to create an XCode basic app and it’s different. https://ardour.org https://ardour.org was first ported to then-OSX in 2006. Almost nothing in the codebase that relates specifically to now-macOS has changed in that time. XCode is a tool, not a platform. Cocoa is the platform, and it changes very little and very infrequently.
  - ironmagma 5y ago
    This is irrelevant in terms of developer experience. I’m sure it’s possible to maintain an existing app for years and years, but if every blog post in existence is written for a different version of the development environment (which are vastly different from each other) and the OS Vendor (Apple in this case) is deleting or never even producing documentation on these APIs, which definitely happens, the rot is too much to keep up with for people trying to learn the system.
    - PaulDavisThe1st 5y ago
      One of the jobs of a software developer is to understand that companies that produce proprietary systems (such as Apple) have their own incentives that do not always align with the desires and needs of those creating software. Put simply, this means that you do not trust those companies to do the right thing for you, and instead you need to identify what level of their technological offerings seem most likely to represent the correct entry point for you/the project. When we first ported Ardour to OSX/macOS, it was abundantly clear that XCode was a non-starter in terms of technology, partly because it was single platform, and partly because its scope was too large - as Unix-based developers we understood the merits (and occasional pain) of more modular toolsets. So I found a handy guide to writing "nibless applications" that completely removed XCode from the picture (along with some Cocoa boilerplate code that isn't actually required). As a result, we've continued to interact with the stable API core of Cocoa, even as Apple dither around the edges. Apple (and Microsoft and .... ) are not your friends. They want you to build software for their platforms, but beyond making that possible in some way, their incentives do not align with yours in any substantive way (partly because they make software too, and have their own API goals and needs that may/will conflict with yours). If you don't understand this, you're inevitably going to have the sort of experience you describe above.
kitsunesoba 5y ago
Cocoa is quite stable, I can vouch for that. So much so that I was able to resurrect an open source Mac app originally written in the early 2000s over the course of a weekend. Some changes were required and there were a bunch of deprecation warnings, but it worked and could’ve been cleaned up pretty easily.