В прошлом, когда браузеры обладали гораздо меньшими возможностями, чем сегодня, а производительность JavaScript была низкой, каждая страница поступала с сервера. Каждый раз, когда вы нажимали на что-то, на сервер отправлялся новый запрос, и браузер впоследствии загружал новую страницу.
Только очень инновационные продукты работали по-другому и экспериментировали с новыми подходами.
Сегодня, популяризируемое современными интерфейсными фреймворками JavaScript, такими как React, приложение обычно создается как одностраничное приложение: вы загружаете код приложения (HTML, CSS, JavaScript) только один раз, и когда вы взаимодействуете с приложением, обычно происходит то, что JavaScript перехватывает события браузера и вместо того, чтобы отправлять новый запрос на сервер, который затем возвращает новый документ, клиент запрашивает JSON или выполняет действие на сервере, но страница, которую видит пользователь, никогда полностью не стирается и ведет себя больше как настольное приложение.
Одностраничные приложения построены на JavaScript (или, по крайней мере, скомпилированы на JavaScript) и работают в браузере.
Технология всегда одна и та же, но философия и некоторые ключевые компоненты работы приложения отличаются.
Примеры одностраничных приложений
Некоторые примечательные примеры:
- Gmail
- Карты Google
- Фейсбук
- Твиттер
- Google Диск
Плюсы и минусы СПА-салонов
Приложение SPA кажется пользователю намного более быстрым, потому что вместо того, чтобы ждать, пока произойдет обмен данными между клиентом и сервером, и ждать, пока браузер повторно отобразит страницу, теперь вы можете получать мгновенную обратную связь. За это отвечает разработчик приложения, но у вас могут быть переходы, вращатели и любые улучшения пользовательского интерфейса, которые, безусловно, лучше, чем традиционный рабочий процесс.
В дополнение к ускорению работы пользователя сервер будет потреблять меньше ресурсов, потому что вы можете сосредоточиться на предоставлении эффективного API вместо создания макетов на стороне сервера.
Это делает идеальным, если вы также создадите мобильное приложение поверх API, так как вы можете полностью повторно использовать существующий код на стороне сервера.
Одностраничные приложения легко трансформируются в прогрессивные веб-приложения, что, в свою очередь, позволяет вам обеспечивать локальное кэширование и поддерживать автономную работу ваших сервисов (или улучшенное сообщение об ошибке, если вашим пользователям необходимо быть в Сети).
СПА-салоны лучше всего использовать, когда нет необходимости в SEO (поисковой оптимизации). Например, для приложений, которые работают без входа в систему.
Поисковые системы, хотя и совершенствуются с каждым днем, по-прежнему испытывают проблемы с индексацией сайтов, созданных с использованием SPA-подхода, а не традиционных страниц, отображаемых на сервере. Это относится и к блогам. Если вы собираетесь полагаться на поисковые системы, даже не утруждайте себя созданием одностраничного приложения, не имея также серверной части для визуализации.
При написании кода SPA вам придется написать большое количество JavaScript. Поскольку приложение может работать долго, вам нужно будет уделять гораздо больше внимания возможным утечкам памяти – если в прошлом срок службы вашей страницы исчислялся минутами, то теперь SPA может оставаться открытым часами, и если есть какие-либо проблемы с памятью, это увеличит использование памяти браузера намного больше. и это вызовет неприятно медленный процесс, если вы не позаботитесь об этом.
СПА-салоны отлично подходят для работы в команде. Разработчики бэкэнда могут просто сосредоточиться на API, а разработчики интерфейсов могут сосредоточиться на создании наилучшего пользовательского интерфейса, используя API, встроенный в бэкэнд.
Как следствие, одностраничные приложения в значительной степени полагаются на JavaScript. Это может сделать использование приложения, работающего на устройствах с низким энергопотреблением, плохим с точки зрения скорости. Кроме того, у некоторых ваших посетителей может быть просто отключен JavaScript, и вам также необходимо учитывать доступность всего, что вы создаете.
Переопределение навигации
Поскольку вы избавляетесь от навигации браузера по умолчанию, URL-адресами необходимо управлять вручную.
Эта часть приложения называется маршрутизатором. Некоторые фреймворки уже заботятся о них за вас (например, Ember), другим требуются библиотеки, которые будут выполнять эту работу (например, React Router).
В чем проблема? Вначале это была запоздалая мысль для разработчиков, создающих одностраничные приложения. Это вызвало общую проблему “сломанной кнопки “назад””: при навигации внутри приложения URL-адрес не изменился (поскольку навигация по умолчанию в браузере была взломана) и нажатие кнопки “Назад”, обычная операция, которую пользователи выполняют для перехода на предыдущий экран, может перейти на веб-сайт, который вы посетили давно.
Теперь эту проблему можно решить с помощью History API , предлагаемого браузерами, но большую часть времени вы будете использовать библиотеку, которая внутренне использует этот API, например React Router .
Оригинал: “https://flaviocopes.com/single-page-application/”