4 ms·

Actually new Google applications being shipped, like Docs and Inbox are using GWT, and its successor, J2CL. J2CL (Java 2 Closure) and J2ObjC together permit cr

Actually new Google applications being shipped, like Docs and Inbox are using GWT, and its successor, J2CL. J2CL (Java 2 Closure) and J2ObjC together permit cross platform application development to run shared code in the server, Web, Android, and iOS. This is not "write once, run anywhere" UI development, the UI layer is still native JS, (Java for Android), and hand-written Objective-C (iOS), but about 70% of the code (business logic layer) is shared between platforms as Java. Java is transpiled to heavily annotated Closure ES6 code (in theory it could be TypeScript) and optimized by the Closure Compiler, OR it's transpiled to Objective-C and imported into XCode. This is not a React-Native approach, teams decided that trying to do "write-once-run-anywhere" UI leads to "uncanny valley" effects as you invariably end up with non-native experiences by trying that approach, instead front end developers who are experts on each platform (Web, Android, iOS) use the best available native tools for those platforms to create the UI 3x, which they wire up to a shared layer which is written once. The reason to go with transpilation, instead of a low level emscripten/bytecode/VM level approach is performance and optimization. Java classes can be pretty easily translated to ES6 classes, and consumed by Babel, or more importantly, Closure Compiler, with aggressive optimizations to split code, tree shake, etc. This information is lost if you just blindly translate the entire stack at a low level. It also means the impedance mismatch is very low. For example, Objective-C or JS code can call into J2Cl code very easily. They're just ES6 modules or Obj-C interfaces/classes.

deleted 9y ago
[deleted]
underwater 9y ago
React Native promote the idea of "learn once, write everywhere", not reusing UI across platforms.
- cromwellian 9y ago
  True, but it is reusing an (alien) middleware on top of that. I like react-native and have used it, but a <Text>, <View>, or <ScrollView> isn't the same thing as directly using the native widget APIs yourself, or using the native tooling like Android XML files, XIBs, etc. There's a class of apps where you really need the direct access, and currently for React-Native, that means writing native modules and tying them to markup, which invariably leads to people trying to create versions that work on Android and iOS unified by a single <Element>. React-Native works, apps like Discord prove that. But Gmail and Docs tried the approach of running their huge apps business logic 100% in JS on mobile, and the performance and memory usage didn't meet expectations. If you try to do something like run formula recalculations on a 20,000 cell spreadsheet, on a low powered Android device, the performance is much worse than running the same code in Dalvik/ART.

deleted 9y ago

[deleted]

underwater 9y ago

React Native promote the idea of "learn once, write everywhere", not reusing UI across platforms.

cromwellian 9y ago
True, but it is reusing an (alien) middleware on top of that. I like react-native and have used it, but a <Text>, <View>, or <ScrollView> isn't the same thing as directly using the native widget APIs yourself, or using the native tooling like Android XML files, XIBs, etc. There's a class of apps where you really need the direct access, and currently for React-Native, that means writing native modules and tying them to markup, which invariably leads to people trying to create versions that work on Android and iOS unified by a single <Element>. React-Native works, apps like Discord prove that. But Gmail and Docs tried the approach of running their huge apps business logic 100% in JS on mobile, and the performance and memory usage didn't meet expectations. If you try to do something like run formula recalculations on a 20,000 cell spreadsheet, on a low powered Android device, the performance is much worse than running the same code in Dalvik/ART.