[Перевод] Семь принципов создания современных веб-приложений

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писалв блоге недавно, в основном, в связи с UX и производительностью.Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

JavaScript бесспорно стал незаменимым инструментом для разработчиков фронтенда. Сейчас сфера его применения расширяется на другие области, такие как серверы и микроконтроллеры. Этот язык программирования выбрали престижные университеты, чтобы обучать студентов основам информатики.

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

Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг? Умирает ли бэкенд? Нужно ли вообще рендерить HTML? Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)? Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях? Нужно ли использовать техники вроде PJAX или TurboLinks? Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно? Далее последуют мои попытки ответить на эти вопросы. Я попытался исследовать, как использовать JavaScript с точки зрения пользователя (UX). В частности, уделил особое внимание идее минимизации времени, которое требуется пользователю для получения интересующих его данных. Начиная с основ сетевых технологий и заканчивая предсказанием будущего поведения юзера.1. Рендеринг страниц на сервере необязателен tl; DR: рендеринг на сервере осуществляется не ради SEO, а для производительности. Принимайте в расчёт дополнительные запросы для получения скриптов, стилей и последующие запросы к API. В будущем, принимайте в расчёт использование метода HTTP 2.0 Push.

Прежде всего, я вынужден обратить внимание на общепринятую ошибку разделять «приложения с рендерингом на сервере» и «одностраничные приложения». Если мы хотим добиться наилучшего восприятия с точки зрения пользователя, то не должны ограничивать себя такими рамками и отказываться от одной альтернативы в пользу другой.Причины вполне очевидны. Страницы передаются по интернету, у которого есть физические ограничения, что незабвенно проиллюстрировал Стюарт Чешир в знаменитом эссе «Это latency, дурачок»:

Расстояние между Стэнфордом и Бостоном 4320 км.Скорость света в вакууме 300×10^6 м/с.Скорость света в оптоволокне составляет примерно 66% скорости света в вакууме.Скорость света в оптоволокне 300×10^6 м/c * 0,66 = 200×10^6 м/c. Односторонняя задержка при передаче в Бостон 4320 км / 200×10^6 м/c = 21,6 м/c. Задержка при передаче туда и обратно 43,2 м/c. Пинг из Стэнфорда в Бостон в интернете современного образца около 85 мс (…)Итак, современное оборудование интернета передаёт сигнал со скоростью 0,5 от скорости света.

Указанный результат 85 мс можно улучшить (и уже сейчас он чуть лучше), но важно понять, что существует физическое ограничение на задержку при передаче информации через интернет, как бы не увеличивалась полоса пропускания на компьютерах пользователей.Это особенно важно в связи с ростом популярности JavaScript-приложений, которые обычно содержат только разметку