Программируйте там, где затык будет, а не там, где он был

https://m.signalvnoise.com/program-to-where-the-performance-puck-is-going-to-be-not-where-it-has-been-2e1c89bac058#.j3g0sp51l
  • Перевод

В 2013 году от рождества Христова мысль, что телефоны с ARM-процессорами будут запускать полноценный JavaScript также быстро, как десктопы, оснащенные x86, вызывала смех. В те старые времена, три года назад, iPhone 5 отставал по мощности примерно в 10 раз. Казалось, что ничего не может измениться в ближайшее время.


Но всё изменилось. Новый айфон 7 запускает JavaScript, согласно измерениям JetStream benchmark, БЫСТРЕЕ, чем самый быстрый на сегодняшний день Макбук (не про и не эйр). Лучший 5K iMac с 4Ггц процессором i7 теперь всего в два раза быстрее 7го айфона в этом тесте. Процессоры ARM улучшаются с совершенно безумной скоростью. Мур расслабился с десктопами, но бежит как сумасшедший в мобильном мире.


img


Скорость прогресса пристыдила многие предсказания будущего, но этот конкретный пример все же поражает. Три года назад — это не так давно! С того времени мы пришли от "на порядок хуже" до "быстрее, чем большинство лаптопов".


Но что еще важнее метрик и бенчмарков это то, как последствия скачка производительности повлияют не только на возможности телефона, но и на общую стратегию.


Вот цитата из 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? Программируйте там, где затык производительности будет, а не там, где он был.

Поделиться публикацией

Комментарии 23

    +1
    БЫСТРЕЕ, чем самый быстрый на сегодняшний день Макбук

    Не в том ли дело, что последний макбук выходил несколько лет назад?

      +3
      Не, речь о том макбуке, что с одним USB-C разъемом и на Intel Core m5.
        0
        Дело в том, что во всей железках эпл очень медленное железо само по себе. Особенно в макбуке 2016, который умудряется отставать даже от surface pro, который вообще в другом формфакторе.
          0
          и при этом стоит дороже мак прошки)
        +5

        JS уже давно достаточно шустрый, как всгда, все упирается в DOM.

          +5
          DOM уже давно тоже достаточно шустрый. Дело в приложениях, которые неэффективно работают как с DOM, так и сами по себе.
          +17
          Отличная отмазка для криворукого кодера.
          — Чего у тебя всё тормозит?!
          — Ничего ты не понимаешь! Я работаю на 5 лет вперёд!
            +10

            Ага, "Программируйте там, где затык был 3 года назад"


            То, что через 3 года компьютеры будут быстрее, не означает, что все пользователи дружно сделают апгрейд железа. У меня железо 3-4 летней давности. Можно предполагать, что через 3 года у пользователей будет полно железа, которое сегодня считается топовым, а у большинства не будет и этого.


            Если ради новой игры некоторые люди и готовы сделать апгрейд (я — нет), то вот ради очередного тормозного мобильного приложения — маловероятно.

              –1
              Вы делаете выводы на основе здравого смысла. Но для поклонников святого Джобса убеждённых пользователей экосистемы Apple это зачастую не работает. Не поменять смартфон хотя бы раз в год считается дурным тоном. Особенно, если новый смартфон трагически отличается от предыдущей модели внешним видом и это могут заметить окружающие.
              +8
              Интересно рассуждает автор. Раз айфон может переварить вас джаваскрипт — значит, всё, проблема решена. А то, что он при этом будет греться аки «Доброе тепло» и разряжаться за полчаса, потому что ему придётся задействовать всю свою мощь ради ваших «способов, которые были до невозможности медленными раньше» — это как бы уже не проблема.
              • НЛО прилетело и опубликовало эту надпись здесь
                  –1
                  То есть тут, получается такая ошибка: телефон стал мощнее, но батарейка не стала толще ( а вероятно еще и тоньше) и такие гибридные способы хоть и стали работать на устройстве, но стали отъедать очень много энергии, которой больше не стало.
                  Но, думаю, конкретному разработчику все равно, что будет с батареей пользователя… К сожалению.
                +2
                Пути необузданной эволюции неисповедимы. Очень печально конечно.
                  +2

                  Чет какой-то бред.


                  Разницы в производительности между нативными и веб-приложениями больше нет.

                  Куда бы она делась, эта разница с 2013-го года? Все стало быстрее, пропорция (разница) осталась такой же как и была. Новых js-движков или более эффктивных DOM с тех пор не придумали.


                  Когда Джон Кармак работал над игрой, ему нужно было писать код не для текущей на тот момент производительности, но на три года вперед.

                  Бедный Кармак. Он делал больше, зная что происзводительность увеличится и это займет приемлемое время. Поэтому игры были современными на момент выхода. Автор же предлагает писать менее эффктивный код, т.е. делать меньше, просто расчитывая что к моменту когда зарелизится это тоже займет приемлемое время.

                    +6
                    Представляю себе лицо пользователя iPhone 6 который сегодня запускает и использует приложение рассчитанное на то что уже iPhone 7 устарел…
                      +4
                      Ничего, купит новый:) А то иш какой хитрый! На старом айфоне вздумал остаться. П.С. сарказм
                        0
                        Доля правды в этом есть. IT-шники понимают проблему. А не-IT-шники говорят, что пора покупать новый телефон, потому что старый уже тормозит. Да и сам я уже подумываю о смене телефона, когда смотрю как у кого-то скайп запускается за 2 секунды. Никуда от этого не денешься. Разрабы стимулируют улучшение железа. Улучшение железа негативно влияет на разрабов.
                        • НЛО прилетело и опубликовало эту надпись здесь
                      +4

                      Очень странно сравнивать с Mac Book, который на intel core m3. Это мобильный процессор, наследник Atom, главными целями перед которыми является минимальное энергопотребление. Разумеется он медленный, да и сравнимый с седьмым iPhone. Но вот только я бы не сказал, что нам нем все (в том числе js) шустро работает, вот от слова совсем. Плотно им не пользовался, но судя по обзорам и тыканьям в магазине — большой айфон с клавиатурой, нежели полноценный рабочий ноутбук. А еще вызывает сомнение сравнение его с iMac с intel core i7 с рабочей частотой 4Ггц, уж слишком малый разрыв. Синтетика такая синтетика

                        +1
                        Меня одного смущает что вопрос про производительность js, а рассматривается на крайне узком круге девайсов, а макбук рассматривается как полноценный десктоп? Или я проморгал что-то в статье?
                          0
                          А в чём вообще смысл делать на js, если есть native? Какие преимущества это даёт разработчикам? Ещё можно было бы понять, если бы это в разы ускоряло разработку.
                          Но я сильно сомневаюсь, что на js приложение равного функционала пишется хотя бы вдвое быстрее, чем на ObjC к примеру.
                            0
                            Когда в подобных проектах https://copy.sh/v86/
                            можно будет запустить «любую» полнофункциональную операционную систему на мобильном устройстве,
                            тогда и разговоры о текущей производительности JavaScript, возможно поутихнут.

                            P.S. Кстати были пробы и запустить в этом проекте ReactOS :)
                              0

                              В теории это позволяет добиться невиданной переносимости — ваш HTML+JS одинаково запустится на айОС, Андроиде, ВинФоне и ещё-что-там-появится-через-год. На практике это верно пока только для очень простых приложений, но там нет ничего нерешаемого.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое