Hacker News new | ask | show | jobs
by nonsince 3422 days ago
So why not have a virtual DOM-based data-driven layout engine that _isn't_ an HTML/JS stack. Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex, we can do better if we're writing native apps (hell, we should have had a better online solution years ago too, but we don't have control there).
4 comments

The core Facebook iOS team built the news feed in ComponentKit. ComponentKit (Objective C++) was inspired by React:

http://componentkit.org/

" Something in a language that is more optimisable and works everywhere, like Lua with C extensions, or OCaml, or Java. JavaScript is hard to get predictable performance from and HTML is extremely complex,"

React Native is not based on WebViews/HTML. It uses a virtual DOM on top of native views:

https://facebook.github.io/react/docs/optimizing-performance...

"React builds and maintains an internal representation of the rendered UI. It includes the React elements you return from your components. This representation lets React avoid creating DOM nodes and accessing existing ones beyond necessity, as that can be slower than operations on JavaScript objects. Sometimes it is referred to as a "virtual DOM", but it works the same way on React Native."

This is quite different from similar Javascript based efforts such as Cordova.

> 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)

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.
Google might have the thing for you...

https://flutter.io/

Too bad Dart has fallen so far out of fashion.
React Native does not generate any HTML. It generates native controls.