Hacker News new | past | comments | ask | show | jobs | submit login
React Native is now open source (github.com)
1039 points by peterhunt on Mar 26, 2015 | hide | past | web | favorite | 287 comments

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

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.

> 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.

(IANAL, TINLA, corrections graciously appreciated.)

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.

That is a big excitement killer

So, basically, if you sue Facebook on grounds of patent/copyright infringement for any reason, you don't get to use their software?

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."

That plus you accept that all of Facebook's patents are valid.

No, it doesn't mean that.

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.

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.

Then why say "whether or not such claim is related to the Software?" That would imply just the opposite to me.

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.)

Well, OK, fair, but for practical purposes it seems like the same thing.

Yes, and the license could easily be construed to imply that your license is immediately revoked if you tweet "Facebook infringes on patents".

but without patents nobody would ever make progress in software and innovation would be stifled

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.


No, in no way does it mean that.

Well thanks for the clarification.

Hope you saw my comment above, which tried to be a bit more clear.

No, but it does say "you agree any kind of claim we make is true".

> 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.

> There isn't actually any license granted after that clause (it occurs before this clause)

"hereunder" does not refer to a direction within the text :)

Yes, it does.

google "define:hereunder" -> "as provided for under the terms of this document."

With sub-qualification:

>further on in a document.

Even your primary definition contains the location clause, 'under the terms'.

> with a sub-qualification

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

It can. But it doesn't necessarily.

Nothing better than ambiguous language in psuedo-legal documents.

> Even just stating your belief that software patents are invalid or unenforceable terminates your license.

I guess that's the interesting part. Sources would be really helpful.

The second link I included in the comment above was to DannyBee's discussion of implicit vs explicit patent grants.

Thanks for the pointer.

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).

I'm pretty sure you're not making any claims in other jurisdictions implicitly — that would be somewhat terrifying.

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.

> (there might be exceptions to this)

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...

Fortunately we germans don't have these kind of problems (yet.)

I'm fairly certain that interpretation is bogus.

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.

The Apache version is:

> 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…

Yes, it strikes me as a fig leaf for something else. I'm not sure what, though.

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.

Yeah, it'll be nice when the license actually reflects this. Until then I wouldn't build my business on it, ever.

Yahoo and Netflix are using React, right? Do you (or anyone) know why they consider the license acceptable, but Google wouldn't?

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.

> Mutually assured destruction

Wouldn't that apply to Google as well?

If you think you can dominate your opponent then MAD is not the most desirable outcome.

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.


I'm interpreting the "this license will revoke" as referring to the additional patent grant, not the BSD license for use of the software.

I wrote about something similar with VP8, which is highly patent-encumbered. Google was like:

1. You have a license to our related patents

2. You're on your own if someone else claims that your use of our stuff infringes their patents

    2a. But if the party suing is also a licensee, they lose their license.
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.


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.

[1] http://arstechnica.com/information-technology/2013/03/google...

[2] http://www.webmproject.org/license/additional/

> 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.

What would you suggest as a solution to this? What should Facebook do?

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.

I've raised this many times before, but you shall not sue us is emphatically not part of the software license. It's a separate grant of patent rights.

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?

The latter.

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.

> It is absolutely possible to legally use React while going ahead and suing Facebook.

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.)

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.

Would it be practically advisable to do so?


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 also means you're no worse off than without a patent grant.

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 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.

Please don't spread fear and uncertainty based on incorrect understanding of licensing.

Suing Facebook does not void your license to use React. It voids your additional patent grant. That's different.

So what does the additional patent grant actually grant?

The guarantee that Facebook won't sue you if they have patents that apply to React.js.

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.

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'm curious too. :)

Well, you can make a pull request editing it. /s

That trick did work on Elon Musk.

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.

This license is great since it reduces the chance of patent litigation in general.

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.

How does that make the industry safer?

Well, let's say that Facebook is using other company's code with a similar patent grant. Then Facebook can't go on the warpath in the first place.

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.

But is there evidence that Facebook is willing to use other companies' code under similar grant?

Are you be able to use BSD licensed code without additional patents grants?

I'm not very familiar with the specific details of software licencing, can someone explain this situation to me?

Thanks for bringing this up. I'm now waiting to hear from our lawyers to know if we should avoid using this.

I'm quite a noob concerning law stuff, can you please provide a little explanation about its patent? Thank you for your attention.

> Full disclosure: I work at Google,

Good for you buddy.

Don't be sad, you will use Angular 2.x when will come out.

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.

If they're serious about open source, they should just Unlicense it.


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".

Webviews have been "getting there" for like 5 years now

They've only existed for 8. We the rest of eternity. I get downvoted but I'm just refuting your unbased claims with facts.

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.

> they focused on running said HTML/Javascript within a performance limited WebView and not the other way around.

Could you explain that? I'm not familiar with phone development and I'm having difficulty figuring out what "the other way around" is.

Phone Gap tried to mimic native Android and iOS UI using HTML, CSS, and JS. React Native uses JS to control 100% native UI.

For some definitions of "100% native UI."

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).

The native uibutton is made of uiviews too

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.

>Reimplementing controls with UIViews

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.

<Carrousel> <Item></Item> <Item></Item> </Carrousel>

On the web you might use a div with overflow:scroll on native a scrollView.

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.

I mean... if you're talking about the entire HTML and CSS spec, then it'd be way, way, way ridiculously slower than just using a WebView.

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.

[1] https://facebook.github.io/react/docs/displaying-data.html

[2] https://facebook.github.io/react/docs/jsx-in-depth.html

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).

Oh, right. Thank you.

Cool to see this. By my count we now have, in no particular order:

- React Native from Facebook (https://github.com/facebook/react-native)

- Appcelerator's Titanium and Alloy Frameworks (http://appcelerator.com)

- Telerik's Native Script (http://telerik.com/nativescript)

- Xamarin (http://xamarin.com)

As I understand it, all three of these frameworks have a JS (or C#) runtime that is compiled along with the app. This JS runtime is what drives the app and uses the native features of each platform (iOS / Android).

I've been building on Appcelerator for the last 4 months on some basic apps, and it works pretty well.

I look forward to trying out some toy apps on the other platforms.

Don't forget http://robovm.com/ (basically java for ios).

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.

Now I feel dirty...

So if I have a common business logic library in Scala, could I build that into both my app and my server side? Write once, run in 2 environments?


It's okay, I think you added to the overall thread : )

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?

Ah- I stand corrected! I spoke with a few Android-focused folks and they set me straight.

On Android, there is no JS execution environment available. We want to avoid the memory and cpu overhead of web views.

So we are basically forced to ship Android with a copy of either JSC or V8.

Cool, thanks for the update. I'm curious to see what the memory footprint of the JS engine is going to be.

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.

There's also Scripting Layer for Android: https://github.com/damonkohler/sl4a

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.

Sounds like you've answered this yourself.

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?

"You don't even have to dive into React (which has its own unique way that I'd call barely JS anymore)."

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.

Yes, the JSX is "weird" to me.

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?

What is it about the "seriousness" of an app that would demand Apple's crappy interface builder?

Haha crappy. Hard to take anything you say seriously if you really believe that.

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.

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...

> for serious apps

Like Facebook's Groups app and Ads Manager app, which both use 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.

Groups is a mix of native code and React Native, but Ads Manager is pure react native. The app is completely written in Javascript.

No, like GarageBand, OmniFocus, Keynote, or hell even iBooks.

React Native is only the view layer. There is a ton more to an app than just the view layer.

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.

I just discovered that. They're using building polyfills to simulate the browser behavior, too. Very cool.

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.

What tools do you use to build interfaces in the JS/HTML ecosystem?

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 ?

Want to get your hands dirty writing iOS apps with React Native? Start here: http://facebook.github.io/react-native/docs/tutorial.html

Looks like it's iOS only right now? Can't see any mention of Android in the docs?

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"

"We are also working on an Android implementation which we will release later"

"Later" could be days or years! I'd love to hear even a very approximate ETA...

I got excited and disappointed. Damn, how long is it going to take?

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.

It's been about a month since the world even knew React Native existed. You consider that a long time?

A month ago:

'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?

HN entitlement never ceases to amaze me

Of course it isn't progress. But nor is a month a particularly long time for progress to occur in.

Right there on the front page: "We are also working on an Android implementation which we will release later."

Oops - thanks! Was too excited and went straight into the docs...

I'm very excited about this, but it's worth highlighting this from the FAQ:

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.

Oops, this was left over from our private beta. Removed now!

Ok now I'm even more excited!

Thanks! :-D

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.

Really exciting stuff!

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:

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 ;)

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.

Their philosophy for react is LOWA - Learn Once, Write Everywhere.

Yeah, I think they are right on the money with that.

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 ;-)

Thank you for turning me on to this, I'm aware of Paul Betts but not this project in particular.

Your welcome, if you want an invite to the Slack room then send me an email.


You're into commercials and marketing hype?

> 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)?

You can `npm install parse` and run it as usual within a React Native app

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?

We built the F8 app with parse, including push notifications

Take a look here: http://facebook.github.io/react-native/docs/pushnotification...

Super! Hopefully React Native + Parse will become my "one ring to rule them all" for app development.

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.

Precisely, every time I go to learn Objective-C/Swift and iOS dev, I feel like I am totally wasting my time.

I would say this is more dead-end than native iOS.

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.

If you can't wait for it, you could use PureScript and fork Thermite [1] to add react-native support :)

[1] https://github.com/paf31/purescript-thermite/

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.

FWIW it won't be cross platform, it will be a separate implementation for Android. The goal is the model, not the write once pipe dream.

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.

True, but if you can write once at least the business logic, is is already a win

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.

Duktape looks quite nice!

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.

Cross-platform, as long as it's iOS? ;)

But why React Native? Reactjs for web makes sense as browsers struggle with DOM manipulation.

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.

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.

Not sure, but it's native UI at least. The demos they showed prior to release were far more responsive than any WebView based solution.

A little typo on the code example on the ListView docs page (https://facebook.github.io/react-native/docs/listview.html#c...):

    new ListViewDataSource
should have been:

    new ListView.DataSource

I'm curious, can somebody talk about the differences between using React Native vs ComponentsKit?

It seems ComponentsKit is a very specific to iOS as opposed to React.


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

What it sounds like is that your data-flow will be react-app-like (flux).

ComponentsKit is Objective-C++ only (no Swift).

I think they've said they are working on a Swift port (at the end of that F8 video talking about it).

Yes. I think it will be worth the time to rethink it for Swift, because Swift is much better suited for this style of programming than Objective-C++.

Please see this image:


I am really confused. Why is this easier - this looks extremely buggy and complex?

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.

well, there goes my weekend


I've been checking my Twitter obsessively today and yesterday for this.

I'vs been obsessively checking too, but for React Relay :(

It's the server-side GraphQL for me :(

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.

Want to use out Relay ahead of the official release? See React Transmit: https://github.com/RickWong/react-transmit

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...

It's personal preference, but I prefer React ATM.

I know what I'm doing this weekend!


2048 - React

I'm the one who wrote that ;) Didn't know it made it into the repo!

Oh! We need an internal integration with HN so we can identify each-other on here :-D

Me too! Got a four-hour car ride to Kentucky. Hopefully I won't be driving.

Can someone point me to the added value by react native? Why so much hype? I just don't see it.

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?

All the SF people, want to meet up casually on this new shinning toy?


Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact