Hacker News Reader

Comment by avidphantasm | Hacker News Reader

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.

View on HN

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)

Arguably the primary React Native performance issue is that JS is single-threaded. Does React Native provide any useful tools for that?

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.

You can run things in workers:

https://github.com/devfd/react-native-workers

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)

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.

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.

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.

Reply on news.ycombinator.com