1. 10

  2. 24
    var weAreConnected = Math.floor(Math.random() * 10) > 5;
    if (weAreConnected === true) {
        isConnected: true
    else {
        isConnected: false

    What? It’s difficult to take the article seriously after that. Seems like a purposely obfuscated example for saying:

    var connected = Math.random() > 0.5;
    this.setState({isConnected: connected});

    And it’s not about not being fluent with JS either. This is just basic boolean stuff.

    1. 6

      The connected variable isn’t reused anywhere either so couldn’t you just do this?

      this.setState({isConnected: Math.random() > 0.5});

      I’d use a ternary statement for setting the color too, but I know some people don’t like those.

      1. 4

        The connected variable isn’t reused anywhere either so couldn’t you just do this?

        Yep, absolutely, in this simple case, i wouldn’t mind either way. But splitting the calculation into its own variable, even though the variable is not reused anywhere else, has some benefits:

        1. Each line is does a one simpler thing: first determine whether we’re connected using a random value, and then set the component state to that.

        2. The code is more debugger-friendly. You can easily tell the value of the connected variable before setting the state by stepping between the two lines.

        I’d use a ternary statement for setting the color too, but I know some people don’t like those.

        Well, ifs in JavaScript are not expressions, so i’d use ?: too :)

        1. 1

          I’d use a ternary statement for setting the color too, but I know some people don’t like those.

          Do you know why ternary statements would be frowned upon? I don’t like nested ternaries, but other than that I find them extremely useful and they aren’t really that hard to use…

          1. 3

            It’s because they’re often used with poor taste. I use them for one-line assignments all the time, but they’re sometimes used nested or with conditions/values complex enough that they span multiple lines.

            1. 1

              The new do expression in the early parts of the standardization process will make this process much nicer if it makes it.

            2. 2

              I had a CS professor from Bulgaria in college that would always chastise me for using them in C telling me “You’re being clever; be clear, not clever.”

              1. 2

                To me, any C code is clever, not clear.

          2. 6

            You’re just too much of a hacker. Not everybody can write this kind of code.

          3. 4

            I have a lot of mixed feelings about this article. There are some points that are well-made, but others…less so.

            Here for instance:

            p.isImmortal = function() {return true}
            console.log(p.isImmortal()) // true
            console.log(p instanceof Person) //true

            Even though you’re replacing a method on the Person class, it still conforms to the signature of the author’s original function. There are a lot of ways to demonstrate type issues here, but this isn’t one.

            var foo = 32
            var bar = foo 
            var otherArray = [bar, 23]
            console.log(otherArray.includes(foo)) // true

            Here I’m not even sure why the author expects this to be anything but true.

            But mostly where this article falls apart for me is that it’s just an anti-javascript rant masquerading as an opinion-piece about React Native, and not even a particularly good one. I dislike Javascript as much as the next person, but given the article’s purported subject, that’s not what I was expecting nor was it particularly useful in the context of this article.

            1. 4

              Why the heck do people not want to write native iOS apps (using Swift/Obj C)? I would imagine that doing so gets the absolute best performance out of any iOS app, if done carefully. It seems like there is a big problem here that Apple must address in making their development workflow simpler for their native developers.

              1. 12

                I hadn’t touched Objective-C since GNUStep and was able to help our mobile dev with a multi-threading bug after about 5 minutes of familiarization with Xcode.

                Nothing’s perfect and I’d definitely prefer to use a typed language and a GUI toolkit with less, uh, GUI and boilerplate, but it didn’t seem bad at all.

                I think this is web devs trying to stay in their comfort zone (which is an ongoing theme if you look around).

                1. 6

                  React Native (and similar projects) is a way of creating (mostly) cross-platform applications for iOS and Android. At least for some people, it’s about practicality, not familiarity.

                  1. 3

                    Also for most web devs React isn’t the most familiar thing in the world.

                2. 10

                  How does this help with running on Android? I can’t afford to hire a Swift and a Java and a web developer for my system.

                  1. 8

                    React native offers significant cycle-speed improvements because you can hot-load code from development (keeping application state) in 2-3 seconds, while still using native controls written in swift/objC.

                    Compare that to 30-90 seconds of build & deploy followed by restarting the app and losing state (and spending another minute getting back into the correct state to test your change).

                  2. 3

                    One of my favourite bumper stickers proclaims:

                    Safety is no accident

                    At first sight, the wit in this quip lies in its double meaning. We are offered a definition of safety as the absence of accidents and the suggestion that it is the product of a set of safeguards.

                    Is safety the product of the safeguards baked into your car, such as seat belts and airbags, or of your safe driving?

                    The answer, of course, is both in equal measure.

                    Drivers should prefer cars that have the widest amount of safeguards built into them. Not because they make driving easier, but because they decrease your chances of having a preventable accident.

                    Likewise, a programming language should offer safeguards against programmer error.

                    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.

                    Really bad flashbacks reading this to trying to add safety to a Javascript codebase and getting pushback, “why don’t we just teach everyone to do the right thing?”