Что такое Изоморфные Javascript приложения На заре Веб

1. Что такое Изоморфные Javascript приложения
На заре Веб взаимодействие с браузерами было таким: веб-браузер запрашивал
каждую страницу заставляя сервер, находящийся где-то в Интернете генерировать
HTML, и отсылать обратно. Этот был хороший подход, так как браузеры в то время
были еще не особенно мощными, да и HTML-страницы, в основном, были
статичными и автономными. JavaScript, созданный чтобы позволить веб-страницам
быть более динамичными, не позволял сделать что-либо более сложное чем слайдшоу или виджет подбора даты.
После нескольких лет развития компьютерных технологий, энтузиасты-разработчики
вытолкнули веб за его ограничения, заставив эволюционировать. Сейчас веб развит
настолько, что превратился в полноценную платформу для приложений — и
быстрый JavaScript и html5-стандарт позволяет разработчикам создавать мощные
приложения, такие которые раньше можно было сделать только под определенную
платформу.
Через некоторое время разработчики начали создавать целые приложения в
браузере, используя JavaScript и новые возможности. Приложения, подобные Gmail,
(классический пример одностраничного приложения) могут мгновенно реагировать
на действия пользователей, больше не нужно бегать по полному кругу на сервер,
только лишь для того чтобы отобразить новую страницу.
О библиотеках типа backbone.js, ember.js и angular.js часто говорят как о клиентских
MVC или MVVM библиотеках. Классическая клиентская MVC архитектура выглядит
примерно так:
Большое количество логики приложения (представления, шаблоны, контроллеры,
модели, интернационализация и т.д.) живет на клиенте, для данных используется
специальное API. Сервер может быть написан на любом языке, таком как Ruby,
Python или Java. В большинстве случаев их роль заключается в отдаче каркасной
страницы. Как только JavaScript файлы загружаются браузером, они выполняться,
клиентское приложение инициализируется, подгружаются данные через
соответствующее API и отрисовывается оставшаяся часть HTML.
Это хорошо для пользователей, потому что, один раз загрузившись, приложение
может быстро переключаться между страницами без перезагрузки, и, если все
сделано правильно, даже работать в оффлайне.
Это хорошо и для разработчиков, так как у идеального одностраничного приложения
есть четкое разделение задач на клиентские и серверные, что обеспечивает
прекрасный процесс разработки и предотвращает необходимость дублировать
слишком много логики между двумя средами, которые к тому же часто написаны на
разных языках.
Недостатки
На практике, однако, у этого подхода есть несколько фатальных недостатков,
которые не позволяют его использовать во многих случаях.
Поисковая оптимизация
Приложение, которое работает только на клиенте не может нормально
взаимодействовать с поисковыми роботами, то есть плохо приспособлено для SEO
по умолчанию. Поисковые роботы работают, создавая запросы к веб-серверу и
интерпретируя полученные результаты, но если сервер возвращает лишь пустую
страницу — от этого мало пользы. Существуют конечно и обходные пути, но не без
пляски с бубном.
Производительность
По той же самой причине, если сервер не генерирует страницу целиком, а вместо
этого приходится ждать загрузки JavaScript на клиент, пользователи несколько
критических секунд видят пустую страницу или значок загрузки. Проводилось
множество исследований изучающих то, какой эффект оказывают медленные сайты
на пользователей, и, соответственно, на прибыль. Amazon утверждает, что каждое
100 мс сокращение загрузки увеличивает прибыль на 1%. Twitter потратил год
совместных усилий 40 разработчиков переделывая сайт, чтобы генерировать
страницы целиком на сервере вместо клиента, получив 5-кратное улучшение
воспринимаемого времени загрузки.
Поддержка
Это в идеале должен получиться милый, четко разделенный код, в жизни ;t
неизбежно часть логики приложения или логики отображения оказывается
продублированной между клиентом и сервером, зачастую написанных на разных
языках. Стандартный пример — форматирование даты или валюты, валидация
форм и логика маршрутизации. Все это превращает поддержку в кошмар, особенно
в случае сложных приложений.
Некоторые разработчики набивают здесь шишки — часто только после того как ты
потратил кучу времени и усилий на создание одностраничного приложения — эти
недостатки всплывают наружу.
Гибридный подход
В итоге, нам нужен гибрид нового и старого подходов: мы хотим получать полностью
сформированный HTML с сервера по причинам производительности и SEO, но нам
нужны так же скорость и гибкость приложений клиентской стороны.
Чтобы добиться этого как раз и используется Изоморфный Javascript.
Изоморфное приложение выглядит примерно так. Озаглавлено “Клиент-серверное
MVC”:
Здесь часть логики приложения или отображения может выполняться как на сервере
так и на клиенте. Это дает много возможностей: оптимизация выполнения, лучшая
поддержка, СЕО по умолчанию, и более контролируемые веб-приложения.
C node.js — быстрой, стабильной серверной JavaScript частью, мы наконец можем
претворить эту мечту в реальность. Создав необходимые абстракции, мы можем
написать логику нашего приложения такой, чтобы она исполнялась и на сервере и на
клиенте — это и есть изоморфный JavaScript.
Что такое Изоморфный Javascript?
 Исполняется в различных окружениях
 Гарантирует одно поведение
 Справляется с разностью окружений через абстракции
Что он нам дает?
 Мы можем создать изоморфный Web UI
 Поддерживает SEO
 Работает как SPA
 Единая языковая среда
 Максимально переиспользуемый код
 Прирост производительности на старте
Что он нам не дает?
 Не работает с хранилищами, работает как правило с RESTfull API
 Чаще всего используется для Web UI
 Не включает код для обеспечения безопасности
Нужно решить несколько проблем
 Разный рендеринг
 Зависимость от окружения
 Запросы за данными к RESTfull API разные
 Собирать серверный код для браузера
Разный рендеринг
1. Virtual DOM – имитация DOM для фреймворка на сервере.Приложение
применяет изменение к эталонному DOM. Происходит сериализация в html
строку. Строка уходит на сервер. Приложение работает с виртуальным DOM
сравнивает его состояние с реальным DOM и применяет изменения.
2. Templates Helpers. Используем шаблонизаторы (Hanlebars). Шаблон рендерим
создавая элемент обертку с меткой. Отправляем на клиент. По этим меткам
привязываем клиентский код
3. Прогресивный рендеринг. Node js Steam Api.
Зависимость от окружения
Нужно создавать контекст (абстракцию) для сервера и клиента
На сервере чтобы получить location используем request.url
На клиенте window.location
Разные запросы
На сервере http модули к Node js
На клиенте XMLHttpRequest (superagent)
Сбор серверного кода (Browserify, Grunt, Webpack)
В итоге
1. Рендеринг можно реализовать по разному
2. С разницей окружений можно бороться
3. Есть готовые изоморфные пакеты для запросов
4. Сбор кода решается просто
Готовые фреймворки
Meteor
Derby
React
Slot
Уже изоморфные:
Инстаграмм (React)
Airbnb (React)
2гис (slot)
Что такое React?
Если использовать определение с официального сайта, то
“React — это JavaScript библиотека, которая используется для создания пользовательских
интерфейсов”.
С помощью React можно создавать компоненты для многоразового использования в вебразработке. Причем, компоненты создаются легко и просто. В этом, собственно, и есть цель
React.
Что делает React особенным?
React очень быстро стал популярен среди JavaScript разработчиков, и на это есть целый ряд
причин. Одна из них — React был разработан Facebook и теперь им активно продвигается и
используется. Это значит, что разработчики, работающие с Facebook, то же активно используют
React: программируют, чинят баги, разрабатывают новые функциональности и т.п.
Другая причина быстрой популярности React состоит в том, что он сильно отличается от
AngularJS, Backbone.js, Ember, Knockout и других широко известных MV* JavaScript фреймворков,
которые появились как грибы после дождя за последние несколько лет. Большинство этих
фреймворков работает по схеме двойного связывания с DOM и его обновлении в зависимости от
событий. Для их использования наличие DOM обязательно, поэтому, когда Вы работаете с одним
из этих фреймворков и хотите провести рендеринг разметки на сервере, Вам придется
использовать PhantomJS или что-то аналогичное ему.
Виртуальный DOM (рассказано выше)
Изоморфизм
Вывод
Веб архитектура развивается циклами. Сначала рендеринг происходил только на стороне
сервера с последующей отправкой данных клиенту. Затем, появился JavaScript, и мы стали
использовать его для простых операций на странице. Наконец, JavaScript развился настолько,
что стало возможным использовать его для создания больших приложений, которые будут
осуществлять рендеринг на стороне клиента и использовать сервер для извлечения данных
через API.
В 2015 же году, мы начали понимать, что имеем в распоряжении мощные серверы, которые
имеют достаточно процессоров и памяти для обработки практически любых данных.
Изоморфный подход к разработке приложений может дать нам лучшее из двух миров: мы можем
использовать JavaScript как на стороне сервера, так и на стороне клиента, что повышает
скорость загрузки и позволяет пользователям видеть информацию на странице быстрее по мере
того, как происходит подгрузка дополнительных элементов на стороне клиента.
React – один из первых фреймворков, которых без сомнения уже множество, что реализует такой
вид поведения. Разработчики Ember уже тоже работают над изоморфными приложениями.
Уверен, что наблюдать за развитием этих фреймворков будет очень интересно!