[Перевод] Программируйте там, где затык будет, а не там, где он был
В 2013 году от рождества Христова мысль, что телефоны с ARM-профессорами будут запускать полноценный JavaScript также быстро, как десктопы, оснащенные x86, вызывала смех. В те старые времена, три года назад, iPhone 5 отставал по мощности примерно в 10 раз. Казалось, что ничего не может измениться в ближайшее время.
Но всё изменилось. Новый айфон 7 запускает JavaScript, согласно измерениям JetStream benchmark, БЫСТРЕЕ, чем самый быстрый на сегодняшний день Макбук (не про и не эйр). Лучший 5K iMac с 4Ггц процессором i7 теперь всего в два раза быстрее 7 го айфона в этом тесте. Процессоры ARM улучшаются с совершенно безумной скоростью. Мур расслабился с десктопами, но бежит как сумасшедший в мобильном мире.
Скорость прогресса пристыдила многие предсказания будущего, но этот конкретный пример все же поражает. Три года назад — это не так давно! С того времени мы пришли от «на порядок хуже» до «быстрее, чем большинство лаптопов».
Но что еще важнее метрик и бенчмарков это то, как последствия скачка производительности повлияют не только на возможности телефона, но и на общую стратегию.
Вот цитата из 2013:
Уточню: на телефоне возможно сделать совместную работу в реальном времени. Но это просто невозможно с JavaScript. Разница в производительности между нативными и веб-приложениями сравнима с разницей между FireFox and IE8: она слишком большая для серьезной работы.
Разницы больше нет. Так что, видимо, теперь айфон 7 официально подходит для Серьезной Работы ;-)
И вот что самое смешное. В 2013 мы сделали приложение под айфон для нашего инструмента совместной работы Basecamp. Мы использовали JavaScript и веб в комбинации. Мы любим веселиться на работе, но мне кажется, что результат был все же Достаточно Серьезным.
Мы использовали мобильный веб в самом сердце наших нативных приложений, и в то время это был рисковый шаг. Шрам от Фейсбука, который отказался от HTML5 в пользу чистого натива в 2012 году, был все еще слишком свеж в памяти тех, кто работал на пересечении веба и нативного кода. И, честно говоря, пришлось идти на компромиссы. Все было не так быстро, как в нативном варианте, но было достаточно быстрым.
И это было во времена «разницы на порядок»! Сегодня производительность этой стратегии не просто достаточно хорошая, она настолько высокая, что может быть офигенной. Или, иными словами, не является проблемой.
Понятно, что производительность седьмого айфона это пока не распространенное будущее. В частности, Андроиду еще есть куда расти, но даже с меньшими показателями, они все еще находятся в зоне обитаемой производительности. В зоне, где другие штуки имеют намного большее значение.
Я не говорю, что гибридный подход не приводит к компромиссам. Все еще есть некоторые моменты, которые ощущаются менее нативно, и им не хватает этой маленькой детали чтобы быть идеальными. И, конечно же, есть приложения, вроде крытых 3D-игр, где нужно выдавить все возможные капли производительности. Но в сегодняшних условиях количество приложений, которые можно создать таким гибридным веб/нативным подходом, и которые будут просто офигеть какие классные, несомненно очень большое. Это число намного, намного больше, чем в 2013 году.
Преимущества в продуктивности при разработке мультиплатформенных сервисов с помощью гибридного подхода — поразительны. Мы бы просто не смогли сделать Basecamp 3 за 18 месяцев и покрыть веб для десктопа, веб для мобильных устройств, нативный iOS, нативный Android и email без гибрида и величественного монолита. Как минимум, не раздувая команду разработки. Это пять платформ и 200+ отдельных экранов.
Это напоминает мне ситуацию, которую я описал в статье Ruby has been fast enough for 13 years. Увеличение производительности означает не только то, что наши штуки становятся быстрее. Это также означает, что мы можем делать новые штуки, новыми способами. Способами, которые были до невозможности медленными раньше. Способами, которые заставляют плакать людей, умещавших полные компьютерные демо в 4 килобайта. Но эти способы, тем не менее, увеличивают общую продуктивность масс.
Это также напоминает мне историю, описанную Джоном Кармаком, легендарным программистом, создателем Doom и Quake. Когда он работал над игрой, ему нужно было писать код не для текущей на тот момент производительности, но на три года вперед, потому что игра выходила через три года. Если бы он программировал для сегодняшнего дня, то игра при выходе была бы уже устаревшей. Поэтому Doom и Quake всегда выглядели круто.
Подумайте об этом когда делаете приложение сегодня. Вы программируете для условий мира 2013 года? Или 2016? Или 2018? Программируйте там, где затык производительности будет, а не там, где он был.
Комментарии (2)
k12th
30 сентября 2016 в 10:52
0↑
↓
БЫСТРЕЕ, чем самый быстрый на сегодняшний день Макбук
Не в том ли дело, что последний макбук выходил несколько лет назад?
GeForester
30 сентября 2016 в 10:55
0↑
↓
Не, речь о том макбуке, что с одним USB-C разъемом и на Intel Core m5.
