16 ms·

Why I'm not a React Native developer

• Rockslide 9y ago
  OK, this isn't really important for the quintessence of the article. But I'm surprised again and again how many developers write code like if (weAreConnected === true) { this.setState({ isConnected: true }) } else { this.setState({ isConnected: false }) } } instead of this.setState({ isConnected: weAreConnected })
  • WalterSear 9y ago
    Or this.setState({ isConnected: Boolean(weAreConnected) }) If you want to be super obvious, and aren't using a type system.
    • sheetjs 9y ago
      or this.setState({ isConnected: !!weAreConnected })
      • WalterSear 9y ago
        I prefer boolean, easier to see what's going on. And, bo-tab( is only two more characters :)
        • debaserab2 9y ago
          It's not any easier if you understand what !! does. Pretty common usage across many languages.
          • gruez 9y ago
            >It's not any easier if you understand what !! does which only applies if you're writing code for yourself. you can't expect everyone to know that idiom. same with using the + operator to cast to number, or an extreme case, the tadpole operator https://blogs.msdn.microsoft.com/oldnewthing/20150525-00/?p=45044 https://blogs.msdn.microsoft.com/oldnewthing/20150525-00/?p=...
            • srssays 9y ago
              !! is an extremely common idiom, across multiple different programming languages. Code should be written so that it is understandable by other professional programmers, not people who started programming two weeks ago.
              • WalterSear 9y ago
                As a professional programmer, I've come to prefer code written to be understood by someone who started two weeks ago.
                • debaserab2 9y ago
                  Then by that principle you'd want to use !! since casting via function or constructor differs more between languages.
                  • WalterSear 9y ago
                    What it looks like in other languages is only minorly relevant to its obviousness and readability.
                    • debaserab2 9y ago
                      I don't see the argument that Boolean(val) "reads easier" than !! as long as you know what !! does.
                      • goatlover 9y ago
                        Wouldn't any programmer recognize that Boolean(val) is a cast to a True/False value that's most likely an object, given the uppercase?
                        • inimino 9y ago
                          Perhaps, but it's a primitive, not an object.
          • WalterSear 9y ago
            Oh I understand, it, and used it for years. Boolean() is just easier to spot in unfamiliar code.
  • Mc_Big_G 9y ago
    I couldn't agree more. I wouldn't accept that from even a junior developer and yet you can easily find "senior" devs writing this crap. It seems like some devs will never understand that less code is better or that ease of reading matters. This is either lack of skill or laziness, neither of which are acceptable.
  • vmarsy 9y ago
    What if `weAreConnected` is `null` or `undefined`? WalterSear's solution solves the issue since both `null` and `undefined` would become `false`: this.setState({ isConnected: Boolean(weAreConnected) }) but in your case you could set `isConnected` to `null` or `undefined` so if later in code someone makes the mistake of writing: if (this.state.isConnected === false) { /* do stuff */ } they could have a bad surprise.
    • debaserab2 9y ago
      this.setState({ isConnected: !!weAreConnected })
      • hypervis0r 9y ago
        This^, plus, you shouldn't really have "null" or "undefined" variables which you treat as bool (if you do, then that's a bug)
      • DeonPenny 9y ago
        Ding ding ding right answer. This is the way most senior javascript devs would right it.
        • corn13read 9y ago
          They'd right it if they were fixing it or write it if they were writing it ;)
    • Rockslide 9y ago
      It certainly doesn't hurt to "cast" the input to boolean. But your second example is the next code smell, because it should just be if (!this.state.isConnected) { /* do stuff */ } (which still works as expected even when dealing with null or undefined).
      • vmarsy 9y ago
        Agreed, but you can't anticipate what another dev could write :) Or if you pass down that `isConnected` down to a library where for some reason they assumed `null` should default to `true` Of course it's very unlikely, but my point is you can't know all use cases of `this.state.isConnected` in advance on a large project so as you say it doesn't hurt to sanitize the input.
  • mamcx 9y ago
    The replies below show why, because JS. Bad languages don't allow a nice life.
    • oceanswave 9y ago
      It's funny how you can spot the junior devs, who are accustomed to one thing and refuse to learn another. There is a beauty about the JavaScript language that most people don't get, and how a lot of behavior can be added after the fact or mutated. Design time type safety is not the end all be all of languages
      • mamcx 9y ago
        But inconsistency is truly a problem. Is not that JS is just "crazy" but with a method on his madness. Is that is just not well designed. So, how we can claim to "developer good software" in front of our customers and defend tools like this?
  • ricardobeat 9y ago
    That goes to show how much salt you should take with the rest of his opinions on JS. Yes, dependency hell is a problem, yes, no type safety (though you can choose TS), the rest? Not so much unless you're trying to hammer JS into the shape of your old favourite language.
  • microcolonel 9y ago
    There's also the if isConnected { backgroundColor = .green } else { backgroundColor = .red } bit, which should be a ternary. I figure that a good rule is: if the feature existed in C, you should know and understand it. If that feature is convenient and doesn't sacrifice performance, then you should use it. Then there's this blatant misuse of the arc4random API, which I'm pretty sure the manpage tells you about. let weAreConnected: Bool = arc4random()%10 > 4
    • joesb 9y ago
      it depends on how you want to structure your code and give sections to code. "if (isConnected) {} else {}" emphasizes to me that there are two branches of code which depends on `isConnected` state. It may have only one thing to do right now. But this is major branch. Future git diff will probably show that the code in the body the branch are added/removed. Ternary expression emphasizes on modification of a single attribute.
• savanaly 9y ago
  I'm really glad to have read this article as it actually solidifies my comfort with using React Native since it seems like a well thought out list of reasons not to use React Native, and now I know that none of them really matter that much to me. The three main disadvantages of React native brought up are: - lack of commitment from Facebook about maintaining it for a long time. This one is the most bothering to me but it's not a dealbreaker. - doesn't like Javascript and its related ecosystem. This doesn't bother me in the slightest, I love modern JS. - the whole all your patents are belong to us thing that comes up every so often. I'm not a startup founder or a lawyer so I will leave such concerns to them. If my employer wants to let me develop in React, all the better for me.
  • kkleindev 9y ago
    I'm curious, what do you love about JavaScript?
    • briandear 9y ago
      Probably that he knows it and doesn’t know Swift.
      • LeoNatan25 9y ago
        What kind of a reason is this? "Ignorance is a bliss."
        • blunte 9y ago
          The point was probably that someone with a good knowledge of one language and little or know knowledge of another favors the one they already know. There are plenty of people who are quite happy with what they have, and they see no reason to change. Then there are people (thankfully) who are never satisfied and who keep progress rolling.
          • LeoNatan25 9y ago
• jack_pp 9y ago
  A problem is the author doesn't seem to care that much about portability, how can you even say that Swift is an alternative to RN? Was curious about counter arguments and came upon this : https://medium.com/@reicheltp/dev-diary-4-why-i-left-xamarin-behind-35817ccd07b2 https://medium.com/@reicheltp/dev-diary-4-why-i-left-xamarin... A little old but I think I prefer RN's disadvantages over Xamarin's
  • pjmlp 9y ago
    That post is from 2016 and most of the bad issues have been tackled.
  • mmargerum 9y ago
    http://www.elementscompiler.com/elements/silver/ http://www.elementscompiler.com/elements/silver/
• worg 9y ago
  Title should have been —Why I dislike JS as a Programming Language instead of swift—
  • blunte 9y ago
    Plus the patent worries - that to me was the other big takeaway.
• whistlerbrk 9y ago
  This article raises so much unfounded FUD it's hard to believe the author is serious. 1. Uncertain Roadmap - Does anyone seriously doubt FB's commitment to RN? When they themselves dogfood it? Or is it more likely they are just too busy making progress (since as the author points out they release every 1-2 weeks) to release a multiyear ROADMAP? 2. Patents - Is anyone here planning on suing FACEBOOK? Who amongst us has the team of lawyers to undergo that? This is for 99.999% of people not a legitimate concern. This is an RMS concern. 3. Javascript - New versions of Javascript address the vast majority of this. Type errors? Use well supported Typescript or Flow 4. Dependencies - This is a result of the Javascript communities overly enthusiastic packaging efforts. This is not an apples to apples comparison, but of all the cons mentioned, sure this is legit. 5. Alternatives - ...and Windows Phone? Seriously? I was rooting like hell for MSFT, but this is just not a thing. I'd rather cover 99.6% of users twice as fast than 99.999 of users painfully using Appcelerator
  • arihant 9y ago
    Regarding your second point -- that also includes the fact that you cannot sue any of the React contributors, not just Facebook. If I have a pull request on React, I can copy everything you ever built on React, down to the interface. It doesn't matter how much I copy because you cannot sue me without losing license to the very thing you used to build it, and thereby not having right to build it in the first place. Read the agreement in full, till point (iii). > (iii) against any party relating to the Software.
    • chrisco255 9y ago
      No you do not lose the copyright license to use React in your code base. It is BSD. You only lose patent grants in the event you sue Facebook. In the event you sue Facebook, you're going to have to comb through your entire product code base and implementations for possible infringement against their portfolio of thousands of patents because you can bet your ass their legal team is going to come after you in retaliation. That is the nature of patent wars.
    • danmaz74 9y ago
      > I can copy everything you ever built on React, down to the interface Downvoted for FUD. That license is about patents, not copyright.
• azangru 9y ago
  The example with the Person class suggests that the author is unaware of JavaScript getters: class Person { get isImmortal() { return false; // noone is immortal } } p = new Person(); p.isImmortal // >>> false p.isImmortal = true; p.isImmortal // >>> false I mean, even plain untyped JavaScript can do that!
  • objectiveariel 9y ago
    You're missing the point. The fact that the language still allows you to write `p.isImmortal = true;` is the issue.
    • coldtea 9y ago
      Which won't do anything. p.isImmortal will still be the setter. So it's a non issue -- and the linter can catch the mistake anyway.
    • oceanswave 9y ago
      And my linter, or flow, typescript will pick that up in the same way the compiler will. Just because tooling these days catches these things in 'type safe' languages doesn't mean it's not a pointer to a chunk of memory that's defined at runtime beneath it all.
  • raquo 9y ago
    That was a bad example indeed. If isImmortal was accepting any params though, you wouldn't be able to make it a getter. And sure, Object.freeze exists, but almost none of the JS code I've seen uses it. And what's the point really when assignments to frozen fields don't even throw an exception, just fail silently. Same for getters. None of those tricks are gonna make JS into a good language in the eyes of people who don't for whatever reason consider it good already.
• Jeaye 9y ago
  So, you'd rather use Xamarin than React Native, in short. Xamarin has excellent tooling and arguably works with saner languages (with better type systems), but it doesn't work on GNU/Linux. We're using RN right now, since it allows us to use ClojureScript, which means we can share code between our Clojure sever and our client. This means we're limited to the JS environment though, which means no good access to multi-threading and a really wonky target language. Performance implications aside. If Xamarin worked on GNU/Linux, we likely would've built our app using it and F#. Until it comes to the Linux world and stops doing things the MS way (open sourcing is a good start), Xamarin is going to be missing out on a number of developers.
  • LeoNatan25 9y ago
    There is Mono on Linux, and it works quite alright. Xamarin can be made to work with Linux, it's jut not officially exposed in the UI by default.
    • Jeaye 9y ago
      Xamarin and Mono are not the same thing. Also, Xamarin Studio may work through WINE or something similar, but it doesn't have any native GNU/Linux builds.
  • madeofpalk 9y ago
    > which means we can share code between our Clojure sever and our client Im curious, what kind of code do you share between your server and app-client?
    • Jeaye 9y ago
      Common utilities for manipulating data, which is what Clojure does best. Logging. A wrapper HTTP API for communication. Lots of specs, using clojure.spec, to describe how the data moving between the client and server should look.
  • wdb 9y ago
    I would rather use RemObjects Elements then Xamarin :) Allows me to share code between Android, iOS, macOS, web. Quite lovely, UI can never me 100% the same for each platform so there is where the main cost will be.
• dreta 9y ago
  Xamarin is given as an example of a better alternative why exactly? You develop a single layout in React Native, while in Xamarin you just share the C# code, so separate platforms need separate UI code (unless you want to rely on their weak Xamarin.Forms API), and at that point you can just write common code in C or C++ and not rely on any third party. It's hardly comparable.
  • LeoNatan25 9y ago
    You can use Xamarin forms if you insist on sharing the layout and have a terrible lowest common denominator fisher-price UI.
• loftyal 9y ago
  I think people should be paying more attention to the core concept of React Native, which is having a view layer that is completely native and a bridge that connects to a javascript engine. People bitch about electron which is essentially a browser in an app window (React Native is NOT that), the concepts of React Native solves a lot of the performance problems of Electron, which I think the electron team should seriously consider implementing.
  • danpalmer 9y ago
    I think people should be paying more attention to the declarative views that React gives us. There’s no reason we couldn’t implement React in Swift and get a lot of the benefits of both approaches with few of the downsides. We wouldn’t have the fast iteration time but it could still be a great option.
  • chrisco255 9y ago
    Microsoft released a library for making native Windows apps with React Native: https://github.com/Microsoft/react-native-windows https://github.com/Microsoft/react-native-windows
  • eadmund 9y ago
    > I think people should be paying more attention to the core concept of React Native, which is having a view layer that is completely native and a bridge that connects to a javascript engine. That is indeed pretty awesome, but wouldn't it be even better were it a better language than JavaScript being bridged to? I'm thinking Lisp, or Python, or TCL, or pretty much anything other than INTERCAL or JavaScript.
    • oceanswave 9y ago
      Out of the languages you mention, I'd still pick JavaScript + typescript
• aiyodev 9y ago
  Got to the section on Javascript and could no longer take the author seriously.
  • logicallee 9y ago
    It does seem that that's what the article was written to be - there were lots of examples carefully "assembled". But I'm curious why you didn't take it seriously. Could you be a bit more specific?
    • alangpierce 9y ago
      Some issues I had with the JS criticisms: * Many of the examples seemed really contrived. Yes, JS lets you overwrite methods for specific instances (which e.g. can be useful for testing) and assign to array indexes way outside the existing bounds, but I haven't seen either of those cause problems for people. * The author repeatedly complains about missing features that would only make sense in a language with a type system. Many popular languages used by professionals are dynamic-typed. It's a legitimate way to do programming, and sacrifices safety in favor of flexibility. And just like how most static-typed languages compile to a dynamic-typed target language (usually assembly), JS has two good static type systems (TypeScript and Flow) that compile down to JS in the same way. * Many of the criticisms apply to many programming languages, and I expect someone comfortable with a few programming languages wouldn't find them too surprising when learning JS. Examples: reference values, implicit exceptions, IEEE floating point edge cases, blockless `if`, switch fallthrough. And many of the examples are disallowed by the default configuration of eslint, which basically everyone uses. * The criticism of ES2016 seemed really disingenuous, and ignored the vast majority of the progress made to the language in that year. There just happened to only be two features that year that crossed the finish line to make it into the spec. ES2015 and ES2017 were both much more significant, and the JS committee meets regularly and is actively working on about 50 different proposals simultaneously. That said, some of the criticisms of JavaScript were certainly legitimate, like the `map(parseInt)` example and the `null`/`undefined` issue (although it still is a meaningful distinction that's occasionally useful).
      • 9y ago
• bernadus_edwin 9y ago
  When i move to RN, Swift 3 is very slow on build time. Xamarin not support instant run. So i move to rn, although it feel not complete product
• roywiggins 9y ago
  NaN !== NaN is not a JavaScript thing, it's a IEEE754 standard thing. The bulk of the gripes about JavaScript are entirely fair, but I'd think that most people who use React Native would be aware of them already?
• tentativeuser 9y ago
  Is it true that React Native cannot be integrated with an existing Swift/Obj-C codebase? For example, say that you want to implement login/register on top of an existing Swift codebase. This is possible, right? (May not have understood OP correctly.)
  • tentativeuser 9y ago
    Nvm! It is possible: https://facebook.github.io/react-native/docs/integration-with-existing-apps.html https://facebook.github.io/react-native/docs/integration-wit...
  • tspike 9y ago
    It's definitely possible but hard to do well; dependency management is a pain.
  • mamcx 9y ago
    Is truly hard. And not even thing in use it for Xamarin or something else. I love to have a react-native-like for just the UI and do my code on swift/F# for the rest.
  • crispinb 9y ago
    It depends what you mean 'on top of'. If you mean adding some RN to an existing app, that is conceptually easy but practically quite messy (https://facebook.github.io/react-native/docs/integration-with-existing-apps.html https://facebook.github.io/react-native/docs/integration-wit...). If you mean adding native modules into an essentially RN app, that's practically very simple (https://facebook.github.io/react-native/docs/native-modules-ios.html https://facebook.github.io/react-native/docs/native-modules-...) but still requires some conceptual care (like any API design).
  • bernadus_edwin 9y ago
    You can use 5 line of code to push uiviewcontroller from xib or storyboard. Easier than encapsulate native code to library rn. Xamarin cannot do that
• briandear 9y ago
  Is it not true that a cross platform system necessarily results in an application that is the lowest common denominator in terms of devices? How does React Native work with ARKit for example? How does React Native take full advantage of the hardware if it has to be cross-platform compatible? The Facebook iOS app is slow, bloated and occasionally glitchy. A company like Facebook seriously doesn’t have the resources to make Android or iOS native applications? Because React isn’t “native.”
  • oakesm9 9y ago
    I believe the majority of the main Facebook app is still "real" native code. It's certainly possible to use any native API you like when using React Native. You can easily write a modules to bridge to native APIs, but you need to be comfortable to drop into native code when required and do that work for both android and iOS. If you don't feel able to do that, you'll be limited to the libraries that others have already written. It's not hard to do though.
  • rimliu 9y ago
    With reagard to Facebook app I guess the problem is that they have too many resources, i.e. gazillion of people working on different parts without even checking what others are doing so you get a bunch of duplicated, triplicated, whatever, code, a bunch of dead code and stuff like that. They also use some kind of generators and run into problems like having too many classes for Xcode to handle. From everything I've heard of it you don't want to do things the way FB does them with their app.
  • crispinb 9y ago
    > How does React Native take full advantage of the hardware if it has to be cross-platform compatible? It's easy enough to add a native module to address specific hardware -- so easy in fact that you can usually find one already done (ARKit for example: https://www.npmjs.com/package/react-native-arkit https://www.npmjs.com/package/react-native-arkit). As with all 3rd party library use you have to do your due diligence of course. The more of these you use, the less 'cross-platform' your code becomes. If there's enough similarity in hardware between platforms, you might write (or find) a react-native library offering a javascript/RN API that addresses native apis under the hood. This is done with animation, for example. > A company like Facebook seriously doesn’t have the resources to make Android or iOS native applications? I'm can't imaging they don't have the resources, and know nothing about FB or its motives. But if I was managing a large cross-platform app, I'd definitely want the largest number of developers I possibly could have communicating via a commonly understood codebase, rather than via meetings and specs.
• alex_escalante 9y ago
  I found funny to say Javascript moves slowly when a lot of people is using async/await, generators, destructuring, etc… everywhere right now. And then it dismisses Flow and even Typescript right away, yeah sure… And the conclusions seem to favor Phonegap, really? Xamarin might not be that bad but doing really nice UI on both platforms require two separate projects (or modules at least). My bets are still on Javascript :)
  • LeoNatan25 9y ago
    Right, much better to have a terrible UI on both platforms using React Native. A great bet. If you insist, you can use Xamarin Forms and have an equally terrible UI on both platform as RN.
    • madeofpalk 9y ago
      idk, maybe try not building a terrible UI?
  • buchanaf 9y ago
    This was the comment that initially made me kind of shrug the article. It's like Javascript can't win. It is either moving to fast or moving to slow. Anyone who has been working with Javascript for the past couple of years (JS exclusively, not the ecosystem) would never say that the language itself is moving slowly. As much as these features might "bloat" the language, they provide some much needed and much desired elegance.
• Keyframe 9y ago
  I come from a bit old school, C world, so excuse the naive question. Is it possible to build both a desktop (Linux/MacOS/Windows) and mobile (tablet and phone, android and IOS) application from same codebase (with slightly different codepaths for UI specifics) with React Native or something similar? I see Xamarin is almost there, but no Linux. I have a need for an app that is mostly word-processing oriented in nature with some interactive graphing and drawing, some displaying, creating and drawing on top of PDFs too. I'm looking for easiest path to create something crossplatform AND performant (and possibly easy on the battery).
  • tspike 9y ago
    Why not just go with C++? You'd still need UI code specific to Android, iOS and Qt, but you could keep your logic layer shared between all of them.
    • crispinb 9y ago
      As a freelance developer at the low end of the market (ie. where most apps and developers live), I can assure you that the logic layer is usually so small that the benefits of making only it cross-platform would be minimal. Most of the code in most of my apps is UI code. RN saves me roughly 80% compared to two entirely separate native codebases. A cross-platform business logic core saves me perhaps 20%.
      • tspike 9y ago
        Sure, I agree for a greenfield social/mobile/local mobile app, RN makes a lot of sense. > both a desktop (Linux/MacOS/Windows) and mobile (tablet and phone, android and IOS) application from same codebase... word-processing oriented in nature with some interactive graphing and drawing, some displaying, creating and drawing on top of PDFs ... definitely doesn't fit that description. At that point, your choices are JS with RN, React and Electron or C++. For custom graphics rendering and editing, JS would be a very odd choice.
        • 9y ago
• kevinsd 9y ago
  (Disclaimer: Using RN in production) The author listed some very legit points that RN is lacking and I share the same pain or complaints. You can beat up any tech with its shortcomings and that will be a good read. But arriving at a conclusion that something unjustified is better is logically flawed.
• grandalf 9y ago
  This article is definitely FUD, there are a few irritating things about React Native, but I think it's still far preferable to native development for most apps. I'll list the annoyances: - npm is a mess, and many libraries in the ecosystem handle sub-dependencies improperly. Facebook has contributed to yarn but has not established a very clear contract for what a properly organized package should be. Thus it is not possible to easily determine which package or sub-package, or sub-sub package (etc) is misbehaving. I estimate that this issue has eaten up easily 10% of the productivity gains that React Native has offered. Facebook generally ignores the github issues about this stuff, in spite of hundreds and hundreds of users having these issues. - Updating to a newer version of React Native is cumbersome. There is a utility called react-native-git-upgrade which often fails to reconcile changes in the ios-specific configuration files. Much of this is due to problems with XCode (not sure how anyone tolerates using that). Compared to simple makefiles XCode's system that react-native interacts with is horribly brittle. - Important libraries are not embraced by Facebook. Things like camera support are not included in React Native's scope, so third party libraries exist, yet often lag because the developer can't make time to keep up with pull request. Facebook should hire the top 15% of community contributors to maintain those projects in-house. Right now probably 30-50% of community libraries are not compatible with the latest stable React-Native. Facebook should realize that library maintainers do not have enough time to properly maintain these libraries and should offer more support and guidance, not to help the maintainers as much as to help people trying to use open source libraries from the community. - Some of the React Native code is pretty ugly. A few times I've had to debug issues and some of it looks like it was written very rapidly and could use a refactor for clarity and ease of debugging. Not the core algorithms stuff, just the bundle management stuff. But in spite of all this I'd still use React Native on a new project. Most apps that aren't strongly architecture-driven could be written in a day or two. It's pretty amazing.
• bkovacev 9y ago
  Could be a bit off-topic here and I hope that my tone is not extremely negative, but why is there a constant "Why we/i/should are/am/should insert possible negation insert a random action and why should you" trend in the professional blogs (not saying this author does the why should you part)? Titles are getting hideous and repetitive. I sincerely hope that this tone could be changed to something more meaningful/technical/constructive rather than listing things why you are or you are not doing something (while this author definitely goes into detail). I definitely endorse freedom of speech and thought, but unless one is a vetted expert in the matter, one should avoid making these blog posts. I'm not the best chef in the world and I do things a certain way, but I do not go around the world telling people that they should do it my way.
  • ksrm 9y ago
    Technical blog titles considered harmful? :)
• ojr 9y ago
  If you want immutable data structures with React/React Native learn Redux with Immutable.js, it has a learning curve but will solve some of your problems
• deleted 9y ago
  [deleted]
• betoharres 9y ago
  dude lost me after pointing about IDE. Wtf, this is not an advantage. This sounds like a "microsoft" arguments. You want to compare productivity? Have you seen how many ready-to-use components there are in RN community? This is the real productivy advantage, not an IDE. But I aggree with all the problems of javascript, they were my excuses to not learn javascript, and here I am, writting RN apps. Things happens in RN world man, you gotta move to the winning side and leave your pride. Get over it.
• mjmsmith 9y ago
  Shorter than the React code, I'm not seeing a big win other than the need for an explicit render() in didSet, which also allows for more fine-grained control if needed. class ViewController: UIViewController { let indicatorView = ConnectivityIndicatorView() override func viewDidLoad() { super.viewDidLoad() indicatorView.frame = CGRect(origin: CGPoint.zero, size: CGSize(width: 20, height: 20)) view.addSubview(indicatorView) } } class ConnectivityIndicatorView: UIView { var isConnected: Bool = false { didSet { render() } } override func didMoveToSuperview() { super.didMoveToSuperview() isConnected = arc4random()%10 > 4 } func render() { backgroundColor = isConnected ? .green : .red } }
  • gunn 9y ago
    Here's a more canonical version of the exact same logic in react: const Root = ()=> <ConnectivityIndicatorView/> class ConnectivityIndicatorView extends Component { state = { isConnected: false } componentDidMount() { const isConnected = Math.random() > 0.5 this.setState({ isConnected }) } render() { const backgroundColor = this.state.isConnected ? 'green' : 'red' return <View style={{backgroundColor, width: 20, height: 20}}/> } } And here's how I would actually write it in my own app: const Root = ()=> <ConnectivityIndicatorView isConnected={Math.random() > 0.5}/> const ConnectivityIndicatorView = ({isConnected})=> { const backgroundColor = isConnected ? 'green' : 'red' return <View style={{backgroundColor, width: 20, height: 20}}/> }
• iroq 9y ago
  >There is a const operator, which helps ensure primitives don’t get mutated. But anything that’s not a primitive is as malleable as jell-o Making so many errors in a sentence about basic language features, when a big chunk of OP's article is argumenting that React Native is bad because JavaScript is bad... Maybe it would be less bad if OP actually learned the language?
  • savanaly 9y ago
    >Mutating a primitive Makes me picture some language where you write "1 = 2" and from then on in your code all 1's are 2's.
• corn13read 9y ago
  tl;dr: I really don't like RN and wasted a ton of time trying to talk people out of it for mostly unfounded reasons that won't affect 99% of users in any meaningful way.
• corn13read 9y ago
  tl;dr: I really don't like RN and wasted a ton of time trying to talk people out of it for mostly unfounded reasons that won't affect 99% of users in any meaningful way.
• vbezhenar 9y ago
  Honestly the only big plus for React Native is that it allows to make both iOS and Android apps at the same time. This is huge. I wrote one app and I'm writing second one and I can't say that it's something particularly better than Objective C, for example. May be for very big apps React would win, but for small and moderate apps I feel that React doesn't provide a lot of advantages, but, again, having to write 2x less code is just huge. I don't know Android at all and I released Android version.
• nathan_f77 9y ago
  The patent stuff doesn't seem very important to me. You might not like it in principle, but I don't think it's going to affect you. The author mentions Flow as a typing solution to solve some of the problems with Javascript development, but didn't like it because you can still write code that crashes if you ignore the warnings. They also complained about the lack of immutability, and mentioned Immutable.js, but weren't happy with that. They went on to say that most of these problems they mentioned are already solved with libraries, but ... libraries are bad? I didn't really pay attention to the huge Javascript rant in the middle, but I've heard it all before, and I totally disagree. I've started to realize that I prefer ES7 Javascript with Flow or Typescript, jest, babel, webpack, etc. I think I actually enjoy writing it more than Ruby or Swift. I really like react-native-web [1]. I've used it to build an app that runs on all mobile devices (iOS, Android, Windows Phone), as well as on the web. There's a lot of quirks and workarounds, but it was actually a lot easier that I expected. Even if you just use plain react on the web, it's easy to write re-usable components and code. They also mentioned hot reloading. If I wrote an article titled "Why I'm a React Native developer", the content would just be the words "Hot reloading." I spent a year developing a native iOS app with Swift, and I never want to go back to waiting for my code to compile. [1] https://github.com/necolas/react-native-web https://github.com/necolas/react-native-web
  • inimino 9y ago
    Unfortunately "I don't think it's going to affect you" is not a strong legal argument and it's hard to dismiss legal risks that so many other companies are taking seriously. I do like React, but the legal uncertainty is a significant downside.
• PaulRobinson 9y ago
  Our legal team at work (an e-commerce player with 9-figure revenues that's raised 8-figure rounds over the years), are currently looking at React's PATENT clause. There is a dependency tree here around whether you currently (or plan to in the future) have any patents. If you don't and you never do, then how can Facebook infringe it in a way whereby you'd want to sue? And then there is the cost of suing. We seem to be reckoning it would cost around $1m to start a serious action against FB, so what does the cost of replacing React look like in that sort of scale? We've costed that, in broad strokes. So on paper, it all looks like we're fine, right? But... But... Here's where they take pause: 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 [...] Subsidiaries? We don't have any of those. "Corporate affiliates"? What does that mean? Oh, it's anybody who owns at least one share in us, or we own one share in them. Wait. What? We have business angels, founders, multiple VC firms and other investors. Do any of them have patents that Facebook might infringe on? What about future investors or people who we might want to be acquired by? Could we have an acquisition blocked because the potential buyer has a war chest of patents they value? And "agent" means external law firms too, right? So if any of the companies we use for advice on an on-going basis get involved in any patent action, what does that mean for us? Suddenly it becomes this huge sprawling mess. Risk aversion is important when you're dealing with a company that is already carrying a 9-figure valuation. We're trying to find a way around it. As an engineer I brought it up with Legal because I want clarity for colleagues and myself: we want a green flag. Unfortunately, in doing that, we may have brought enough scrutiny to it that they are going to tell us to stop using it. If/when that happens we'll talk about it and share that information. In the meantime, we continue to use it, but we're doing so with caution, and we accept there may be a re-tooling cost.
  • oceanswave 9y ago
    Microsoft uses React on office/outlook.com and they're much bigger than you
    • PaulRobinson 9y ago
      1. They have more money too, they can afford to take risks 2. They probably already have a patent agreement in place with FB not to sue each other 3. It's perfectly possible nobody in MS has had this actually cleared with their legal team. You can't assume they have.
• brad0 9y ago
  Why is it that we have to bring web technologies to the native platforms rather than using native platforms on the web?
  • tuukkah 9y ago
    The web is open, standardised, has the mindshare and the runtime (browser) is everywhere. There have been initiatives to bring e.g. Qt or GTK to web, but no success AFAIK.
    • brad0 9y ago
      Yeah you're right. Open standards makes sense. It's a shame that no one takes something like the old Android codebase and makes it for web in the canvas. Is that even possible?
  • chr1 9y ago
    We are doing both, see webassembly, it's just that web tech is simpler and there are more people who enjoy it, so it is used more often if performance requirements allow.
  • deleted 9y ago
    [deleted]
• user5994461 9y ago
  Clearly, that guy despises javascript with a passion. He should get a job that doesn't require him to ever come in contact with javascript.
• ups101 9y ago
  TL;DR: "react native sucks because javascript". So much else I wanted to know from an experienced iOS dev, like: - How is perf in a large app with lots of network IO? - How does animation/ transition fit with reacts render loop and how does it perform, especially during network IO? - How much is lost from not being able to do multithreading? - How hard is it to achieve the last 20% fine tuning of feel and perf? - How much flux is the community driven deps typically causing? - Is memory management an issue? GC stutters, leaks? - Do some UI parts simply not scale well enough, requiring native code instead? e.g. infinite scrolling, charts, complex transitions? - How mature is the tool chain? Build time? - Frequency of breaking changes from core? from common deps? Cost of staying up to date? Developing in JS, with all the pros/cons of the JS language, is the very premise of the react native deal. Most issues raised would apply just as well to any web app.
• z3t4 9y ago
  In JavaScript it's only the primitive objects (Number, String, Boolean, null, undefined) that are "by value". Everything else is "by reference". And when you write {foo:1} you create a new object. So it's logical that array.includes({foo:1}) is false. You can however point {foo:1} to a variable, and then use that variable as a reference, eg. var foo = {foo: 1}; array.push(foo); array.includes(foo);
• z3t4 9y ago
  > In JavaScript, functions don’t have a return type, you don’t know what can be returned by the function Do engineers actually depend on the compiler to save their ass and don't bother looking up in the documentation or reading the source code to see what a function returns !? No I don't think so. There's a saying that every bug that ever existed in a static typed language actually did pass the type checks. If the compiler finds a bug it's rather luck that the two parameters passed in the wrong order was not both of the same type, and not because of better language design. If you don't know what a function returns, you can say "bad documentation", or "bad code", but don't blame it on the language.
• z3t4 9y ago
  > What’s nothing? I know the == operator drives people crazy sometimes, and you are told to use === but if you actually understands what == does it's a convenience that null==undefined so you don't have to type if(foo == null || foo == undefined). You could argue that having two (or with false it's three) types of "nothing" is confusing, but for me they mean different things. undefined means it has not been defined, null means it explicitly "nothing" and false means it's "not true". And for convenience you can write if(foo) to check for them all.
• z3t4 9y ago
  You can laugh at JavaScript because of all the fun and stupid things you can do with it like writing entire programs with just {[( but with meta programming and operator overloading that is common in many "serious" languages there are even more "WTF" possibilities.