React Native is now open source
github.com
github.com
See for example the discussions at https://news.ycombinator.com/item?id=9111849 (eg. https://news.ycombinator.com/item?id=9113515)
Full disclosure: I work at Google, where many are sad to not be able to use recent Facebook code.
You have to differentiate between copyright and patents.
From the perspective of copyright you're perfectly in the clear, the grant of rights that's part of the BSD license will not be revoked.
What will be revoked is the right to Facebook's patents insofar they apply to React.js. First of all that that requires, that Facebook actually has patents that apply to React.js. It also means you're no worse off than without a patent grant.
I prefer the Apache 2.0 wording, but this seems to be blown widely out of proportion.
No, see discussion above re: implicit and explicit patent grants. You don't fall back to an implicit grant when an explicit one is revoked.
It is absolutely possible to legally use React while going ahead and suing Facebook. You do not lose your license to React by suing Facebook.
What you do lose is an explicit grant of additional patent rights - the grant given in the PATENTS file. Note that there is no specification therein regarding what patents might be covered; it's completely possible that none of Facebook's patents have anything to do with React. I haven't looked. in any case, patents are totally distinct from you license to use React.
Would it be practically advisable to do so?
Only if it's possible to use React without infringing (or licensing) any Facebook patents. "Use" is not just about copyright.
(Which, as you point out, is plausible; there's just no reason to believe it's guaranteed to be true.)
It should only regard to react. If the clause is to protect their right to develop react, it should only pertain to such.
Suing Facebook does not void your license to use React. It voids your additional patent grant. That's different.
To put it simple, without the patent grant you'd be worse off. But with the Apache 2.0 version you'd be better off.
> If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
This seems equivalent to me, is the Facebook one broader?
> The license… will terminate… for anyone that [claims] infringement of any patent… by any party if such claim arises… from any software, product or service of Facebook.
> The license… will terminate… for anyone that [claims] infringement of any patent… by any party relating to the Software.
> The license… will terminate… for anyone that [claims] that any right in any patent claim of Facebook is invalid or unenforceable.
Wow.
It means that you lose the additional license to use any of Facebook's patents that may cover React. These may or may not exist.
As an example, say Facebook owns patent 1234567 "Method and system for reacting natively". Google owns 7654321 "High-density computers in a data center". Google builds the new Maps app using React Native. This would infringe 1234567, except that React Native comes with a patent grant, so the Maps app is properly licensed.
Then Google sues Facebook over Open Compute Project, claiming infringement of patent 7654321. This has nothing to do with React Native, but Google has just lost its license to 1234567. So Facebook now gets to sue Google over the Maps app. (More likely, Facebook will threaten to sue in order to force a settlement for the other lawsuit.)
Also, they'll likely be patenting whatever they can out of this technology, whether it's valid or not, you'd have to fight any action that Facebook holds against you - in the meantime invalidating everything, allowing Facebook to sue you for violating potentially dozens of patents; most everyone can't afford a lawsuit.
Facebook open sourcing all of these things is purely a power play, and not trying to contribute to the developer community. The power that this is going to allow Facebook to leverage in the future could get really nasty - it's why Google isn't using any of it.
"That Facebook patent is invalid." or "Software patents are invalid."
And even if we assume that to be true and assume that both parties believe in patents want a robust, well-functioning software patent system, that clause still sucks. If Facebook and I both invent something at roughly the same time and apply for patents, and the Patent Office misreads our applications and grants them both, and I point this out to them and I had priority (thereby invalidating some of Facebook's claims), Facebook gets to terminate all my patent licenses.
There are two separate kinds of legal protection at issue here, copyright and patent. The only thing that's close to covering ideas is patent law, not copyright law. (I'm assuming US law here, since that's where Facebook and I both are, but most of this is generally true I think.)
Copyright covers a creative expression, and is automatic. If I write a story, paint a picture, compose a song, or code a program, copyright secures my ability to commercialize that creative work as I see fit. If someone else writes a similar story, paints a similar picture, etc. but does not use my words or notes or lines of code, they aren't infringing my "copy right", because they're not copying my work.
Patents cover inventions, and are very non-automatic and best acquired with lawyers. Their term is also much shorter (about a decade, instead of about a century). US law currently lets you patent an algorithm or an arrangement of computer systems, under the artifice that you're actually patenting the implementation of that algorithm on any physical computers. Patents are issued for the invention, not for a specific implementation, and any implementation that works the same way infringes the patent.
(Trademarks, for reference, cover names used in advertising, i.e., "trade marks". They're somewhat automatic, they only cover names, and they're not very often relevant to F/OSS licenses.)
Traditionally, F/OSS licenses have been primarily concerned with copyright, partly because several of them were written when software copyrights were well-acknowledged and enforced, but when software patents were rare or nonexistent. This leaves you in the unfortunate situation where e.g. Facebook can write some code (automatically gaining a copyright), get a patent on the idea, open-source the code, and then sue you for patent infringement despite your copyright license. To avoid that, Facebook has an explicit patent grant in addition to the copyright license. (Although, as other commenters have pointed out, F/OSS licenses that don't specifically restrict themselves to copyright can potentially be read as a implicit patent grant if you stare at it hard enough.)
At no point in this does Facebook claim ownership of your work. Certainly your idea isn't legally owned by anyone, either you or by Facebook, if you haven't gotten a patent on it. Facebook's patents remain Facebook's patents, with or without this clause.
Because patents cover any implementation of an invention (whether or not the implementor knew about the patent), and because patents are in stupidly dense legalese, it's super common for people to be inadvertently infringing a bunch of patents. The traditional solution for this is that large companies have defensive patent portfolios in a sort of mutually-assured-destruction scenario: if Facebook sues Google over a patent, Google will countersue over all the patents they have. So there's an armistice, at least among big companies. The explicit patent grant weakens that, because now Google can just incorporate parts of React into their React-competitor, and Facebook loses a patent from their defensive portfolio.
So a few clauses like these are normal: you get a patent grant from Facebook, as long as you don't sue Facebook over (different) patent infringement. This maintains the armistice between big companies, and it's also great for the little guy, who wasn't going to sue anyway because they don't have any/many patents (but also doesn't have a defensive portfolio because they don't have any/many patents). These clauses only cover claims of patent infringement, which are the thing that everyone is unintentionally doing en masse, not copyright infringement, which is much harder to do unintentionally, so they're pretty fair.
But the fourth clause is super weird. It means that you can't dismantle any of Facebook's patents by e.g. providing prior art, without losing your patent license. It might even mean you can't lobby for software patent reform. It solely holds up Facebook's patent portfolio and the armistice between big companies. Usually dismantling patents is a good thing for everyone, because it's disarmament, and it's unfortunate this license doesn't extend to people who do that.
(IANAL, TINLA, corrections graciously appreciated.)
If that reading is correct, you can still use React Native to the extent that doing so doesn't violate any of Facebook's patents. They could argue it does and you could argue it doesn't. Until and unless a judge ruled that it did, you could continue using the software.
Edit: Geofft that's a good point. I suppose this really is a poison pill for a sufficiently large company.
For Google's use case, it means that if they ever find themselves in court claiming to have prior art on any of Facebook's patents (let's say Facebook sues them over something G+ does, and Google says it was described in the literature well before either of them), they automatically lose the (patent) rights to all of Facebook's OSS, even if they're legally in the right. So they can't build anything they care about on React.
The general argument is made that there is an implicit patent license granted when an open-source license is applied to a software product, and that this explicit patent license somehow overrides the implicit patent license (despite not being part of the license itself).
I've received different advice on the matter, so YMMV. But at the Google level, I'd imagine there'd be channels to negotiate an acceptable solution to this issue…
But I think you've made a very good point. If you're not going to avoid all component-based and/or virtual-DOM view engines, picking an alternative to React may not give you any advantage in a legal situation.
I'm not really sure what Facebook thinks they are gaining with this clause. They aren't going to stop patent trolls, because they are non-practicing entities. Maybe they want to guard against someone making improvements to React and then suing Facebook if they do something similar later.
Wouldn't that apply to Google as well?
I'm confused. The Facebook PATENTS stuff seems no worse than MIT-licensed code that includes no patent grant at all.
In other words, if the PATENTS termination clause takes effect, then the software essentially reverts to being plain MIT, instead of MIT + patent grant, right?
EDIT: Appears the issue is implicit vs explicit patent grant, and the Facebook PATENTS stuff can indeed be worse than no patent grant. https://news.ycombinator.com/item?id=9113515
As far as I understand it, the patent grand terminates when you end up in court with Facebook and then you're effectively distributing software that may or may not be covered by patents you don't own/have a license for.
>anyone that makes any claim (including by filing any lawsuit, assertion or other action)
Even just stating that a Facebook patent is invalid terminates your license.
>any right in any patent claim of Facebook is invalid or unenforceable
Even just stating your belief that software patents are invalid or unenforceable terminates your license.
However, if you read closely, the last paragraph starts out with:
>The license granted hereunder
There isn't actually any license granted after that clause (it occurs before this clause), so I'd argue the entire last paragraph is meaningless puffery.
"hereunder" does not refer to a direction within the text :)
>further on in a document.
Even your primary definition contains the location clause, 'under the terms'.
Odd, that didn't show up in my view o_O Maybe google is geo-targetting dictionary definitions...
Also, 'under the terms of this document' does not literally mean 'physically located beneath this sheet of paper' :P
I guess that's the interesting part. Sources would be really helpful.
That might or might not be Facebook's goal in the license, but regardless, it seems like a great outcome. Likewise, avoiding that outcome might or might not be Google's reason for not using this code, but since other companies are, it seems in need of explanation.
Or they sue each other anyways and it takes another 5-10 years to figure that situation out, hobbling any OS development under those licenses while there are very clear and widely used and accepted patent grants available.
There's a reason the FSF recommends Apache 2.0 if you aren't going to go GPL.
But this new patent license is stronger. If it would make the industry safer from patent armageddon in the long term, it might be worth the effort to popularize yet another license.
Let's say 10 years from now Facebook decides to go on the warpath over fairly bogus patents. The EFF puts the headline patent on their Most Bogus patent busting list and then puts out the cry for "who is with us?"
No company using any Facebook open source code answers.
How does that make the industry safer?
I understand there might be a chicken-and-egg problem here. But the final outcome seems optimal with this license. And someone has to go first.
I'm mostly interested in the interpretation since it's a curious use case. The actual grant you'd lose is pretty much useless in that scenario either way (as it can't really be granted due to the software not patentable issue).
Whether the clause is triggered or not shouldn't matter if the patents aren't valid in your jurisdiction.
You don't have to state your rights — you just have them (there might be exceptions to this).
---
I'd love to get an answer to the bigger question as well.
Are there ever! For example, right against self-incrimination must now be invoked explicitly. Refusing to answer a question (they will say "being evasive") can be used against you unless you affirmatively state you are exercising your right to remain silent. [1]
[1] - http://www.abajournal.com/news/article/chemerinsky_silence_i...
Facebook holds patents granted in the US. Those patents to do not apply to all other jurisdictions. German law doesn't consider US software patents invalid, they just don't apply under German jurisdiction.
Basically, if Facebook can't sue you for patent infringement in the first place, the clause doesn't apply. If you use React in a product that enters the US market (or any market that is subject to US patent law), that's a different story.
That said, I'm suspicious that the entire thing is not enforceable in Germany in the first place (to clarify: I'm not claiming it's invalid, just speculating that it may not be enforceable in German courts). German contract law is actually pretty restrictive when it comes to what may or may not be in implicit agreements like software licenses.
Case in point: WhatsApp was told off in Germany because it blocked the accounts of users who used third-party clients. Using third-party clients was explicitly forbidden in the WhatsApp ToS, but the clause was considered "surprising" and therefore invalid. The ruling argued that using third-party clients was accepted by most popular similar apps and losing access (not just in the third-party client, but in WhatsApp proper) because of doing that could not reasonably be expected by users.
There are also serious restrictions to what rights you can waive. Not only doesn't the public domain exist in German law (you can grant a universal unrestricted non-exclusive license, but you can't waive your ownership completely), nor can you completely disclaim responsibility (e.g. you can still be sued for intentional harm even if you give something away for free). Another example was Walmart in Germany trying to prohibit employees from entering romantic relationships with each other (and failing, resulting in lots of bad PR).
There's a reason contracts in Germany typically include a clause stating that even if any single clause is legally invalid the other clauses (or even "the spirit of those clauses" in so far as it can be enforced otherwise) still remain in effect. I'm not sure whether this is actually required, but the idea is that it prevents contracts from becoming invalid because of any single clause being ruled invalid.
Good for you buddy.
1. You have a license to our related patents
2. You're on your own if someone else claims that your use of our stuff infringes their patents
2a. But if the party suing is also a licensee, they lose their license.
These kinds of licenses have network effects, and are only really effective in a mutually-assured destruction scenario.
http://ipjournal.law.wfu.edu/2011/03/googles-afraid-its-free...
Not only did the call for patents never actually materialize anything (12 supposed but never named companies in a press release four years ago), Google bought out the MPEG LA's claims anyway[1].
Meanwhile the VP8 patent grant[2] is exactly the kind of thing being contrasted here: you lose your license to the VP8 patents only if you sue over patent infringement in VP8 itself.
[1] http://arstechnica.com/information-technology/2013/03/google...
If I'm reading this right, any fork of this code is not covered by the patent-protection can be sued into oblivion, by Facebook themselves if they feel threatened. Wow.
Ability to fork is crucial for real life open-source projects, so having a clause like that pretty much nulls out any open-source benefit which may have been there in the first place.
This weekend I am going to try and get a working application built using React Native. Facebook are absolutely killing it in regards to their open source contributions. The learn once, write anywhere paradigm is smart as opposed to what others have done via their write once, deploy anywhere approach which just doesn't work for web and native applications.
Could you explain that? I'm not familiar with phone development and I'm having difficulty figuring out what "the other way around" is.
I'm a little concerned because, for example, a button is not implemented as a native UIButton, and a ListView doesn't use UITableView. Instead they are composed of native UIViews with a lot of JavaScript glue.
That being said, Facebook has more experience writing iOS apps than me, so it may be possible that those things don't really matter (and doesn't preclude 1:1 components from being added down the road).
Some food for thought: what if you kept HTML and CSS but instead of using a WebView to render it, you rendered the DOM manually using UIViews? You could even make overflow: scroll; turn into UIScrollViews automatically.
<Carrousel> <Item></Item> <Item></Item> </Carrousel>
On the web you might use a div with overflow:scroll on native a scrollView.
If it's using UIViews, it isn't reimplementing native controls. It's using native controls, same as if it was implemented with (interface builder) .nib files. That's like saying "reimplementing html/css with html/css".
I've spent 15 minutes with React Native so far, and as best I can figure, the answer is no.
If they were building the GUI components from UIKit pieces, they'd get all of this for free. But I understand it would be pretty hard to get all this working with the flexible layout architecture they have... so I'm guessing they'll have to slow add all the accessibility features in over time.
[1] https://facebook.github.io/react/docs/displaying-data.html
I downvoted you not because I don't agree that Native will be compelling but because I hate to see all this hate that's come out against hybrid apps in general that's even been propagated by React Native devs.
Webviews will get there. WKWebView is already a huge step forward. I think Native is great, but it's not a clear winner in many cases. I even like "learn once apply everywhere" (though it doesn't really go against the web in any way), but I would say the mountain of hybrid apps out there actually disprove that it "just doesn't work".
That's just FUD. Only hybrid apps that use non-native scrolling are jittery, and for years now you can use '-webkit-overflow-scrolling: touch` to get native scrolling with bouncing.
- React Native from Facebook (https://github.com/facebook/react-native)
- Appcelerator's Titanium and Alloy Frameworks (http://appcelerator.com)
- Telerik's Native Script (http://telerik.com/nativescript)
- Xamarin (http://xamarin.com)
As I understand it, all three of these frameworks have a JS (or C#) runtime that is compiled along with the app. This JS runtime is what drives the app and uses the native features of each platform (iOS / Android).
I've been building on Appcelerator for the last 4 months on some basic apps, and it works pretty well.
I look forward to trying out some toy apps on the other platforms.
We also do Scala, Kotlin, Clojure etc. and we are OSS as well (we started out as OSS). You can build unlimited apps without paying us a dime. You can also compile the entire compiler plus Eclipse/Idea/Maven/Gradle integration yourself so you aren't locked in.
We expose all iOS APIs and have a custom bridge besides JNI to make binding and subclassing of Objective-C APIs and C APIs as seamless as JNA or p/invoke, but without performance overhead. We use LLVM to compile JVM bytecode to native code directly, so performance is excellent and on par with Objective-C.
At this point you can write apps for iOS and Android, using the native UI APIs, and share business logic between them and your backend, if that's also JVM based. I personally think that using native UI APIs is best. However, for CRUD or enterprise apps you may not care about shininess, which is why our next focus will be on a cross-platform UI toolkit for Android and iOS.
You do have to pay for debugging support, interface builder integration and SLAs/hotfixing. We hope that's a fair way of supporting our OSS work.
Now I feel dirty...
On Android, there is no JS execution environment available. We want to avoid the memory and cpu overhead of web views.
So we are basically forced to ship Android with a copy of either JSC or V8.
The main advantage I see is that it's open source and free (with some patent caveats).
There's also Corona SDK, which uses lua and OpenGL. Write once, build for Android, iOS, and Windows Phone 8. UI performance is quite good. Supposedly building Mac and Windows desktop apps is coming soon, but HTML5 support was announced a year ago and has not yet happened.
The free version of Corona SDK supports only a subset of the native APIs (albeit an extensive subset that's probably sufficient for 95% of uses). If you want the full set, you have to pay $1,000+ a year for Corona Enterprise and implement your own os-specific glue logic.
How, when you're running JS on a different thread to the iOS main thread, do you avoid race conditions? A simple example:
* Say a button's event handler pushes a new view controller onto the navigation stack, what's to stop the user from tapping the button twice very quickly before the JS thread gets a chance to service the first tap, eg it may be garbage collecting or busy elsewhere, and once it's free again it runs the handler twice and pushes two view controllers onto the navigation stack?
Looks great by the way, i'll certainly check it out.
Also ask yourself a question, do you really think you can call yourself an iOS developer when the only way you truly know how to create apps is with React?
Like Facebook's Groups app and Ads Manager app, which both use React Native?
Dragging and dropping all the time is cumbersome and it is impossible to version control storyboards in any meaningful way. Dragging lines to outlets is a real pain, and the references stick around after you delete stuff, causing countless infuriating runtime crashes.
Most things that you would like to do can only be accomplished with goofy hacks.
Long thread of 50loc+ answers to something that would be accomplished with one line of CSS: http://stackoverflow.com/questions/19226965/how-to-hide-ios7...
I don't really want to call myself an iOS developer. I just want to port a simple web app to iOS, and my options are learning just enough iOS development to do it myself, or hiring a real iOS developer. So I'm curious if this framework would tip the scale in favor of the first option.
You don't even have to dive into React (which has its own unique way that I'd call barely JS anymore).
Have you tried Cordova / Phonegap?
Eh, I assume you're referring to the JSX syntax. I happily don't use it at all. It's all just JavaScript functions and objects.
But even the pure JS method. I shouldn't have said "barely JS anymore".
I'm just not a huge fan of apps built entirely in JS that spit out markup. I find it so messy personally, but also a giant brain shift too.
The commenter I was replying to wanted a way to take a web site and get it to run as an app. HTML, CSS, JS -- Cordova / Phonegap is one way to do it that requires very little rewriting of your code. At least compared to taking a HTML/CSS/JS web app and rewriting it in React.
Granted, I am no React expert and plan to give it more time soon. But at the 30k ft view, it's simpler to port your app that's already built by using Cordova. If you're going to rewrite anyway, sure, use React Native if you're already a strong JS programmer.
Compared to more complex frameworks, React hems closely to JavaScript as a language. I enjoy working with it because it lets me write entirely in JavaScript without any weird template languages or typical framework "bloat." In my experience, it helps me write readable and correct frontend code.
Random tangent: sometimes I imagine that React would have another name—say, something dull like "libdomdiff." The JavaScript world for some reason seems to operate by making everything into a fancy big deal; every library needs its own conferences and consultancies. I feel like being a "React expert" is kind of overrated. It's basically just a library with like a dozen functions.
But you're right too that it is a different way of writing apps. I hope your experiences with it will be as positive as mine!
Saying this, I have no real idea how abstracted react native is from normal IOS dev, so maybe it wouldn't be as helpful as, say, learning python and django at the same time.
I totally agree with you, but does it matter in the grand scheme of things? Look at web developers that only know frameworks. They may only know jQuery or only know Rails, but if they're still getting shit done, does it ultimately matter? There may come a day where that developer is required to go deeper than the lib/framework allows and they may be exposed or may be forced to learn more or they may drown because they never learned to swim.
This is interesting to me because it brings up the question of how important is mastery when there are deadlines?
What proportion of iOS UI elements are available through React Native ? Is there a 1:1 mapping somehow, but how are discrepancies between platforms (Web/iOS/Android) handled then ?
Could a complex app's views realistically be built entirely using this or would you have to resort to native UI elements in some cases ? How well would they mix with React Native code ?
'We'll release an Android version later'
A month later:
'We'll release an Android version later'
You consider this progress at least in terms of PR & communications?
When asked when it will be released they said "You will know when its released, it will be really obvious"
Q. Can I submit my own React Native app to the App Store?
A. Not yet, but you will be able to soon. If you build something you want to submit to the App Store, come talk to us ASAP.
Thanks! :-D
The reason I'm excited for it: Java promised write-once-run-anywhere, which means you are always serving the least common denominator. React Native promises learn-once-write-anywhere, which means a single team of engineers can realistically build high-quality apps using the target platform's UI paradigms.
Really exciting stuff!
You're into commercials and marketing hype?
Since when is react providing any semblance of stability? Javascript is already bad enough of a moving target without an unstable api on top of it.
I am extremely hopeful about React. Even though I know Objective C and have apps in the app store, I'd use a cross-platform toolkit if I could get Android and Windows for free (or minimal effort). In my past experience it didn't really play out that way, but I am ever hopeful that this time it will really work.
Funnily enough it's a different matter for games, see Unity, UE4, libGDX, Cocos2D-x etc.
Adobe Air comes pretty close to "WORA". For 2D games it goes almost without saying, but throw in the excellent Starling + Feathers framework and it is great for Apps too. A drawback is of course that you do not have native UI, but if you can get passed that it works really really well.
I evaluate cross platform technologies quite regularly and my opinion still is that Adobe Air is the best (just make sure you stay away from Flex ;) For everyone who gave up on Adobe Air some time ago I highly recommend to take another look. The Eco system did not stop to evolve at all and it provides a really good development environment.
Funny you mention Flex, still gives me the shivers, still used by a lot of enterprises around here. Pretty much on par with applets in terms of badness.
But considering that you do not necessarily have any costs in developing Air (you get the compiler, and also good editors, for free) it is not that bad at all.
I also do not write native extensions myself, but at least you know there is the option in case u need to access some native library. But yes, in that case it is not really "write it once" anymore.
https://www.adjust.com/ http://www.mobileapptracking.com/ http://www.appsflyer.com/ https://www.kochava.com/ http://www.fiksu.com/
Alright.. I am done with promoting now, I think ;)
I guess a lot depends on what is meant by encountered but Xamarin would probably be a much more full featured cross platform UI toolkit than anything else out currently.
Supports Xamarin.iOS, Xamarin.Android, Xamarin.Mac, WPF, Windows Forms, Windows Phone 8 and Windows Store apps. Check out "Writing Mobile Apps the Github Way by Paul Betts" @ https://www.youtube.com/watch?v=voa44OHBKME
It is the framework that powers GitHub for Windows and various other undisclosed projects ;-)
Take a look here: http://facebook.github.io/react-native/docs/pushnotification...
This seems to be the case with a lot of cross-platform development kits. One or the other of the platforms is a second-class citizen.
It seems that all of us are salivating at the idea of having true cross-platform tools that actually work really well on all environments so I will keep my fingers crossed that Facebook can pull it off.
My concern is that it actually works and isn't buggy as hell on one of the platforms, which is something that I haven't found from similar toolkits.
For example, I used to have a phone with only 1gb of internal storage, on which Facebook took over 200mb on its own (far more than basically any other app). It's pretty clear that whatever the devs are doing in regard to space usage, they're doing it incorrectly.
If the latter, I wonder if the React Native developers have considered using Duktape rather than JavaScriptCore. Duktape might be better for memory usage, since it uses reference counting, with mark-and-sweep GC only being necessary to break cycles.
Because we built React Native around an asynchronous batched bridge, we can plug it into any JS execution environment. For now we plug it into JSC, which is available on iOS 7 and 8. We also use websockets to execute the JS in chrome so we can utilize the debugger.
Without much difficulty, we can make the bridge work over a WebView (if we want to support older iOS versions), or Duktape.
Native apps rendering capacity is sub-micro seconds. Hoping for Appcelerator's dreaming Hyperloop that give us native JS capabilities.
I still plan to use ReactJs (web) within web-view.
new ListViewDataSource
new ListView.DataSourceIt seems ComponentsKit is a very specific to iOS as opposed to React.
My understanding is that ComponentsKit has you write your iOS apps with ObjC/Swift or whatever, but it gives you a way of structuring your apps that is similar to React.js
http://facebook.github.io/react-native/img/chrome_breakpoint...
I am really confused. Why is this easier - this looks extremely buggy and complex?
I've been checking my Twitter obsessively today and yesterday for this.
It's basically Relay but using Promises instead of GraphQL to write queries. Transmit is coincidentally also a very efficient way to create isomorphic apps that can render on the server.
https://github.com/facebook/react-native/tree/master/Example...
How would one go about making the Movies sample accessible, or is that even possible?
Scala -> Scala.JS -> React Javascript -> Native code
I'll have to try this out on a small project and write about it.
var { AppRegistry, Image, ListView, StyleSheet, Text, View, } = React;
is this ES6 feature?
It gives an error in Console.
http://facebook.github.io/react-native/docs/nativemodulesios...
We use a key-value store for most of our client-side persistence:
http://facebook.github.io/react-native/docs/asyncstorage.htm...
still wish there was a way to develop for iOS on windows platform but I guess I will have to purchase a mac now if I want to build mobile apps