Introducing React Native [video]
youtube.com
youtube.com
If this delivers on its promises (no reason to assume it won't, seeing as it's already being used in large apps) then it's going to change the mobile development landscape.
It sounded like they may even be hinting at in-browser testing the way they were knocking on provisioning profiles and perhaps maybe even some sort of live-reload development tool? I'm really interested in seeing what kind of tools Facebook will make available along side the core React Native project. Mind you, this is a huge gift even if they don't have any fancy tools to go along with it.
Really excited, thanks FBOS team.
Do you mean JSX? Because "the React syntax" is just plain JS unless you're using JSX, is it not? IIRC even vdom nodes can be created by hand with literal objects.
<Component1 attr1="value1" attr2={foo}>
<Component2/>
<Component3/>
</Component1>
Component1(
{attr1: "value", attr2: foo},
Component2(),
Component3()
);After playing around with it a little bit I have to admit it's so much better than anything else I tried (vanilla JS, jQuery, Backbone, Angular, Dojo).
React (+ Flux) is possibly a great way to introduce people to web development since it avoids common pitfalls and really allows (forces?) you to think about what you are doing more clearly.
It stopped me from paying attention to React until someone suggested it might be the best fit for a problem I had and I followed the introduction's plea to "give it five minutes".
Turns out it's exactly what I wanted and needed. It comes with a lot of (optional but related) other good ideas like immutability and unidirectional data flow. I can't wait to see how React Native works out.
Since React Native is using the background thread for everything, this limits what can be done with the UI. E.g. how are they going to handle user-directed animation if the operations are not run on the UI thread? These things can't be done in an async fashion... Curious to find out more about their architecture, leaving the judgement for later.
The video shows live-reload development in Tabris.js, with a developer app so you can test and debug on your device as you go. Pretty neat, huh? :)
It differs in that it uses the same techniques as Google Inbox to run native code. We cross compile to Objective-C with j2objc, and cross-compile to JS via GWT, the data binding, controllers, are shared code on all platforms that run full speed native, while the UI templating language on each platform is platform native (e.g. angular directives directly in Android XML files)
It produces completely platform-impedance matched apps on each platform (e.g. native on mobile, JS on Web) while allowing the continued use of the regular UI design toolchains people are used to (Android Studio/Xcode Interface Builder)
1) it uses templating (in our case, HTML, Android XML, and XIB) 2) it is cross platform, runs everywhere, even server 3) it produces native apps
It's different in this sense:
1) it doesn't do DOM diffing, it does two-way data-binding 2) it's statically compiled to native code, it doesn't try to run JS in native platforms, and doesn't require any async seems between between the native platform (it's all static linkage)
There may be other differences. The audience is Java and people who want no-compromise native integration. We target 70% code sharing between platforms, but expect the UI to be rebuilt for each platform.
The core engineers behind J2ObjC were those who built Swing at Sun. We're pretty sour on the idea that write-once run-anywhere UIs are possible. Best experience dictates custom design for each frontend IMHO, and shared UI widgets may get you into an 'uncanny valley' state where you're composing the native widgets in ways that are alien to platform specific style guidelines.
The guy in the video said a similar thing. It sounds like they want people to be able to use the same tools for each platform, not necessarily share all the code.
That's an odd conclusion. They're clearly possible, perhaps you mean they don't provide some notion of excellent UI. But even then, web apps are rather a big counter-example ... web apps have never looked native, never been consistent with each other, they don't even try, yet many of them are very popular.
The nativeness of UI is something that seems to matter to developers more than end users. Users react strongly to polish and strong design, but if that is totally inconsistent with the platform only a vocal minority seem to care.
The point about Swing is that, it's good, so long as we're talking about custom LAF, not the Windows/Motif/OSX PLAF, which look/act sort of like the OS UX, but not quite.
Honestly, this sounds like quite a technical achievement, but...
WHY? WHY? Why... are we still forced to go through these extraordinary lengths just to get pictures and interaction on a screen?
Eventually mobile performance, and API surface area will increase to the point where they're "good enough". Then they'll be an inflection point where people write Web apps for cross platform-ness for all but the most demanding stuff (like games or video editing)
https://www.youtube.com/watch?v=UEIHfXLMtwA
(IOW: I want you, personnaly, to work for this objective :))
I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.
imo, the talk comes off a bit like a sales pitch at a pep rally.
It could be the case that the features you mentioned are suitable today for web applications targeting the latest iPhone on browsers on the latest standards, but not when React was first developed.
Sorry for coming across as a sales person. Someone tweeted about a previous presentation of mine in the past asking "who the hell is this marketing guy they had do this talk". I assure you I'm not in either marketing, or sales, I just get really excited sometimes.
http://tympanus.net/Development/SidebarTransitions/
http://tympanus.net/Tutorials/CaptionHoverEffects/index.html
As Tom said, you can't do layout or prerendering-to-bitmap in a web worker: there's no DOM or Canvas API unless you bring your own, and despite Emscripten it's foolhardy to bring your own. If you want to decode a JPEG, you have to do that on the main thread and pass it to the worker right now (except in Firefox with its nonstandard ImageData API). [0] Which brings us back to square one.
> no one ever comes close to native widgets
I think a lot of that has to do with the fact that the iOS UIKit internal code for animations is closed source - the best anyone can do is reverse engineer, move their thumb and see how things react. What are the Bezier points on the curve used for the fade when you "back-swipe" from the left of the screen? Good luck figuring that out - it's possible, but only barely. Tom hinted at the idea that if developers were better organized, they might be able to replicate things better, but it would still be an uphill battle.
[0] https://developer.mozilla.org/en-US/docs/Web/API/Worker/Func...
It's pretty easily to replicate iOS functionality in iOS itself just because it's a better environment, it's not the 'secret' numbers.
But if taking the example of Paper, it's built on top of Pop which is absolutely open source and handles all the animations: https://github.com/facebook/pop.
So in theory you should be able to replicate all this stuff on the web, but you can't because it's just not build with highly responsive UI in as the focus.
My phrasing was somewhat hyperbolic, but I basically said: "Do you honestly think that a person, in the middle of a natural disaster, trying to determine whether or not their family and friends are okay, gives a sh about 60fps animations?"
The real value of React Native is that it allows engineers who know React (and React is really, really easy to learn btw), to build great feeling applications without putting in a ton of effort. Sure, it's possible to get close enough on web, but it's really, really hard to do so.
One of the things we tout in product infrastructure at Facebook is that when building frameworks, you need to enable engineers to fall into the "pit of success". The asynchronous nature of this implementation allows application logic to be run off the main thread by default, which we think is a huge advantage over a traditional web model.
I think the poor reviews of Facebook's HTML5 mobile app shook the company to the core and they swung a bit far in the other direction, abandoning the possibility that the web will ever be mobile ready. I think the truth lies somewhere in the middle; no, you can't get native performance from the web, but you can get close. And every year it gets a little closer because phones are getting ridiculously powerful.
All this said, I think Facebook's approach to the platform fragmentation problem is clever and worth checking out, but I'd still bet on HTML5 over the long term.
It feels like there is a bias against web based apps in general because I usually have a bad experience with them or stop using an application when I get annoyed with the user experience. I'm sure it's possible to create a good user experience with a non-native toolkit. It just seems like the people that really give a damn go native in order to offer a better experience.
I would argue that for most apps, the interface can only get in the way - Facebook included.
But it doesn't have a lot of gestures+animations+images, so that might be the difference.
Things are still being figured out. There are lots of experiments to make layouts render faster and motions more fluid; Virtual DOMs, JavasScript layout managers, canvas, WebGL, GPU accelerated CSS transforms.
And did even Steve Yegge ever see this next big language coming?
The real power of React isn't just the virtual DOM -- it's being able to leverage Flux and an immutable, single-source-of-truth app state. Pretty much every time I turn around to build something, this combination has made what used to be an exercise in hair-pulling into an absolute joy.
It's looking more and more likely. And I agree, if React + Flux/etc becomes the de facto portable standard for the next generation of web and mobile development, we will be in pretty darn good shape. I've only done some tutorial apps and experimental stuff so far, but they're definitely on to something.
But basically the tl;dw seems to be that you can write JavaScript React code that runs efficiently on mobile and renders native primitive components instead of dom primitives (<View> instead of <div>).
It also introduces the idea of "Learn once, write everywhere" instead of "Write once, run everywhere", which I think is a great idea.
"Learn once, write anywhere."
--
I had to build a simple at first but very complex under the hood. I wrote that app in a weekend with react and was a ton fun and most important worked well since day one.
I have been out from the web development since like 1.5 year, but yeah IMO react is the best thing happened to javascript since ... ever.
Thanks again guys!
Why?
I currently have an MVP in ionic framework and would love to port this over to react. Though I should say that Ionic is amazing in its own right.
Also, I tend to agree with some of the comments in this thread -- regular Joe user can't really tell the difference. Ionic on an iPhone looks damn-near close to native. Android leaves a little to be desired.
Nice work React team
As for Android being slow does that include 4.4 devices, or just older version of Android? If it's older devices, you should try the new Ionic beta with Crosswalk integration (you'll need to install/enable Crosswalk, but it's very easy to do). Sadly, it'll add about 25mb to your .apk, but on phones earlier than 4.4 the performance boost is at least 10x if not more.
However, I have not yet optimized images or CSS. I'll probably spend next week looking into optimizations for ionic.
What platforms are targetted? Out of, say, iOS, Android, Linux/X11 desktop, Windows desktop, WinRT, OSX?
We're starting with iOS and Android, which will keep us busy for the foreseeable future. That said, we will open source soon, and we'd be happy to accept help targeting other platforms!
I can't wait for the API docs and sources to be released.
Tweets and videos are lousy at conveying information : )
As a long time web oriented .NET developer wanting to pick up mobile who has been wondering whether to go Cordova or dive in fully native (ObjC/Java/Xaml) this is going to make the choice very difficult.
[1] https://github.com/winjs/winjs/wiki/Using-WinJS-with-React
I put "web oriented .NET developer" in my response for this specific type of question. I kind of defaulted (11 years ago) into ASP classic and ASP.NET as a result of ad hoc consulting/support work for MS technologies back in 2000. But despite my affection for C# I abandoned ASP.NET's faux desktop event driven emulation for MVC as soon as it was released. Ever since then I felt sort of stuck in between thinking of myself as a Web Developer vs thinking of myself as a .NET Developer.
Which brings my long winded response back to your original question about WPF and data binding. WPF and Xaml are pretty foreign to me (I still have no idea about how WPF/SL/WinRT Xaml differ it all seems like Xaml to me) despite a long history with C#. But I am interested in native app development, so I have been torn on whether to go all in with C# knowing I could take it cross platform with Xamarin but need to reorient myself into the Xaml world or go all in with HTML5 knowing Cordova could be "mostly good enough".
I'm a Microsoft fan (I actually enjoy my Surface RT and Windows Phone) so WinJS on Windows 8 seemed like a good hedge for not throwing away all my JS knowledge (which is becoming a predominant part of my work with SPAs) but still letting me go fully native. But the overall Windows dev community seems to have spoken, Xaml is it and WinJS is a pariah, MS doesn't help much by staying mum on the matter but I think they are trying to shove WinJS into the Cordova camp and double down on Xaml for Win 10 with WinJS eventually fading away.
w0.Right.Bind = w1.Left + w2.Width;
I've since moved on to my own dependency management (rebranded hence forth as managed time) system called Glitch [2], but that's because I'm trying to invent what's next.
I'm an MS employee but I have no idea what what is being done in this area. I do have lots of respect for WPF, it was weird that the other platforms couldn't put forward a decent UI platform for so long (well, JavaFX, but it didn't go anywhere).
[1] http://bling.codeplex.com/
[2] http://research.microsoft.com/en-us/people/smcdirm/managedti...
What they've done with react native sounds a lot like how WPF works anyways (scene graph updated in UI thread, rendering thread then renders scene graph). Now, there is nothing wrong with that, I think its all good. But I don't think there is a good reason to use React in Windows project since most of the problems it solves have already been solved.
Like many abstractions in WPF, bindings have a "shadow world" feeling, where they are their own little isolated DSL. With the React model, "bindings" are just JavaScript expressions. Sure, with WPF you can overload operators and create "ExpressionBinding" converters and play other tricks, but you can feel the seams between the subsystems.
On the topic of the scene graph: React's scene graph is an abstract service that you can only interact with in limited ways. WPF's scene graph is a big mutable machine with most of its moving bits exposed. To a first approximation, React's rendering strategy is laziness and WPF's rendering strategy is fixed point iteration. The former is much more likely to produce easy to understand and high performing UIs, even if it comes at the cost of making a few special use cases harder. In such cases, you can bypass the abstraction and muck with the platform guts, which seems to be the default choices in the dependency properties context.
I've never heard anyone claim that laziness leads to more performant UIs. It has always been the opposite in my experience: by loosening up evaluation orders and allowing for glitching, you reduce the amount of book keeping needed to come up with optimal DAG-style re-computation orders. For example, consider a double-indirect (flat-map-style) dependency:
countLabel.Content = folderView.Selected.Count;
Link please!
https://medium.com/@floydophone/building-a-real-time-frosted...
I agree it's possible to make things that feel good, it's just very, very hard, and it's certainly not the default.
React Native is very different than other approaches because:
1. We're not promising to give you One Weird Trick that allows you to change nothing about your development philosophy/practices and yet automatically create excellent mobile experiences. If you're developing for mobile, and you want an excellent user experience, you must care about performance and you must care about programming nuanced interactions. Behind any great mobile experience, is someone who cared. Don't believe anyone that tells you differently. However, I feel that the amount of work that React Native asks of developers in order to achieve it, is much less than any other alternative that I've seen.
2. React Native doesn't use the DOM at all. React naturally tames many of the performance issues that typically arise from unpredictable programming practices in the browser, but that can only get you so far. React Native takes it to the next level, beyond what can be done in the browser. React Native shows that ReactJS has always been more about "zero DOM" than "virtual DOM" (contrary to popular belief).
4. React Native is different because we want to keep some of the best parts about web development. Just because we want the performance and resource control of native views, that doesn't mean we should abandon the great things about the web. With React Native, you can use CSS FlexBox to lay out your native views, and many other familiar style attributes - but without the catastrophic CSS style reflows. The event system also works exactly as it does in your React apps today because it runs the same library code. By building in terms of the subset of web styles/layout that we know we can make fast native implementations for, it allows developers to build great apps today without setting back progress of the web in the future. I feel this is strictly better than encouraging developers to abandon anything remotely resembling web technology and instead learn a completely different toolchain (or two or three).
3. React Native is different because it makes high quality apps written in JS possible. With browsers, you will likely run up against a fundamental limitation and there's nothing you can do about it. Either you don't have access to a platform component (certain scroll view with physics/Maps), or the interaction that you're implementing keeps getting interrupted by image decoding and there's nothing you can do about it.
With React Native, you can do something about it. You can build ReactJS apps using native platform views that could never be implemented in JS (like Maps), and you can also build using higher performing granular building blocks (multi-threaded decoded <Image />) (<View/> blocks that don't use the DOM at all). The result is that this unlocks an unprecedented level of quality that feels great and matches the platform characteristics.
The native components might behave slightly different on each platform so I was wondering if you guys have subclassed the native components to behave similarly on all platforms.
You're probably aware, but it's always good to keep in mind that we don't have a goal to allow people to "write your app once, run anywhere". You should be able to share as much code as you want to share, but the truth is that great mobile experiences design not only for the platform, but even for the device. We should build apps that take advantage of the extra screen real estate on an iPhone6+, for example. So even within a single platform, you'll want to design specific experiences, and the same goes for implementations across different platforms.
How are react native apps architected ? Is it something like a model that is written in pure JS that is common for all platforms ?
So after I've created the model in JS , would I have to tailor the render() method for each platform ?
Flux store now originates from native source - do we now have a 'native -> JS interpreter -> native' double transition on every flow?
If the JavaScript is interpreted, would hot-loading mid-flight to change behavior of the native app be possible?
This is a classic gridbag cartoon: http://madbean.com/anim/totallygridbag
And not having the "native feel" or performance. I think browser vendors are on the verge on closing this gap totally. If not browser vendors, hardware will do it.
.Net Winform, WPF, Swing, etc., they don't allow you to make modification to UI outside main thread.
Based on how they are specifically talking about not sharing code but sharing knowledge (i.e. same API, different components), I'd assume the environment-specific stuff is implemented by the actual primitive components (View, etc, the equivalent of div, etc, in the browser).
They make it very clear that you won't be taking your web app and just magically have it work natively. You'd just write your native app using React, too.
I can't wait to have access to this repo to see source code and examples.
Having a brief look over the ReactJS webpage, it seems like it would replace view controllers and perhaps Storyboards?
Or are we talking about writing the entire application in Javascript, declaratively?
Currently there is no details on React Native, however, I don't believe it would replace the Storyboard as views are still necessary for the React code to interact with the components.
What you would be doing is coding in JS and behind the scenes your app would interact with the views and do the necessarily updates. I'm guessing it'll be a hybrid approach. While you'll most likely still need to know Obj-C or Swift, you can probably get away with a lot of boiler plate code with React.
[1] http://youtu.be/KVZ-P-ZI6W4?t=24m5s [2] https://itunes.apple.com/us/app/facebook-groups/id931735837?...
I mean he admits he had to build a bunch of products before he understood the concept, but didn't waste a single slide to explain it in the presentation.
The typical example for this is SQL - you don't tell an SQL database how to run a query, you tell it what you want, and it figures it out.
In Reacts case, you describe your application in terms of components that know how to render themselves given different sets of data, or states. When the application state changes, the entire application is re-rendered. The "magic" of React is that the use of a virtual dom to create an efficient diff from the current dom state to the new dom state allows this to be very performant, ensuring a minimum of actual dom changes are made.
The resulting components are much, much easier to reason about. You can see, looking at the code, exactly how the component will behave given different data. In essence, what you see is what you get. This is a far better dev experience than working with components that can be mutated by events; you need to build a mental model of all the various states that the component could find itself in.
I was driven to this approach using Backbone to tame a particularly complex interface, similar in complexity to the ads example shown in the video. But as mentioned, doing this naively (in this case, re-rendering a backbone template instead of mutating it), leads to all kinds of user interface glitches. React smooths over those glitches.
Look at 10:00 ... that sounds very much like what we were going through and building at the exact same time
http://platform.qbix.com ... self contained components, completely parallelizable etc. Also in PHP and JS :)
And it all works!
The source code for the iOS native engine (and the JS infra, and some examples) will be given to attendees of React.js Conf tomorrow (Jan 29). The iOS and Android versions of React Native will be open sourced soon! :)
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 [2]) for Titanium related stuff.
Also my company, SMC, does a lot of great opensource things for Titanium (on gh we’re @smclab)
EDIT: To clarify, I am sure that the current UIKit also tries to do optimize rendering. They probably do some kind of internal batching, etc. But they have no (public) data format like DPS or a virtual DOM that is generated, optimized and rendered. I don't think that DPS is all that different.
React belongs one level "up", abstracting away the translation from a declarative representation of the view to a stream of calls on some lower level mechanism to reproduce that representation in the most efficient way possible.
The basic idea of React is that instead of having your application spitting out an instruction here and an instruction there, which may result in lots of reflows and redrawing, if individual state changes are expensive it can be more efficient to re-create a full representation of the desired state and have an engine compare that desired state to the actual state and figuring out the best possible set of steps to get from the actual to desired state.
E.g. the engine may be able to figure out that a subtree changes so much it's going to be best to just replace it wholesale instead of manipulating node by node.
The "output" from a React style engine can be a series of DOM manipulations, or it could be DPS instructions, or any number of other things - the idea is very general.
angular_devs ∩ dart_devs ~= 0 (relative to angular_devs) react_devs ∩ mobile_devs ~= react_devs
Almost everyone who uses react also has to do mobile development, and would like a simpler way to do it. This solves a real and widespread need.
Wait, can you quote where they said that. Maybe a particular time in the video...
Also, while all Dart does for Angular is fragment the community (because now we have Angular web devs using Dart, Angular web devs using JS and soon Angular web devs using AtScript), React Native actually does the opposite.
A lot of web devs already also do mobile development or at least work on hybrid apps (i.e. WebView-based mobile apps). React Native enables web devs to develop mobile apps that wouldn't have been feasible before (either because of the limitations of WebView or because they would have had to worry about learning an entirely different stack that is orthogonal to their web technology knowledge).