20 ms·

Why I'm Not a React Native Developer

362 points by nootopian 10y ago

rco8786 10y ago
You could have just said "I don't like Javascript" and ended the post there.
- atoko 10y ago
  I feel like this is some sort of signaling, a la 'no true programmer uses javascript, because types!'.
  - matwood 10y ago
    We all use it, but 'no true programmer likes javascript.' :)
    - joshuahutt 10y ago
      I must not be a true programmer, then. :/
    - sotojuan 10y ago
      I know plenty of intelligent and accomplished programmers who use and like JavaScript. I like poking fun at it every now and then, but come on.
    - ovao 10y ago
      I quite like JavaScript for relatively light scripting tasks. In that role, I find it pretty well-suited. For complex applications I'm as leery of it as anyone else.
    - matwood 10y ago
      Since apparently people are missing my ':)' above, they are missing that I replied to what I thought was a joke with another joke. So just to be clear, it was a joke. Sigh.
  - jakebasile 10y ago
    I used to half joke like this, but recently I've been doing some React work in ES6 with Flowtype annotations. It's actually not that bad.
    - jnbiche 10y ago
      Exactly. Flow even has tagged unions now, and `maybe` types. TypeScript is also a very mature solution to this problem. A true professional works with whatever language he needs to solve his/her problem, and shores up that language with the best tools available. In this case, I half agree, because I think mobile development is best done using native platforms. But if you're doing web development, JavaScript is a must. And React is an elegant way to handle browser UI (Flow/Redux is also quite nice way to handle browser state, if a bit verbose). I do share his concerns about the patent clause, and about Facebook's long-term commitment to the project, but at the level of personal projects, these concerns have not been enough to scare me away.
      - st3v3r 10y ago
        "A true professional works with whatever language he needs to solve his/her problem, and shores up that language with the best tools available." Right. And JavaScript is not that language, unless you are doing web stuff.
        jnbiche 10y ago
        > Right. And JavaScript is not that language, unless you are doing web stuff. Do I hear an echo in here? "I think mobile development is best done using native platforms. But if you're doing web development, JavaScript is a must."
      - bbcbasic 10y ago
        A true Scotsman comment nested in another true Scotsman comment. It's haggis all the way down!
  - qwertyuiop924 10y ago
    Well then, if no true programmer likes dynamically typed languages, I'd better make some calls... 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.
    - mkawia 10y ago
      I see it like; smart,disciplined programmers are capable of writing complex programs in dynamically typed languages without making as many errors.
    - wtbob 10y ago
      Lisp, though, does have types.
      - qwertyuiop924 10y ago
        All languages have types. Lisp, however, and particularly the versions that those people worked with, are dynamically typed, like Javascript. Unlike JS, they aren't weakly typed, but that's not the point. To say nothing of Ruby and Python, for which there are also programmers on that list.
        wtbob 10y ago
        Common Lisp compilers may implement static typing. The default type is T, though — but with declarations, a compiler can enforce anything the programmer declares or it infers.
        qwertyuiop924 10y ago
        Most of those people either worked with MACLisp, or dynamically typed Scheme.
tmorton 10y ago
Aside from the discussion of JS and React Native, I want to highlight this: > 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.
- mtrn 10y ago
  Raymond Hettinger highlighted the community aspect for languages very well in this keynote: https://www.youtube.com/watch?v=b_pTxGu2L04&feature=youtu.be&t=6m46s https://www.youtube.com/watch?v=b_pTxGu2L04&feature=youtu.be... - he of course talks about Python, but the principles apply to any language or ecosystem.
- EdwardDiego 10y ago
  Hmm, communities become less important as languages become more widely used. When was the last time you referred to the Java community, singular? 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.
revicon 10y ago
tldr; Author doesn't like writing in javascript and fears that Facebook may some day decide to stop supporting React Native.
- sn0v 10y ago
  It'd be nice to have a TL;DR bot on HN, at least for the more clickbait-titled articles (not saying this is one).
- ChrisLTD 10y ago
  Ariel also doesn't like this clause in the React license: 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.
  - hackerboos 10y ago
    That's in all of the React licenses.
    - ChrisLTD 10y ago
      Thanks, I updated my original comment.
  - sebastianconcpt 10y ago
    That alone makes it a non-starter
    - Lazare 10y ago
      Why? (Honest question.)
__derek__ 10y ago
This is a good post up until the rehash of JavaScript's sins.
- leonatan 10y ago
  It picks up later on. I too had issues with some of the JS stuff, but it's worth continuing reading. Also worth to take a look at the references.
RussianCow 10y ago
Is anyone using TypeScript with React Native? I'd be interested to see how easy that is to integrate.
- pier25 10y ago
  In that case it would probably make more sense to just use NativeScript instead of React Native. https://www.nativescript.org/ https://www.nativescript.org/
  - cornflake 10y ago
    NativeScript looks really promising. My colleagues have used it for numerous client apps. It's not as mature as Appcelerator Titanium so it doesn't have as many plugins for advanced things like video recording or audio playback but if it continues to get traction, it could become a really good option.
  - RussianCow 10y ago
    NativeScript doesn't have tight integration with React, and I don't really want to build that layer myself.
    - SomeCallMeTim 10y ago
      Angular 2 is pretty awesome and faster than React.
      - gareim 10y ago
        Source on that speed claim, please.
        SomeCallMeTim 10y ago
        I can't find the benchmarks that I'd based my comments on to be honest, and I have to get back to work. :| From what I remember, the final version of Angular 2 added a lot of performance, which pushed it ahead of the latest React in performance. I did find this: http://webscripts.softpedia.com/blog/recent-benchmark-shows-the-speed-of-angularjs-2-499638.shtml http://webscripts.softpedia.com/blog/recent-benchmark-shows-... But the Auth0 benchmarks disagree and show React is faster: https://auth0.com/blog/more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/ https://auth0.com/blog/more-benchmarks-virtual-dom-vs-angula... Angular 1 is terrible performance-wise; that much is certain.
dahdum 10y ago
Unless I'm wrong, the only listed alternatives are both paid and closed source. Xamarin (requires VS Pro) or Appcelerate (requires $480-$1200/year/developer).
- matwood 10y ago
  I believe Xamarin is now free post the MS acquisition with various parts and pieces even becoming open source: https://blog.xamarin.com/xamarin-for-all/ https://blog.xamarin.com/xamarin-for-all/
  - dahdum 10y ago
    I was actually looking here: https://store.xamarin.com/ https://store.xamarin.com/ 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.
    - romanovcode 10y ago
      No, it's completely free with VS Community (which is also free). And you don't have to pay if your company has 5 or less people working on it. You also have to pay if you have 250+ computers/people employed or your revenue is 1m+/year. Sounds pretty reasonable to me.
- cornflake 10y ago
  Most of the Appcelerator community i'm in touch with use the free Titanium builds instead of paying for an Appcelerator license: http://builds.appcelerator.com.s3.amazonaws.com/index.html#master http://builds.appcelerator.com.s3.amazonaws.com/index.html#m... 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.
- SomeCallMeTim 10y ago
  Others have mentioned Xamarin is free and (mostly? entirely?) open source now. See also NativeScript [1]. 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. [1] http://nativescript.com/ http://nativescript.com/
wmil 10y ago
This is a nit pick, but isn't his "Ambiguous curly braces" example actually breaking due to automatic semicolon insertion? return {{a: 4}} Isn't valid anyways. ESLint easily flags it as an error.
- SomeCallMeTim 10y ago
  Exactly: Linting rules requiring semicolons should be considered a best practice. 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...
  - wmil 10y ago
    For anyone else reading this in the future, I should mention that the ESLint 'no-unreachable' rule will catch this even if you don't require semicolons.
    - SomeCallMeTim 10y ago
      Good point! Didn't say this explicitly, but TypeScript will, by default, prohibit unreachable code as well. [1] [1] "allowUnreachableCode" defaults to false: https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...
joshkpeterson 10y ago
Author says the bad outweigh the good, but we haven't fully evaluated the good. 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?
STRML 10y ago
This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint. 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}} />; } The point is, much like many things in software, it's all about perceptions and familiarity. He's not familiar with JS, and I don't fault him for that - it's a quirky language. But for the many, many developers who have built up a tolerance to JS and built/use tools to tame it, moving to React Native is a breath of fresh air vs learning Android & iOS toolchains and idiosyncrasies.
- jontro 10y ago
  The point of having isConnected in the state is that it will change depending on OS events. Random is just used as an example
  - atoko 10y ago
    Even with state, his code is overly verbose and can be expressed in a much more idiomatic way. var weAreConnected = Math.floor(Math.random() * 10) > 5; if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } } turns into var weAreConnected = Math.floor(Math.random() * 10) > 5; this.setState({ isConnected: weAreConnected }); It's almost like he wrote it in the most obtuse way possible to prove his point. Unless he writes like that normally; If so then I can see where he's getting all these errors from.
    - jontro 10y ago
      Absolutely, especially since he/she wrote it that way in the swift version let weAreConnected: Bool = arc4random()%10 > 4 self.isConnected = weAreConnected
joshwcomeau 10y ago
Ughhh. It's fine if you prefer statically-typed languages to dynamically-typed ones, but that's a preference, not a reason to try and say that JS is objectively terrible. 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.
- steego 10y ago
  I prefer statically-typed languages too, but this is easily solved by using something TypeScript or Flow.
  - pzh 10y ago
    Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift. JS has its uses, but it's difficult to debug, doesn't take advantage of all the advances in modern languages design that help prevent whole classes of bugs, and carries a lot of baggage. The only benefit would be universal app development, but even then Xamarin seems like a better choice.
    - DenisM 10y ago
      Speaking of Xamarin. RN supports iOS, Windows, and Android. Plus RN is somewhat close to React, so some code could be reused between the two. Plus you get out-of-band code updates! Xamarin supports iOS, Windows, and Android. But there is no web story. Or is there?
    - steego 10y ago
      > Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift. The JavaScript toolchain is more than good enough to build the kinds of applications that React Native targets. Most of these applications aren't stellar apps that require critical performance or rigorous type checking, they're just dumb front-ends to REST endpoints. If you're going to build an awesome app, then use better tools. The reason I would use React over Xamarin is simple: Speed of training and development. I can hire, train and get a React developer up and running and building proof-of-concepts a lot quicker than on Xamarin.
swsieber 10y ago
After reading this and other comments here, I sort of just wish there were Haxe bindings for to the React Native stuff.
- gagege 10y ago
  That would be cool. What I really want for Christmas this year is React Native but with Elm instead of JS!
elcct 10y ago
JavaScript has its share of bad things but that's mostly solved by good tooling. I think Java or ObjectiveC feel too "heavy" for UI development. React makes it simple and even with its downsides in my opinion it makes other technologies no longer relevant in this domain .
- barryhoodlum 10y ago
  I agree, UI development is a different beast. 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.
- romanovcode 10y ago
  >it makes other technologies no longer relevant in this domain 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.
  - elcct 10y ago
    Do you have any specific example where Java or ObjectiveC/Swift would be of better use?
    - romanovcode 10y ago
      Anything that requires some kind of processing like, for example facebooks own Instagram.
      - 10y ago
cocktailpeanuts 10y ago
A lot of people here seem to criticize the OP's POV on javascript, but my biggest takeaway was the more abstract parts of his post, such as patents and uncertain roadmap. These are very REAL problems. 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)
- Lazare 10y ago
  > my biggest takeaway was the more abstract parts of his post, such as patents and uncertain roadmap. These are very REAL problems. 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.)
  - cocktailpeanuts 10y ago
    My point was not about the details, but about the uncertain nature of an open source project driven by a company. The patent issue is just one of the "symptoms" of this problem. When someone open sources their technology and adds a set of detailed clauses that adds some restriction (doesn't matter if it's a "real" restriction or not), it means they couldn't go all out. It also means as a user, you do have reasons to be cautious about it, not because of what the license says in detail, but because of the reason behind the behavior. 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.
pacomerh 10y ago
The alternatives mentioned here are not really of the same type. A better example of an alternative would be something like https://www.nativescript.org/ https://www.nativescript.org/
doozy 10y ago
I evaluated React Native for a project and decided to go with NativeScript instead for a number of reasons: 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.
- msie 10y ago
  Another vote for 7): I tried a little project in React Native and was intimidated by all the tooling and build steps needed to get my project running on iOS. To be good with React Native you will have to be proficient with all the tooling and all that seems to be a shaky foundation. There are lots of parts that can be updated and can break your project (I say in a vague way).
- hesarenu 10y ago
  I have been using RN from 0.19 onwards never broke my app a single time. React encourages thinking in components and component would be tightly coupled. I have many kitkat users on my beta app on playstore. For me reactjs is way simpler. Angualr seems like a jee framework.
- cm2187 10y ago
  On the tooling I presume it is impossible to get help with the html markup, since it is commingled with code? Like there is no way to start writing html in your js function and for the IDE to autocomplete a class name based on the CSS it knows will be loaded on a page. This is sort of coding in notepad. Or are there tools that see through the js and understand how the whole page will fit together?
- solidr53 10y ago
  Wow, hold on guys. This enterprise dude thinks all the tooling around the RN ecosystem is very confusing. Angular 2 must be better then.
chukye 10y ago
The most part of cons is criticising JavaScript and NOT React Native. I know how JS works, and I LOVE IT. The only part of the post that I liked is when he talks about the license, all the rest is just bullshit from a person who don't like JS.
- pekk 10y ago
  It's not bullshit if it's a valid consideration when you are trying to build an app on say iOS and weighting it against say Swift. How many times does this need to be said? It depends on what you are trying to do and what you want.
  - chukye 10y ago
    Ok, this is a good point. But, the author just point out the quirks of JS language, and not things about the RN itself. Would be more fair if he pointed out the quirks in python or had focused on the RN. All he says about JS is very well known and is there since 90s. Also, he is saying that its not safe because he can't understand and workaround with the pitfalls, JS has a lot of problems, but also has a LOT of great solutions for them, and by that this not means that the language is not safe, just means that its harder to work with.
  - solidr53 10y ago
    "What if you forget to put break in-between your cases in a switch statement. They will leak." This man, my friend, is an idiot.
enturn 10y ago
It would be good to have when the article was written/updated on the page. I found Sep 22, 2016 in the changelog (link at the bottom) for first commit.
draw_down 10y ago
I think it's a really nice way to make an app :)
sebastianconcpt 10y ago
React "componentization" is nice. For me there are two things that makes it a non-starter: 1. That legal clause mentioned in the article and 2. The complexity of learning this platform is the same as learning the native without the same benefits on the control over the hardware (actually with added complexity potential lack of control)
kschiffer 10y ago
I believe in the end it all boils down to the fact that JavaScript is a language that wasn't made for the needs of modern day (web) applications, but since it is still a standard, we need to force it into a form where we can have best control over its shortcomings. That's why things like Typescript, Flow and React exist in the first place. I know this article is about mobile app development, but I think JavaScript would not have the sort of widespread use today if it wasn't for the fact that we use it for website scripting. 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.
- qwertyuiop924 10y ago
  Besides, while JS's problems are very real, they're quite exaggerated. It's still a perfectly usable language, even without TS and whatnot. And unlike some languages used for app programming, an error doesn't have the potential to hand you a segfault.
  - tempodox 10y ago
    > ...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?
    - qwertyuiop924 10y ago
      If you segfault, that's not because your state is corrupt. Not usually, anyways. Typically, you'll segfault from a use-after-free error or similar.
deleted 10y ago
[deleted]
gorkemyurt 10y ago
Ability to update your app over the wire with React Native is a massive advantage overlooked in the article. (via Codepush or something similar) 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.
qwertyuiop924 10y ago
The legal concerns are legitimate, but frankly, I am unconvinced by the criticisms of JavaScript: There are well-known, well-designed tools like ESLint, and if you like types, Flow and TypeScript, which can mitigate the issues. That's more than you can say about Java (COBOL 2.0, now with a bevy of cargo-cult OO that makes things more overly complex), or Objective-C (All the safety of C, with similar OO problems, and a weird syntax that very few people like, and of course, no GC).
- readymade 10y ago
  Some of us happen to think that no GC is a good thing, in Obj-C's case. Swift eschews it as well.
  - qwertyuiop924 10y ago
    Manual memory management: It's all fun and games until OOM errors come knocking, or- Segmentation Fault: Core Dumped. I rest my case. There's a place for manual memory management. It's not in application code.
    - pzh 10y ago
      Not necessarily. Swift uses ARC by default, and you'd really have to go out of your way to do any manual memory management.
      - qwertyuiop924 10y ago
        Ah. I originally talking about Objective-C, so I assumed that we were talking about manual memory management. Of course, ARC has its own problems... Hope anybody implementing graphs knows what they're doing, or you'll leak memory like Niagra Falls.
        readymade 10y ago
        Objective-C also uses ARC by default, and that's been the case for several years now. In any event, avoiding retain cycles is relatively straightforward and most iOS devs I know would agree that the low memory overhead and lack of GC pauses are worth the occasional extra effort of weak references.
Legogris 10y ago
Maybe nitpicking, but the author states that "Your codebase can now create an app that can run on millions of additional devices, and you’ve increased your outreach by several orders of magnitude." Yeah, Android is growing, but iOS still has substantial market share. Switching to React Native will definitely not give a > 100x increase in outreach.
- striking 10y ago
  The Android market share is >60% and rising, though. Not sure what you're talking about. https://bgr.com/2016/06/02/apples-mobile-market-share-sees-big-drop-in-may-as-android-skyrockets/ https://bgr.com/2016/06/02/apples-mobile-market-share-sees-b... 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.
  - Legogris 10y ago
    The nitpick being that usually, one order of magnitude = 10x, two orders of magnitude = 100x, and so on. So it's a very exaggerated statement if taken at face value.
weixiyen 10y ago
Reasons why I am a React-Native developer: - 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.
- macspoofing 10y ago
  >React-Native is not for every scenario What scenario isn't it for?
  - vmasto 10y ago
    Dare I say games? I honestly can't think of anything else.
    - justinlardinois 10y ago
      Definitely. Unless you have an extremely simple game, you're probably not even using the OS's built in UI framework; something like Android NDK[0] and whatever its iOS equivalent is are more suitable. [0] https://developer.android.com/ndk/index.html https://developer.android.com/ndk/index.html
  - ziziyO 10y ago
    Anything where you need to stay alive in the background and periodically do something.
    - Axsuul 10y ago
      So like a messaging app?
bikamonki 10y ago
Could FB plug the cord on React once it does no longer align with its core strategy? Sure, it did it with parse.com without the least concern for the community of users/clients. The apology was to leave behind a half-cooked open source version of parse server. The exact same thing could happen to the React community. I'd say stick to true open source projects and descentralized communities.
- mbrock 10y ago
  What's not true about the open source of React?
  - UweSchmidt 10y ago
    Developed by a company, if they stop it's still open source but who will maintain it? Linux is "truer" open source since it's all volunteers from day 1.
- hanspeter 10y ago
  If they use React to develop their own apps doesn't give some assurance that they're going to stick? 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.
- JMCQ87 10y ago
  Yupp, there's enough precedent with Parse alone.
jbhatab 10y ago
Article feels clickbaity with some points that have been addressed and discussed thoroughly already. These are known cons of using a javascript framework that compiles to native. 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.
browniefed 10y ago
React Native Core Contributors responding and agreeing with some of the points. https://www.facebook.com/groups/reactnativeoss/permalink/1593579080938720/ https://www.facebook.com/groups/reactnativeoss/permalink/159...
brhsiao 10y ago
As someone who loves React, the hardest thing about it for me is debugging. I'll get some error about how renderComponent doesn't accept null values or whatever, and when even the outermost error is so cryptic, the stack trace is even less helpful. Is there a conventional solution to this I'm not aware of?
- dwaltrip 10y ago
  When the stack trace is inscrutable, I find binary search debugging to be helpful. Comment out half of the functionality, see if the error is still there. Narrow the search to the half that is causing the problem, rinse, and repeat until the offending line of code is found. However, if the error occurs inconsistently, this approach can be much harder to use.
- darkmarmot 10y ago
  As someone who uses a different component-based js framework, can you not just put a breakpoint in the chrome dev tools on the renderComponent method for that component?
  - larsnystrom 10y ago
    renderComponent is not part of any of your components. I think the React equivalent of what you mean is the render method of a component. 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.
    - darkmarmot 10y ago
      gotcha, thanks!
raspasov 10y ago
Like JavaScript? Use JavaScript. Don't like JavaScript? Use ClojureScript. Problem solved :)
formula_ninguna 10y ago
We have PureScript which is statically typed, pure functional language compiling to JS, can't it be adopted for React Native development somehow?
- bbcbasic 10y ago
  You really need to check out Elm. 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.
  - pka 10y ago
    Elm's type systems is really constrained compared to PureScript's. It's great for people coming from JavaScript, but not so much for those coming from Haskell. 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.
    - bbcbasic 10y ago
      I was under the impression that Elm rolls it's own virtual-dom?
      - pka 10y ago
        iirc they scrapped that in favor of virtual-dom a long time ago.
- pka 10y ago
  Yes, it can, although I can't say how usable those bindings are. [0] https://github.com/arthur-xavier/purescript-react-native https://github.com/arthur-xavier/purescript-react-native [1] https://github.com/hoodunit/purescript-react-native https://github.com/hoodunit/purescript-react-native
dustinmoorenet 10y ago
There is a bug in his code in the `Unsafe initialisation` section. He tries to access variables that are not defined in that scope. A linter would have caught that. 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
kimshibal 10y ago
Alibaba's Weex is better than React Native.
andrepd 10y ago
To add to the list of javascript gripes, performance is terrible. For the web we can sort of excuse it because ok, it's running in a browser and has to be cross platform and interpreted and etc. But for a native app? No excuse to burden the user with a slow, sluggish, resource and battery draining app when a compiled native app can be snappy, quick to load, and light on the CPU.
- deleted 10y ago
  [deleted]
- pitaj 10y ago
  Have you tried it? Unless you're handling custom animations in the main thread, the UI feels exactly the same as native.
qaq 10y ago
Granted Swift is a nice language TS or JS + transpiler + flow is decent and unlike Swift you can actually utilise multiple threads :) The patent stuff is moot point Apple has about the same language in their license.
greggman 10y ago
The author's rant on JS and npm deps has a point but his rant on typescript, flow, and other transpilers completely misses the mark. If JavaScript is an unsafe language and therefore anything that compiles on top of it is unsafe the same is true of Swift as it compiles to assembly/machine language which is unsafe. If you consider JavaScript some cross platform assembly language then there is no difference between the two ideas. 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
- RodericDay 10y ago
  > If you consider JavaScript some cross platform assembly language I am so sad right now
  - bbcbasic 10y ago
    Why? Some of the transpilers like Typescript are quite light touch.
  - jahewson 10y ago
    asm.js is exactly that!
- pekk 10y ago
  > He also rants about using the best language that catches the most errors but then picks Swift as his solution. That is because he is weighing solutions for developing native apps on Apple devices, where Swift is one of the best options.
mastazi 10y ago
From the article: > 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?
jayajay 10y ago
This is very ominous. In other words, don't build a RN app because, if it takes off, Facebook can copy the business model independently and claim it as their own. And, if you try to do anything about it, your license to use RN is revoked, rendering your app as nothing more than a petty copyright infringement. 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.
iOSGuy 10y ago
I use React Native and he's mostly right. Coming from the perspective of a native platform, this ecosystem is bat shit insane. It's harder, full of pitfalls, rife with complications, and rickety as all hell. 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.
jondot 10y ago
I'm the author of http://programmingreactnative.com http://programmingreactnative.com, maintain the https://github.com/jondot/awesome-react-native https://github.com/jondot/awesome-react-native list and built some other tools and libraries for React Native, along with a few apps. 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.
- jjuel 10y ago
  So we will have many variants? Does sound like a classic JavaScript thing to have many frameworks that do the same thing. Reminds me of this: https://xkcd.com/927/ https://xkcd.com/927/
- DiThi 10y ago
  > Apple's Developer terms 3.3.2 and 3.3.3 Where can I find them?
vikeri 10y ago
For all the hate of JS, I'm developing a RN app in ClojureScript, so I rarely touch JS and instead use what I percieve to be a nicer language: https://youtu.be/6IYm34nDL64 https://youtu.be/6IYm34nDL64
inian 10y ago
This article can probably be renamed to "why Javascript is bad"..only patents and dependencies issues were related to react native..the rest of the article was about how Javascript sucks..and I think developers are already equipped to take the call if they want to use js on a large project or not..
thwee 10y ago
We haven't moved much from MVC apps, have we?
- romanovcode 10y ago
  Nothing wrong with MVC.
franciscop 10y ago
Please what kind of programmer would ever do this? if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } That is just verbose unnecessarily: this.setState({ isConnected: weAreConnected }); And probably not so popular, but this: var color; if (this.state.isConnected) { color = 'green' } else { color = 'red' } Would be simplified often to: var color = this.state.isConnected ? 'green' : 'red';
- bbcbasic 10y ago
  > what kind of programmer would ever do this? An enterprise developer.
  - franciscop 10y ago
    Laughed too hard
    - Ensorceled 10y ago
      ... and then, after a while, started crying.
- EdwardDiego 10y ago
  A programmer whose output is measured by LOC...
- strugglefun 10y ago
  > Please what kind of programmer would ever do this? Someone with an interesting development development history (maybe C?), with little grasp of the idioms of newer coding styles.
  - andrewmcwatters 10y ago
    What?
- 10y ago
drinchev 10y ago
I was hoping to read more about performance. React is a resource hog for complex state and no 'componentShouldUpdate' method defined. 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.
thedonkeycometh 10y ago
tldr; javascript and facebook
_pmf_ 10y ago
Idiomatic React looks like a horrendous mix of PHP3 and VBA.
minitech 10y ago
> JavaScript allows for objects to be left in an inconsistent state right after being created, as their properties don’t need to be initialised. No, you just forgot to put `this` in front of `width` and `height`. (Arguments do default to `undefined`, though.)
Codestare 10y ago
I'm a skeptical native mobile developer. What are some examples of good apps currently in the store, written in React Native?
- romanovcode 10y ago
  There are none, really. Maybe Discord? Other than that there are no widely known apps that uses React Native.
  - gagege 10y ago
    Who said "widely known"? There are tons of "good" apps.
kowdermeister 10y ago
You probably shouldn't ever use the phrase [random-technology] developer. It puts you in a box that associates you with all the shortcomings of the given technology.
caub 10y ago
var a = 0; var b = -0; 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
- Arkanum 10y ago
  I'm not sure that's right. 1/0 is undefined NOT infinity, hence -1/0 is also undefined. So actually line 3 should evaluate as true.
  - kuschku 10y ago
    NaN === NaN evaluates to false. That’s what happens here, not anything with Infinity.
    - Arkanum 10y ago
      Yeah, that makes sense mostly. But why is NaN === NaN false? What am I missing here?
      - kuschku 10y ago
        Because there is many ways NaN can be generated, all very different. == is only defined for numbers, too. 1/0 and 50/0 aren’t the same, for example.
    - caub 10y ago
      just type them in your console instead of saying wrong things
      - kuschku 10y ago
        Then they don’t conform to the IEEE standards, and the Javascript implementers are wrong.
themihai 10y ago
Ok, so to 'fix it' we need React in Swift(instead of JS) without the facebook license clause. It sounds like the next UI framework. Unfortunately you can't have it all because Swift doesn't work on browser(yet, wasm will make it possible)
adamlett 10y ago
I love this quote from the article: "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."
Sagiri 10y ago
> There is no mechanism for you to mark a function as potentially crashing your teammate’s code or for specifying how to process an exception. 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).
betenoire 10y ago
> This allows over-the-air code updates. Any changes in your JavaScript code can be instantly pushed to your users while the app is in production Is this really true? Or is the author referring to the dev. edit/view loop?
leshow 10y ago
This post is completely false, you can absolutely build a safe language on unsafe foundations. Swift is compiled to assembly, which is unsafe, yet it provides a 'safe' interface (not as safe as Rust, but still). Similarly, Flow/Purescript/Elm have every ability to provide a safe interface to javascript.
tboyd47 10y ago
This article is beautiful. 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!
wczekalski 10y ago
I wrote a counterargument to it. http://wokalski.com/Why-Im-not-afraid-to-develop-in-React-Native/ http://wokalski.com/Why-Im-not-afraid-to-develop-in-React-Na...
spasquali 10y ago
These "JavaScript is stupid, why don't you all see that!! Why! Why! Why?!??!!" rants are really entertaining nowadays. The author has also invented a (perverse?) extension of Atwood's Law (which law predicted React Native): anything that can be blamed on JavaScript will be blamed on JavaScript. If JavaScript ran for president it would be Hillary Clinton, and every other language would occupy one thread on Trump's Toupee.
tracker1 10y ago
Responses to each category... 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. 3. JavaScript 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.
avocade 10y ago
Probably the best dev article I've read this year to date. Have youz a newsletter? :)

362 points by nootopian 10y ago

rco8786 10y ago

You could have just said "I don't like Javascript" and ended the post there.

atoko 10y ago
I feel like this is some sort of signaling, a la 'no true programmer uses javascript, because types!'.
- matwood 10y ago
  We all use it, but 'no true programmer likes javascript.' :)
  - joshuahutt 10y ago
    I must not be a true programmer, then. :/
  - sotojuan 10y ago
    I know plenty of intelligent and accomplished programmers who use and like JavaScript. I like poking fun at it every now and then, but come on.
  - ovao 10y ago
    I quite like JavaScript for relatively light scripting tasks. In that role, I find it pretty well-suited. For complex applications I'm as leery of it as anyone else.
  - matwood 10y ago
    Since apparently people are missing my ':)' above, they are missing that I replied to what I thought was a joke with another joke. So just to be clear, it was a joke. Sigh.
- jakebasile 10y ago
  I used to half joke like this, but recently I've been doing some React work in ES6 with Flowtype annotations. It's actually not that bad.
  - jnbiche 10y ago
    Exactly. Flow even has tagged unions now, and `maybe` types. TypeScript is also a very mature solution to this problem. A true professional works with whatever language he needs to solve his/her problem, and shores up that language with the best tools available. In this case, I half agree, because I think mobile development is best done using native platforms. But if you're doing web development, JavaScript is a must. And React is an elegant way to handle browser UI (Flow/Redux is also quite nice way to handle browser state, if a bit verbose). I do share his concerns about the patent clause, and about Facebook's long-term commitment to the project, but at the level of personal projects, these concerns have not been enough to scare me away.
    - st3v3r 10y ago
      "A true professional works with whatever language he needs to solve his/her problem, and shores up that language with the best tools available." Right. And JavaScript is not that language, unless you are doing web stuff.
      - jnbiche 10y ago
        > Right. And JavaScript is not that language, unless you are doing web stuff. Do I hear an echo in here? "I think mobile development is best done using native platforms. But if you're doing web development, JavaScript is a must."
    - bbcbasic 10y ago
      A true Scotsman comment nested in another true Scotsman comment. It's haggis all the way down!
- qwertyuiop924 10y ago
  Well then, if no true programmer likes dynamically typed languages, I'd better make some calls... 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.
  - mkawia 10y ago
    I see it like; smart,disciplined programmers are capable of writing complex programs in dynamically typed languages without making as many errors.
  - wtbob 10y ago
    Lisp, though, does have types.
    - qwertyuiop924 10y ago
      All languages have types. Lisp, however, and particularly the versions that those people worked with, are dynamically typed, like Javascript. Unlike JS, they aren't weakly typed, but that's not the point. To say nothing of Ruby and Python, for which there are also programmers on that list.
      - wtbob 10y ago
        Common Lisp compilers may implement static typing. The default type is T, though — but with declarations, a compiler can enforce anything the programmer declares or it infers.
        qwertyuiop924 10y ago
        Most of those people either worked with MACLisp, or dynamically typed Scheme.

tmorton 10y ago

Aside from the discussion of JS and React Native, I want to highlight this: > 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.

mtrn 10y ago
Raymond Hettinger highlighted the community aspect for languages very well in this keynote: https://www.youtube.com/watch?v=b_pTxGu2L04&feature=youtu.be&t=6m46s https://www.youtube.com/watch?v=b_pTxGu2L04&feature=youtu.be... - he of course talks about Python, but the principles apply to any language or ecosystem.
EdwardDiego 10y ago
Hmm, communities become less important as languages become more widely used. When was the last time you referred to the Java community, singular? 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.

revicon 10y ago

tldr; Author doesn't like writing in javascript and fears that Facebook may some day decide to stop supporting React Native.

sn0v 10y ago
It'd be nice to have a TL;DR bot on HN, at least for the more clickbait-titled articles (not saying this is one).
ChrisLTD 10y ago
Ariel also doesn't like this clause in the React license: 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.
- hackerboos 10y ago
  That's in all of the React licenses.
  - ChrisLTD 10y ago
    Thanks, I updated my original comment.
- sebastianconcpt 10y ago
  That alone makes it a non-starter
  - Lazare 10y ago
    Why? (Honest question.)

__derek__ 10y ago

This is a good post up until the rehash of JavaScript's sins.

leonatan 10y ago
It picks up later on. I too had issues with some of the JS stuff, but it's worth continuing reading. Also worth to take a look at the references.

RussianCow 10y ago

Is anyone using TypeScript with React Native? I'd be interested to see how easy that is to integrate.

pier25 10y ago
In that case it would probably make more sense to just use NativeScript instead of React Native. https://www.nativescript.org/ https://www.nativescript.org/
- cornflake 10y ago
  NativeScript looks really promising. My colleagues have used it for numerous client apps. It's not as mature as Appcelerator Titanium so it doesn't have as many plugins for advanced things like video recording or audio playback but if it continues to get traction, it could become a really good option.
- RussianCow 10y ago
  NativeScript doesn't have tight integration with React, and I don't really want to build that layer myself.
  - SomeCallMeTim 10y ago
    Angular 2 is pretty awesome and faster than React.
    - gareim 10y ago
      Source on that speed claim, please.
      - SomeCallMeTim 10y ago
        I can't find the benchmarks that I'd based my comments on to be honest, and I have to get back to work. :| From what I remember, the final version of Angular 2 added a lot of performance, which pushed it ahead of the latest React in performance. I did find this: http://webscripts.softpedia.com/blog/recent-benchmark-shows-the-speed-of-angularjs-2-499638.shtml http://webscripts.softpedia.com/blog/recent-benchmark-shows-... But the Auth0 benchmarks disagree and show React is faster: https://auth0.com/blog/more-benchmarks-virtual-dom-vs-angular-12-vs-mithril-js-vs-the-rest/ https://auth0.com/blog/more-benchmarks-virtual-dom-vs-angula... Angular 1 is terrible performance-wise; that much is certain.

dahdum 10y ago

Unless I'm wrong, the only listed alternatives are both paid and closed source. Xamarin (requires VS Pro) or Appcelerate (requires $480-$1200/year/developer).

matwood 10y ago
I believe Xamarin is now free post the MS acquisition with various parts and pieces even becoming open source: https://blog.xamarin.com/xamarin-for-all/ https://blog.xamarin.com/xamarin-for-all/
- dahdum 10y ago
  I was actually looking here: https://store.xamarin.com/ https://store.xamarin.com/ 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.
  - romanovcode 10y ago
    No, it's completely free with VS Community (which is also free). And you don't have to pay if your company has 5 or less people working on it. You also have to pay if you have 250+ computers/people employed or your revenue is 1m+/year. Sounds pretty reasonable to me.
cornflake 10y ago
Most of the Appcelerator community i'm in touch with use the free Titanium builds instead of paying for an Appcelerator license: http://builds.appcelerator.com.s3.amazonaws.com/index.html#master http://builds.appcelerator.com.s3.amazonaws.com/index.html#m... 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.
SomeCallMeTim 10y ago
Others have mentioned Xamarin is free and (mostly? entirely?) open source now. See also NativeScript [1]. 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. [1] http://nativescript.com/ http://nativescript.com/

wmil 10y ago

This is a nit pick, but isn't his "Ambiguous curly braces" example actually breaking due to automatic semicolon insertion? return {{a: 4}} Isn't valid anyways. ESLint easily flags it as an error.

SomeCallMeTim 10y ago
Exactly: Linting rules requiring semicolons should be considered a best practice. 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...
- wmil 10y ago
  For anyone else reading this in the future, I should mention that the ESLint 'no-unreachable' rule will catch this even if you don't require semicolons.
  - SomeCallMeTim 10y ago
    Good point! Didn't say this explicitly, but TypeScript will, by default, prohibit unreachable code as well. [1] [1] "allowUnreachableCode" defaults to false: https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option...

joshkpeterson 10y ago

Author says the bad outweigh the good, but we haven't fully evaluated the good. 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?

STRML 10y ago

This is simply a list of things the author doesn't like about JS, very much of which is practically solved by Flow/TS and ESLint. 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}} />; } The point is, much like many things in software, it's all about perceptions and familiarity. He's not familiar with JS, and I don't fault him for that - it's a quirky language. But for the many, many developers who have built up a tolerance to JS and built/use tools to tame it, moving to React Native is a breath of fresh air vs learning Android & iOS toolchains and idiosyncrasies.

jontro 10y ago
The point of having isConnected in the state is that it will change depending on OS events. Random is just used as an example
- atoko 10y ago
  Even with state, his code is overly verbose and can be expressed in a much more idiomatic way. var weAreConnected = Math.floor(Math.random() * 10) > 5; if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } } turns into var weAreConnected = Math.floor(Math.random() * 10) > 5; this.setState({ isConnected: weAreConnected }); It's almost like he wrote it in the most obtuse way possible to prove his point. Unless he writes like that normally; If so then I can see where he's getting all these errors from.
  - jontro 10y ago
    Absolutely, especially since he/she wrote it that way in the swift version let weAreConnected: Bool = arc4random()%10 > 4 self.isConnected = weAreConnected

joshwcomeau 10y ago

Ughhh. It's fine if you prefer statically-typed languages to dynamically-typed ones, but that's a preference, not a reason to try and say that JS is objectively terrible. 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.

steego 10y ago
I prefer statically-typed languages too, but this is easily solved by using something TypeScript or Flow.
- pzh 10y ago
  Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift. JS has its uses, but it's difficult to debug, doesn't take advantage of all the advances in modern languages design that help prevent whole classes of bugs, and carries a lot of baggage. The only benefit would be universal app development, but even then Xamarin seems like a better choice.
  - DenisM 10y ago
    Speaking of Xamarin. RN supports iOS, Windows, and Android. Plus RN is somewhat close to React, so some code could be reused between the two. Plus you get out-of-band code updates! Xamarin supports iOS, Windows, and Android. But there is no web story. Or is there?
  - steego 10y ago
    > Yeah, but why use another patch on top of a patch where there are modern type-safe languages like Swift. The JavaScript toolchain is more than good enough to build the kinds of applications that React Native targets. Most of these applications aren't stellar apps that require critical performance or rigorous type checking, they're just dumb front-ends to REST endpoints. If you're going to build an awesome app, then use better tools. The reason I would use React over Xamarin is simple: Speed of training and development. I can hire, train and get a React developer up and running and building proof-of-concepts a lot quicker than on Xamarin.

swsieber 10y ago

After reading this and other comments here, I sort of just wish there were Haxe bindings for to the React Native stuff.

gagege 10y ago
That would be cool. What I really want for Christmas this year is React Native but with Elm instead of JS!

elcct 10y ago

JavaScript has its share of bad things but that's mostly solved by good tooling. I think Java or ObjectiveC feel too "heavy" for UI development. React makes it simple and even with its downsides in my opinion it makes other technologies no longer relevant in this domain .

barryhoodlum 10y ago
I agree, UI development is a different beast. 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.
romanovcode 10y ago
>it makes other technologies no longer relevant in this domain 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.
- elcct 10y ago
  Do you have any specific example where Java or ObjectiveC/Swift would be of better use?
  - romanovcode 10y ago
    Anything that requires some kind of processing like, for example facebooks own Instagram.
    - 10y ago

cocktailpeanuts 10y ago

A lot of people here seem to criticize the OP's POV on javascript, but my biggest takeaway was the more abstract parts of his post, such as patents and uncertain roadmap. These are very REAL problems. 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)

Lazare 10y ago
> my biggest takeaway was the more abstract parts of his post, such as patents and uncertain roadmap. These are very REAL problems. 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.)
- cocktailpeanuts 10y ago
  My point was not about the details, but about the uncertain nature of an open source project driven by a company. The patent issue is just one of the "symptoms" of this problem. When someone open sources their technology and adds a set of detailed clauses that adds some restriction (doesn't matter if it's a "real" restriction or not), it means they couldn't go all out. It also means as a user, you do have reasons to be cautious about it, not because of what the license says in detail, but because of the reason behind the behavior. 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.

pacomerh 10y ago

The alternatives mentioned here are not really of the same type. A better example of an alternative would be something like https://www.nativescript.org/ https://www.nativescript.org/

doozy 10y ago

I evaluated React Native for a project and decided to go with NativeScript instead for a number of reasons: 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.

msie 10y ago
Another vote for 7): I tried a little project in React Native and was intimidated by all the tooling and build steps needed to get my project running on iOS. To be good with React Native you will have to be proficient with all the tooling and all that seems to be a shaky foundation. There are lots of parts that can be updated and can break your project (I say in a vague way).
hesarenu 10y ago
I have been using RN from 0.19 onwards never broke my app a single time. React encourages thinking in components and component would be tightly coupled. I have many kitkat users on my beta app on playstore. For me reactjs is way simpler. Angualr seems like a jee framework.
cm2187 10y ago
On the tooling I presume it is impossible to get help with the html markup, since it is commingled with code? Like there is no way to start writing html in your js function and for the IDE to autocomplete a class name based on the CSS it knows will be loaded on a page. This is sort of coding in notepad. Or are there tools that see through the js and understand how the whole page will fit together?
solidr53 10y ago
Wow, hold on guys. This enterprise dude thinks all the tooling around the RN ecosystem is very confusing. Angular 2 must be better then.

chukye 10y ago

The most part of cons is criticising JavaScript and NOT React Native. I know how JS works, and I LOVE IT. The only part of the post that I liked is when he talks about the license, all the rest is just bullshit from a person who don't like JS.

pekk 10y ago
It's not bullshit if it's a valid consideration when you are trying to build an app on say iOS and weighting it against say Swift. How many times does this need to be said? It depends on what you are trying to do and what you want.
- chukye 10y ago
  Ok, this is a good point. But, the author just point out the quirks of JS language, and not things about the RN itself. Would be more fair if he pointed out the quirks in python or had focused on the RN. All he says about JS is very well known and is there since 90s. Also, he is saying that its not safe because he can't understand and workaround with the pitfalls, JS has a lot of problems, but also has a LOT of great solutions for them, and by that this not means that the language is not safe, just means that its harder to work with.
- solidr53 10y ago
  "What if you forget to put break in-between your cases in a switch statement. They will leak." This man, my friend, is an idiot.

enturn 10y ago

It would be good to have when the article was written/updated on the page. I found Sep 22, 2016 in the changelog (link at the bottom) for first commit.

draw_down 10y ago

I think it's a really nice way to make an app :)

sebastianconcpt 10y ago

React "componentization" is nice. For me there are two things that makes it a non-starter: 1. That legal clause mentioned in the article and 2. The complexity of learning this platform is the same as learning the native without the same benefits on the control over the hardware (actually with added complexity potential lack of control)

kschiffer 10y ago

I believe in the end it all boils down to the fact that JavaScript is a language that wasn't made for the needs of modern day (web) applications, but since it is still a standard, we need to force it into a form where we can have best control over its shortcomings. That's why things like Typescript, Flow and React exist in the first place. I know this article is about mobile app development, but I think JavaScript would not have the sort of widespread use today if it wasn't for the fact that we use it for website scripting. 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.

qwertyuiop924 10y ago
Besides, while JS's problems are very real, they're quite exaggerated. It's still a perfectly usable language, even without TS and whatnot. And unlike some languages used for app programming, an error doesn't have the potential to hand you a segfault.
- tempodox 10y ago
  > ...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?
  - qwertyuiop924 10y ago
    If you segfault, that's not because your state is corrupt. Not usually, anyways. Typically, you'll segfault from a use-after-free error or similar.

deleted 10y ago

[deleted]

gorkemyurt 10y ago

Ability to update your app over the wire with React Native is a massive advantage overlooked in the article. (via Codepush or something similar) 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.

qwertyuiop924 10y ago

The legal concerns are legitimate, but frankly, I am unconvinced by the criticisms of JavaScript: There are well-known, well-designed tools like ESLint, and if you like types, Flow and TypeScript, which can mitigate the issues. That's more than you can say about Java (COBOL 2.0, now with a bevy of cargo-cult OO that makes things more overly complex), or Objective-C (All the safety of C, with similar OO problems, and a weird syntax that very few people like, and of course, no GC).

readymade 10y ago
Some of us happen to think that no GC is a good thing, in Obj-C's case. Swift eschews it as well.
- qwertyuiop924 10y ago
  Manual memory management: It's all fun and games until OOM errors come knocking, or- Segmentation Fault: Core Dumped. I rest my case. There's a place for manual memory management. It's not in application code.
  - pzh 10y ago
    Not necessarily. Swift uses ARC by default, and you'd really have to go out of your way to do any manual memory management.
    - qwertyuiop924 10y ago
      Ah. I originally talking about Objective-C, so I assumed that we were talking about manual memory management. Of course, ARC has its own problems... Hope anybody implementing graphs knows what they're doing, or you'll leak memory like Niagra Falls.
      - readymade 10y ago
        Objective-C also uses ARC by default, and that's been the case for several years now. In any event, avoiding retain cycles is relatively straightforward and most iOS devs I know would agree that the low memory overhead and lack of GC pauses are worth the occasional extra effort of weak references.

Legogris 10y ago

Maybe nitpicking, but the author states that "Your codebase can now create an app that can run on millions of additional devices, and you’ve increased your outreach by several orders of magnitude." Yeah, Android is growing, but iOS still has substantial market share. Switching to React Native will definitely not give a > 100x increase in outreach.

striking 10y ago
The Android market share is >60% and rising, though. Not sure what you're talking about. https://bgr.com/2016/06/02/apples-mobile-market-share-sees-big-drop-in-may-as-android-skyrockets/ https://bgr.com/2016/06/02/apples-mobile-market-share-sees-b... 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.
- Legogris 10y ago
  The nitpick being that usually, one order of magnitude = 10x, two orders of magnitude = 100x, and so on. So it's a very exaggerated statement if taken at face value.

weixiyen 10y ago

Reasons why I am a React-Native developer: - 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.

macspoofing 10y ago
>React-Native is not for every scenario What scenario isn't it for?
- vmasto 10y ago
  Dare I say games? I honestly can't think of anything else.
  - justinlardinois 10y ago
    Definitely. Unless you have an extremely simple game, you're probably not even using the OS's built in UI framework; something like Android NDK[0] and whatever its iOS equivalent is are more suitable. [0] https://developer.android.com/ndk/index.html https://developer.android.com/ndk/index.html
- ziziyO 10y ago
  Anything where you need to stay alive in the background and periodically do something.
  - Axsuul 10y ago
    So like a messaging app?

bikamonki 10y ago

Could FB plug the cord on React once it does no longer align with its core strategy? Sure, it did it with parse.com without the least concern for the community of users/clients. The apology was to leave behind a half-cooked open source version of parse server. The exact same thing could happen to the React community. I'd say stick to true open source projects and descentralized communities.

mbrock 10y ago
What's not true about the open source of React?
- UweSchmidt 10y ago
  Developed by a company, if they stop it's still open source but who will maintain it? Linux is "truer" open source since it's all volunteers from day 1.
hanspeter 10y ago
If they use React to develop their own apps doesn't give some assurance that they're going to stick? 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.
JMCQ87 10y ago
Yupp, there's enough precedent with Parse alone.

jbhatab 10y ago

Article feels clickbaity with some points that have been addressed and discussed thoroughly already. These are known cons of using a javascript framework that compiles to native. 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.

browniefed 10y ago

React Native Core Contributors responding and agreeing with some of the points. https://www.facebook.com/groups/reactnativeoss/permalink/1593579080938720/ https://www.facebook.com/groups/reactnativeoss/permalink/159...

brhsiao 10y ago

As someone who loves React, the hardest thing about it for me is debugging. I'll get some error about how renderComponent doesn't accept null values or whatever, and when even the outermost error is so cryptic, the stack trace is even less helpful. Is there a conventional solution to this I'm not aware of?

dwaltrip 10y ago
When the stack trace is inscrutable, I find binary search debugging to be helpful. Comment out half of the functionality, see if the error is still there. Narrow the search to the half that is causing the problem, rinse, and repeat until the offending line of code is found. However, if the error occurs inconsistently, this approach can be much harder to use.
darkmarmot 10y ago
As someone who uses a different component-based js framework, can you not just put a breakpoint in the chrome dev tools on the renderComponent method for that component?
- larsnystrom 10y ago
  renderComponent is not part of any of your components. I think the React equivalent of what you mean is the render method of a component. 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.
  - darkmarmot 10y ago
    gotcha, thanks!

raspasov 10y ago

Like JavaScript? Use JavaScript. Don't like JavaScript? Use ClojureScript. Problem solved :)

formula_ninguna 10y ago

We have PureScript which is statically typed, pure functional language compiling to JS, can't it be adopted for React Native development somehow?

bbcbasic 10y ago
You really need to check out Elm. 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.
- pka 10y ago
  Elm's type systems is really constrained compared to PureScript's. It's great for people coming from JavaScript, but not so much for those coming from Haskell. 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.
  - bbcbasic 10y ago
    I was under the impression that Elm rolls it's own virtual-dom?
    - pka 10y ago
      iirc they scrapped that in favor of virtual-dom a long time ago.
pka 10y ago
Yes, it can, although I can't say how usable those bindings are. [0] https://github.com/arthur-xavier/purescript-react-native https://github.com/arthur-xavier/purescript-react-native [1] https://github.com/hoodunit/purescript-react-native https://github.com/hoodunit/purescript-react-native

dustinmoorenet 10y ago

There is a bug in his code in the `Unsafe initialisation` section. He tries to access variables that are not defined in that scope. A linter would have caught that. 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

kimshibal 10y ago

Alibaba's Weex is better than React Native.

andrepd 10y ago

To add to the list of javascript gripes, performance is terrible. For the web we can sort of excuse it because ok, it's running in a browser and has to be cross platform and interpreted and etc. But for a native app? No excuse to burden the user with a slow, sluggish, resource and battery draining app when a compiled native app can be snappy, quick to load, and light on the CPU.

deleted 10y ago
[deleted]
pitaj 10y ago
Have you tried it? Unless you're handling custom animations in the main thread, the UI feels exactly the same as native.

qaq 10y ago

Granted Swift is a nice language TS or JS + transpiler + flow is decent and unlike Swift you can actually utilise multiple threads :) The patent stuff is moot point Apple has about the same language in their license.

greggman 10y ago

The author's rant on JS and npm deps has a point but his rant on typescript, flow, and other transpilers completely misses the mark. If JavaScript is an unsafe language and therefore anything that compiles on top of it is unsafe the same is true of Swift as it compiles to assembly/machine language which is unsafe. If you consider JavaScript some cross platform assembly language then there is no difference between the two ideas. 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

RodericDay 10y ago
> If you consider JavaScript some cross platform assembly language I am so sad right now
- bbcbasic 10y ago
  Why? Some of the transpilers like Typescript are quite light touch.
- jahewson 10y ago
  asm.js is exactly that!
pekk 10y ago
> He also rants about using the best language that catches the most errors but then picks Swift as his solution. That is because he is weighing solutions for developing native apps on Apple devices, where Swift is one of the best options.

mastazi 10y ago

From the article: > 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?

jayajay 10y ago

This is very ominous. In other words, don't build a RN app because, if it takes off, Facebook can copy the business model independently and claim it as their own. And, if you try to do anything about it, your license to use RN is revoked, rendering your app as nothing more than a petty copyright infringement. 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.

iOSGuy 10y ago

I use React Native and he's mostly right. Coming from the perspective of a native platform, this ecosystem is bat shit insane. It's harder, full of pitfalls, rife with complications, and rickety as all hell. 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.

jondot 10y ago

I'm the author of http://programmingreactnative.com http://programmingreactnative.com, maintain the https://github.com/jondot/awesome-react-native https://github.com/jondot/awesome-react-native list and built some other tools and libraries for React Native, along with a few apps. 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.

jjuel 10y ago
So we will have many variants? Does sound like a classic JavaScript thing to have many frameworks that do the same thing. Reminds me of this: https://xkcd.com/927/ https://xkcd.com/927/
DiThi 10y ago
> Apple's Developer terms 3.3.2 and 3.3.3 Where can I find them?

vikeri 10y ago

For all the hate of JS, I'm developing a RN app in ClojureScript, so I rarely touch JS and instead use what I percieve to be a nicer language: https://youtu.be/6IYm34nDL64 https://youtu.be/6IYm34nDL64

inian 10y ago

This article can probably be renamed to "why Javascript is bad"..only patents and dependencies issues were related to react native..the rest of the article was about how Javascript sucks..and I think developers are already equipped to take the call if they want to use js on a large project or not..

thwee 10y ago

We haven't moved much from MVC apps, have we?

romanovcode 10y ago
Nothing wrong with MVC.

franciscop 10y ago

Please what kind of programmer would ever do this? if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } That is just verbose unnecessarily: this.setState({ isConnected: weAreConnected }); And probably not so popular, but this: var color; if (this.state.isConnected) { color = 'green' } else { color = 'red' } Would be simplified often to: var color = this.state.isConnected ? 'green' : 'red';

bbcbasic 10y ago
> what kind of programmer would ever do this? An enterprise developer.
- franciscop 10y ago
  Laughed too hard
  - Ensorceled 10y ago
    ... and then, after a while, started crying.
EdwardDiego 10y ago
A programmer whose output is measured by LOC...
strugglefun 10y ago
> Please what kind of programmer would ever do this? Someone with an interesting development development history (maybe C?), with little grasp of the idioms of newer coding styles.
- andrewmcwatters 10y ago
  What?
10y ago

drinchev 10y ago

I was hoping to read more about performance. React is a resource hog for complex state and no 'componentShouldUpdate' method defined. 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.

thedonkeycometh 10y ago

tldr; javascript and facebook

_pmf_ 10y ago

Idiomatic React looks like a horrendous mix of PHP3 and VBA.

minitech 10y ago

> JavaScript allows for objects to be left in an inconsistent state right after being created, as their properties don’t need to be initialised. No, you just forgot to put `this` in front of `width` and `height`. (Arguments do default to `undefined`, though.)

Codestare 10y ago

I'm a skeptical native mobile developer. What are some examples of good apps currently in the store, written in React Native?

romanovcode 10y ago
There are none, really. Maybe Discord? Other than that there are no widely known apps that uses React Native.
- gagege 10y ago
  Who said "widely known"? There are tons of "good" apps.

kowdermeister 10y ago

You probably shouldn't ever use the phrase [random-technology] developer. It puts you in a box that associates you with all the shortcomings of the given technology.

caub 10y ago

var a = 0; var b = -0; 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

Arkanum 10y ago
I'm not sure that's right. 1/0 is undefined NOT infinity, hence -1/0 is also undefined. So actually line 3 should evaluate as true.
- kuschku 10y ago
  NaN === NaN evaluates to false. That’s what happens here, not anything with Infinity.
  - Arkanum 10y ago
    Yeah, that makes sense mostly. But why is NaN === NaN false? What am I missing here?
    - kuschku 10y ago
      Because there is many ways NaN can be generated, all very different. == is only defined for numbers, too. 1/0 and 50/0 aren’t the same, for example.
  - caub 10y ago
    just type them in your console instead of saying wrong things
    - kuschku 10y ago
      Then they don’t conform to the IEEE standards, and the Javascript implementers are wrong.

themihai 10y ago

Ok, so to 'fix it' we need React in Swift(instead of JS) without the facebook license clause. It sounds like the next UI framework. Unfortunately you can't have it all because Swift doesn't work on browser(yet, wasm will make it possible)

adamlett 10y ago

I love this quote from the article: "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."

Sagiri 10y ago

> There is no mechanism for you to mark a function as potentially crashing your teammate’s code or for specifying how to process an exception. 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).

betenoire 10y ago

> This allows over-the-air code updates. Any changes in your JavaScript code can be instantly pushed to your users while the app is in production Is this really true? Or is the author referring to the dev. edit/view loop?

leshow 10y ago

This post is completely false, you can absolutely build a safe language on unsafe foundations. Swift is compiled to assembly, which is unsafe, yet it provides a 'safe' interface (not as safe as Rust, but still). Similarly, Flow/Purescript/Elm have every ability to provide a safe interface to javascript.

tboyd47 10y ago

This article is beautiful. 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!

wczekalski 10y ago

I wrote a counterargument to it. http://wokalski.com/Why-Im-not-afraid-to-develop-in-React-Native/ http://wokalski.com/Why-Im-not-afraid-to-develop-in-React-Na...

spasquali 10y ago

These "JavaScript is stupid, why don't you all see that!! Why! Why! Why?!??!!" rants are really entertaining nowadays. The author has also invented a (perverse?) extension of Atwood's Law (which law predicted React Native): anything that can be blamed on JavaScript will be blamed on JavaScript. If JavaScript ran for president it would be Hillary Clinton, and every other language would occupy one thread on Trump's Toupee.

tracker1 10y ago

Responses to each category... 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. 3. JavaScript 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.

avocade 10y ago

Probably the best dev article I've read this year to date. Have youz a newsletter? :)