Корольова. Таблетки для схуднення для Інтернету
Близько року тому Микита Прокопов опублікував статтю-маніфест "Розчарування програмним забезпеченням". Судячи з позитивних відгуків, розробники хочуть піклуватися про якість продукції, яку вони виробляють. Чи пора починати діяти, можливо?
У цьому дописі я хочу розповісти про свій проект, який, на мій погляд, може вилікувати основні проблеми з продуктивністю сучасного Інтернету та зробити користувача трохи щасливішим. Ось вони - розмір наборів JS, тривалий час до інтерактивності, велике споживання оперативної пам'яті та центрального процесора.
Перш ніж читати далі, перейдіть за посиланням. Спробуйте зіграти кілька матчів. Бажано грати з робочого столу.
Трохи історії
Спочатку творці Інтернету розробляли браузер як тонкий клієнт для веб-серверів. Браузер відображав гіпертекстові сторінки, отримані від сервера. Це було просто і елегантно. Як це часто буває, красива ідея зіткнулася з реальністю, і через кілька років виробники браузерів додали підтримку мови сценаріїв. Спочатку він призначався лише для декорування. До середини першого десятиліття вважалося правильним створювати веб-сайти з JS як варіант.
Сучасний підхід до розробки веб-сайтів є результатом зростаючих вимог до інтерактивності користувальницького інтерфейсу. Завдання щодо поліпшення інтерактивності лягли на плечі дизайнерів шаблонів. Часто вони не мають компетенції та повноважень розробляти "наскрізне" рішення. Розробники шаблонів навчились JS і стали інженерами-розробниками. Логіка поступово почала надходити від сервера до клієнта. Фронтенд-хлопцеві зручно писати все на стороні клієнта. Для бекенд-хлопця зручно не думати про користувача. "Я дам вам JSON, і тоді мені все одно", - кажуть вони. Два роки тому архітектура без серверів стала популярною. Припущення полягало в тому, що програми JS працюватимуть безпосередньо з базами даних та чергами повідомлень.
На даний момент звичайний веб-сайт - це складна програма, написана на JS, і простий сервер API. Основна логіка виконується на жировому клієнті, а серверна частина вироджується до проксі-сервера бази даних.
Якщо технічний борг на стороні сервера може не вплинути безпосередньо на вашого користувача, то на стороні клієнта це вплине. Якщо ваш стартап «злетить» і почне заробляти, то далі із зростанням навантаження ситуація буде лише погіршуватися з точки зору продуктивності. Вимоги зміниться. Кодова база розбухне, а коефіцієнт обороту в команді зросте. Сторінка буде жиріти від залежностей. Веб-сайт завантажить застарілий JSON. Фонові завдання будуть множитися в кількості, кожна з них працює протягом декількох мілісекунд щосекунди, що через деякий час призведе до відставання та потепління iPad нещасного користувача, щоб він міг смажити на ньому яйця. Ніхто не наважиться виправити це через страх зламати систему. Це закінчиться тим, що згорілі хлопці, що перегоріли, приїжджають до менеджера з пропозицією кинути старий потворний фреймворк і переписати все з нуля на новий блискучий. Менеджер відмовить, і хлопці, що працюють у фронті, почнуть використовувати обидва разом.
Як працює Корольов
Отже, що, якщо ми повернемося до поворотного пункту? До того моменту, коли хтось придумав оновити вміст без перезавантаження сторінки, а історична неминучість породила AJAX? Що якщо ми залишимо все на сервері і зробимо тонкий клієнт? Найкращі сайти роблять попередній візуалізацію сторінок на сервері, щоб користувач міг бачити інтерфейс перед завантаженням JS. Ми можемо піти далі і залишити лише код на клієнті, який відповідає за обробку вводу-виводу, враховуючи поточні вимоги до інтерактивності. Думки про це привели мене до проекту Корольова.