And just as a heads-up to those who haven't watched, implementation details and code samples are coming tomorrow.
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.
No, React Native translates a declarative API into imperative calls. Just like React does in the browser (after going through the Virtual DOM as, essentially, an optimisation).
Yes, just like the DPS interpreter translates (high-level) DPS into (low-level) pixels. Looks pretty similar to me. (but then I am not overly familiar with DPS or ReactJS)
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.
It's not similar. Postscript (display or "regular") is imperative. It's an instruction stream.
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.
If I'm one of Reacts competitors I'm ecstatic that they're abandoning the web. It reminds me of when Angular wastes energy on angular.dart because of a Google mandate. Didn't help them much.
React has been carefully designed to encompass better UI patterns regardless of the underlying platform. There are some very thoughtful and capable people working on it. Worth reading Jordan's thoughts here https://news.ycombinator.com/item?id=8962171
The benefits of using Dart are debatable. There are however no such doubts on the utility of native mobile apps. The lack of adoption of Dart is due to the lack of interest within the broader JS community; the same community which is going to be excited about React supporting native apps. This immediately improves the targets to which they can deploy with skills they already have.
Instead of "abandoning the web" I'd call it a "post browser" framework. What we're seeing here is the first piece in the next-gen internet world that doesn't require a web browser.
One of the reasons I have more confidence in React than Angular is that Facebook and Instagram actually use React in flagship products. I wouldn't worry about React abandoning the web until Facebook and Instagram stop using it for their web products.
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).
From the video, Facebook mentions that they are using the React native for the Facebook iOS groups application. Theres a live demo to demonstrate. Video starts at 24:05.
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!
Very interesting. Microsoft allows you to build fully native (not webview wrappers) apps using WinJS, and they have shown that React (along with Angular) can be used to build those apps [1]. I wonder if Microsoft will put resources into bridging the gap between React Native and Windows 10.
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.
TL;DR to below: focusing on JS instead of Xaml seems like a smarter play for a .NET developer that hasn't used Xaml in WPF or SL previously.
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.
I program in WPF in C# with absolutely no XAML. I used to use dependency properties/data binding a lot, I even made a wrapper [1] so you could write things like:
w0.Right.Bind = w1.Left + w2.Width;
And that would automatically generate a one way data binding in WPF (so if w1's left property, w2's width property, or w0's width property changes, w0's left property is automatically recomputed).
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).
I should have mentioned that I don't actually have a problem with WPF or Xaml from a technical standpoint (I've been watching several Pluralsight and MSVA courses and the binding certainly looks very powerful). My wavering between WPF/C# vs HTML/JS/C# is more about where I think development will be going in the future and how that works out for me professionally. That is why I really was hoping WinJS would take off so I could get the best of both worlds, being able to develop for an OS (WP/Win8) I actually enjoy but also not letting my web dev skills atrophy. I'm very curious to see if WinJS gets mentioned at Build this year or if it will fade quietly into the background.
React, as the developers argue, is a step beyond data binding. It emphasises immutability and a single data flow, rather than the combinatorial interdependency of the data binding approach.
One way data binding is supported by WPF also, I mean, two-way data binding is the unusual odd man out. And of course, the one way data flow functions have to be immutable and you have to take a dependency whenever when you read a property imperatively.
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.
Having worked on production software with both WPF and React, I can tell you why React's "data binding" approach is categorically different (better, in my opinion) than WPF's.
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.
Right, WPF's declarative databinding support is separated from imperative semantics, even if they can interact a bit (a databinding relationship can be formed and destroyed imperatively). But I've moved away from WPF to Glitch, which doesn't have that problem: all code runs in the same world, with dependency tracing, re-evaluation on dependency change, and logging to support rollback as needed. In that case, now I'm curious how React compares to what I'm working on right now.
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;
If count changes, you update the label. But if selected changes, you have to stop observing the previous selected folder's count property and start observing a new selected folder's count property. Carefully tearing down and building back dependency chains is tough, but if you just play lose with the dependencies, it is actually quite easy to handle (you might get some spurious re-evaluations). Note that WPF can't handle this without lots of hackery, which is one reason I moved all my UI work to Glitch (the other is that WPF is totally inappropriate performance wise for writing compilers and language-aware editors). I'm curious how React handles indirect state? Or does it need to do dependency tracing at all (it wouldn't if its not incremental; I can't tell by looking at the website)?
I do a lot of Javascript for the front end SPA of our WCF based api, so I'm content with both js and C#, I try not to get too hung up on either language's respective baggage.
I think this can be really amazing as is react js now.
--
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.
Because when you deal with complex code react make it easier to read and as said in the talk more confident when making changes. On a large codebase we all know that you have to be a good JS dev to keep it well organized well readable etc...
I wish they'd go into more detail on why they can't make an app like paper in the browser environment. They mentioned something about Web Workers being crippled and later on explained how their framework puts JavaScript in it's own thread by default.
I'm also wondering why in their experience no one ever comes close to native widgets when imitating them in a Web apps.
with gpu-accelerated css transitions, requestAnimationFrame, virtual dom and web workers, the experience can be damn close. he makes it seem like "no comparison", this is provably false at least for the apps he demoed. for games, native is still necessary. what react offers beyond performance though, is definitely awesome.
imo, the talk comes off a bit like a sales pitch at a pep rally.
I don't know - but given Facebook's past with WebView on their flagship app I feel they would be best qualified to say whether or not those solutions once fully implemented are satisfactory.
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.
You're absolutely right that it is possible to get close. I think my main point here, (though I probably didn't cover this well enough and I was being somewhat hyperbolic, I guess), was that 'damn close' is unfortunately not the default on web, and it's actually really, really hard to get there.
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.
You're right that it's possible to get really, really close, but the effort required is very large and best avoided if possible. Not to mention, there will always be subtle differences between your UX and native, and it sucks to be in a position where you have to defend that difference to, say, your CEO who's asking why "it just feels different." Or worse, he can put his finger on exactly why it feels different and it's some tiny glitch that's out of your control but ruins the "polish" of the app in his opinion. It puts you in the position of either busting your ass to achieve the impossible or defending mediocrity.
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.
Since you are in native you could decode in native in a different thread and pass the decoded data into the Webview, but not sure if thats really better since you would still have to create an image object from the raw bitmap data.
The curves used in iOS are all pretty standard, they're easily to replicate if you want.
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.
There's quite a bit of hyperbole in this talk. Some web apps do in fact come close to native, but to the trained eye of a Facebook software engineer it will feel miles behind. Your average Joe doesn't give a shit, as long as they can use the app. If they did, Facebook's Paper wouldn't have been such a flop.
This is absolutely a great point, and honestly, I used this exact argument early on in the development of React Native to convince folks that cared a ton about craft and were super worried about performance, that it's more important to make sure you have a reliable application that adds value to peoples' lives, before you even earn the right to start thinking about craft.
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.
The best part of React Native, if it can deliver on its promises, is that it will provide web developers with a toolset they can use that will satisfy customers or product managers who demand perfect native experiences (whether or not it makes business sense to demand it).
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.
Don't underestimate the users. They might use different words, but their comments and ratings will tell the story of web/hybrid suffering. Unfortunately web is not meant for apps, but for interactive documents.
Don't overestimate users either. It's very easy to build for other geeks rather than the General public. Netflix apps are almost all built using web technologies and it doesn't seem to bother most users. I think there's been an overemphasis on pixel perfect UI and on UX in general but people don't want nice UI's, they want useful apps.
For Netflix, the interface can only get in the way. People are there to watch movies and that's basically it. You can't "nail" the interface like you can with applications you interact with more.
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 think his answer was that all the magic numbers and heuristics that make the physics and animations and whatnot feel perfectly native are black boxes. if you want to make a "native" iOS/Android experience on the mobile web, you literally need to guess about all of those things -- and it'll always feel a bit off. probably a corollary of the uncanny valley
I'm pretty sure an app like Paper is possible using web technologies (if you only support the latest browsers). I don't even see why they bring Paper as an example since I think the app is pretty shit UX wise.
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.
Just a minor quibble; I think the speaker is a bit too negative about faux-native apps, especially with React. For example, see this demo by Pete Hunt:
If you look at the demo you'll see that while it's likely close to the best you can do with web tech, the physics don't feel correct because we can't reuse the native constants. Also the UI is very flat and simple. More complex UIs would be a struggle without react native.
That sounds amazing. It's been a while since I haven't been that excited about a framework. Native wrappers are so hard to create and maintain that it's promising to have a company like Facebook behind one.
I can't wait to have access to this repo to see source code and examples.
Well, my money is on this (concept if not implementation) being the future of client-side development. Absent horrific performance/robustness problems, which seem pretty unlikely from this team, this is sounding like the droids we were looking for, the holy grail ring to unite us all, web and native.
And did even Steve Yegge ever see this next big language coming?
Having spent the past six or so months working with React and Flux, I sure hope so. For the first time in my technical career, I've actually enjoyed working in Javascript.
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.
Based on what metric? A Facebook team talking about a Facebook framework and a HN thread filled with React enthusiasts? I am not bashing any of it, but to suggest critical mass is a bit immature.
Yeah, I have yet to meet a react developer in person. Maybe the definition of 'critical mass' is just enough fans to have commentors posting about it 24 hours a day. I would say rust has reached critical mass if react has.
The community enthusiasm and features add up to the critical mass necessary to push me into giving it a good look... also, I wanted to say "critical mass" in connection with "React" ;)
I understood that the native react serializes the ui "DOM" to some format and sends it to the native process. Will the native rendering engine be open source and/or will the protocol be open/specified ? This could be handy for embedded targets.
I bet someone is planning to write a Markdown editor using React Native. Maybe a text editor is a good test if React Native app can be as good as native app.
I'm part of the group that thought "what the hell?" when I first saw the React syntax - but seeing this has completely changed my mind and I'm really looking forward to picking up React as soon as possible.
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.
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.
Yeah it's completely optional, facebook built it because they had built something similar previously and they like it, and I guess it may be simpler for "pure" designers used to HTML and stuff, but it's AOT-compiled to the corresponding JS calls and the mapping is fairly simple:
You really don't need to use JSX; I can't stand the look of it but love using React (I use it with CoffeeScript, but don't mind it with raw JS either).
I too had a WTF moment when I first saw JSX but after seeing a bunch of videos from the FB team explaining the whole concept being React and Flux it just made so much sense.
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.
I think everybody reacts quite viscerally to JSX the first time they see it. Mostly because it looks like something that has been tried in the past and didn't work then. It's actually not like that at all, though. It's decidedly not a template language but just an alternative syntax for JS.
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.
Up till this day, I still hate JSX but love the rest of React. The syntax problem though, is easy to solve. The verbosity and ugliness of XML was already contested when it was conceived, as it was being called a re-invention of S-expressions. In the end, I wrote all my React apps in sexps with paredit mode. With simple, purely syntactic macros, it's pretty pleasant.
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.
I'm Jordan and I'm on the React (and React Native) team. There's been some great questions and insight on this thread. React Native offers a ton of benefits around productivity (and ability to use React of course), but since there are many questions about performance, I thought I'd share some of my own personal perspective on the matter.
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.
Do you guys have a set of cross platform components like <Image> , <View> , <Map> that will work across Android , iOS and Web ?
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.
We have a <View> and <Image> that works on iOS and Android. We also had web implementations working as a proof of concept but I'm curious if the community would be more interested in helping us implement/maintain the web implementations since we want to focus more on the integrations with each native platform for now.
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.
That's interesting. I guess I can't really understand it until I see it finally released. A set of basic widgets like Lists,Sliders and Switches should definitely cover most use cases.
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 ?
Avoiding CSS reflows in modern browsers should be pretty well documented, and I imagine it only makes sense to discuss reflows in a particular browser.
@vjeux will cover more about the style/layout API in React Native tomorrow, but the main point I wanted to get across is that React Native's style rules are a limited subset that are generally cheaper to compute. More importantly - the result of these computations aren't given to the JS environment in a synchronous manner. You can't read/write/read/write style properties/computations and inadvertently trigger more reflows than necessary. I've seen that pattern make web experiences unusable. In React Native, reads must be done asynchronously, and they are batched together for efficiency. Not only is this one major footgun that React Native takes away, but the asynchronous nature also means that style computation (layout primarily) can be done in a different "pipeline" stage, which opens up future opportunity to parallelize that work with JS execution.
Is the JavaScript 'react host' implemented in native (Objective-C/Swift/Java) language and interpreted during runtime? How are the calls between threads managed - especially wrt marshaling of data structures?
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?
I wonder why it is such a big of a deal of not having DOM API:s on the WebWorker thread? I think the discussion from Browser vendors is that there is no use case or benefit of having them there.
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.
190 comments
[ 3.1 ms ] story [ 275 ms ] threadBut 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."
[1] http://en.wikipedia.org/wiki/Display_PostScript
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).
[1] http://youtu.be/KVZ-P-ZI6W4?t=24m5s [2] https://itunes.apple.com/us/app/facebook-groups/id931735837?...
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.
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:
If count changes, you update the label. But if selected changes, you have to stop observing the previous selected folder's count property and start observing a new selected folder's count property. Carefully tearing down and building back dependency chains is tough, but if you just play lose with the dependencies, it is actually quite easy to handle (you might get some spurious re-evaluations). Note that WPF can't handle this without lots of hackery, which is one reason I moved all my UI work to Glitch (the other is that WPF is totally inappropriate performance wise for writing compilers and language-aware editors). I'm curious how React handles indirect state? Or does it need to do dependency tracing at all (it wouldn't if its not incremental; I can't tell by looking at the website)?Link please!
--
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'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.
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.
This is a classic gridbag cartoon: http://madbean.com/anim/totallygridbag
I can't wait to have access to this repo to see source code and examples.
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.
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.
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? :)
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?
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.