[reggieband]

> why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack

I'm not advocating RN, I just understand the motivations behind frameworks like it. I think "to make devs lives easier" is not a fair assessment. Also, to be fair, JS performance is generally adequate. My own experience with performance on mobile devices often fell back to rendering (e.g. managing textures, making animations smooth, infinite tiled scrolling). Very rarely was raw CPU processing a major concern. My experience may not be typical.

As for other cross platform native development libraries/platforms/etc. - I've had some experience with a few of them (e.g. marmalade[0] which was in C++) and generally they do not work for me. I even attempted to write my own and it was its own monster.

In general, I am personally biased towards Native. I would definitely take RN on a test spin if I was in the prototype phase of a new app. I would use that time to determine if I wanted to bring RN into production or re-write as Native.

[0] https://en.wikipedia.org/wiki/Marmalade_(software)

[LeoNatan25]

What is "adequate"? Any long term task still hangs the business logic thread - the only thread - unless you fallback to native. At what point does constant fallback to native for implementing what is not possible in JS a detriment to development? You may say, multithreading is an edge-case, but is it? I have not been involved in a single project where actual multithreading was not needed. Also, the way RN is implemented internally, such as async bridge and layout (CSSLayout / "yoga"), it is quite impossible to use native optimized views, such UITableView with reusable views, because this API is designed for synchronous API calls.