Single Page Application — это web-приложение, компоненты которого загружаются единожды на одной странице, а контент подгружается по необходимости.
В нашей первой статье на COSSA речь пойдет о Single Page Application (SPA). Рассмотрим плюсы и минусы современных web-приложений построенных по принципам одностраничного сайта-приложения (SPA)
Если коротко, то в простейшем варианте SPA это web-приложение, компоненты которого загружаются единожды на одной странице, а контент подгружается по необходимости.
SPA напоминают простые нативные приложения, с разницей лишь в том, что исполняются в браузере, а не в собственном процессе операционной системы, это и является ключом к популярности SPA. На вскидку, известная Meduza или Medium, всеми любимый InVision (projects.invisionapp.com) — все это SPA в том или ином виде.
Почему же SPA приложения такие крутые?
Первым и очевидным плюсом мы бы выделили богатый User Experience таких веб-приложений. Из-за того, что мы имеем одну веб-страницу, построить насыщенный и функциональный пользовательский интерфейс гораздо проще. Одновременно с этим удобно хранить, обновлять и управлять состоянием представлений. Тут в помощь приходит реактивный подход в программировании пользовательского интерфейса, который лучше всего сочетается со SPA приложениями.
Используя респонсив дизайн, “одностраничники” отлично работают на всех устройствах: стационарных, мобильных, любых. Такое комбо-вомбо из респонсив+SPA способно удовлетворить намного большее количество пользователей, нежели обычный адаптивный сайт, не говоря уже о старичках без адаптивного дизайна вообще.
SPA исключает постоянные запросы к одному и тому же контенту при перемещении пользователя по сайту. Несмотря на то, что кэширование в вебе, сегодня достаточно эффективное, если нечего будет кэшировать, то и время на это тратить не нужно — бинго!
Изначально, при первой загрузке, необходимо загрузить чуть больше данных. Это можно принять за явный недостаток, так как, обычно, все приложение собирается в один большой бандл и грузить его нужно весь сразу. Если приложение очень большое, то этот бандл может оказаться чрезмерно громоздким. Однако, этот минус можно полностью нивелировать, используя разбиение большого бандла на модули и “ленивую” (lazy) их подгрузку.
Многие опасаются использовать SPA из-за того, что практически все поисковые роботы и социальные сети на сегодняшний день “не видят” контент таких сайтов (пока в SPA умеет только Google). Используя серверный рендеринг и изоморфное приложение мы полностью избавляемся от этой проблемы. Поисковые системы получают готовые HTML странички со всей мета-информацией и семантической разметкой.
При знакомстве со SPA технологией может показаться, что есть еще один серьезный недостаток — нужно найти серьезных (читай очень дорогих) разработчиков, которые смогут грамотно спроектировать архитектуру приложения. Но и тут все не так однозначно. Крутая команда разработчиков одним своим присутствием в проекте обычно провоцирует бурное его развитие.
Немного остановимся на том, как мы в своих проектах используем всё это многообразие “ништяков”. Наше видение архитектуры конечно не догма, но работает очень даже неплохо.
В качестве фреймворка для SPA мы используем Angular Universal (изоморфное Angular приложение). До выхода Angular Universal из беты, мы успешно использовали SPA на AngularJS и серверный рендеринг прикрученный нами к Ruby on Rails. Говоря о последнем, мы используем его сейчас как бэк-энд для API. В качестве языка программирования SPA мы используем TypeScript. Для сборки бандлов мы используем Webpack и загружаем модули лениво (lazy-подход). Использование Angular Universal позволяет использовать еще одну крутую фишку — AOT компиляция кода. В отличие от JIT-компиляции при стандартном подходе, заранее скомпилированный AOT-код быстрее обрабатывается браузером.
В результате, при запросе какой-то конкретной страницы веб-приложения пользователем, он получает отрендеренную страницу сервером, которая отображается у него сразу же после завершения запроса браузером (как правило 20–30 миллисекунд). После этого начинается загрузка основной части приложения в фоне, но пользователь уже видит страницу в том виде, в котором она будет у него в итоге (без назойливых белых экранов). Благодаря AOT компиляции, после загрузки всех скриптов приложения, страница быстро перерисовывается уже самим браузером. Пример использования SPA на реальных проектах:
- http://profamily.video/ (Angular Universal)
- https://shop.yudashkin.com/ (AngularJS + пререндеринг на Rails).
Максимально упрощенная схема нашей реализации SPA в рамках экосистемы “сферического проекта в вакууме” выглядит так:
Детальных плюсов огромное количество. Если Google за 2017 год все свои основные ресурсы перевёл на SPA, то стоит задуматься. Как говориться “Сопливых вовремя целуют”.
Подписываемся на наш телеграм-канал!