The first thing I do now on each Facebook open-source reveal, is to check the PATENTS file for the toxic second paragraph, to see if they've changed it. Sadly, no. I can't imagine being able to use this at any decent-sized company with lawyers. :-( https://github.com/facebook/react-native/blob/master/PATENTS
> The license… will terminate… for anyone that [claims] infringement of any patent… by Facebook… whether or not such claim is related to the Software.
> 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.
(Someone had a post asking a good question about what this means. It got downvoted and deleted, which I think is unfortunate for a community that cares about learning about the world around it, so I'm replying here.)
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.
If you use any of their work then it opens you up to Facebook leveraging this against you. If they feel you violate a patent of theirs and they ask for a royalty or licensing fee - you can't even say it's not a valid patent or you void the right to use React Native, and anything else that has the PATENTS file in it (which is all of their stuff AFAIK) - that's why Google doesn't use it.
I'm not sure that is the case. The linked document says:
"The license granted hereunder will terminate ..."
that could be read to mean both licenses, the copyright one and the patent one, but the most natural reading, particularly as they are in separate files, is that it is referring solely to the patent license.
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.
Yes, but it also affects you in the case that you argue that some other, unrelated Facebook patent is invalid, even if you're happy to concede that the patents covering React Native are valid.
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.
Minor correction, the term of a patent is 20 years from the date of filing in most countries. The amount of time you can exercise your rights during this term is dependent on how quickly the patent office approves your application (if you get stuck on a backlog, the term length may change). Still not a century, but it is quite long.
No, the license terminates when you make a claim (of which a lawsuit is a subset of) that any 'right' of any patent claim that Facebook makes is invalid or unenforceable. This would include statements to the effect:
"That Facebook patent is invalid." or "Software patents are invalid."
You keep making definitive statements. Are you saying that you can keep using React Native if your patent rights are waived? That'd only be the case of those patents don't exist - but even then Facebook is stockpiling patents related to everything connected with social networks.
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 clause relates to the patents you own that you're suing Facebook over, not the patents Facebook owns that they're (no longer) granting you a license to.
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.)
Even if we assume that to be true, the fourth of those statements still sucks. No free software license denies use to people who have the wrong political views. If you manage to get software patents outlawed in one jurisdiction, your patent license expires in all other jurisdictions. Imagine how much the FSF would love to have a clause saying, if you weaken the GPL in court, your license to use any GPL software expires... but they don't.
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.
> Full disclosure: I work at Google, where many are sad to not be able to use recent Facebook code.
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
IANAL, but the argument seems to be that there is an implicit patent grant in the MIT license. MIT gives you a license to use the software, and you can't use the software without a patent grant, therefore you have an implicit patent grant. The existence of an explicit patent grant means that you can use React without an implicit patent grant, so you don't just automatically get one if you lose the explicit patent grant.
Wouldn't that implicit patent grant be in every other BSD-style license as well?
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.
No, being in court with Facebook is only one place where the termination can happen:
>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.
Can anyone tell me how this clause is interpreted when I use React in Germany?
German law (simplified) claims that no software patent is valid unless it solves a technical problem (in the physical problems sense).
Does this mean since I accept German law as valid by being a citizen of the country I implicitly claim some (ergo any) Facebook patents are invalid and the clause triggers automatically?
Is living in such a country enough or do I have to actively state "Facebook patents..invalid IMO"? What about the German government itself using React?
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).
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]
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.
So I guess you don't use any Apache licensed products at work either? Since the only reason Facebook added the PATENTS file is to keep the new BSD license in line with their old Apache license. http://www.apache.org/licenses/
Apache 2.0's license clause does not have an equivalent to "The license granted hereunder will terminate, automatically and without notice, for anyone that makes any claim (including by filing any lawsuit, assertion or
other action) alleging [...] that any right in any patent claim of Facebook is invalid or unenforceable."), which is the problematic part as it means that you can't even defend yourself if Facebook sues you.
> 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?
That says that if you claim that the thing being licensed violates your patents, your grant to their patents covering the thing is terminated. Facebook's patent grant has that, but also invalidates the patent grant if you claim that any of their patents are invalid (which you are likely to do if Facebook sues you for violating one of their patents).
So what if Apache committed something that is infringing on your patents and you sue? Does that mean you would have to stop using that specific apache licensed software (e.g. hadoop, maven, etc)
You lose the patent grant for that specific product: e.g. if you sue someone over a patent infringement in Hadoop you lose the patent grant for Hadoop, but not Maven. This may or may not mean that you have to stop using Hadoop.
I'm not a lawyer and I'm using my best guess. But you have to be on the offensive and sue Apache to terminate their license, Facebook's license says even claiming their patents are invalid terminates the license.
As with the other discussions on this matter, I remain sceptical that this clause is a problem.
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…
That's a good point actually. Regardless of your personal opinion on the applicability of the clause, if your company's lawyers say you can't use FB's software, you're pretty much out of luck. I wonder how many companies and developers have been effectively blocked out of the ecosystem as a result.
I asked the FB Engineers that were manning the Open Source booth at F8 today about this. They assured me that it wasn't a threat, or any change in ideology on their end as open source contributors. That they were also concerned with the community, and that their lawyers were looking into it currently. Not really an answer, but at least they awknowleged the criticisms.
Mutually assured destruction. If Facebook sued Yahoo, Yahoo could sue Facebook right back.
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.
Pre Mayer Yahoo did sue Facebook over patents. They settled. As far as I could see the fact that the only big patent fight fb has been in ended with a company with a boatload of lawyers being cool with these terms should bode well for anyone else. If you have patents they shouldn't rely explicitly on open source library x y z, but I am not a lawyer either.
Any idea what there is in React that Facebook have or are likely to have Patents over? Presumably, using another React-like framework might open you up to issues with these without the (limited) protection of the patent grant.
There is prior art, the first time I saw vdom was at Clojure Conj 2012, six months before React was publicly released. Project was called "webfui" by Conrad Barski, https://m.youtube.com/watch?v=HeI5-D7SQe8
You just terminated all of your Facebook patent licenses, just then, by your assertion alleging that any right in any patent claim of Facebook is invalid or
unenforceable.
I don't think anyone has been able to answer this (and I suspect anyone at Facebook who might know is not allowed to bring it up).
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.
This is quite an out of date article and your #3 is totally wrong.
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.
> The first thing I do now on each Facebook open-source reveal, is to check the PATENTS file for the toxic second paragraph, to see if they've changed it. Sadly, no
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.
It's a near-certainty that any tech giant is going to have patent issues with any other tech giant, not bundling the consequences of this with their open source licenses would be a good start.
I am not a lawyer, but perhaps they could just skip the second paragraph? I understand the motivation behind discouraging people from suing you, but putting "you will not sue us for patent infringement" into a software license is a bit weird.
Are you nitpicking legal semantics (including something in one agreement or another), or saying it's possible to legally use React-Native while suing Facebook for completely unrelated patent infringement?
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.
OK, so I can legally use React-Native in my app while suing Facebook for unrelated patent infringement. I also can claim the patent they are suing me for infringing is invalid while continuing to use React-Native.
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.
It says if you get into a patent disagreement with their company you can no longer use react, whether they sue you, or you sue them. I'm not planning on suing facebook, but if they sue me, suddenly I have 2 problems, the lawsuit, and not being able to use react anymore.
It should only regard to react. If the clause is to protect their right to develop react, it should only pertain to such.
Not quite - there's an implied patent license that comes with licenses that mention nothing about patents, because otherwise nobody could use the code. Once the license explicitly gives a patent grant, it replaces that implied patent license. Think of it like C++ default constructors.
I guess lawyers like run-on sentences. That second paragraph is one sentence, and is one of the longest I have seen. I guess the more complicated a sentence is composed, the more opportunity for legal interpretation.
If all companies issued code under these terms, and they all used each others' code, it would certainly make patent lawsuits impossible between them.
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.
> it would certainly make patent lawsuits impossible between them
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.
I get that Apache and GPL are well-established (perhaps not GPL3 yet though?), and that encourages stability to use them.
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.
The reason is not just that Apache is well established, it's that it's sane in its extent.
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.
Well, potentially, if Angular 2.x adopts the virtual DOM like React , Angular directives could be used in native Apps,just like React Native. There is no reason why it can be done.Any framework that isn't tightly coupled with the DOM can be "ported" to plateforms outside the browser.
Remember this day, because React Native is going to be a game changer (patent clause stuff aside). Others like Phone Gap tried to make it so you could build native apps using HTML/Javascript but they failed because they focused on running said HTML/Javascript within a performance limited WebView and not the other way around.
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.
I think there's a lot of proof that it does work, given there's 300,000 Ionic apps, tons in production.
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".
Yeah I'm sorry, but web views are incredibly substandard to native apps. I've never found I hybrid app that I found comparable to its native counterpart. Simple things like scrolling can be very spotty most of the time.
>> Simple things like scrolling can be very spotty most of the time.
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.
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).
I don't even see a button class in React Native... but if there was one and it was custom-made from UIViews, it's going to look and act differently than a native button. Turn on accessibility features -- does the button's title get read aloud? If you turn on button highlighting, does the button get an outline? If you turn on bold text or large text, does the text of the button change?
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.
Absolutely. My primary concern is with the controls feeling native. Reimplementing controls with UIViews doesn't seem much better than reimplementing them with HTML/CSS (save for performance). There's still surface area to break the illusion.
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.
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".
It may be a "native control" but if you reimplement UIBUtton and have to recreate what Apple did to create it in the first place, that's where things tend to fall apart.
If you write JSX. What would be the benefit of using html anymore? Your own components can be the same on web or native. The base components might be a bit different but that isn't difficult to learn.
One of the big pieces in React Native was reimplementing flexbox positioning (they did it using randomly generated test cases in a TDD-based process; described in the "diving deeper" video iirc). So as long as you use flexbox to position your html, it should be pretty portable to react native.
With React Native, instead of writing HTML/CSS and running it on a crappy browser embedded in an app, you write code that looks like HTML/CSS (it's actually JSX)[1][2] and it is translated to native code.
It's not translated. The JS runs to create a declarative description of what the ui should look like, which is reduced to a diff representing the changes that needs to be made to the native ui. These change commands are then marshalled to native code which simply implements the changes (add this thing, move this thing, remove this thing).
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.
Thanks for remembering and mentioning us. We don't have as huge a marketing budget as the other folks, so I'm going to shamelessly piggy back on your comment here.
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.
In the case of React Native, we don't actually compile a JS runtime. We avoid that overhead by using whatever JS environment is available on the platform. In the case of iOS, we use JSC.
My last update (from two weeks ago or so) was that you were going to bundle a JS runtime for Android as there's too much variation in earlier versions. Has that changed?
I would love to see a comparison between some of these different frameworks. HN is abuzz about React Native, but is it really that much different than the others? In particular, do the others attempt to be declarative like React Native? Is the performance comparable?
The main advantage I see is that it's open source and free (with some patent caveats).
For those who like React (especially with the performance gains of React over the major frontend frameworks excepting Angular 2), it is also a huge positive - part of the problem with hybrid apps currently is performance problems. React assists with this greatly, as seen by the performance metrics out there.
>By my count we now have, in no particular order...
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.
Hi, technical question from a long-time iOS developer here, i hope you can put my concerns at ease:
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.
Should someone learning iOS development stick to vanilla iOS while learning, or would it be feasible to use React Native from the outset? I already have some React experience, and I have some React-based web app that I'd like to turn into native iOS app.
If you're learning iOS development, stick to learning iOS development. A framework, no matter how cool and neat it is, will not replace pure iOS development for serious apps.
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?
> do you really think you can call yourself an iOS developer when...
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.
Diving straight into a framework while learning the underlying system in parallel can teach you a lot about best practices and design patterns and so forth. Personally I'd say doing both is a good idea. Just make sure you learn the whys and hows for everything the framework is doing. You can vacuum up all the accumulated knowledge of the framework team.
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.
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.
Sure, that's reasonable. If you already have a site and want to run it with native features quickly, Cordova is an excellent choice. That goes even if your site is already built on React.
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!
> 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?
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?
It's pretty bad. It works well for very basic vanilla example apps that have certain patterns. But for even very small real-world apps, you end up having to call a bunch of stupid imperative methods on viewDidLoad. It's a joke. The patching that you have to do with imperative code is not visible in the interface builder and so you end up with a bunch of empty looking storyboards a lot of the time.
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.
How much code is React Native and how much code is hand written Objective-C ? can you answer that question ? "Use" doesn't mean 100% without a single line of Objective-C written.
Not just the view. React Native also gives you access to HTTP and full JavaScript logic, so the model, view and controllers can be written using React Native.
You should at least take a look at Swift. These frameworks are great when they work , but as soon as they don't ... imagine yourself looking at a stack trace of a language you don't understand and have to debug that shit ... You should at least get familiar with basic IOS , widgets, swift ...
I actually just completed an iOS course. I think that it's good to know how things are done, and there are some things that you'll want to do completely native. (Such as complex graphics). But the iOS interface building tools are utter crap compared the JS/HTML ecosystem. I would say, build a few small apps completely native, just to see what you're not missing out on and be ready to write swift or objc to do really complex or performance critical things.
Stick to vanilla iOS for now. I think it's telling enough that FB doesn't have all of their apps on RN. I don't think there will ever be a real replacement for Native. It's just a matter of how close a framework could get to copying it.
I think it is a better choice to start by getting accustomed with 'pure' iOS development.
It will be easier to learn RN if you think it is useful to your projects with a good understanding of the platform.
DevOps guy here, new to both JS and iOS, forgive the naive questions :
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 ?
Some react-native developers were at last months React London User Group. It's apparently being built there but they are working through some perf issues.
When asked when it will be released they said "You will know when its released, it will be really obvious"
It's taking them a long time since the announcement of the new framework at React conf. They said they would release an Android compatible version soon and still we're waiting for any updates beside the usual cliche.
Sorry for the inconvenience. If you need something to fill the time while waiting for them to deliver your free software, maybe you should try contributing to an open source project.
React Native is the most promising cross-platform UI toolkit I've thus far encountered. Congratulations to the team that built / launched it.
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.
WORA is pretty much a pipe dream, to different are the platforms and UI toolkits. One of the reasons why we heavily focus on enabling the same language(s) on multiple platforms while using the native UI toolkits with RoboVM.
Funnily enough it's a different matter for games, see Unity, UE4, libGDX, Cocos2D-x etc.
I think many people dismiss this recommendation right away nowadays, but here it goes:
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.
I can see the appeal of Adobe Air and its ecosystem. I guess on mobile the only problem is binding to system services & ad providers. IIRC most of that is already covered by 3rd parties, but it's a bit involved to do it yourself.
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.
Hey.. actually I also just got the task to integrate an Ad provider in out game and made a little research. As far as I can see almost all big companies are providing Adobe Air SDKs for integration. For Example:
Yes.. as far as I can tell most of this bindings are covered by native extension of 3rd parties. Not always free (but not that expensive), so u have to buy an extension for a quality FacebookSDK integration for example. Still far cheaper than for example Xamarin.
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.
I've heard the term "write once, test everywhere!" But, since testing is actually a good thing, I think the spirit of the quote is "write once, fix glitches everywhere"
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.
React Native is the most promising cross-platform UI toolkit I've thus far encountered.
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.
Time for the now, almost weekly, shoutout for http://reactiveui.net which is a functional reactive programming framework that uses the Reactive Extensions for .NET to create elegant, testable User Interfaces that run on any mobile or desktop platform.
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 ;-)
> 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.
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.
Great news!
One question: since FB just announced React+Parse, I wonder how's support for Parse in React Native? Or put it a better way, if I want to write an multi-platform app based on Parse, should I consider using React Native? or it's still better to developer separate apps for each platform to get the best of Parse (especially for features like push notification)?
Great! I guess it wouldn't be a problem for common operations like data creation and fetching, since underneath it's all implemented through REST APIs. But what about push notification? Parse's JS library doesn't support it, but its iOS library does support it through platform's push notification mechanism. Does this mean using Parse in React Native, I can't get Push Notification to work on iOS? or I still have to write native iOS apps to get push?
I'm interested in this primarily because I don't find it appealing to invest in (basically non-transferable) iOS platform skills. I want to build native mobile UIs for my projects, but not with a dead-end language and tools.
Does anyone else really want to see a version of Elm that compiles to React Native? Since Javascript is the de facto intermediate language of the 21st century, frameworks like React Native open a lot of doors.
Incredible on iOS. Android support... coming soon!
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.
Having used Facebook's Android app, I would probably count them out right off the bat. That app is complete junk -- it's slow, bloated, glitchy, and so greedy with permissions it makes a mockery of the whole system.
In fairness, the Facebook app is not developed in React Native. I'd be more curious what Facebook Groups and Ads Manager are like on Android (if they even exist), since those are the touted "React Native" apps.
That's an interesting assessment. I've actually been generally impressed with it. Loads fast, seems to be pretty intelligent about caching profile images and the like, and is generally pretty responsive (on a Galaxy S5). It is pretty handsy with the permissions, though.
I think the key to our different experiences is that you're on a pretty high-end phone. The real issues with the app become more apparent the lower-end device you have.
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.
Looking at the name of the UI components, that definitely seems to be true, as a lot of them have "ios" appended to the class name. But, even if you're writing Objective C, you might have different storyboards for the phone vs the iPad. so I don't think it's unreasonable to have different views for the different devices.
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.
I am also wondering how much scope there is for writing generic interfaces that delegate to UI specific components as needed. I haven't done any native mobile development before so I'm not sure how possible this will end up being, but seems plausible.
Is React Native for iOS able to take advantage of JavaScriptCore's JIT compiler on any version of iOS? Or can it only use the interpreter?
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.
Fills the same niche as Cordova/PhoneGap or Xamarin. It's kinda the best of both. Intuitive dev process for web developers not needing to learn new paradigms. Fully native compilation for better performance than WebViews.
Are you sure they compile to native? IIUC they use JavaScriptCore on iOS, which currently doesn't JIT. Probably good enough to drive UI and you can implement performance hungry stuff in native code.
With React Native you write your apps in JavaScript, in a React.js style.
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
Looks like the chrome debugger. I just built a react native app, and for the basic Ajax + list view, it is far easier than the usual drag'n'drop/imperative iOS we are used to.
Someone wrote a GraphQL query parser. https://github.com/madjam002/graphqlite There aren't any GraphQL servers yet though. Pretty hard to write too in a generic useful-for-all manner.
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.
How does this compare to Qt project QtQuick, which supports far more platforms then react native. Both use javascript and both are reactive programming systems...
After figuring out how to deploy to device (see AppDelegate.m), I tested accessibility and it seems there is virtually none. At least in the Movies example app, VoiceOver reads practically nothing.
How would one go about making the Movies sample accessible, or is that even possible?
Yes, that's an ES2015 (formerly known as ES6) feature called destructuring. It's just one of the great features of ES2015. You can use ES6 today by transpiling to ES5 with https://babeljs.io
They've stated in the past that they're focusing on iOS then Android first but that the system could be used on other platforms like Windows/Mac/Linux.
Nothing should stop you from doing it (if you can navigate your way around the codebase). However, we want to make it easy for you to use your favorite tools. Read more about how the packager currently works https://github.com/facebook/react-native/blob/master/package...
With RN, you really only need XCode to build the initial app and the final build for submission - everything in between can be done on any platform that can run the packager with a phone for actual testing. So if you have a friend with a mac, you're good!
Your apps run in JavaScriptCore (like Mobile Safari) on device, but our packager includes a transpiler set up so that you can use most ES6 features already.
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.