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

У 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? Програмуйте там, де затики продуктивності буде, а не там, де він був.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.