3 ms·

Emm... nativescript?

DonHopkins 8y ago
NativeScript is cool -- I really like it. But as far as I understand it, there's a bit of a fatal problem going forward on iOS, last time I looked at it a year or so ago (I'd be thrilled if they've come up with a way to address this problem): The iOS NativeScript bridge uses the old deprecated UIWebView and JavaScriptCore's Objective C integration stuff that lets you directly call back and forth between Objective C and JavaScript. However, that Objective C bridging stuff is not supported on WkWebView, since it runs in a separate process, and has a different way of sending messages to the web browser, but not calling native code directly or passing pointers to objects or buffers in memory. Why would you want to do that? To get direct access to an array of binary floating point numbers, or the pixels of a canvas or WebGL texture, instead of converting to and from JSON, or serializing images as data urls with base 64 encoded png files, for example. (Yech!) You can send messages back and forth to WkWebKit, but that's vastly less performant than the direct calling UIWebKit JavaScriptCore bridging stuff, which operates in the same process and memory space. And the NativeScript iOS integration layer is totally dependent (built on top of) on the way the JavaScriptCore bridging stuff works, and would have to be completely rewritten from scratch (and be much less efficient and require a lot more plumbing on both sides), in order to support that kind of out-of-process messaging to WkWebKit. The great thing about NativeScript is that gives you has such an efficient high bandwidth interface to native code from JavaScript. But it just necessarily uses an old crappy JavaScript engine with no JIT. One of the best thing about using WkWebKit is that the Just In Time compiler is enabled, so it's blazingly faster than running JavaScriptCore in the same process (which has it disabled, since non-Apple apps aren't allowed to write to code memory). Of course it depends on how much of your application is written in JavaScript and would benefit from the JIT, and how much it depends on calling and sending data back and forth between native code and JavaScript. But the NativeScript way of doing things makes many assumptions that would make it very slow with RPC messaging instead of direct calling. PhoneGap/Cordova is fine using WkWebKit because it uses a JSON messaging interface in the first place, not the more efficient higher bandwidth Objective C bridging stuff. It's JavaScript/Objective C bridge is much simpler than NativeScript, and people don't use it the same way that NativeScript is designed to be used. NativeScript, as cool and amazing as it is, is deeply tied to old technology on iOS, JavaScriptCore and UIWebKit.

NativeScript is cool -- I really like it. But as far as I understand it, there's a bit of a fatal problem going forward on iOS, last time I looked at it a year or so ago (I'd be thrilled if they've come up with a way to address this problem): The iOS NativeScript bridge uses the old deprecated UIWebView and JavaScriptCore's Objective C integration stuff that lets you directly call back and forth between Objective C and JavaScript. However, that Objective C bridging stuff is not supported on WkWebView, since it runs in a separate process, and has a different way of sending messages to the web browser, but not calling native code directly or passing pointers to objects or buffers in memory. Why would you want to do that? To get direct access to an array of binary floating point numbers, or the pixels of a canvas or WebGL texture, instead of converting to and from JSON, or serializing images as data urls with base 64 encoded png files, for example. (Yech!) You can send messages back and forth to WkWebKit, but that's vastly less performant than the direct calling UIWebKit JavaScriptCore bridging stuff, which operates in the same process and memory space. And the NativeScript iOS integration layer is totally dependent (built on top of) on the way the JavaScriptCore bridging stuff works, and would have to be completely rewritten from scratch (and be much less efficient and require a lot more plumbing on both sides), in order to support that kind of out-of-process messaging to WkWebKit. The great thing about NativeScript is that gives you has such an efficient high bandwidth interface to native code from JavaScript. But it just necessarily uses an old crappy JavaScript engine with no JIT. One of the best thing about using WkWebKit is that the Just In Time compiler is enabled, so it's blazingly faster than running JavaScriptCore in the same process (which has it disabled, since non-Apple apps aren't allowed to write to code memory). Of course it depends on how much of your application is written in JavaScript and would benefit from the JIT, and how much it depends on calling and sending data back and forth between native code and JavaScript. But the NativeScript way of doing things makes many assumptions that would make it very slow with RPC messaging instead of direct calling. PhoneGap/Cordova is fine using WkWebKit because it uses a JSON messaging interface in the first place, not the more efficient higher bandwidth Objective C bridging stuff. It's JavaScript/Objective C bridge is much simpler than NativeScript, and people don't use it the same way that NativeScript is designed to be used. NativeScript, as cool and amazing as it is, is deeply tied to old technology on iOS, JavaScriptCore and UIWebKit.