One possibility: You have a JS interpreter running your React code. You generate a virtual DOM and hand it off to React. React sends the virtual DOM through a message bus to native code. So far, nothing crazy here, this is how frameworks like cordova work. That native code dynamically translates the virtual DOM into native UI elements.
"React Native: everything native, controlled by async batched JS put in a background thread. Learn once, write everywhere. #reactjsconf" [1]
"Fb groups app in iOS App Store is powered by it #reactjsconf" [2]
"iOS and Android native using all the same ideas as React, all the power of native." [3]
React has been gaining traction as I'm sure we're all aware, but this is next-level stuff. I'm particularly interested in how styling's going to work; if this is really translating into true native stuff then there must be a CSS-analogue?
"learn once, write everywhere" - I like the sound of that! But I guess in the spirit of React this is still only the "V" in MVC right? I don't suppose they are planning to broaden the scope to anything other than rendering views. So if you want to use this to build native apps, I guess you are going to have to integrate another cross-platform solution for storage/sensor APIs?
React is much more than just the V in MVC. It sells itself in that way for presenting the ability of being just exactly that. Thus, it can quite easily coexist with other frameworks. I actually think the established and well known selling points of React, like the Virtual DOM and "V in MVC" are just very nice side effects. The most important thing is the concepts and principles adopted from FRP, which in my opinion makes React a very powerful tool for JavaScript in general, a local optima of what can be done with JS right now.
My guess is we're missing an important piece of the puzzle. Unless they have a js to everything interpreter. In which case thats much bigger news than react.
Its more of a shiv to convert react elements/calls into native UI elements, using a native server to receive streams/messages (unsure which) and convert them.
I doubt it would happen at runtime in iOS/Android, though? They would need to ship a JS interpreter that gets run on application startup, parse the React files, instantiate the native controls and create a bridge between them back to the JS interpreter?
Well on second thought I guess Appcelerator Titanium does something similar. So it's native UI only, but with the added overhead (JS interpreter + bridge, larger binary size, slower startup, etc.).
Coupling your app to any framework has proved to be a really bad idea in the long run, to me this is a step in the wrong direction. If I've understood this announcement correctly.
Yes, the whole system is just basically component rendering (react) + a message bus oriented architecture (flux). The architecture is not novel, but I think the big change between React Native (or whatever they're going to call it) and any actual native application is the same difference between approaches like Cordova (formerly known as PhoneGap) and node-webkit. Platform independence.
The problem with "old school windows message loop" is the "windows" part (not because I don't like windows, "mac" or "linux" or "freebsd" or "solaris" could all go in there). Why haven't we abstracted presentation (functionality is a harder/more nuanced proposition).
This is awesome news. I've been working on a desktop application using React, node-webkit and browserify and it's been a great development experience. Being able to leverage web technologies to build native apps has been a huge time saver. However, I'm relying on the NodeJS components in order to do things like access the file system and fork commands. I'm wondering how React Native will handle this functionality. Will it be an extended API or can you only do AJAX calls? Either way it's very exciting.
Doing everything is a side effect of the architecture.
"The virtual dom is an implementation detail of React.js. React Native demonstrates that many rendering contexts are possible."
This was kind of the exciting point all along :).
DOM just happens to be the output of a function that people are most interested in at the moment.
but people have been talking about using it with canvas and other stuff, too. It's a generally-useful way to map functional data to render-trees.
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
Native APIs are exposed as JS modules. And XHR, for example, is polyfilled in terms of whatever native capability exposed. You can totally use npm modules, provided any module that it uses is polyfilled.
My bet is that they are working with thrift for their transport layer. We're moving the same direction. I should be landing a bunch of diffs over the next week to the JS thrift libraries to support XHR and websockets in the nodejs thrift library (for use with browserify).
I tend to prefer native interfaces over web interfaces, but found it really bothersome to have to work with native toolkits. There's stuff like tint2 (https://github.com/trueinteractions/tint2), but it's still not stable enough, IMO.
This is HUGE. I'm extremely excited to try this out. Being able to write the interface with JS/JSX, and then switch between JS and native code as you see fit or the need arises is truly the best of both worlds. For a lot of problems JS is not your bottleneck, but if it does become your bottleneck you can rewrite it natively!
Hi, I'm Jordan from the React team. I'm happy to answer any questions about React Native, but @vjeux will be giving a more thorough talk tomorrow that you won't want to miss (if you're at ReactJSConf), so I might wait for him to answer some of them.
This is not the DOM. This is not a web view. If you know ReactJS, you can build native apps with React Native.
iOS and android right now. And yes, native components can be rendered directly with JSX. And you won't need to mix with DOM. <h2> For example doesn't mean anything on iOS.
React has, from day one, sought to liberate itself from the underlying low level building blocks of a particular environment. There were always good reasons to so (normalizing browser inconsistencies etc). There is another benefit of the specific way in which we've built this library level layer of abstraction - we've formed a serializable boundary that allows vanilla React to sit on one side, and any set of lower level building blocks on the other. Before today, we simply had the DOM renderers sitting on the other side of that boundary. React Native replaces the DOM renderers with native renderers which allows people to render platform <View>/<ScrollView>/<NativeWhatever> instead of <div>/<span>. Other than that, you get to use the exact same React API that you already know (even down to the event bubbling). You can bridge to things that are only available on the platform, and can in general make higher performance granular building blocks that cannot be accomplished with web technology (such as <Image> components that decode images more efficiently or with different concurrency models). As with everything, JSX is not required to take advantage of this - and you can use any of the compile-to-js languages that you use with React today.
Yes, that should be possible – it loads JS packages from a custom server right now but there's no reason it can't use Webpack. You'll be able to reload immediately (without recompiling) already by pressing Cmd-R in the simulator.
There will be more detail tomorrow, but at a high level:
* JS engine on a background thread
* Communicates via batched, async messaging protocol to a native (objc or android) server running on the main thread (basically create_view(), update_view(), destroy_view(), on_event() etc)
* Plug-in for React that speaks that protocol
* Tools to make cross-platform dev a bit easier (standard text component, cross-platform flexbox layout system)
* Designed to take advantage of native platform views, NOT be the next Java Swing
Given the presence of https://github.com/facebook/css-layout it will probably flex-based. Not cool as a constraint based layout but good enough for easier portability of knowledge.
Can I create the largest possible square div in a rectangular div with this library? That is my standard test as to whether a layout framework is advanced enough to meet my basic needs. (vanilla CSS fails this test of course, even with the most recent extensions, AFAIK)
Source? AFAIK if you want your border, padding and margin respected, there is no way to do the above in vanilla CSS. Which is why css-flexbox was proposed.
With css-flexbox, you probably can. Your DIV should have flex-grow: 1 which will make it take the allowable space along the "main axis" (shared with other flex-growers) and then align-items: stretch, to pick up all available space along the "cross axis". With some nesting, you can do pretty much whatever you want except for the grid layout. Grid layout is another thing coming but barely implemented in the today's browsers.
Anyways, flex-box is not available in IE < 10. IE10 requires ms- prefix. If React makes it available everywhere (IE8+) that will be really great.
Thanks, but last I looked into this it wasn't possible for this to work for a square in a parent rectangle of arbitrary dimensions. Can you find an example that works, using jsfiddle or something similar?
Are you excluding hacks? Because you can do this pretty easily in CSS2 since padding is always relative to width. Make your square div { width: 100%; height: 0; padding-bottom: 100% (or whatever ratio you want, doesn't have to be 1:1); };
What would be awesome and truly useful is real constraints, like in CAD software. I should be able to express every width, height, x, and y value as a variable, or as a function of other variables. So I call the device height "A", the width "B", and express the rest of the UI in terms of those variables. Then at runtime "A" and "B" are defined, and the rest of the layout magically does its thing.
What Apple calls "constraint-based layout" is cool, but does not follow the classical definition of what a constraint-based layout actually is. They don't use variables anywhere in the IB UI. You can only define proportions in code which is incredibly clunky.
How does it compare to Appcelerator Titanium? That's also a JavaScript-to-native-UI layer utilizing a JS runtime. http://www.appcelerator.com/titanium/
I know one complaint among many was that wrapping native API in a new framework can limit access to functionality and customization; you're limited to the choices of the framework designer. Another is debugging is harder since native tools don't understand the framework and you're dependent on the tool chain provided by the framework makers.
That’s why they (Appcelerator) have a pretty solid but not well documented plugin infrastructure.
At the same time they are moving to a more native-friendly infrastructure, code-named Hyperloop.
React Native uses similar principles of AsyncDisplayKit (doing as much work as possible on a background thread and only doing what we absolutely need to on the main/UI thread) but does not depend on AsyncDisplayKit.
I know it's a bit of an orthogonal concern, but will this project provide a way to style native apps using web technologies (e.g. CSS) as well? I'm very excited about building native apps with React, and would be even more so if I could also leave behind the very-poorly-designed Android style primitives.
I'm not at the conference and haven't had a chance to read too much into this yet (so if the answer is just wait you'll see that's good :D)
Can I use the same kind of jsx I am on the web today or is there going to be something different? Will sharing components between web and native mobile apps be possible?
Wow. It looks like we're going to have to make our platform (http://platform.qbix.com) integrate with React out of the box. This sounds pretty awesome.
In short, how will it work and do you have any links we should check out, or people I can contact? The React virtual DOM has all kinds of elements that map to DOM elements, so how would it render in a native app? What about native APIs and Javascript that can interface with it e.g. like it does in PhoneGap? What is the equivalent here?
Since we've heard Facebook Groups is built with it, and it's said to be iOS/Android - to what extent is the choice to build Groups with this responsible for the fact it's not in the Play store? Basically, if Groups is ever coming to Android is this helping or hindering porting?
Will this layer be released as a separate project so that other projects like raynos/mercury [2] or elm [1] can target this interop layer?
mercury was fully decoupled from virtual-dom [0] (such that you can use virtual canvas or virtual-gl). Would be really nice if this stuff can be used by other libraries easily.
Yes pleaseeeee tell me I can take advantage of just the View layer and use my own Model and Controller setup. With Titanium views are 'just' JS objects, so I can use Spine, Backbone, and other libraries for business and data logic.
It's just you don't really need Backbone with React because plain object/array models are more convenient, and controllers aren't needed because there's no need to “orchestrate changes” between view and model. Check out Flux as an example of architecture (not a framework) that works really well with React.
Exactly. I once started a project with backbone and used React for the view layer. I quickly realized I didn't need the Backbone models and collections, and ended up only using the router and a few small other things. Eventually i replaced these remaining parts with some 'micro-frameworks' like lo-dash, page.js, superagent, etc.
Apologies - In at the deep end with a very specific (hardcore?) question.
In Titanium it is difficult, if not impossible without resorting to a Native plug-in (which kinda defeats the object of using it IMHO as this is not 'Learn once, use anywhere'), to re-create an interface similar to the Facebook app. i.e. the vertical scrolling timeline with embedded horizontal scrolling images in each post. (on Android it really does suck) due to issue with memory, threading etc.
So I guess my question is, is it something to that React Native could cope with, or would it potentially suffer from the same memory, threading issues?
And my guess is that at some point it has to surface, so a good architectural comparison would be fab.
I can't wait to see more details about this. I hope this isn't another botched attempt at trying to solve the cross compiled native app challenge. I've seen and signed up for so many hype machines for solving this problem including plain old responsive web apps, Adobe AIR, Phone Gap, Corona, and Famo.us. I've invested time in learning about all of these platforms, but in the end they all fell short in some way or another. I have high hopes for $FB though because I've really enjoyed most of the projects they've open sourced including React and Pop. Personally, it's been easier for me to just learn and use Swift/Obj-C. The main caveat is that my apps are limited to running on iOS.
If you already know ReactJS, then it'll probably be a lot easier for you to learn React Native than Swift or Objective-C.
If you are working on a team with primarily JS developers, React Native is probably a better choice to go with.
Will this cause Swift to be irrelevant? Probably not.
--
If you are learning iOS and doing production / client work, you should be aware that using a third party framework could actually break your app. I'm interested in React Naive, but also very weary about it. Facebook released a framework called Three20 back in iOS 2.0/3.0 days and abandoned the project shortly afterwards. Of course being open source there is bound to be people who take over the project, but it's something to think about.
I this this is a great mentality over the classic write once run everywhere approach.
We're currently building a native cross-platform desktop email client in React + Flux on Atom Shell. As Nilas thinks about mobile and other platforms it's clear that the interaction design and information architecture are radically different. While some code should be re-used most shouldn't. Having a reusable architecture and way of building apps is definitely the better way to go.
* Write JS as usual. Write React as usual, but don't use the DOM JSX elements (or the React.DOM) factories - instead use the new 'NativeView' elements.
* The code you write runs in a Javascript interpreter on the background thread.
* The NativeView elements communicate transparently with a native server running on the main thread, which renders and fills native views based on the instructions sent.
* The JS runs react the usual way - I'm assuming the tree reconciliation happens the same way as well - the diff instructions are just sent to the native view server.
Has anyone asked if this can use other JS libs other than just React ones? Also, if it's just using say JavaScriptCore and rendering native, I assume this means speed limitations imposed by the lack of Nitro/etc on the UIWebView are moot?
Hi, I'm just reading through the ReactJS docs for the first time, and I found something peculiar. Let me explain.
So, as I understand ReactJS invokes a render() method defined by the user (programmer), and the result of that is diff'ed to previous results of the same method, and as a result, the DOM is modified.
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?
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.
DOM is stateful, whereas the render() method is stateless.
For instance, if you add a <button> to the DOM, it will stay there forever. On the other hand if the next call to render() no longer includes the <button> then React will do the work of removing it from the DOM.
There are two things that stop it from being slow in practice:
1. The virtual DOM that render deals with is several orders of magnitude faster than the real DOM, so you need to have thousands of elements before it starts taking longer than making the one change to the real DOM for the one element that changed
2. You can skip calling render on subcomponents that haven't changed, so while updating a list of 10000 elements where one has changed would require iterating through 10000 elements, updating a list of 100 elements that each contains 100 elements where one of the bottom level elements has changed would only require iterating through 200 elements.
Swapping out inner html has issues such as losing form data and bound events (etc...). Ignoring that you also have life cycle issues. For instance if you have a component that needs to know its render height you want a hook for calculating that height AFTER the entire DOM has updated. Otherwise you are going to force multiple layouts (bad). React provides these life cycle methods.
As far as the render method being big, the premise React is built on is that the virtual DOM is much faster than the real DOM. Test as necessary for your own comfort / use cases. I personally trust the testimonials of people smarter than me that aren't the React team also feel this is true and are making real changes to their products based on that. I also trust my own experiences that the DOM is slow :)
There are added benefits for an immutable / FRP style of building a UI, but I think you're more interested in the rest of my answer.
Nothing to be confused about, you have a valid hypothesis: "Rendering and Diffing in Javascript is slower than DOM manipulation". However, all hypothesis need to be experimented before having any real meaning.
It just happens that testing this hypothesis and finding it invalid was the foundation for React.
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.
A render in react doesn't return DOM elements. Render is a pure function which projects app state into a description of the view. Let's call this description A, so render(state) -> A. When state changes and render is called a second time we get a new description, render(newState) -> B. A diff is then applied to them diff(A, B). The diff can then be translated to an update strategy for the actual DOM (or in this case, native components). From this the smallest set of changes are applied to bring the DOM in line with the current state. It turns out it's far quicker to diff objects in memory than query the DOM. The DOM is treated as a stateless rendering engine, with progressive updates applied as app state changes.
Of course, in your example, there is a point where N gets so large that it poses problems. This is true whether you're using the raw DOM or an abstraction like React. The solution is the same in either case - cull non-visible elements from the render tree (again react makes this as efficient as possible).
EDIT: it's also worth noting you can skip updating entire subtrees in React with shouldComponentUpdate hooks. This avoids the case where you go through the render/diff cycle and it turns out there is no difference, and so nothing to update. Paired with immutable data structures this method can be a simple reference equality check (shallow equals) oldState !== newState, and therefore can really get the most efficient rendering possible
But how do I remove non-visible elements from the render-tree? Is this something I have to do explicitly like I would have to do without React? Or does React somehow take care of this for me?
Amelius, I cannot reply to you directly for some reason. Anyway...
So say you're rendering some long list of items. Because react is just plain JS (no templates!), you will map the array of items to components in your render. You give each item a key so that react can reconcile components across renders. If component with same key is returned from render next time then it's kept in the DOM (and any updates applied), if not then it's removed. So the involved part becomes determining what is visible or not, and then slicing your list of items to only map a subset. This is the more involved part. I haven't built anything like this myself, but I'm guessing it basically boils down to: listening to scroll events on container, determining y offset, get height of contaoner and height of elements, use that to determine which items in list should be mapped to components in render. That bit is the same whether react or not.
See James Longster's epic blog post "Reducing User Interface Complexity, Or Why React Is Awesome" [0]. Where he details this kind of approach with his for-demp-purposes-only react-like lib.
render() -> returns N items every time it is invoked
And React will diff those N items against the DOM (using a key) every time an update is required.
So, to me it appears that still O(N) amount of work has to be done every time something small changes in the list.
This is not necessarily a bad thing. But here we assume that doing render() is faster than actually building the DOM from scratch, even though they have the same computational complexity, O(N).
Anyway, I'll have a look at that link. Very interesting, thanks again.
no, it doesn't compare to DOM, it compares to the last result of render - an important difference performance-wise. the DOM is many times slower to query than plain objects.
also remember big-O notation doesn't really capture the essence of the problem here. looping through and querying N DOM elements is probably orders of magnitude slower than doing the same with N objects in memory
> 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)
I see React effectively as the controller of UI state changes. This can be applied on any datapath, i.e. model to view rendering - web / native / games.
174 comments
[ 3.0 ms ] story [ 246 ms ] threadLooks like it's not being open sourced for a while, but apparently the attendees are going to have some hands on tomorrow.
2015 seems like it's shaping up to be the year of React!
Something needs to replace AngularJS I guess, until the next big thing.
This announcement is about replacing html elements (div, h1, img, etc.) with native elements. Should be faster going native than via web elements.
"React Native: everything native, controlled by async batched JS put in a background thread. Learn once, write everywhere. #reactjsconf" [1]
"Fb groups app in iOS App Store is powered by it #reactjsconf" [2]
"iOS and Android native using all the same ideas as React, all the power of native." [3]
React has been gaining traction as I'm sure we're all aware, but this is next-level stuff. I'm particularly interested in how styling's going to work; if this is really translating into true native stuff then there must be a CSS-analogue?
[1] https://twitter.com/AnnaPawlicka/status/560505089207463936
[2] https://twitter.com/floydophone/status/560504204343521280
[3] https://twitter.com/voodootikigod/status/560503641920921600
cannot wait for more details.
So all the good bits of CSS without any of the bad - including browser compatibility problems?
Doesn't explain stuff like fonts & colours though...
Edit: looks like this isn't hybrid as I assumed but truly native
Well on second thought I guess Appcelerator Titanium does something similar. So it's native UI only, but with the added overhead (JS interpreter + bridge, larger binary size, slower startup, etc.).
Um, why? They already have JavaScriptCore (it's an iOS API).
The problem with "old school windows message loop" is the "windows" part (not because I don't like windows, "mac" or "linux" or "freebsd" or "solaris" could all go in there). Why haven't we abstracted presentation (functionality is a harder/more nuanced proposition).
That said, their success (over something like node-webkit + react) will definitely depend on how well they match and integrate the native APIs.
"The virtual dom is an implementation detail of React.js. React Native demonstrates that many rendering contexts are possible."
This was kind of the exciting point all along :). DOM just happens to be the output of a function that people are most interested in at the moment. but people have been talking about using it with canvas and other stuff, too. It's a generally-useful way to map functional data to render-trees.
[1] https://www.nilas.com/
I tend to prefer native interfaces over web interfaces, but found it really bothersome to have to work with native toolkits. There's stuff like tint2 (https://github.com/trueinteractions/tint2), but it's still not stable enough, IMO.
This is HUGE. I'm extremely excited to try this out. Being able to write the interface with JS/JSX, and then switch between JS and native code as you see fit or the need arises is truly the best of both worlds. For a lot of problems JS is not your bottleneck, but if it does become your bottleneck you can rewrite it natively!
This is not the DOM. This is not a web view. If you know ReactJS, you can build native apps with React Native.
Does it allow you to render native components with JSX as opposed to only DOM elements? Can you mix the two, somehow?
I dreaded my Xamarin build times..
[1]: http://gaearon.github.io/react-hot-loader/
* JS engine on a background thread
* Communicates via batched, async messaging protocol to a native (objc or android) server running on the main thread (basically create_view(), update_view(), destroy_view(), on_event() etc)
* Plug-in for React that speaks that protocol
* Tools to make cross-platform dev a bit easier (standard text component, cross-platform flexbox layout system)
* Designed to take advantage of native platform views, NOT be the next Java Swing
The issue is that it’s only width-constrained.
Anyways, flex-box is not available in IE < 10. IE10 requires ms- prefix. If React makes it available everywhere (IE8+) that will be really great.
What Apple calls "constraint-based layout" is cool, but does not follow the classical definition of what a constraint-based layout actually is. They don't use variables anywhere in the IB UI. You can only define proportions in code which is incredibly clunky.
I know one complaint among many was that wrapping native API in a new framework can limit access to functionality and customization; you're limited to the choices of the framework designer. Another is debugging is harder since native tools don't understand the framework and you're dependent on the tool chain provided by the framework makers.
TBH, I don't use React right now but this is a game changer.
Can I use the same kind of jsx I am on the web today or is there going to be something different? Will sharing components between web and native mobile apps be possible?
If it's still small do you plan on the majority of future components to be first-party or third-party (community)?
Extremely exciting either way, wish there was a livestream of tomorrow.
In short, how will it work and do you have any links we should check out, or people I can contact? The React virtual DOM has all kinds of elements that map to DOM elements, so how would it render in a native app? What about native APIs and Javascript that can interface with it e.g. like it does in PhoneGap? What is the equivalent here?
Is it like Titanium in some way?
You say this is not DOM or some hybrid solution?
Either this is too good to be true or ground breaking stuff.
Do you mean that react could completely get rid of having to write stuff in Java or Objective-C?
Yes, with React Native you'll be able to write native mobile apps completely in JavaScript.
mercury was fully decoupled from virtual-dom [0] (such that you can use virtual canvas or virtual-gl). Would be really nice if this stuff can be used by other libraries easily.
[0] https://github.com/Matt-Esch/virtual-dom
[1] http://elm-lang.org/
[2] https://github.com/Raynos/mercury
It's just you don't really need Backbone with React because plain object/array models are more convenient, and controllers aren't needed because there's no need to “orchestrate changes” between view and model. Check out Flux as an example of architecture (not a framework) that works really well with React.
In Titanium it is difficult, if not impossible without resorting to a Native plug-in (which kinda defeats the object of using it IMHO as this is not 'Learn once, use anywhere'), to re-create an interface similar to the Facebook app. i.e. the vertical scrolling timeline with embedded horizontal scrolling images in each post. (on Android it really does suck) due to issue with memory, threading etc.
So I guess my question is, is it something to that React Native could cope with, or would it potentially suffer from the same memory, threading issues?
And my guess is that at some point it has to surface, so a good architectural comparison would be fab.
Perhaps the Hyperloop/React Native race is on :-)
I'll try to address some of the other more specific questions inline.
I'd bet Angular going Native first, though, I guessed it was coming with 2.0
https://twitter.com/andy_matuschak/status/560511204867575808
From an architecture point-of-view, there is ReactCocoa.
If you already know ReactJS, then it'll probably be a lot easier for you to learn React Native than Swift or Objective-C.
If you are working on a team with primarily JS developers, React Native is probably a better choice to go with.
Will this cause Swift to be irrelevant? Probably not.
--
If you are learning iOS and doing production / client work, you should be aware that using a third party framework could actually break your app. I'm interested in React Naive, but also very weary about it. Facebook released a framework called Three20 back in iOS 2.0/3.0 days and abandoned the project shortly afterwards. Of course being open source there is bound to be people who take over the project, but it's something to think about.
Very excited for this. I have been looking at React for a while, now it's certainly time to take a plunge.
I this this is a great mentality over the classic write once run everywhere approach.
We're currently building a native cross-platform desktop email client in React + Flux on Atom Shell. As Nilas thinks about mobile and other platforms it's clear that the interaction design and information architecture are radically different. While some code should be re-used most shouldn't. Having a reusable architecture and way of building apps is definitely the better way to go.
I can't help but think about that other chestnut, "A determined programmer can write Fortran in any language."
Of course it makes sense to apply a pattern that you know worked great in the past. The tough part is deciding when it's worth trying something else.
* Write JS as usual. Write React as usual, but don't use the DOM JSX elements (or the React.DOM) factories - instead use the new 'NativeView' elements.
* The code you write runs in a Javascript interpreter on the background thread.
* The NativeView elements communicate transparently with a native server running on the main thread, which renders and fills native views based on the instructions sent.
* The JS runs react the usual way - I'm assuming the tree reconciliation happens the same way as well - the diff instructions are just sent to the native view server.
They claim perf is fine though (e.g. because render is always async, app code is always in background).
We shall see!
So, as I understand ReactJS invokes a render() method defined by the user (programmer), and the result of that is diff'ed to previous results of the same method, and as a result, the DOM is modified.
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?
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.
So, as you can see, I'm a bit confused...
For instance, if you add a <button> to the DOM, it will stay there forever. On the other hand if the next call to render() no longer includes the <button> then React will do the work of removing it from the DOM.
1. The virtual DOM that render deals with is several orders of magnitude faster than the real DOM, so you need to have thousands of elements before it starts taking longer than making the one change to the real DOM for the one element that changed
2. You can skip calling render on subcomponents that haven't changed, so while updating a list of 10000 elements where one has changed would require iterating through 10000 elements, updating a list of 100 elements that each contains 100 elements where one of the bottom level elements has changed would only require iterating through 200 elements.
As far as the render method being big, the premise React is built on is that the virtual DOM is much faster than the real DOM. Test as necessary for your own comfort / use cases. I personally trust the testimonials of people smarter than me that aren't the React team also feel this is true and are making real changes to their products based on that. I also trust my own experiences that the DOM is slow :)
Nothing to be confused about, you have a valid hypothesis: "Rendering and Diffing in Javascript is slower than DOM manipulation". However, all hypothesis need to be experimented before having any real meaning.
It just happens that testing this hypothesis and finding it invalid was the foundation for React.
Watch this video[https://www.youtube.com/watch?v=XxVg_s8xAms] I think it does a good job discussing this hypothesis and why they chose not to worry about it.
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.
Of course, in your example, there is a point where N gets so large that it poses problems. This is true whether you're using the raw DOM or an abstraction like React. The solution is the same in either case - cull non-visible elements from the render tree (again react makes this as efficient as possible).
EDIT: it's also worth noting you can skip updating entire subtrees in React with shouldComponentUpdate hooks. This avoids the case where you go through the render/diff cycle and it turns out there is no difference, and so nothing to update. Paired with immutable data structures this method can be a simple reference equality check (shallow equals) oldState !== newState, and therefore can really get the most efficient rendering possible
So say you're rendering some long list of items. Because react is just plain JS (no templates!), you will map the array of items to components in your render. You give each item a key so that react can reconcile components across renders. If component with same key is returned from render next time then it's kept in the DOM (and any updates applied), if not then it's removed. So the involved part becomes determining what is visible or not, and then slicing your list of items to only map a subset. This is the more involved part. I haven't built anything like this myself, but I'm guessing it basically boils down to: listening to scroll events on container, determining y offset, get height of contaoner and height of elements, use that to determine which items in list should be mapped to components in render. That bit is the same whether react or not.
See James Longster's epic blog post "Reducing User Interface Complexity, Or Why React Is Awesome" [0]. Where he details this kind of approach with his for-demp-purposes-only react-like lib.
[0] http://jlongster.com/Removing-User-Interface-Complexity,-or-...
If I get this clearly, then still:
render() -> returns N items every time it is invoked
And React will diff those N items against the DOM (using a key) every time an update is required.
So, to me it appears that still O(N) amount of work has to be done every time something small changes in the list.
This is not necessarily a bad thing. But here we assume that doing render() is faster than actually building the DOM from scratch, even though they have the same computational complexity, O(N).
Anyway, I'll have a look at that link. Very interesting, thanks again.
also remember big-O notation doesn't really capture the essence of the problem here. looping through and querying N DOM elements is probably orders of magnitude slower than doing the same with N objects in memory
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)