Program where the plug will be, not where it was

In 2013, from the birth of Christ, the idea that phones with ARM processors would launch high-grade JavaScript as quickly as desktops equipped with x86 caused laughter. In those old days, three years ago, the iPhone 5 was about 10 times behind in power. It seemed that nothing could change in the near future .

But everything has changed. The new iPhone 7 launches JavaScript, as measured by the JetStream benchmark , FASTER than the fastest MacBook today (not pro and not Air). The best 5K iMac with a 4GHz i7 processor is now only twice as fast as the 7th iPhone in this test. ARM processors are improving at a completely insane speed. Moore is relaxed with the desktops, but runs like crazy in a mobile world.

The speed of progress has shamed many predictions of the future, but this particular example is still striking. Three years ago is not so long ago! Since that time, we have come from "an order of magnitude worse" to "faster than most laptops."

But more importantly, metrics and benchmarks are how the consequences of a performance jump will affect not only the capabilities of the phone, but also the overall strategy.

Here is a quote from 2013:

Clarify: on the phone it is possible to do teamwork in real time. But that's just not possible with javascript. The difference in performance between native and web applications is comparable to the difference between FireFox and IE8: it is too big for serious work .

There is no more difference. So, apparently, now iPhone 7 is officially suitable for serious work ;-)

And that's the funny thing. In 2013, we made an iPhone app for our Basecamp collaboration tool . We used javascript and web in combination. We love having fun at work, but it seems to me that the result was still Serious Enough.

We used the mobile web in the heart of our native applications, and at the time it was a risky move. Facebook Scar, who abandoned HTML5 in favor of net native in 2012, was still too fresh in the memory of those who worked at the intersection of the web and native code. And, frankly, I had to make compromises. Everything was not as fast as in the native version, but it was fast enough .

And it was in times of "difference in order"! Today, the performance of this strategy is not just good enough, it is so high that it can be awesome. Or, in other words, is not a problem.

It is clear that the performance of the seventh iPhone is not yet a common future. In particular, Android still has room to grow , but even with lower rates, they are still in the zone of habitable performance. In an area where other things are much more important.

I am not saying that a hybrid approach does not lead to compromises. There are still some moments that are felt less natively, and they lack this little detail to be perfect. And, of course, there are applications, like covered 3D games, where you need to squeeze out all the possible drops of performance. But in today's environment, the number of applications that can be created with such a hybrid web / native approach, and which will simply go off cool, is undoubtedly very large. This number is much, much larger than in 2013.

The productivity benefits of developing multiplatform services using a hybrid approach are astounding. We simply could not make Basecamp 3 in 18 months and cover the web for the desktop, web for mobile devices, native iOS, native Android and email without a hybrid and a magnificent monolith . At least, without inflating the development team. These are five platforms and 200+ separate screens.

It reminds me of the situation that I described in the Ruby article has been fast enough for 13 years . Increasing productivity means more than just getting our stuff faster. It also means that we can make new things in new ways. In ways that were impossibly slow before. Ways to make people cry who fit 4 kilobyte full computer demos . But these methods, however, increase the overall productivity of the masses.

It also reminds me of the story described by John Carmack, the legendary programmer, creator of Doom and Quake. When he was working on the game, he needed to write code not for the current performance at that moment, but for three years ahead, because the game was going out after three years. If he had programmed for today, the game would have been outdated upon exit. So Doom and Quake always looked cool.

Think about it when you make an app today. Are you programming for peace 2013? Or 2016? Or 2018? Program where the performance gag will be, not where it was.