He also makes some of the React examples quite a bit more complicated than they need to be. Declarative UI is very simple!
Here's the same code, using both class and functional styles (whichever you prefer), in a much more succinct style (11 LOC vs 49):
class Root extends Component {
render() {
var isConnected = Math.floor(Math.random() * 10) > 5;
return <ConnectivityIndicatorView isConnected={isConnected} />;
}
}
function ConnectivityIndicatorView(props: {isConnected: boolean}) {
const color = props.isConnected ? 'green' : 'red';
return <View style={{backgroundColor: color, width: 20, height: 20}} />;
}
That's definitely not a fair characterization of this article.
Concerns about roadmap and patent usage show up before any concerns about JS.
Edit: Though I agree, a strangely large amount of the article is dedicated to "Why I just don't like Javascript."
Yes, if you use React you're basically agreeing not to sue Facebook over patents. Except if Facebook was acting in bad faith they'd probably have enough patents you could be found in violation of to ruin you anyway. If your software is non-trivial, it's already violating patents you probably never even heard of.
But the real kicker is that if you're not using React you're probably already using open source software. And in the JS ecosystem that probably means you're using software under MIT, BSD and ISC licenses, which have no patent provisions whatsoever.
Fun fact: AngularJS uses the MIT license and does NOT contain a patent grant whatsoever. If you use AngularJS, Google can sue you over any patents it holds that are relevant to AngularJS -- they don't even have to wait until you sue them first.
Ember? Same thing (MIT license without patent grant).
jQuery? Although it was dual-licensed as MIT/GPL at some point it's now only MIT-licensed and again contains no patent grant.
In other words: unless you have an explicit patent grant, you're at risk of being sued by the owners of whatever patents you happen to be infringing upon. The only difference is that you're entirely reliant upon the goodwill of the patent owners while React explicitly shields you unless you sue Facebook over patents.
As to the roadmap, it's open-source with a vibrant community, if FB steps down, people in the community can fork, step up and continue maintaining... That's the whole reason behind open-source is that you can continue it.
Also, re: your edit.. yeah, far too much... yes JS has oddities, but the null reference issue is present in most OO languages, not to mention a lot of the other issues are well known and/or present in a lot of other languages as well.
Most JS specific oddities can be warned against with linters, and you can use TS/flow if you really want type checking at build.
From the blog post:
> JavaScript’s deficiencies seem to impress everyone except JavaScript developers, for whom the aspects of JavaScript that I outlined above are not awful warts, they’re “quirks” or “gotchas” that you, not your language, have to be on the lookout for.
I think his point is that calling JS "quirky" makes it sound benign, or even cute. However, JS's quirks are actually serious shortcomings compared to other languages.
For native iOS and Android developers React Native has a huge intrinsic appeal, for all the reasons he outlined at the start of the post. It's really tempting. Plus, the enthusiasm and scale of the JS community can sometimes ovrshadow concerns non-JS devs have about the language.
To me the post seems helpful. From my experience React Native will certainly not be all puppies and roses for people coming from Java, Swift or Obj-C.
This is a lot more than "simply a list of things the author doesn't like about JS". The first part of the post in fact is totally orthogonal to JS, and all about React Native as a platform/project.
While I'm at it, I find the graphs towards the end claiming, for example, that using Xamarin (or Appcelerator) is more productive than React Native, or implying Swift is barely shy of perfectly safe to stretch credulity.
Finally, Javascript's "slow" state of development is a feature as well as a weakness, just as Swift's rapid pace of development is both a weakness and a feature. React itself progresses at a breakneck pace.
The reason ES2015 was so huge and so delayed was actually that ES5 was pretty much the lowest common denominator everyone was able to agree on after the proposals for ES4 went up in flames. ES5 is necessarily incremental and ES2015's delay was mostly caused by the repercussions of ES4's failure -- ES4 failed because it valued innovation over backwards compatibility.
I mean TC39 has announced that they will make a new release every year, batching whatever proposals are stable at that point. How can anyone call that particularly "slow" with a straight face?
var weAreConnected = Math.floor(Math.random() * 10) > 5;
if (weAreConnected === true) {
this.setState({
isConnected: true
})
}
else {
this.setState({
isConnected: false
})
}
}
var weAreConnected = Math.floor(Math.random() * 10) > 5;
this.setState({
isConnected: weAreConnected
});
Do I resent the guy who comes by once a year and reminds me chainsaws exist? No I do not.
That said, some of the more recent changes from MS have me interested in .Net again... I've even played around with some of the core/mono onbuild docker containers, which wasn't a bad experience at all.
One of shortcomings of language listed by author is precisely this: shortcomings in language are not fixed by fixing the language but by adding new community-supported library.
function ConnectivityIndicatorView(props: {isConnected: boolean}) {.. props.isConnected ..}
vs function ConnectivityIndicatorView({isConnected}) {.. isConnected.. }?
Same with switch fallthrough, same with error handling, same with half his issues with JS.
There are some legitimate grievances tucked in there, but the author lost me by pretending that his preferences were universal.
I strongly believe statically typed language are objectively superior to dynamically typed ones. Many might say that this is my subjective opinion or just a matter of personal preference, but I absolutely disagree.
[†] (a bit of) my experience explained here: https://news.ycombinator.com/item?id=12594616
I wouldn't even consider dealing with a big JS codebase without either Flow or Typescript now.
TypeScript has a flag that prohibits switch fallthrough, for instance, though that's an easy one to set up a linter to catch.
One reason I prefer NativeScript to React Native; they are embracing TypeScript and Angular vs. React. I find Angular 2 to be more flexible, but that I freely admit is a preference.
While it can be tremendous help, calling it a best practice misses the point.
The funniest/alarming example for me though was immutablility. The documentation exhorts the developer to take care not to make assignments to immutable objects. And there's your immutability: just don't change object and it will be immutable.
if (weAreConnected === true) {
this.setState({
isConnected: true
})
}
else {
this.setState({
isConnected: false
})
}
this.setState({ isConnected: weAreConnected });
var color;
if (this.state.isConnected) {
color = 'green'
}
else {
color = 'red'
}
var color = this.state.isConnected ? 'green' : 'red';I've seen some coding rules/guides that explicitly forbid short form of 'if' statement usage.
Someone with an interesting development development history (maybe C?), with little grasp of the idioms of newer coding styles.
An enterprise developer.
I am a javascript programmer AND an iOS programmer. I work with React to build web apps at work. And lately I have played around with react native, but I felt uneasy jumping ship to use solely react native for the very same reason.
I instead decided to learn Android programming. There's really nothing to lose going that route (after all, you're learning Java, which is arguably the #1 popular language in the world, so even if you end up giving up on Android, you still know Java), compared to spending the same time learning React Native which has very uncertain future (I would trust it much more if it was not from a corporate entity like Facebook)
I would say the patent issue is more FUD than a real issue; he praises Swift but Swift has a very similar patent grant and termination clause. The key difference is that the Swift grant terminates if you end up in a patent dispute with Apple over something related to Swift; the React grant terminates if you end up in any patent dispute with Facebook.
So the whole issue boils down to "what if you get into a patent dispute with Facebook over a patent that doesn't relate to their core web UI tech". Which...I dunno, is that a real concern?
> “nice quantum physics technology you have here, would be a shame if something bad were to happen to your app”
Yeah, okay. But if my core business is making apps, then every patent I might have is likely to be covered by both patent grant termination clauses. So the issue is...?
(Also, the author is conflating the license to use React with the license to use any patents, if any, which cover React. If, as is entirely possible, no Facebook patent covers any React technology, then having the patent grant terminate would not concern you.)
But anyway, this patent issue is just one part of the larger issue, which is uncertainty. When Apple or Android changes the API policy in the future, you'll be struggling to adapt to the new reality with what you have. Sometimes it works, but sometimes it doesn't. Currently it does make sense for some people to build using react native, but if I were you, I would rather learn Android. Really, if you already have iOS experience, a lot of the paradigm is pretty similar and it won't be super difficult to learn.
This "cross platform" concept used to be valuable maybe in 2010 when it wasn't clear what mobile platforms would be dominant (with windows phones, blackberries, and even samsung launching their own developer platforms). But it's 2016 now, and we're pretty sure it's either iOS or Android. All you need is just those two platforms.
Yes!
On one hand, tons of HN commenters claim to be opposed to 1) NPEs going after smaller software concerns 2) giant ecosystem software vendors being the only choice when it comes to mobile/web technologies, but then this amateurish ¯\_(ツ)_/¯ mindset carries the day on easily graspable concepts that directly affect the likelihood of patent infringement.
> But if my core business is making apps, then every patent I might have is likely to be covered by both patent grant termination clauses. So the issue is...?
Given the increasingly broader markets that Facebook, Amazon, et al. want to break into, the issue is for businesses whose core business doesn't relate to apps but that still want to leverage modern software (aka all of them).
Stop brushing off issues you don't understand and calling them FUD.
> Notwithstanding the foregoing, if Facebook or any of its subsidiaries or corporate affiliates files a lawsuit alleging patent infringement against you in the first instance, and you respond by filing a patent infringement counterclaim in that lawsuit against that party that is unrelated to the Software, the license granted hereunder will not terminate under section (i) of this paragraph due to such counterclaim.
When I started my current job, I was talking to our tech director on how ive been using react native a bit. Been meaning to do an internal demo for it. I do find some of the development tools awesome, but really when we already have experienced iOS and android devs in house, why not keep growing in that area instead? React Native could be a way to do some quicker business wins, with clients that need cross platform in a short time frame. But I'm not convinced it's the right solution outside of that.
console.log(a === b) // true
console.log(1/a === 1/b) // false
That's perfect math you mean, of course -Infinity != Infinity, what did you expect?
I think you should rather think harder, learn math possibly, and your 'safety' problems with arrays are not problems at all, it's the opposite for other people
Oh the irony, when stating that 1/0 = infinity. If you'd learn maths yourself, you'd know that 1/0 is undefined.
1/0 is like 1/0⁺ (limit of 1/x in ]0,+∞[ when x->0) == Infinity.
1/-0 is like 1/0⁻ (limit of 1/x in ]-∞,0[ when x->0) == -Infinity.
1/Infinity is 0 ....
0/0 is however an indefinite form, so it's NaN
so the behavior of JS makes sense
And even if 1/0 and 1/-0 returned NaN, they wouldn't be equal to each other too
For instance, nobody uses Objective-C for iOS development any more (see: Swift). And modern Java is a decent language to develop in (with Rx and the like). You can even develop for Android in kotlin, which gives many of the advantages of JavaScript, but with a static type system and deep IDE integration.
I won't argue with you on how good the languages are. It's a matter of opinion, and I'll never change your mind.
Besides, establishing one langauge as better than another was never my point.
I rest my case. There's a place for manual memory management. It's not in application code.
- It works, really well.
- Iteration speed alone has helped us retain at an extremely high DAU/MAU ratio compared to years past.
- Both my apps have near 5 star rating across the board, probably the highest rated in the Sports category since we released, and none of our users notice that it is a RN app, which is really surprising b/c RN on Android is not up to par with iOS.
React-Native is not for every scenario, but I disagree with the author's final conclusion, that "the pros do not outweigh the cons". It's really quite the opposite in our case. The pros (OTA and productivity) heavily outweigh the cons.
Would love to see something better come out, but the recommended alternatives by the author wouldn't make the cut for us.
What scenario isn't it for?
The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates, (ii) against any party if such Patent Assertion arises in whole or in part from any software, technology, product or service of Facebook or any of its subsidiaries or corporate affiliates, or (iii) against any party relating to the Software.
So if the reciprocity clause in Facebook's patent grant is a problem, all recent MIT licensed software out there without a patent grant would also be off limits.
Apparently the free version has usage restrictions? I do consider free w/ Visual Studio Pro license not really free.
EDIT: The licensing pages are confusing but you're right, my mistake.
And TypeScript solves 80% of his complaints. A good linter with ruleset hits most of the remaining 20%.
Cross-platform is the way to go in 2016. It's a waste to write in Swift and Java to cover two platforms.
Titanium has always been a pretty advanced product however ever since Appcelerator introduced it's licensing/arrow stuff, Titanium (and Alloy) uptake seems to have fallen off a cliff.
So I guess that developers familiarity with the language is what makes it so popular (as in often-used) and is also why we suddenly start using it for arbitrary scripting and mobile app development. The obligatory use of JavaScript in web development led to a whole range of developers growing accustomed to it and now, in spite of its limitations, trying to transfer their ideas to other fields of development.
React Native is just a neat way for JavaScript (React) developers to be able to script UIs for mobile OS's without changing their toolset. And I think for that it's perfectly fine. Obviously if you've never been big into JavaScript I can totally see how cannot make much sense of it all and yeah a lot of the things pointed out are perfectly legitimate. Yet I still think the question whether it makes the language unusable for one scenario or the other is very very opinionated.
And unlike some languages used for app programming, an error doesn't have the potential to hand you a segfault.
And that is a good thing why? So you don't realise there was an error and your app runs on in a corrupted state?
He also rants about using the best language that catches the most errors but then picks Swift as his solution. I have a feeling there's lots of other devs that would not rank Swift at the top of languages that catch the most errors and therefore the author is being hypocritical in ranting that you should always use the best since they're arguably not using the best.
The article did make some other interesting points
That is because he is weighing solutions for developing native apps on Apple devices, where Swift is one of the best options.
I am so sad right now
Hey, RMS, Abelson, Sussman, Steele, Guido, Larry, Matz, Richard Gabriel, ESR, DHH, Flatt, and Felleisen, it turns out you're not true programmers! Okay, cool.
Needless to say, I claim No True Scottsman.
1. RN releases a new version every 2 weeks breaking my app every time. NS is a lot more conservative between releases.
2. I don't like mixing presentation and logic, RN encourages doing so, NS does not.
3. TypeScript is a first-class citizen in the NS environment, it is not in RN.
4. Angular 2 > React
5. NS created a smaller executable with better performance than RN for my test app.
6. I couldn't get RN to work with one of my older devices (KitKat), and even though dozens of developers had already reported the issue, they don't care. NS worked in the same device just fine.
7. All the tooling around the RN ecosystem is very confusing.
The exact same thing could happen to the React community. I'd say stick to true open source projects and descentralized communities.
Besides React is not a platform like Parse was and it should not impact the community to the same degree even if Facebook pulls out.
However, if the error occurs inconsistently, this approach can be much harder to use.
The problem I think the OP is talking about is when there is an error thrown somewhere in the react library code (e.g. in renderComponent) and the stack trace doesn't even touch any of your code. That makes it really hard to find the fault behind the error.
This is a lot more common with libraries like RxJS, but I've seen it with React as well.
The only way I know of to deal with these situations is to put console.log calls everywhere in my code until I've narrowed down the source of the bug.
This man, my friend, is an idiot.
[0] https://github.com/arthur-xavier/purescript-react-native
It's an ML-like language with built in functional reactive framework similar to React, but built to work naturally with the language rather than requiring the FFI binding you'd need if you use Purescript.
Also, you still need FFI in Elm. elm-lang/virtual-dom is basically just a wrapper around the native virtual-dom library. Also, afaik there's nothing like react native for virtual-dom.
He briefly mentions hot reloading and declarative UI at the start, but it's drowned out by his ranting on JS and doesn't seem to earn it any points in the end. But those two are huge boons for UI development, to the point where it's worth putting up with JS's flaws as a language. Flexbox and media queries make CSS pretty decent for layouts. Dynamic languages are a double-edged sword - for UI you often want something up and running and useable to see if it actually feels right, without worrying about interfaces and types too much. Objective-C and Java can feel clunky in comparison.
Are you really trying to say that React Native makes Java not relevant for Android and ObjectiveC/Swift not relevant on iOS. Maybe you are correct if you want to build Hello World application, when you will be needing something more optimized sooner or later you'll have to rewrite it in Java/Swift.
> Perhaps more importantly, your software development platforms also shape you as a software engineer. A software development platform encourages (or forces) the use of one language over another, prioritises certain architectures over others, requires using specific tools and workflows, and marries you to an entire ecosystem and its developer community.
People talk about the "right tool for the job" and "good developers are polyglots." This is true to an extent, but there are still communities with different priorities, and they often form around languages and tools.
Likewise, there's not a single JavaScript community, but there's a bunch of communities around specific tools and frameworks. As you'd expect.
But I, when interviewing, expect good developers to be capable of learning new paradigms - the fact that they know nothing but node.js and node.js's ways is irrelevant, if they are capable of learning.
The author has very low expectations compared to me. And I don't feel I've been proven wrong yet by any of the hires I said yes to.
Obviously the conclusion that follows is that I think React Native is going to be a revolution for mobile development. Not only will it succeed, it will get copied, and you'll have many variants of the same like-minded platform (open source, developer-oriented, low-barrier language).
Regarding the article, my point of view is that some points in this article are valid, but are trivially obvious:
- Javascript is Javascript, take it or leave it. Flow and Typescript is an evolution that to me looks good. It is one language that was adopted to be user-facing in React Native. According to Apple's Developer terms 3.3.2 and 3.3.3 only interpreted languages that run on JavascriptCore are allowed to be pushed to market.
- You can't know what the future holds. I was part of the Ruby community at the start, then Node, then Go. I was hard core into .NET, and before that Java. I saw platforms and technologies rise and fall, and was surprised over and over. I was much into Silverlight, a technology that Microsoft wanted to take over native development on the Web. Guess what happened to Silverlight? THAT was very nasty. We all know how that feels, but that's nothing to attribute just to React Native.
- Regarding patents: I believe we will have alternatives to React Native long-term, with the same properties but we'll still choose React Native :). However I also believe Facebook doesn't use patents in a bad way that the author hints at, as far as we know and as far as we've seen. I also met with core React Native developers, and they're awesome.
Practical advise: I'd suggest for the author to meet with the React Native core team.
Where can I find them?
What are some examples of good apps currently in the store, written in React Native?
return {{a: 4}}
Isn't valid anyways. ESLint easily flags it as an error.
But I think TypeScript should also be considered a best practice, and between the two that would solve pretty much all of his complaints.
Well, that and using "==" to compare to null, vs. "===" to compare to everything else. But the linters all can make that distinction as well.
But he explicitly hates on linters in the article as well. And dismisses TypeScript and Flow ... because his coworkers aren't being forced to use it? THAT is the real problem, I think...
Yeah, Android is growing, but iOS still has substantial market share. Switching to React Native will definitely not give a > 100x increase in outreach.
You're right about the last part, though. You won't literally get a 100x increase in reach from just switching to React Native. Being able to develop on two platforms at once might help a little bit there, though, which is what I think the author was trying to say.
https://www.facebook.com/groups/reactnativeoss/permalink/159...
I am not a React Native developer, but I am a React Web developer (not by choice). The author summed up my feelings about React and JS in general so eloquently. The Swamp Castle and Freedom from Digging bits were so on point.
I am betting that my comment will get buried in the bottom of the comment avalanche, but if the author is reading, thank you for making my day!
However, there are also some pretty excellent benefits that come with all the Bad of React Native and JS so for the moment, it can be very much worth the trade offs. I've been working with it for over a year, and for now I'll be sticking with it.
No, you just forgot to put `this` in front of `width` and `height`. (Arguments do default to `undefined`, though.)
"The fact that millions of drivers productively drive cars without wearing a seatbelt isn’t a good argument for cars with no seat belt. Similarly, the fact that millions of JavaScript developers productively use an inherently unsafe language isn’t a good argument for the use of unsafe languages."
If you're going to RN, go Pure Native at the same damn time ;) It's awfully ironic since they market RN to rid us of the need for Pure Native. Or, is it ironic? It seems this clause and their marketing efforts are truly shield and sword. I'm not really surprised; it's a very cunning way to hijack ideas from other people.
I have used RN, though, and it's a blast to develop with it. Thankfully, none of my kooky ideas are going to be important enough for this fine print to apply to me.
Javascript is like democracy. It works best when:
- lots of people participate
- we understand its warts
- it's allowed to evolve
- the powerful aren't allowed to write the rules
I will be very happy to see an app in React Native, just to check if it is as responsive as Objective C or Swift.
If you just want something easily replaceable, use something like cordova.
If you want perfectly native and guaranteed support, use the native SDKs.
If you want simplicity with a javascript framework that compiles to native with the concerns of it being made by facebook then use react native.
React native solves a lot of peoples problems especially if they are starting an app from scratch.
> Compared to React Native, both Xamarin and Appcelerator have better prospects at longevity. Appcelerator (the maker of Titanium) (runs on apps installed on 350 million devices) was acquired in January 2016
Last time I tried (circa 2013) Appcelerator seemed a bit unpolished and the tooling was sub-par (I vaguely remember of some hacks needed to get their custom IDE runnning on Windows), I would like to know how are they doing now. Could anyone familiar with it summarise their recent developments?
In big companies app releases are a huge problem when 100+ committers and tens of features are released to the same app sometimes within the same app update. React Native has the potential to enable feature teams independently update the app.
Maybe I'm misinterpreting this, but is the author actually advocating for Java-style checked exceptions? I can't even remember the last time I heard somebody say something positive about them (other than just now, possibly).
Similarly, Flow/Purescript/Elm have every ability to provide a safe interface to javascript.
Is this really true? Or is the author referring to the dev. edit/view loop?
1. uncertain roadmap
It's open-source, and given the amount of contribution and efforts to get third party targets for windows, ubuntu and mac I seriously doubt it's going anywhere any time soon.
If you look at React proper, it's not much different, and that has gone incredibly well... React has some of the best diagnostic information in terms of error/warning states of any web ui tooling I've used.
2. Patent grant
The reason for the separate patent grant is because a copyright license, particularly a permissive one like BSD (or MIT, ISC, etc) do not specify patented parts of the application. MS-PL iirc was basically an MIT-like license with a patent grant (with nuclear deterrent) attached.
Most large companies that are publishing larger open-source tools have similar clauses to their patent grants. That said, I'm against software patents as a rule, so this concerns me very little.
Hell, Apple's swift license has a similar provision...
... 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.
I won't argue the merits of JS over other languages... I will say that I've enjoyed working with it, it's my favorite language, warts and all, and that you can write horrible code in any language.
There's TS, flow, eslint and many other tools to help with issues there.
The cartoon illustration predates npm, es6 and a lot of other work towards making things a lot better. Also, you've already invested into React*, then you may as well invest in babel/es7+, redux and a handful of other options that do add a direction.
3. Dependencies
That's the nature of large software projects... also, with node ecosystem, it means that React doesn't have to re-create a lot of work that has already been done.
4. Alternatives
As to Xamarin and Appcelerator, what about web and desktop targets? You will have to re-create a large amount of your codebase, and even non-ui bits in order to support them.
SUMMARY:
In general, I understand your arguments... but you're missing one... You can use a single unifying platform and language for all of your front end and back-end code while being able to target pretty much every platform in wide use with minimal changes.
The JS/npm ecosystem is one of the most vibrant in developer history, while a mixed blessing sometimes, it does work incredibly well.
So, question for people who use React Native - how long does it take to go from [100% front end developer familiar with React] ...to [writing solid native apps] with React Native? And how much platform-specific knowledge outside of RN do you need to absorb in order to do this well?