Одностраничные и многостраничные веб-приложения: плюсы, минусы, подводные камни. Single page application или одностраничное веб-приложение Понятие и назначение одностраничного web портала spa

В этой статье речь пойдет о Single Page Application (SPA). Будут рассмотрены плюсы и минусы web-приложения построенного по принципам одностраничного сайта (SPA)

Single Page Application - сокращенно SPA, в переводе на русский язык означает “Приложение одной страницы”. Другими словами SPA - это web-приложение, размещенное на одной web-странице, которая для обеспечения работы загружает весь необходимый код вместе с загрузкой самой страницы. Приложение такого типа появились сравнительно недавно, с началом эры HTML5 и SPA является типичным представителем приложений на HTML5 .

Как мы знаем, HTML5 это нечто иное как HTML + CSS3 + JavaScript + [несколько новых тегов]. Таким образом, SPA - это приложения написанные на языке JavaScript. И, следовательно, немного перефразировав предыдущие определение получаем:

“SPA - это web-приложение, размещенное на одной странице, которая для обеспечения работы загружает все javascript-файлы (модули, виджиты, контролы и т.д.) , а также файлы CSS вместе с загрузкой самой страницы.”

Если приложение достаточно сложное и содержит богатый функционал, как например, система электронного документооборота, то количество файлов со скриптами может достигать нескольких сотен, а то и тысяч. А “…загрузка всех скриптов…” никоим образом не означает, что при загрузке сайта будут загружены сразу все сотни и тысячи файлов со скриптами. Для решения проблемы загрузки большого количества скриптов в SPA призван API под названием AMD . AMD реализует возможность загрузки скриптов по требованию. То есть, если для “главной станицы” одностраничного портала потребовалось 3 скрипта, они будут загружены стразу перед стартом программы. А если пользователь кликнул на другую страницу одностраничного портала, например, “О программе”, то принцип AMD загрузит модуль (скрипт + разметка) только перед тем как перейти на эту страницу.

Получается немного скомкано: “Одна страница.. другая станица, третья страница… одностраничный портал”. Расставим все точки над “Ё”. Страница сайта, на котором размещены все ссылки на все CSS, и ссылки на скрипты, необходимые для работы SPA мы назовем “Web-страница”. Файл с такой странице обычно называется “index.html” (в ASP.NET MVC может быть index.cshtml или index.vbhtml или даже index.aspx) А страницы, которые переключает пользователь внутри одностраничного портала назовем “модули”.

Давайте рассмотрим плюсы и минуты данного подхода. Зачем всё это нужно и почему SPA так популярен?

Первым плюсом стоит отметить тот факт, что приложения на SPA отлично работают на устройствах как стационарных, так и мобильных. “Большие” компьютеры, планшеты, смартфоны, и, в конце-концов, простые телефоны (некоторые) могут беспрепятственно работать с сайтами построенных по принципу SPA. Итак, первый “плюс” - работа на большом количестве устройств , а значит, создав одно приложение, вы получаете гораздо большую аудиторию пользователей нежели при использовании стандартного подхода.

Далее второй “плюс” - богатый пользовательский интерфейс , так называемый User Experience. Так как web-страница одна, построить богатый, насыщенный пользовательский интерфейс гораздо проще. Проще хранить информацию о сеансе, управлять состояниями представлений (views) и управлять анимацией (в некоторых случаях).

Третий “плюс” - SPA существенно (в разы) сокращает так называемые “хождения по кругу”, то есть загрузку одного и того же контента снова и снова . Если ваш портал (сайт) использует шаблон, то вместе с основным содержанием какой-либо страницы посетитель сайта обязательно загружает разметку шаблона. Да, кэширование данных на данном этапе развития WWW достигло высочайших результатов, но если нечего кэшировать, то и время, и ресурсы на это не тратятся.

Если вы программируете на C#, то единственным минусом SPA является необходимость изучения JavaScript. Во всяком случае, других глобальных проблем мне выяснить не удалось.

Принципы любого фреймворка (о них поговорим позже), который реализует парадигму SPA должны придерживаться следующих понятий и определений:

• SPA поддерживает клиентскую навигации. Все “хождения” пользователя по модулям-страницам однозначно фиксируются в истории навигации, причем навигация при этом является “глубокой”, то есть если пользователь скопирует и откроет ссылку на внутреннюю модуль-страницу в другом браузере или окне, он попадет на соответствующую страницу.
• SPA размещается на одной web-странице, значит всё необходимое для работы сайта (портала) скрипты и стили должны быть определены в одном месте проекта - на единственной web-странице.
• SPA хранит постоянно состояние (важные переменные) работы клиента (клиентского скрипта) в кэше браузера или в Web Storage .
• SPA загружает все скрипты требующиеся для старта приложения при инициализации web-страницы.
• SPA постепенно подгружает модули по требованию.

Как вы уже наверное догадались, SPA - это абстрактное понятие. Это принцип архитектуры приложения. Давайте поговорим с чего начать при разработке сайта по принципам SPA.

Существует большое количество базовых библиотек (фреймворк - от английского слова framework - “основа, структура, каркас”), которые реализуют принцип Single Page Application. Что дают эти фреймворки:

• обеспечивают базовые принципы для SPA разработки, минимизируя трудозатраты на решение универсальных задач (смотри раздел “Составляющие SPA);
• фреймворки созданы сообществом разработчиков, а значит используют опыт создания сайтов множества программистов;
• фреймворки являются отправной точкой для создания структуры на основе Single Page Application.

Так как я уже много лет работаю на платформе NET, то я буду рассматривать шаблоны Single Page Application на основе ASP.NET. Давайте рассмотрим следующую сравнительную таблицу.

В таблице приведены наиболее распространённые шаблоны для как основа построения Single Page Application приложения. Обратите внимание, синим фоном выделены базовые кирпичики для построения полноценного фреймворка, таких как DurandalJS и HotTowel , которые выделены зеленым цветом.

Содержимое подобного сайта подгружается с сервера при помощи AJAX — асинхронного JavaScript и XML . Для реализации работы через AJAX нужна также реализация части приложения на серверной стороне. Обычно используются скриптовые языки. Для удобства работы и масштабирования системы выбирают REST (архитектура взаимодействия частей приложения).

Для построения одностраничных приложений используют различные фреймворки:

• backbone.js (рус .)- легкий библиотека, написана автором CoffeeScript и используемая для разработки SPA-страниц с поддержкой REST архитектуры
• ember.js (рус .)- тоже бесплатный JavaScript-фреймворк основанный на модули Модели-Представления-Контроллера (шаблон разработки — MVC)
• angular.js (рус .) — фреймворк, MVC. Один из авторов продолжается заниматься фреймворком, работая в Google.

Можно построить используя работу с селекторами по идентификатору и целевому селектору :target , CSS-свойства для управлением видимостью содержимого (display, visibility и margin). Шаблоны одностраничного сайта включает все необходимое содержимое для работы посетителя. В этом простейшем случае подключать JS-фреймворки обходимости нет.

Псевдокласс:target позволяет выбрать такие HTML-элементы на странице, атрибут id у которых совпадает со значением хеша из адресной строки. Например, если в адресной строке присутствует URI: http://сайт/test-po-html#result, то на HTML-странице будет найден элемент с идентификатором #result и к нему применятся CSS-стили.

Каркас такой страницы может выглядеть так (внимание! Для упрощения используется одинаковая высота у всех страниц. На практике объем содержимого буде разным)

Container{ font: 1em sans-serif; width:600px; min-height:500px; margin:auto; border:1px solid #000; position: relative; } h1,h2,h3,h4,h5,h6 {margin: 0;} .page{ width:600px; height:430px; position: absolute; top:60px; display: none; background-color: #fff; } div:first-of-type{ display:block; z-index: 1; } div:target{ display:block; z-index: 2; }

Одностраничный статичный сайт ссылка1 ссылка2 ссылка3 ссылка4 страница 1 одностраничного сайта страница 2 одностраничного сайта страница 3 одностраничного сайта страница 4 одностраничного сайта

Посмотреть пример работы . Со страницами, использующими JS-фреймворки работа строится другим способом.

Термин «одностраничное приложение» (или SPA) обычно используется для описания приложений, которые были созданы для Интернета. Эти приложения доступны через веб-браузер, как и другие веб-сайты, но предлагают более динамичные взаимодействия, напоминающие родные мобильные и настольные приложения.

Самая заметная разница между обычным сайтом и SPA – это уменьшение количества обновлений страницы. У СПА более тяжелое использование AJAX – способ общения с серверными серверами без полного обновления страницы – для загрузки данных в наше приложение. В результате процесс рендеринга (построения) страниц происходит в основном на стороне клиента с помощью JavaScript.

В то время как строительство SPA-приложений является модным и считается современной практикой развития, важно знать о его недостатках, в том числе:

• Браузер делает большую часть тяжелого подъема, что означает, что производительность может быть проблемой – особенно на менее способных мобильных устройствах.
• Сложность поисковой оптимизации (SEO), сложность предоставления вашего контента поисковым системам и сайтам социальных сетей, которые предоставляют предварительный просмотр ссылок.

Большинство современных фреймворков JavaScript работают над тем, как обрабатывать серверный рендеринг SPA, т.е. пользователь получит полностью заполненную страницу, когда SPA будет загружен впервые, вместо того, чтобы, например, увидеть индикатор загрузки.

Рендеринг на стороне сервера может облегчить некоторые из блогов, которые браузеры должны выполнять при рендеринге страниц, а также поможет решить проблему SEO и доступности контента.

Чем больше интерактивности происходит на стороне клиента, тем больше кода JavaScript требуется для того, чтобы эти интерактивные элементы функционировали хорошо. И чем больше написано кода, тем важнее иметь чистую и хорошо продуманную кодовую базу. И это именно та проблема, которую решают фреймворки JavaScript, – каждый с собственным подходом.

Существует множество открытых исходных JavaScript-фреймворков, которые помогают создавать SPA-приложения, такие как.

Облачные веб приложения набирают популярность. Множество ИТ компаний видят эту тенденцию и все больше программных продуктов разрабатывают на основе удаленного доступа. Существует много аналогов desktop программ, которые предлагают онлайн версию за небольшую ежемесячную плату.

Они дают больше гибкости и мобильности. Например, вы легко можете вносить данные в облачные CRM или ERP системы через свой мобильный телефон и это может происходить в удобном для Вас месте. Как видно с графика Statista , рынок облачных решений растет и к 2026 году должен достигнуть почти 522 миллиардам долларов.

Чтобы обеспечить стабильную работу сложных веб приложений, желательно использовать технологии которые дадут наилучшую производительность и скорость. Существует два способа разработки веб приложений: одностраничные приложения (SPA) и многостраничные приложения(MPA). Давайте рассмотрим какая между ними разница и какие преимущества имеет каждый тип веб приложений.

Одностраничные приложения позволяют имитировать работу десктоп приложений. Архитектура устроена таким образом, что при переходе на новую страницу, обновляется только часть контента. Таким образом, нет необходимости повторно загружать одни и те же элементы. Это очень удобно для разработчиков и пользователей. Для разработки SPA используется один из самых популярных языков программирования - javascript . Небольшое веб приложение можно сделать с библиотекой jQuery.

Но, сразу стоит отметить, что jQuery очень плохо подходит для разработки крупных проектов. Наша компания, Merehead, рекомендует использовать более мощные технологии для разработки SPA. Для этих целей хорошо подойдет React.js, Angular.js, Vue.js и другие фреймворки/библиотеки. Их архитектура позволяет разрабатывать гибкие веб приложения. Более того на базе фреймоврков можно строить мобильные приложения с повторным использованием когда. Такие возможности дает Rreact Native и Ionic. Основные преимущества Single Page Application:

При всех своих достоинствах, Single Page Application имеет некоторые недостатки, которые сдерживают рост популярности:

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

Одностраничные веб приложения хорошо подходят для разработки динамических платформ, с небольшим объемом данных. Кроме того, если Вам потребуется в будущем построить мобильное приложение , SPA отлично подойдет как основа. Основным недостатком, который сдерживает стремительный рост популярности SPA это плохая SEO оптимизация. Проекты, где SEO имеет важнейший приоритет, стоит использовать MPA.

Многостраничные приложения имеют более классическую архитектуру. Каждая страница отправляет запрос на сервер и полностью обновляет все данные. Даже если эти данные небольшие. Таким образом тратится производительность на отображение одних и тех же элементов. Соответственно это влияет на скорость и производительность. Многие разработчики, для того чтобы повысить скорость и уменьшить нагрузку, используют JavaScript/jQuery. Хороший пример, обновление товаров без перезагрузки страницы, при использования фильтров в интернет магазине. Это намного удобней и главное быстрее. Главные преимущества Multi Page Application (MPA):

Используя MPA вы можете найти подходящее коробочное решение. Например использовать Magento, OpenCart для разработки e-commerce веб приложения или Dolphin, Elgg для разработки социальных сетей . Недостатки MPA:

Основным преимуществом МПА является хорошая SEO оптимизация и огромные количество коробочных решений.

• Tutorial

Одностраничные приложения (SPA) имеют мнжество преимуществ, таких как скорость, по-настоящему хороший UX, и полный контроль HTML-разметки. Становится всё больше и больше сайтов SPA; всё больше инструментов, которые упрощают процесс разработки SPA. Вы, вероятно уже читали о молодом и перспективном фреймворке Vue.js . Предлагаю вам глубже погрузиться в Vue и на конкретном примере разобраться с простым SPA.

Мы напишем клиент-серверное приложение простейшего блога. Приложение будет отображать список записей а также полный текст каждой отдельной записи. И само собой, всё это будет происходить без перезагрузки страницы.

Ознакомившись с примером этого приложения, вы научитесь извлекать данные в Vue, создавать роуты и разберётесь с интересной особенностью Vue - однофайловыми компонентами.

Итак, для начала установим vue-cli в качестве глобального пакета:

$ npm install -g vue-cli
Затем проинициализируем проект с выбранным шаблоном; для нашего примера более чем достаточно использовать webpack-simple.

$ vue init webpack-simple vue-spa
Далее перейдём в папку vue-spa и запустим npm install в терминале. После установки всех пакетов, мы можем запустить наше приложение в режиме разработки.

$ npm run dev
Эта команда автоматически запустит наш проект на локальном dev-сервере webpack. В браузере появится наше простейшее приложение Vue. Конечно оно выглядит совсем не так, как бы нам хотелось, и годится лишь в качестве отправной точки для начала чего-то большего. Чтобы продолжить работу, предлагаю сначала ознакомиться со структурой нашего шаблона.

Внутри шаблон webpack-simple имеет следующую структуру:

Файл index.html содержит простую разметку HTML с единственным элементом “app” в body. Он будет заменён на DOM, сгенерированный vue. По этой причине тэг body не рекомендуется использовать в качестве корневого элемента.

В папке src лежит файл main.js, который содержит точку входа webpack. Компоненты Vue импортируются там же. Ещё там описан корневой экземпляр Vue, который пока что имеет два свойства. Свойство ‘el’ обеспечивает экземпляру Vue связь с указанным DOM элементом. Ещё одно - функция отрисовки, генерирующая DOM из App.vue . В общем, это все, что нам нужно знать о структуре шаблона webpack-simple, не так много, не так ли? Основная часть нашего приложения будет запрограммирована в App.vue. Расширение.vue определяет файл как однофайловый компонент vue. Это одна из особенностей Vue с которой мы сейчас познакомимся поближе.

Каждый файл *.vue состоит из блоков трёх типов: , и опционально . В результате, мы можем разделить проект на связанные компоненты. Внутри компонента его шаблон, логика и стили неотъемлемо связаны, и их совмещение фактически делает компонент более целостным и легко поддерживаемым. Теперь мы готовы приступить к созданию блога на Vue.

Давайте посмотрим, что собственно мы собираемся реализовать. У нас будет заголовок с названием нашего блога в верхней части страницы. С левой стороны у нас будет фиксированная боковая панель, в которой мы будем отображать заголовки наших записей, это будет что-то вроде оглавления. Остальная часть страницы будет занята динамическим блоком, в котором будет отображаться сам текст записи.

Vue.js SPA
Во-вторых, создадим экземпляр Vue со свойством data, которое мы разместим в массиве с нашими сообщениями. На данный момент он пуст, но вскоре мы поместим в него данные, полученные с сервера внутрь массива.

После первого обращения, вы больше не сможете добавлять реактивные свойства к корневому объекту данных. Поэтому, прежде чем создавать экземпляр Vue, рекомендуется объявить все реактивные свойства на уровне корня.

export default { data () { return { posts: } } }
Кроме того, можно добавить немного стилей, чтобы приложение выглядело лучше.
Код приложения хостится на github.com . Достаточно клонировать репозиторий и переключать ветку по номеру шага чтобы проследить разработку приложения шаг за шагом например:

$ git checkout step-1
В настоящий момент нам абсолютно нечего отображать в нашей навигационной панели, поэтому давайте получим данные с сервера. Для этого я выбрал Axios - простой в использовании HTTP-клиент. Вы также можете использовать любой удобный для вас способ, например, Vue-ресурс или собственную выборку или даже jQuery Ajax.

$ npm install --save-dev axios
Затем импортируем его в компонент App и определим метод getAllPosts() который будет делать запрос к серверу и присваивать его свойству posts. Вызываем метод в хуке created(), который будет вызываться после создания экземпляра Vue и после установки настроек обращения к данным.

Import axios from "axios" export default { data () { return { posts: null, endpoint: "https://jsonplaceholder.typicode.com/posts/", } }, created() { this.getAllPosts(); }, methods: { getAllPosts() { axios.get(this.endpoint) .then(response => { this.posts = response.data; }) .catch(error => { console.log("-----error-------"); console.log(error); }) } } }
А теперь отобразим все заголовки записей в боковой панели.

{{ post.title }}
До сих пор мы отображали только заголовки записей, но пока мы ещё не можем видеть сами записи. Теперь необходимо отобразить полный пост в разделе контента в соответствии с выбранным названием на боковой панели. В то же время хотелось бы, чтобы каждая запись была доступна по своему уникальному адресу.

$ npm install --save-dev vue-router
Для настройки роутинга вернёмся к файлу main.js. Здесь мы определим настройки роутинга и добавим их в наш экземпляр Vue.

Import Vue from "vue" import Router from "vue-router" import App from "./App.vue" import Post from "./components/Post.vue" import Hello from "./components/Hello.vue" Vue.use(Router) const router = new Router({ routes: [ { path: "/", name:"home", component: Hello, }, { path: "/post/:id", name:"post", component: Post, props: true, }, ] }) new Vue({ el: "#app", render: h => h(App), router })
В настройках роутинга мы указали, какой компонент вызывает отрисовку по соответствующему пути. Поскольку только компонент Post.vue будет отвечать за отрисовку каждого поста, нам не потребуется определять путь к каждому посту, достаточно определить динамический путь.

Path: "/post/:id"
Этот путь содержит динамический сегмент:id который указывает на конкретный пост. При этом у нас есть доступ к этому сегменту в компоненте Post через this.$route.params.id . Однако использование $route в нашем компоненте закрепит жесткую связь с роутом, что в свою очередь ограничивает гибкость компонента, поскольку он может использоваться только на определенных URL-адресах. Вместо этого мы можем использовать опцию props и установить её в true . После этого $route.params станет связан с опцией props компонента Post.
Теперь, когда мы создали роутер, мы можем вернуться к нашему приложению и добавить еще несколько строк в шаблон.

{{post.id}}. {{post.title}}
Здесь мы имеем два компонента vue-router : и . Первый - это компонент для включения навигации пользователя в приложении с поддержкой роутинга. Второй компонент - это функциональный компонент, который отрисовывает согласованный компонент для данного пути.

Остался заключительный шаг. Нам нужно отобразить содержимое записи поста.

{{ post.body }}

{{ post.id }}

Import axios from "axios"; export default { props: ["id"], data() { return { post: null, endpoint: "https://jsonplaceholder.typicode.com/posts/", } } }
Затем опишем метод getPost() , который будет получать только одну запись поста по идентификатору и вызовем его в хуке created() .

Methods: { getPost(id) { axios(this.endpoint + id) .then(response => { this.post = response.data }) .catch(error => { console.log(error) }) } }, created() { this.getPost(this.id); },
Почти готово. Если мы запустим приложение сейчас, мы увидим, что, хотя URL-адрес меняется, мы видим единственный пост, который был отрисован первым. Дело в том, что для отрисовки разных постов у нас есть один и тот же компонент, и Vue не нужно его пересоздавать из-за лишней траты ресурсов, а это также означает, что хуки жизненного цикла компонента не будут вызваны.
Чтобы это исправить, нам просто нужно установить watcher для объекта $route .

Watch: { "$route"() { this.getPost(this.id); } }
Теперь всё работает так, как и должно. Чтобы получить версию для продакшина достаточно выполнить команду npm run build в консоли.