John Gruber Reviews the iPhones 7

At DaringFireball this morning, Gruber published his review of the new iPhones 7 that will hit retail this Friday. It’s a lengthy review but very well thought out, and I recommend reading it in its entirety.

Regarding the home button no longer being a physically pushable button, John observes that it’s likely due to the fact that so many iPhone users in Asia and elsewhere are loath to use the button because it’s considered breakable since it’s a moving part.

I think Apple designed this no-click button in the hopes that it will get these people to use the home button as intended. But now we’re all stuck with a button that doesn’t feel as good. […]

It’s a minor tragedy if I’m right that this is why Apple has made the home button worse for the rest of us […]

Something I’ve noticed about Apple, though, is that it often has more than one reason for making a product decision such as this one. I think Gruber’s onto something, but I can’t help wonder if there’s more to it than this. In a MacRumors article that John linked to, we read:

Apple has been working on developing touch and display driver integration (TDDI) chips since 2015, which would let the Touch ID fingerprint recognition system be embedded directly into the display, allowing for the elimination of the Home button.

I’m not sure that we’ll be seeing the home button go away completely in next year’s iPhone. It does sound plausible, however, that the next iPhone will have a screen that goes edge to edge. You wouldn’t want a physical button on something like that. Even if it were technologically possible, it wouldn’t make any sense. Apple is beginning the transition to the 2017 iPhone with this new home button in the iPhones 7. I suspect Asia has something to do with this change, but I think next year’s new iPhone has a lot to do with it — I daresay it’s the primary reason.

Regarding whether to get the iPhone 7 or the iPhone 7 Plus, Gruber nails it:

It all comes down to the camera. And the camera decision all comes down to Portrait mode. And Portrait mode isn’t available yet.

If Portrait mode had been bundled in the initial release of iOS 10, I might have preordered an iPhone 7 Plus. A few months isn’t that big of a deal after the fact, but it sure feels that way at the time.

This is outside the scope of Gruber’s article but there’s another problem with the Plus model. Not only is its software going to take a couple months to be fully realized, but the device itself is hard to get right now. Several of us got up Friday at midnight PDT1 and tried to order the iPhone 7 Plus with no luck. The online Apple Store opened its doors somewhere around 12:10 AM2 and the Plus models became unavailable just a few minutes afterwards. There was a window of fewer than 5 minutes in which you could preorder an iPhone 7 Plus. It will be weeks or possibly months before it becomes available to everyone. That’s actually a real problem if you’re on Apple’s iPhone Upgrade Program. With this program, you cannot upgrade to the new iPhone until you’ve made 12 payments on your current one. In other words, if you pick up the iPhone 7 Plus two weeks after it initially hits retail, you’ll have to either wait two weeks after next year’s iPhone hits retail in order to get it, or you’ll have to make an extra arbitrary payment. It would only be $40, give or take, but it’d be a real nuisance. There’s no way I’m doing that. Because Apple has such low availability of the Plus model compared to its demand, it doesn’t make sense using the iPhone Upgrade Program to buy it if you’re wanting the new iPhone each year as soon as it comes out. You’re better off paying cash for it and then selling it a month before the new one is announced, which gets messy.

  1. Since midnight is the start of the day, that’s 12:00 AM PDT. ↩︎

  2. Apple has launched iPhones before. It confuses me that it doesn’t have a deploy process that’s timed closer to the stroke of midnight. If your deploy process takes 10 minutes, you start at 11:50 PM, not 12:00 AM. ↩︎

Kyle Richter on Working Remote

From the Martian Craft blog, Richter (CEO) weighs in on remote work:

A good deal of the workforce needs to be constantly pressured to work. These are the same people who waited until the night before a paper was due in college before starting it. Remote work is a dream life for the lazy, they can get by with the bare minimum work and perhaps never be noticed. […]

Remote work inherently attracts the lazy and the unenthusiastic. However remote work also attracts some of the smartest, motivated, and passionate people on the planet.

This post is one of the best things I’ve read about remote work.

Apple's Removal of the Headphone Jack from the iPhone 7 is Great for Athletes

This afternoon I rode 26 miles on my bicycle. I past several solo runners, two of which had Apple EarPods. One of them was holding his iPhone in his hand while running. I sympathize with this. I try to run a 5K at least once per week and that’s how I listen to audio too. I listen to podcasts with EarPods while holding my iPhone in my hand.

I can’t speak for this runner, but the reason I hold my iPhone in my hand instead of letting it bounce in my pocket is because when it’s in my pocket and I’m not babying the cord, the cord bounces around and threatens to pull the EarPods out of my ears. It’s really nerve racking; the faster I run, the worse it gets. A 9 minute mile might be tolerable, but a sprint pace at 6 or 5.5 minute miles becomes unbearable. Even with my iPhone in my hand, the swinging weight of the cord tugs at my ears. If you’ve ever run with EarPods you know exactly what I’m talking about.

Having wires coming out of your ears is unnatural in any environment, but I argue it’s especially cumbersome when running. These AirPods are going to solve a true pain point, and I can’t wait until they hit the market next month. I still plan to run with my iPhone, but at least it will be able to stay in my pocket. Yesterday’s AirPods announcement is great news for runners.1

My only regret with the AirPods is that Apple isn’t shipping them in the box as the default earbuds. We don’t need wired EarPods that connect to Lightning, and we certainly don’t need an adapter that connects to a headphone jack. Make people pay extra for that stuff.2

  1. As a tangent, until I’ve seen how accurate the Apple Watch Series 2 is with its GPS, I actually think that the AirPods are more pertinent for serious runners than the new watches are. The reason for this is because the Apple Watch Series 2 uses Assisted GPS (aGPS) instead of only pure GPS. The delay you get on a Garmin GPS watch when you’re about to start a run is a nuisance but it’s what makes the data so much more accurate than the aGPS on a smartphone or on this new watch. I’d love to be wrong, and I’m going to be looking for Strava activities with this new watch to compare, but I just don’t see it being good enough to replace my Garmin Forerunner 10. Here’s a good chart explaining the differences between GPS and aGPS. ↩︎

  2. That’s what the purist in me wants but of course Apple did the right thing. They’ll get plenty of kickback and flack for their move as it is, and they’ve chosen the route that will cause the least amount of problems for people including me who have $200 Beats headphones that require a headphone jack. ↩︎

One More Thing About Arrow Functions in ES6

Arrow functions make it possible to write single-line functions with no curly brackets.

1
2
let print = (msg) => console.log(msg);
print("Hello world"); // outputs "Hello world"

The fact that JavaScript now has this syntax makes being a JavaScript developer a real power trip. If you study C and Java in college, this doesn’t look anything like that. If it wasn’t already, JavaScript is now one of those languages that to the uninitiated is something “those weird people” mess with. I guess I’m one of those now.

The thing is, if you look at the emerging landscape, it’s filled with Ruby and Swift and ES6. We’re moving away from stuff that looks like straightforward derivatives of C.

Arrow Functions and the “this” Keyword in ES6

Go to ES6Fiddle, paste in this ES5 code, and run it:

1
2
3
4
5
6
7
8
9
10
11
var obj = {
  fn: function() {
    console.log(typeof this);
    return new Promise(function(res, rej) {
      console.log(typeof this);
      setTimeout(res, 1000);
    });
  }
};

obj.fn();

This will output the following.

1
2
object
undefined

Next, paste in this ES6 code.

1
2
3
4
5
6
7
8
9
10
11
const obj = {
  fn: function()  {
    console.log(typeof this);
    return new Promise((res, rej) => {
      console.log(typeof this);
      setTimeout(res, 1000);
    });
  }
};

obj.fn();

This will output the following.

1
2
object
object

What’s going on here? In ES6, we’re using an arrow function. As Dr. Axel Rauschmayer points out regarding arrow functions in ES6:

Their this is picked up from surroundings (lexical). Therefore, you don’t need bind() or that = this, anymore.

This is really powerful. I’ve done both bind() and that=this quite a bit in my lifetime of ES5. You might be wondering however what you’d do if there’s ever a time that you need to access the inner this. As far as I can tell, this just isn’t possible with arrow functions. Dmitri Pavlutin writes:

this in JavaScript is a powerful feature. It allows to change the context depending on the way a function is called. Frequently the context is the target object on which invocation happens, making the code more natural. It says like “something is happening with this object”.

However the arrow function binds the context statically on declaration and is not possible to make it dynamic. It’s the other side of the medal in a situation when lexical this is not necessary.

Sometimes, the old school ES5 syntax is a must, apparently. Good luck with lint rules that don’t like this traditional function expression!

Anti-patterns in JavaScript Promises

From the bluebird docs:

It is easy to fall into this when you don’t really understand promises and think of them as glorified event emitters or callback utility. […]

In the explicit construction anti-pattern, promise objects are created for no reason, complicating code.

Unlike AngularJS, React does not have a built-in promise library. jQuery has one that people often use, but including the entire jQuery library just for its promise API seems overkill. Lately I’ve been doing some work with bluebird instead. What I love about bluebird’s anti-pattern docs is that they tell you when you shouldn’t even be using a promise library at all. If you’re interacting with an API that returns a promise, there’s no reason to return anything other than that promise in a wrapper method. It’s only when you’re in a world of callback functions that have no promises in scope that bluebird becomes necessary. A lot of the time, we write more promise stuff than we need to get the job done.

I can’t think of a faster way to instill trust in developers than to inform them of when your library isn’t needful. Kudos to bluebird.

Elliot Jay Stocks on Apple vs Google

Last Saturday, Elliot Jay Stocks wrote a Medium piece on his disenfranchisement of the Apple ecosystem.

The result is two-fold: firstly, from a software perspective, Google-authored apps have all but replaced Apple’s defaults on my iPhone; secondly, for the first time ever, I find myself potentially choosing a Google phone over an Apple phone — a choice that represents not just a one-off hardware purchasing decision, but a first tentative step outside of Apple’s ecosystem and, as a result, a break in unashamed Apple fanboy-ism.

Apple’s high ground has always been their superior hardware. Here are a couple of anecdotal metrics:

  1. Year over year, more and more software developers are switching to Macs to do their work. Not just more developers, but a higher percentage of developers.
  2. The iPhone 6S, nearly a year old, is still faster than the brand new Galaxy Note 7.

Apple isn’t worried about having a monopoly on the software that runs on your devices. Its goal is to be the best at hardware and the best at operating system software. On the side, it writes enough of its own apps that the average user could use only its apps, but that’s not its goal. Apple makes its money selling hardware. Once that point of sale is over, it tries to up-sell SaaS packages like premium iCloud Storage and Apple Music, but those are side gigs compared to the hardware.

If Elliot wants to run a bunch of Google apps on his iPhone’s home screen, Apple has achieved its primary goal.

Elliot goes on:

It’s not that Apple no longer creates great products, but there’s just not that spark there anymore, is there?

If you read this article carefully, Elliot isn’t comparing Apple to Google, he’s comparing present Apple with past Apple. Where’s Google’s great spark? Where’s its magnificent product launches equal to those of Apple’s past? They don’t exist. The landscape has matured. The kinds of ground-breaking work that Apple did in the 2000s aren’t sustainable. Steve Jobs knew this back in 2007:

Every once in a while a revolutionary product comes along that changes everything. It’s very fortunate if you can work on just one of these in your career. … Apple’s been very fortunate in that it’s introduced a few of these.

We’re in a new era now, and Elliot is rejecting Apple without an equal alternative. He’s allowing the past to flavor his perception of the present, instead of looking at the present objectively.1

His conclusion:

All this is to say: if Google can be this good on a competitor’s operating system, how much better can it be in its own environment?

A rarely remembered fact is that iOS is more profitable for Google than Android is by a large margin. If anything, Google spends more talent and energy on iOS than on Android. I’m afraid that Elliot is setting himself up for disappointment, but he should give Android a try so he can see for himself. He’ll find that the experience within Google’s apps is pretty much the same, while the overall operating system runs slower and some of the frames are janky.

  1. As an aside, this is one of the reasons it’s so hard to play against a computer chess engine. The engine analyzes each stage of the game as if there were no history. The engine has no desire to continue surging forward with a previous idea that, as good as it was at the time, is now detrimental. It’s incredibly difficult for humans to have this detachment. ↩︎

Harvest 2.0

Earlier this week, Harvest announced version 2.0 of their Mac App. It’s now much more visually similar to the company’s iPhone app:

One of the biggest changes you’ll notice on a daily basis is in the forms you use to track and edit time entries. New Entry Previous versions of Harvest for Mac used two different forms for entering and editing time. In Harvest for Mac 2.0, you’ll notice we’ve used the same design for both forms. The end result makes the app much more intuitive.

Harvest is my favorite time tracking software.1 With the robust key shortcuts, I can create a brand new time entry without ever touching a mouse. I can resume a previous one with a single click to the top right corner of the screen. This is much faster than pulling a phone out of my pocket and messing with it. For professionals, Mac Apps are where it’s at, and it’s great to see Harvest give its desktop app the time and attention it deserves.

Also delicious is the fact that if you’re on a Windows, you get a Chrome extension, not an app. Harvest knows its customer base.

  1. Even though I’m an employee and not a contractor primarily, I keep track of every second I spend at my desk. It’s important to know how many hours per day are spent at a computer, and what was accomplished in those hours. ↩︎

Separation of Concerns in ReactJS

Michael Chan, in an excellent gist:

A component like this would be rejected in code review for having both a presentation and data concern.

If you’re new to ReactJs I highly recommend going through this gist. Bottom line: if you’re making an API call to a server within a component, you’re best off not having that component output JSX.

Are Native Fonts Here to Stay on the Web?

Earlier this week, WordPress announced 4.6 “Pepper”. One of the interesting things in this release was the transition to native fonts for the dashboard:

The WordPress dashboard now takes advantage of the fonts you already have, making it load faster and letting you feel more at home on whatever device you use.

WordPress is 25% of the Internet, so a lot of site owners are going to get used to this. Last month Github switched as well.

It’s too early to tell if it’s a fad or the beginning of a longterm trend.