Use ReactJS to Build Native Apps

> I can understand this, but... The DOM is already incrementally rendered by the browser. That is, changes to the DOM are not direct, but are performed by the browser in a way that is as efficient as possible. So, why the need for a render() method?

The browser tries to batch updates as efficiently as possible, but because of the model there are limits on that, reflow and layout thrashing are easy pitfalls to fall into for instance. React's model obviates these issues so the system can make significantly more assumptions about what is happening, and it can combine and batch more aggressively.

Furthermore, React's updates can trivially be delayed as much as necessary (in browsers, usually to sync them with the next repaint using requestAnimationFrame), not so for DOM mutations.

> Also, the render() method itself could be quite big and thus could take a long time to run, and almost completely nullify all advantages of incrementally updating only the display.

It could be but it usually isn't, and more importantly for these cases (and others) the system can be told that there's no need to re-render the component (`shouldComponentUpdate` in react), the previous result can be reused as-is.

For "pure" components (which simply map application state to render state) it's easy to implement, and downright trivial when using persistent datastructures: it's just an identity check (which is why systems built from the ground up on persistent datastructures like clojurescript/om or elm.html are faster than "naïve" react OOTB: they can assume components are pure, will only use their parameters/state to generate UI state, and that said parameters/state hasn't been screwed with; React being a more general-purpose JS library can't afford to make these assumption, it has to be opted in explicitly)

Yep, I overlooked that fact, yeah that's awesome. I can imagine a world where people just come up with lots of mappings for the result, modularly. That's awesome

So let's assume I have a listbox with N elements in it. I assume the render() method has to visit each of these elements every time an updates takes place, so it is O(N). Please correct me if I'm wrong here.

Now for a certain value of N, things will become slow, unresponsive. I'm guessing now that this value of N is above the value where the browser cannot handle this number of elements anyway. Is this correct?

PS: I understand that it is possible to completely optimize the listbox case. But that is not the scenario I'm interested in. I'm interested most and above all in the typical use-case. I'm just using a listbox as an example here. Just replace it by any other sufficiently complicated and customized UI component if desired.

Seasoned Appcelerator’s Titanium Mobile SDK dev here. Looks like that a lot of people here is comparing this announcement from the react team to the Titanium Mobile SDK. I’d like to give some info to shed some light on the differences, and probably anticipate the challenges they have to (or had to) solve.

## Architecture

Both Titanium SDK and this Native React thing do have a JavaScript runtime behind the curtains.

Both frameworks will run the JS runtime on the background, on a different thread from the UI. This is incredibly important to remind.

Titanium SDK follows an OOP-ish, imperative approach. You create views using factories (`Titanium.UI.createScrollView({ })`) and you add those views to parent views (`parent.add(child)`). This is very similar to a browser DOM, and in fact it’s cumbersome to work with. They built an xml preprocessor called Alloy which does a better job at exposing the view hierarchy right in the source, but it just compiles down to JS, `create()` and `add()`.

This is important for the evaluation at least for the following reason: every time you update a property on a view (actually on a proxy object to the real view) you’re crossing the bridge and you have to pay that penality. The bridge is the void between the JS runtime’s thread and the main, UI’s one. This is incredibly painful when trying to do JS animations, sometimes if you’re not careful you can get hurt very badly. You can still do great things, but it’s way better to use the native `.animate()` methods, which cross the bridge only twice (at start, and at the end as a callback invoking).

On Native React you should not have this kind of problems because changes will be batched and updated on a update loop basis or at least debounced. Or at least optimized in some smart way. I believe.

## Layout

One big problem will be the layout. Given that they don’t want the developers to understand every layout system every platform provides, they have to normalize it somehow. Titanium SDK has it’s own layout system, incredibly easy to understand even from a web-only dev experience:

a) by default everything is absolute positioned,

b) you can get a vertical flow layout by setting the 'layout' property on the parent view or

c) you can get a horizontal flow (inline-block-ish) by setting 'layout' to horizontal.

Native React will probably follow a more intimately web-ish approach, just look at this JS/C/Java implementation of the box-model and flex-box specification by Facebook itself [1]

[1]: https://github.com/facebook/css-layout

## Support and limits

Titanium SDK is always criticized for being to limited in what you can do with it. This actually comes from two different issues:

1) they have to (almost) manually implement every API you might need, by proxying from native-land to JS-land;

2) they have to follow every release of the platform’s SDK;

3) you cannot just put native code along-side your JS code, so you cannot go where they didn’t.

Let’s see how Native React will solve this issue.

Titanium SDK is undergoing an heavy lifting refactoring to solve exactly this issues. The project is code-named Hyperloop and is already working behind the curtains for the Windows 8 version of the SDK.

## Conclusion

Because I shamelessy want to karma-drift this topic, I’ll stop here.

It’s interesting, but until they show us some (native) code... it’s just ideas.

Follow me on twitter (@_pier) and github (@yuchi) for Titanium related stuff.

Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab)

Does this include desktop apps?