[Touche]

I would say that React Native is the biggest threat there.

[mixedCase]

Doesn't perform well enough outside of high-end devices.

[mwcampbell]

Do you have anything to back that up?

[seivan]

Run some lists with images on them on iPhone 5. Anecdotal, and I am sure you can dig into metal to improve performance, but out of the box, it's kinda poor. I still like React and I'm hopeful React-Native will improve.

[mwcampbell]

Thanks. I wonder how much of that is due to the fact that JavaScriptCore can't use JIT compilation when running in an iOS application other than Safari.

[andrewjl]

As of iOS 8 that's no longer the case. JSC JIT compilation can be used in native apps. (It's also used by WKWebView.)

http://trac.webkit.org/wiki/JavaScriptCore

"JavaScriptCore is an optimizing virtual machine. JavaScriptCore consists of the following building blocks: lexer, parser, start-up interpreter (LLInt), baseline JIT, a low-latency optimizing JIT (DFG), and a high-throughput optimizing JIT (FTL)."

[DerekL]

Apps can use JavaScriptCore, and JavaScriptCore can use JIT, but these can't happen together, because third-party apps aren't permitted to execute writeable memory.

http://stackoverflow.com/questions/22281265/is-javascriptcor...

[zepto]

This has been false for years.

[ewmailing]

I haven't used React Native, but I've done quite a bit with native bridging with JavaScriptCore and v8. If your performance bottlenecks are crossing the Javascript-to-native boundary, JIT can't help you. And crossing the bridge boundary isn't the cheapest operation.

[mwcampbell]

That isn't an issue with React Native, which runs JS on its own thread and implements an asynchronous, batched bridge between JS and native.

[fotidim]

As long as React Native requires the developer to use Javascript to write his code this is a no go for the sane of us.