I think it's a very strong point that moving script code off the main thread can help achieve smooth UIs. No more GC pauses, no more slowdowns if the JS engine hits a snag, etc.<p>I think this is actually possible on the web as well. Someone could write a UI framework which runs JS in a Worker, and sends messages to the main thread, on which there is HTML and minimal JS to receive the messages and handle them.<p>I'm surprised this hasn't been done, or has it and I just haven't heard about it?<p>If you're worried about the overhead of transferring lots of messages from the Worker to the main thread, I think it can be pretty fast actually. I did an experiment with proxying WebGL that way, which is a fairly high-traffic API, with nice results,<p><a href="https://blog.mozilla.org/research/2014/07/22/webgl-in-web-workers-today-and-faster-than-expected/" rel="nofollow">https://blog.mozilla.org/research/2014/07/22/webgl-in-web-wo...</a><p>For something rendering a UI, message passing overhead should be reasonable, especially if the framework is smart enough to only send over what changes (like React Native does).
> "This is <i>solid engineering</i>. And it completely reinforces the fact that <i>React.js is the right way</i> to build apps."<p>This just comes off as really weird to me. Why would any sane developer make a statement like this? It sounds preachy and brainwash-y and weird. If there's anything we learn as developers it's that there never is and never will be a single "right way" to do everything. Reading stuff like this makes me doubt the entire article.<p>There's a difference between writing objectively about something that's interesting that you enjoyed, and trying to lay down a dogma. TBH, the more of this article I read, the more my view of it's goals swayed towards the latter.
Declarative UI is boss.<p>I know Andy (former UIKit team) was quoted in the intro thread but I'll do it again:<p><i>>I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a huge deal.</i><p><a href="https://twitter.com/andy_matuschak/status/560511204867575808" rel="nofollow">https://twitter.com/andy_matuschak/status/560511204867575808</a><p>If you're averse to React because of JSX, “mixing templates and views” and similar superficial “best practices”, you're missing out. Engineers embracing React are not dumb. You should consider a possibility that they think it's good for a reason, and that reason is something you should learn about instead of armchair-rejecting it.<p>Try tuning out your inner rule-of-thumb linter for a weekend and really give it a try.
Seriously please stop making assumptions on Titanium without knowing a thing about it.<p>> With the latter, you're also interfacing directly with native objects all the time, which is doomed to fail performance-wise. React Native actually performs the layout on a separate thread [...]<p>Wrong. With Titanium you work with proxies. And JS is in a separate thread. The only actual difference between ReactNative and Titanium on this side is the functional/fully-declarative/almost-stateless vs imperative DOM-like philosophy.<p>Let me slip this through: «if you don’t know something then don’t make it look like you do».<p>Sorry for the rant. I’m just very upset from yet another post like this.
I'm looking forward to desktop UIs also being supported by something like this -- e.g. native Windows, GTK+, and Cocoa widgets. Then we'd have a true framework for writing GUI apps that can share most of their code across the whole range of platforms, which would make me literally stand up and start singing right now. Lalalalalalala!<p>If you coupled this with conditional stuff around what kind of form factor you're on (screen size, etc.) you could design mobile first UIs that gracefully <i>enriched</i> on a larger form factor. Lalalalalala!<p>I don't know of Facebook cares, but I WILL PAY FOR THIS! For a well-engineered modern platform that did all of the above I would pay thousands of dollars. So if the choice comes down to staying free and abandoning this effort vs. making it a profit center, please for the love of all that is holy take my money.<p>Really when you look at the labor costs of developing parallel UI efforts on many platforms, a cross-platform dev system that delivered a <i>high quality</i> native-feeling experience across every major platform could be worth at least tens of thousands of dollars to millions of people.
I love the concepts behind React, and I agree this is a huge deal...I just wish it weren't javascript. It is a terrible language, and the languages that compile to javascript are a poor substitute (bloated code sizes, interop issues, poor runtime performance, etc). For a framework that is all about state machines (a good thing! All UIs are state machines), I hate that there aren't better ways to model them in the language. I would kill to be able to do React in F# or OCaml.
Sounds amazing... What are the challenges, limitations, and tradeoffs for using React Native? There have been similar initial reviews of Titanium, Phonegap, and Xamarin, but in my experience they all have serious issues that make native development a better option in most cases.
Probably the most useful way to get a read on this is to compare it to Titanium, also a JS-to-native framework that runs JS on a separate thread. The biggest problems with Titanium were not performance. A couple of the most common complaints:<p>1) You don't have full access to native SDK functionality (e.g. all the latest cool things in iOS8). You're going through a cross-platform API wrapper and limited to the choices of the framework architect. So it can be frustrating to go down this path only to find you still can't quite get the native experience you want.<p>2) Debugging is harder because the native toolchain (e.g. Xcode) doesn't understand the framework. You have to rely on tools provided by the framework.<p>AFAICS the author doesn't address these issues. He seems to focus largely on the (theoretical?) performance optimization of not crossing the JS-to-native bridge as much in React... by being even more isolated from the native APIs and doing more work in JS. But even if true, performance was not the chief complaint with the closest predecessor to this.
> the mess of HTML and CSS get in the way of frameworks instead of helping them<p>I totally understand where the author is coming from, and do agree... BUT there is a flip side to this, which is that HTML and CSS enable us to come up with and implement totally unique designs and interfaces. The lack of standard layout and complex "widgets" is definitely a pain in the ass, but it also enables a lot of unique-looking websites and designs. It's kind of a pet peeve of mine when platforms/CMS's try to output markup instead of just providing data to the view layer... they are always outputting the "best practice" (if lucky) at the time they were built, and then a year or two later you want to do things a different way and you're stuck.<p>So I'm super excited about React.js and love the simple mental model with flux etc., but another part of me also worries that one can't dictate the markup exactly the way one wants because it has to be recognizable to the virtual dom as well (or the iOS view in native, or whatever other front-end React will output to).
Maybe someone with more React.js experience can enlighten me about this though? (I've only dabbled).
I get this weird feeling that React Native has been created as a stand-in until webview is truly ready to take over mobile. I can't imagine a scenario where by end of 2015 (or early 2016) mobile webview technology won't be sufficient for 99% of mobile apps.
So if this is native widgets etc., the main point is being able to write this in JavaScript, right? Anything in it for those who don't consider this inherently beneficial?<p>Souns a lot like GWT, s/Enterprise "architects"/Web "ninja"/ to me.
OK, so how long before we backport the Android UI toolkit to WebGL using GWT and get rid of HTML and CSS altogether? Or even just write a sane new one?<p>Very interesting that this stuff comes from Facebook, who have very little concern about being indexable by search engines.
The code style really reminds me of ExtJS circa 2.x (not sure what it's like now), which was pretty good at what it set out to do. However, React Native requires compiling down to various different platforms which means having to maintain multiple compatibility layers to continually shift to keep up with the native vendors. You're also pretty much stuck with proprietary distributors as well. Fun. Fun.<p>This does look interesting, but honestly, I think this can either already, or very soon, be replicated on the web, a platform which holds tremendous advantages that native will likely never be able to catch up to. Perhaps there's an argument that these apps can also be translated to the web when their time comes, but I wonder what sacrifices are being made in the name of going Native?<p>React Native seems to be an attempt to fight in the opposite direction (Web -> native) while the real momentum is going the other way (native -> Web), and the best part is, you don't even have to do anything to get it, the major players are building that open ecosystem for us.
As someone who has developed many apps using Appcelerator Titanium, I am looking forward to getting my hands on this to see where the differences lie.<p>I know that it has taken Titanium years to mature, so I wonder if it will take a similar amount for React to iron out the bugs - I'll be surprised / pleased if they hit the ground running.<p>Hopefully they'll hurry up and make it public!
I'm assuming React Native can load external JS files over the network? If that's the case, then I understand why Facebook is building this.<p>They could have control of their application and behavior and make even more changes than before without re-submitting to the App Store.
<p><pre><code> "React Native actually performs the layout on
a separate thread, so the main thread is as free
as it can possibly be to focus on smooth animations
(it also provides flexbox for layout,
which something that no other framework provides)"
</code></pre>
Interestingly - though perhaps increasingly less relevant - this is how BlackBerry 10 platform native QML-based applications work as well.
For me the best of the web has always been HTML & CSS which I miss so often when dealing with native widgets or creating my own. The only thing that used to scare me off the web was JavaScript. Give me a HTML & CSS frontend, please. But let me keep my beloved Scala or Swift ;)
I'm still very excited to try it. I agree that this is the way forward for writing apps. I have attempted to write iOS apps before, and the problem is not objc, I actually kinda like objc. The problem is the damn view layer.
Didn't we do this already with Qt? Or Java? Or wxWidgets? Or OpenGL? Seems like cross-platform UIs have been a reality for quite some time.<p>What does React bring to the table that these do not?
This is yet another reason why you shouldn't use animations in CSS3 and should do them in JavaScript. I honestly don't understand how behavior (which is what animations are) got baked into a declarative style language.<p>Layout (which is also behavior if the layout changes with the dimensions of the viewport) and animations are two things that need to be removed from CSS and implemented in JavaScript.
sounds interesting. not a fan on reacts workflow because i use jade templates w/ backbone that get compiled to html for me and its much less code, but separating javascript and native components into different threads is a great idea.<p>i believe we should be able to see javascript being used as a responsive language portable across all devices and being used to control native components as a separate layer.<p>im actually working with a flexbox xml/html wrapper framework for iscroll that i might use to build a responsive app that not only does pc animations but performs alot of nice mobile slider animations that seem to go at 60 fps on modern handhelds, but its up to emerging gapping technologies like cordova and this to make the use of future "responsive ui kits" which i believe should be emerging soon.