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.
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.
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"
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
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?
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 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.
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.
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.
> 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.
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.)
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.
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."
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.
(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 infringem...
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.
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.
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…
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.
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.
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.
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.
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 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.
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.
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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:
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 ;-)
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.
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?
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
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?
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.
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.
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.
> 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.
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!
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.
> 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?
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.
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.
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 ...
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.
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...
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...
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.
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.
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.
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.
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.
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.
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 ?
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.
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.
297 comments
[ 1.9 ms ] story [ 271 ms ] threadI'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.
'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"
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.
https://news.ycombinator.com/item?id=9113515
> 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 infringem...
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.
http://unlicense.org/
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
3. You lose your license if you come after us for anything.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...
[2] http://www.webmproject.org/license/additional/
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.
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 ;-)
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
https://github.com/facebook/react-native/tree/master/Example...
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...
Take a look here: http://facebook.github.io/react-native/docs/pushnotification...
It seems ComponentsKit is a very specific to iOS as opposed to React.
https://github.com/facebook/componentkit
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://www.meetup.com/SF-React-Native-Meetup/
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?
https://babeljs.io/
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.
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 ?
[1] https://github.com/paf31/purescript-thermite/
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.