3 ms·

Because it could facilitate more code sharing between the platforms, reducing development costs, increasing the talent pool of engineers who can contribute to n

Because it could facilitate more code sharing between the platforms, reducing development costs, increasing the talent pool of engineers who can contribute to native mobile projects, allow for development toolchains outside of XCode and Android Studio. It's just a case of offering a system API that could be called from whatever language - but Apple don't want iOS apps written in Kotlin or C++ and who knows why Android is so locked down.

cudgy 4y ago
Further fragmentation to support many methods (eg languages and frameworks) to develop apps on a single platform also spreads the support of the platform thinner as there are fewer developers using a core set of methods on the platform, resulting in wasted and duplicated efforts across all the various methods. Your approach results in, for example, a developer familiar with a single or very few languages being able to develop across multiple domains using the same language regardless of whether it is appropriate for that domain. Basically, using only a hammer to build a house. Another approach that results in higher quality software is to have domain experts in each area using the languages and tools most optimized for that domain. Do you hire 20 Javascript developers doing all the programming across the entire solution? Or hire a mix of developers with different skillsets to achieve better quality? The hiring of only one type of developer is a lazy approach, in my opinion, and is largely responsible for poor quality of software with greater complexity.
- apatheticonion 4y ago
  > Your approach results in, for example, a developer familiar with a single or very few languages being able to develop across multiple domains using the same language regardless of whether it is appropriate for that domain. Basically, using only a hammer to build a house. Sadly this statement describes the current environment. It's hard to find a desktop application today that isn't written using Electron or a similar Web engine for the GUI layer. Not only is it more fiscally efficient for businesses to consolidate their engineering skill sets, but it reduces the technical liability that needs to be tested. That said, Electron sucks - so why don't companies use native GUI libraries? Because they are hard to use and unstable (Windows WinUI is a great example). An abstraction layer to offer a stable consistent GUI API ensures applications are stable while the burden of maintaining stability rests with the abstraction. > Or hire a mix of developers with different skillsets to achieve better quality? If we look at the mobile ecosystem as a case study, apps which are available on Android and iOS are most often build with a UI abstraction like React Native or Cordova (WebView/WebKit). Seldom are native apps for both platforms developed. This is for various reasons - anecdotally my previous employer had dedicated iOS and Android teams comprising of 1 person on each team. We had roles open for 12 months, then the Android developer left so the iOS developer had to learn Android development. They managed to hire a new Android engineer after 18 months. Overall - if making a UI for all operating systems was as easy as consuming a crate/package into your Rust or Go project and building a UI - we would see a lot more efficient native applications.

cudgy 4y ago

Further fragmentation to support many methods (eg languages and frameworks) to develop apps on a single platform also spreads the support of the platform thinner as there are fewer developers using a core set of methods on the platform, resulting in wasted and duplicated efforts across all the various methods. Your approach results in, for example, a developer familiar with a single or very few languages being able to develop across multiple domains using the same language regardless of whether it is appropriate for that domain. Basically, using only a hammer to build a house. Another approach that results in higher quality software is to have domain experts in each area using the languages and tools most optimized for that domain. Do you hire 20 Javascript developers doing all the programming across the entire solution? Or hire a mix of developers with different skillsets to achieve better quality? The hiring of only one type of developer is a lazy approach, in my opinion, and is largely responsible for poor quality of software with greater complexity.

apatheticonion 4y ago
> Your approach results in, for example, a developer familiar with a single or very few languages being able to develop across multiple domains using the same language regardless of whether it is appropriate for that domain. Basically, using only a hammer to build a house. Sadly this statement describes the current environment. It's hard to find a desktop application today that isn't written using Electron or a similar Web engine for the GUI layer. Not only is it more fiscally efficient for businesses to consolidate their engineering skill sets, but it reduces the technical liability that needs to be tested. That said, Electron sucks - so why don't companies use native GUI libraries? Because they are hard to use and unstable (Windows WinUI is a great example). An abstraction layer to offer a stable consistent GUI API ensures applications are stable while the burden of maintaining stability rests with the abstraction. > Or hire a mix of developers with different skillsets to achieve better quality? If we look at the mobile ecosystem as a case study, apps which are available on Android and iOS are most often build with a UI abstraction like React Native or Cordova (WebView/WebKit). Seldom are native apps for both platforms developed. This is for various reasons - anecdotally my previous employer had dedicated iOS and Android teams comprising of 1 person on each team. We had roles open for 12 months, then the Android developer left so the iOS developer had to learn Android development. They managed to hire a new Android engineer after 18 months. Overall - if making a UI for all operating systems was as easy as consuming a crate/package into your Rust or Go project and building a UI - we would see a lot more efficient native applications.