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