5 ms·

All of these JavaScript frameworks are recreating native runtimes on top of “standard” JavaScript engines. It seems wrong to me to tailor a JavaScript engine to

All of these JavaScript frameworks are recreating native runtimes on top of “standard” JavaScript engines. It seems wrong to me to tailor a JavaScript engine to a particular framework. Ideally the goal would be to move native framework-less JavaScript forward so that we don’t need all these over-complex competing frameworks.

runawaybottle 6y ago
Shouldn’t this be a hidden layer under React native? The thing you suggest is impossible without having Google or Apple take up the initiative. All JS improvements for the last 10 years required a lot of bypassing of browser and device maker’s implementation.
cellularmitosis 6y ago
The primary React Native performance issue on iOS is that Apple disables the JIT when using JavaScriptCore. If you run some JS in a WKWebView you should see it speed up by 5 to 10x. (WKWebView runs in a different process, so they allow the JIT)
- Cthulhu_ 6y ago
  To be anal, the root cause of that is using javascript instead of building a native app. I get that Facebook has the biggest apps on any platform and they run into platform limitations (like number of classes on Android) and build cycles so for them it makes sense to make a dynamic partial-hot-reloading-in-place app development framework, but they're still beholden to the runtime that Apple offers them. (In theory they could compile JS to a compiled binary that Apple's reviewers are okay with, but I don't know enough about any of that)
  - JUNGLEISMASSIVE 6y ago
    The security implications of running JS in an interpreter and running native bytecode are very different, though. Native apps also routinely request much more permissions and gather extra user data such as contacts, just because it is possible to do so.
  - notsureaboutpg 6y ago
    Right, and since using Javascript has such poor performance over using a native app on iOS, and since developers prefer to use Javascript instead of build multiple native apps, Hermes exists to bring Javascript performance closer to native app performance. Way better to have a tool that helps Javascript performance than to burden developers with having to write native iOS/Android apps separately
- afavour 6y ago
  Arguably the primary React Native performance issue is that JS is single-threaded. Does React Native provide any useful tools for that?
  - spullara 6y ago
    You can run things in workers: https://github.com/devfd/react-native-workers https://github.com/devfd/react-native-workers
  - nicoburns 6y ago
    That's not the primary issue. The main issue that there isn't (or wasn't until recently) a fast, low overhead way to communicate between JavaScript and native code. That's changing with JSI, and I think we might find React Native gets a lot faster in practice if they ever complete the work.
jbverschoor 6y ago
That’s what programmers tend to do. Inception :-). Abstraction over virtualization over abstraction over virtualization etc. And still there are root exploits that are about to go all the way back up I like react-native, as in the architecture (nativescript has a better bridge). Unfortunately it’s JavaScript. I guess we’ll have to deal with it another 40 years min.

runawaybottle 6y ago

Shouldn’t this be a hidden layer under React native? The thing you suggest is impossible without having Google or Apple take up the initiative. All JS improvements for the last 10 years required a lot of bypassing of browser and device maker’s implementation.

cellularmitosis 6y ago

The primary React Native performance issue on iOS is that Apple disables the JIT when using JavaScriptCore. If you run some JS in a WKWebView you should see it speed up by 5 to 10x. (WKWebView runs in a different process, so they allow the JIT)

Cthulhu_ 6y ago
To be anal, the root cause of that is using javascript instead of building a native app. I get that Facebook has the biggest apps on any platform and they run into platform limitations (like number of classes on Android) and build cycles so for them it makes sense to make a dynamic partial-hot-reloading-in-place app development framework, but they're still beholden to the runtime that Apple offers them. (In theory they could compile JS to a compiled binary that Apple's reviewers are okay with, but I don't know enough about any of that)
- JUNGLEISMASSIVE 6y ago
  The security implications of running JS in an interpreter and running native bytecode are very different, though. Native apps also routinely request much more permissions and gather extra user data such as contacts, just because it is possible to do so.
- notsureaboutpg 6y ago
  Right, and since using Javascript has such poor performance over using a native app on iOS, and since developers prefer to use Javascript instead of build multiple native apps, Hermes exists to bring Javascript performance closer to native app performance. Way better to have a tool that helps Javascript performance than to burden developers with having to write native iOS/Android apps separately
afavour 6y ago
Arguably the primary React Native performance issue is that JS is single-threaded. Does React Native provide any useful tools for that?
- spullara 6y ago
  You can run things in workers: https://github.com/devfd/react-native-workers https://github.com/devfd/react-native-workers
- nicoburns 6y ago
  That's not the primary issue. The main issue that there isn't (or wasn't until recently) a fast, low overhead way to communicate between JavaScript and native code. That's changing with JSI, and I think we might find React Native gets a lot faster in practice if they ever complete the work.

jbverschoor 6y ago

That’s what programmers tend to do. Inception :-). Abstraction over virtualization over abstraction over virtualization etc. And still there are root exploits that are about to go all the way back up I like react-native, as in the architecture (nativescript has a better bridge). Unfortunately it’s JavaScript. I guess we’ll have to deal with it another 40 years min.