Назначение одностраничного web портала spa. Одностраничное приложение. Итак, зачем это баловство

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

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

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

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

SPA: Минусы

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

Составляющие SPA

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

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

Шаблоны SPA (SPA templates)

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

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

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

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

Сравнение возможностей шаблонов SPA

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

Итак, следуя данным предоставленных в таблице вы можете создать Single Page Application приложение используя “голый” ASP.NET и KnockoutJS. Однако, реализацию работы с данными (DAL) вам придется писать самостоятельно, впрочем, как и управление навигацией и историей навигации в том числе.

май 21 , 2017

Одностраничные сайты или Single Page Applications (SPA) - это круто. Главный их профит в том, что SPA быстрее и отзывчивее на действия пользователей. Достигается это за счет переноса логики работы на клиентскую сторону и активного взаимодействия с сервером посредством ajax.

Бытует мнение, что SPA - это мощные приложения на ангуляре или реакте, ворочающие тоннами данных в какой-нибудь панели управления или в сложном сервисе. И в целом это так. Но я убежден, что есть смысл писать одностраничные приложения не только для таких сервисов, но и для обычных корпоративных сайтов-визиток.

Зачем это надо и как это сделать, приложив немного усилий? Об этом ниже. Поехали.

Итак, зачем это баловство?

Самое главное - это скорость работы.

Конечно, при разработке одностраничного сайта-визитки мы столкнемся с некоторыми проблемами:

1. Как подступиться, с чего начать?
2. Как разобраться с историей браузера, с History API?
3. Какой фреймворк или библиотеку изучить: ангуляр, реакт? А мы ни одного не знаем...
4. Как заставить поисковики индексировать одностраничный сайт?

Ответы на эти вопросы:

1. Разберемся в этой же статье, на примере простого сайта
2. Тоже расскажу ниже, это десяток строк кода
3. Никакой, обойдемся нативным javascript-ом и jQuery в качестве помощника
4. Про поисковики будет следующая статья из этой серии

Почему без ангуляра-реакта?
Конечно же, это очень нужные темы, рекомендую их изучать. Но для нашего примера они не понадобятся, нам достаточно обладать минимальными знаниями javascript-a.

Одностраничники - это тема не одной статьи. Это будет целый проект, серия статей минимум из трех штук. И затрагиваться в нем будут самые разные темы. Но уточню. Мы будем строить не сложную админку со взаимодействием с сервером посредством REST API (по крайней мере, в самом начале). В первых уроках наш одностраничный сайт будет обычной визиткой из десятка страниц. Но сайт будет работать без перезагрузки страниц и радовать наших пользователей скоростью и отзывчивостью интерфейса.

Идея сайта, как он устроен

Возьмем самый обычный корпоративный сайт: главная страница, раздел "О проекте", контакты и блог. В разделе "Блог" будет несколько ссылок на внутренние страницы. На каждой странице забьем какой-нибудь контент и вставим немного перекрестных ссылок.

На каждой странице сайта, как правило, есть повторяющийся контент. У нас это будет шапка и меню. И есть основное содержимое страницы, которое меняется. Мы сделаем так: загрузим страницу всего один раз, а потом кликая по ссылкам, будем динамически подгружать нужное содержимое аяксом. При этом мы будем менять заголовок страницы во вкладке браузера, url в адресной строке и запоминать историю в браузере, чтобы работала навигация через кнопки Назад/Вперед браузера.

Контент для каждой отдельной странице будет храниться в отдельном html-файле.

Можете сразу посмотреть, что у нас в итоге получится -

Структура сайта и подготовительные работы

Структура файлов-папок такова. В корне проекта файл index.php и.htaccess. Почему именно php, а не html, расскажу позже. В папке css лежат стили в файле main.css. В папке js - библиотека jquery.js и главный файл приложения main.js. В папке pages лежат html-файлы с содержимым сайта - на каждую страницу по одному файлу.

Готовим контент

Я сделаю демо-сайт на примере своего проекта webdevkin. Набор страниц будет таким:

— main - Главная
— about - О проекте
— blog - Блог

— shop - Интернет-магазины
— frontend - Фронтенд
— mysql - База данных MySql
— widgets - Встраиваемые виджеты

— simpple - Проект Simpple
— contacts - Контакты

Соответственно, в папке pages будут лежать 9 html-файлов. Всю разметку для контента найдете в . Для примера приведу содержимое только одного файла - simpple.html

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

Как видно, никаких head, body, html, script здесь нет - только разметка, относящаяся к конкретной странице.

index.php и.htaccess

Почему не index.html?
Дело в том, что на нашем сайте будет одна-единственная физическая страница - index. Но нас интересуют и такие адреса, как site.ru/about, site.ru/contacts и прочее. Но страниц about и contacts в корне нашего сайта нет. Папка pages с набором html-файлов - это не полноценные страницы, а просто куски html-кода, которые встраиваются внутрь общего каркаса.

Поэтому, чтобы при обращении к site.ru/about не посыпались 500, 403 и еще бог знает какие ошибки, мы должны все входящие запросы на сайт перенаправлять на index.php, который уже и будет эти запросы разруливать. Впрочем, пока что index.php у нас - это обычная html-разметка без единой строчки php-кода (но это только пока). А в.htaccess мы пропишем следующее. Возвращаться к нему придется редко.

RewriteEngine On Options +SymLinksIfOwnerMatch RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-l RewriteRule ^(.+)$ index.php?q=$1

В тему
Однажды я писал статью про Простой RESTful-сервис на нативном PHP . Там Вы найдете немного больше информации про такой способ перенаправления запросов.

html-код будет у нас очень простым. В head подключаются стили css/main.css. В подвале 2 js-файла: js/jquery.js и js/main.js. А в body будет следующее:

Сначала выводим меню. Дальше идет заголовок страницы. И ниже пустой div с id=content (не обращайте внимания на style="" - парсер когда-нибудь выбесит и я его заменю). В #content будут подгружаться динамически содержимое страниц из файлов pages/*.html. Пока ничего интересного.

Только обратите внимание на атрибуты data-menu и data-link="ajax" у ссылок. Они введены для того, чтобы отличать ссылки-навигации от обычных внешних ссылок, которые на нашем сайте тоже будут. data-link="ajax" означает, что при клике по этой ссылке мы перехватим стандартное поведение браузера и возьмем работу со ссылкой в свои руки. А data-menu означает, какой пункт главного меню будет выделен при клике на оную ссылку. Здесь data-menu дублируется с атрибутом href, но возможны и другие варианты. Например, когда мы залезем в раздел frontend блога, то мы укажем data-menu="blog".

2 примера для наглядности:

simpple.ru Главная страница simpple.ru

Стили main.css

Быстро пролистаем и скопипастим самое скучное - файл css/main.css.

Body { position: relative; font-family: "Helvetica Neue Light", "HelveticaNeue-Light", "Helvetica Neue", Calibri, Helvetica, Arial; font-size: 1em; font-weight: 400; color: #333; } a, a:visited { color: steelblue; } a:hover { color: navy; } .wrapper { width: 80%; margin: 0 10%; } .spa-title { font-size: 1.2em; text-align: center; } menu { margin-top: 2em; padding: 0; text-align: center; } menu a { display: inline-block; margin-right: 10px; padding: 5px 15px; text-decoration: none; } menu a:hover, menu a.active { background-color: steelblue; color: white; } .page-title { text-align: center; } ul li { list-style-type: circle; }

А вот теперь самое интересное - javascript-код, который превратит наш набор отдельных файлов в одностраничный сайт.

javascript. Общий код и конфиги

Зададим каркас js-кода.

Var app = (function() { var config = {}; var ui = {}; // Привязка событий function _bindHandlers() { // ... } // Инициализация приложения function init() { // ... _bindHandlers(); } // Возвращаем наружу return { init: init } })(); // Запуск приложения $(document).ready(app.init);

Мы имеем отдельный модуль app, который при загрузке страницы запускает свою функцию init. В ней навешиваем обработчики событий и выполняем еще некоторый код. Также видим 2 объекта: config и ui. В ui будут закэшированы все dom-элементы, которые понадобятся нам в работе.

Var ui = { $body: $("body"), $menu: $("#menu"), $pageTitle: $("#page-title"), $content: $("#content") };

$menu нам нужно, чтобы выделять отдельные пункты меню, $pageTitle будем менять динамически при переходе между страницами, а в $content будет подгружаться содержимое файлов pages/*.html

А вот config выглядит интереснее.

Var config = { siteTitle: "Webdevkin SPA", mainPage: "main", pages: { main: { title: "Главная", menu: "main" }, about: { title: "О проекте", menu: "about" }, blog: { title: "Блог Webdevkin-a", menu: "blog" }, simpple: { title: "Проект Simpple", menu: "simpple" }, contacts: { title: "Контакты", menu: "contacts" }, shop: { title: "Интернет-магазины", menu: "blog" }, frontend: { title: "Статьи о фронтенде", menu: "blog" }, mysql: { title: "База данных Mysql", menu: "blog" }, widgets: { title: "Встраиваемые javascipt-виджеты", menu: "blog" } } };

siteTitle: "Webdevkin SPA" - заголовок сайта, используется в нескольких местах.
mainPage: "main" - указываем стартовую страницу сайта, ту, которая откроется при заходе на site.ru. Сейчас это главная страница main, но Вам запросто может прийти в голову поставить стартовую, например, "О проекте" - about.

Самое важное во всем конфиге - это объект pages. Каждое поле объекта описывает одну страницу сайта. Сейчас нам понадобятся только 2 пункта: заголовок страницы и меню, к которому оная страница относится. Ключи объекта, то есть страницы, совпадают с названиями файлов в pages/*.html и атрибутами href во внутренних ссылках.

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

Подгрузка контента с помощью ajax. History API

Пойдем по порядку. Займемся функцией init, в которой есть привязывание нужных событий _bindHandlers

// Привязка событий function _bindHandlers() { ui.$body.on("click", "a", _navigate); window.onpopstate = _popState; }

В первой строке мы отлавливаем клики на внутренние ссылки a и отправляем их в функцию _navigate. Теперь мы окончательно убедились, что нужны отдельные атрибуты data-link="ajax" :-)

Далее window.onpopstate = _popState;
Из документации.
Событие popstate отсылается объекту window каждый раз, когда активная запись истории меняется между двумя записями истории для одного и того же документа.
Проще говоря, это срабатывание кнопок Назад/Вперед в браузере. Как мы видим, нативное поведение браузера тоже нужно перехватывать. Поэтому мы отдадим управление функции _popState.

Для лучшего восприятия приведу код сразу для обеих функций

// Клик по ссылке function _navigate(e) { e.stopPropagation(); e.preventDefault(); var page = $(e.target).attr("href"); _loadPage(page); history.pushState({page: page}, "", page); } // Кнопки Назад/Вперед function _popState(e) { var page = (e.state && e.state.page) || config.mainPage; _loadPage(page); }

При явном клике по ссылке _navigate мы останавливаем всплытие события клика и отменяем дефолтное поведение браузера (переход по ссылке). Затем мы определяем страницу, которую мы хотим загрузить (понимаем по атрибуту href), и вызываем новую функцию _loadPage. Она и сделает всю основную работу по загрузке контента, изменению заголовка и прочее-прочее. И в конце через history.pushState добавляем новую запись в истории браузера. Да, мы сами, явным образом создаем историю браузера. Тогда, когда считаем нужным. И сохраняем данные о загружаемой странице в объект {page: page}. Эти данные нам пригодятся в следующей функции _popState.

В _popState идея аналогична: ищем нужную страницу и запускаем ту же _loadPage.

Var page = (e.state && e.state.page) || config.mainPage;

e.state && e.state.page - вытаскивает нам страницу из объекта истории, которую мы предусмотрительно записали в _navigate. Если же объект e.state недоступен (например, когда мы первый раз зашли на сайт site.ru и еще не успели побродить по нему), то берем страницу, указанную главной в нашем конфиге - config.mainPage.
По совести говоря, функция history.pushState и тот факт, что в window.onpopstate доступен объект e.state с данными, записанными в pushState, - это все, что нам достаточно знать о History API. Для более любопытных товарищей, не сомневаюсь, что гугление поможет найти и другие хорошие способы работы с историей браузера.

Мы же глубокими изысканиями заниматься не будем, а напишем код главной функции _loadPage

// Загрузка контента по странице function _loadPage(page) { var url = "pages/" + page + ".html", pageTitle = config.pages.title, menu = config.pages.menu; $.get(url, function(html) { document.title = pageTitle + " | " + config.siteTitle; ui.$menu.find("a").removeClass("active"); ui.$menu.find("a").addClass("active"); ui.$pageTitle.html(pageTitle); ui.$content.html(html); }); }

Выглядит он вполне заурядно. Сначала формируем url, то есть путь, по которому мы загрузим html для страницы. Потом вытаскиваем из конфига заголовок страницы и пункт меню, подлежащий выделению. Далее получаем html-содержимое страницы через банальный jQuery.get и выполняем еще ряд нехитрых действий.

а) Обновляем заголовок страницы
б) В 2 строки выделяем нужный пункт меню
в) Меняем заголовок уже на самой странице, в html-коде
г) Загружаем собственно html-содержимое страницы, полученное из url

Почти все! Остался маленький момент. Если мы сейчас перейдем, например, на страницу site.ru/blog и обновим ее, то загрузится не блог, а пустая страница. Потому что при инициализации мы _loadPage не вызываем. Чтобы это исправить, нам нужно дописать пару строк в функцию init, которая в итоге будет выглядеть так

// Инициализация приложения function init() { var page = document.location.pathname.substr(1) || config.mainPage; _loadPage(page); _bindHandlers(); }

Вот теперь точно все!

Подведем итоги и напомним ссылки

Итак, мы написали простой, но вполне рабочий одностраничный сайт, а также немного узнали, как работает History API. Честно говоря, чувствую себя режиссером плохого фильма, когда 80% времени ведут к какой-то грандиозной развязке, а в конце все оказывается намного проще, чем ожидалось.

С одной стороны, почти весь код - это просто подготовка, обвязка, написание конфигов и прочих скучных вещей. А действительно полезный код, выполняющий непосредственную работу, занимает 2 десятка строк.

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

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

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

И небольшой опрос

Роман Липский

Мир программного обеспечения сейчас эволюционирует с огромной скоростью. Всего пару лет назад настольные компьютеры и ноутбуки являлись основными устройствами, под которые была заточена веб-разработка. Сегодня дела обстоят совсем не так.

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

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

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

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

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

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

Как мы уже упоминали выше, и у SPA, и у MPA есть свои плюсы и минусы. Давайте же разберемся в разнице между двумя типами приложений и постараемся найти правильное решение в области веб-разработки для вашей компании.

Чтобы сделать это, мы попросим директора веб-направления BLAKIT Виталия Озерского дать свои экспертные комментарии по теме. Надеемся, что вместе мы сможем облегчить для вас этот выбор.

Одностраничные приложения

Одностраничные приложения работают в рамках браузера и не требуют перезагрузки страницы или загрузки дополнительных страниц во время использования. Подобные приложения ежедневно используют миллионы юзеров, даже не замечая этого. Самые популярные примеры: GitHub, Gmail, Google Maps и даже Facebook.

Виталий Озерский: одностраничные приложения, как правило, максимально интерактивны, причём настолько, что у пользователя складывается ощущение, будто он работает с десктопным приложением: реакция приложения на пользовательские действия моментальная в большинстве случаев. Этим SPA выгодно отличаются от многостраничных сайтов, где при каждом действии пользователю необходимо дожидаться загрузки новой страницы.

Одностраничные приложения созданы специально для того, чтобы предоставлять пользователям отличный UX, напоминающий «естественную» среду браузера без перезагрузок страниц, а значит, без задержек при совершении действий.

Типовое одностраничное приложение выглядит как веб-страница, подгружающая и обновляющая контент без перезагрузки с помощью JavaScript. SPA запрашивает разметку страницы и её контент, а затем создает конечный вид страницы непосредственно в браузере. Такого эффекта можно достигнуть благодаря продвинутым фреймворкам JavaScript, таким как AngularJS, Ember.js, Meteor.js, Knockout.js.

ВО: Помимо основных популярных фреймворков разработчики BLAKIT способны также разрабатывать одностраничные приложения при помощи ReactJS.

Основное преимущество React – невысокий порог входа. React довольно прост в использовании; практически любой разработчик, знакомый с HTML, может создавать React-приложения.

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

Мы используем React вместе с библиотекой Redux, которая позволяет заложить правильную архитектуру и создавать сложные веб-приложения, легко поддающиеся масштабированию.

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

Преимущества одностраничных приложений:

SPA характеризуются отличным быстродействием, так как большинство ресурсов, которые они используют (HTML+CSS+Скрипты), загружаются лишь однажды в течение сессии использования приложения. После совершения действий на странице меняются лишь данные.
Разработка веб-приложений обычно быстрее и эффективнее. Нет необходимости писать отдельный код для рендера страницы на стороне сервера. Также гораздо легче запустить процесс разработки подобных приложений, потому что писать код можно начинать с файла file://URI, не используя при этом никакой сервер.
SPA оптимизированы для Chrome debugging, разработчики могут отслеживать сетевые действия, изучать элементы страниц и данные, с ними ассоциируемые.
Если у вас уже есть SPA, будет возможность с тем же бэкендом создать и мобильное приложение.
SPA более эффективны в кэшировании данных на локальных носителях. Приложение высылает один запрос, собирает все необходимые данные, и с этого момента способно работать даже в режиме оффлайн.

Недостатки одностраничных приложений:

SEO-оптимизация одностраничных приложений, по очевидным причинам, не очень проста. Контент приложений загружается при помощи AJAX (Asynchronous JavaScript and XML) - метода обмена данными и обновления приложения без перезагрузки страницы, в то время как SEO-оптимизация основана на устойчивости контента в каждой отдельно взятой странице. При этом продвижение вашего сайта в поисковиках не невозможно. Многие изменения в SEO можно провести на стороне сервера, а компании вроде Google продолжают придумывать новые решения для того, чтобы облегчить жизнь как владельцам SPA, так и их пользователям.
Они довольно долго загружаются, поскольку тяжелые клиентские фреймворки должны сперва загрузиться в браузер.
SPA требуют JavaScript в активном режиме в браузерах пользователей. Если кто-то из ваших клиентов вручную отключит использование JavaScript, они не смогут в полной мере воспользоваться вашим приложением. Даже если вы будете кэшировать и обрабатывать ваши страницы на стороне сервера (а это сейчас тоже возможно), вы всё ещё рискуете не доставить пользователям без JS все функции одностраничного приложения в правильном виде.
По сравнению с традиционными приложениями, SPA чуть хуже защищены. Благодаря межсайтовому скриптингу (XSS), злоумышленники имеют возможность внедрять дополнительные скрипты на стороне клиента.
Некоторые утечки памяти в JavaScript могут привести к падению производительности даже в мощных системах

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

ВО: SPA подходят для любого бизнеса, который нуждается в автоматизации своих процессов. А вот для корпоративных веб-сайтов и интернет-каталогов, к примеру, лучше использовать более традиционные веб-сайты.

Многостраничные приложения

Многостраничные приложения работают более традиционным способом, так сказать. Каждое значительное изменение данных или выгрузка информации обратно на сервер приводит к рендерингу новой страницы в браузере. Многостраничные приложения, очевидно, «тяжелее», чем одностраничные, и обычно нацелены на отображение большего количества контента.

Сложность и издержки при разработке MPA выше, также для них требуется многоуровневый дизайн UI. К счастью, сейчас это уже не такая большая проблема, поскольку AJAX позволяет обновлять только определенные части приложения, а не перебрасывать кучу данных между серверами и браузерами.

Преимущества многостраничных приложений:

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

Недостатки многостраничных приложений:

Frontend и backend разработка в данном случае объединены очень тесно.
Разработка МPA довольно сложна, так как она требует использования фреймворков как на клиентской, так и на серверной стороне. Сроки и издержки разработки, соответственно, не так приятны для многих компаний.

SPA или MPA?

Перед тем как принимать решение о разработке веб-приложения, нужно в первую очередь иметь в виду цель его создания. Если в бизнесе вам приходится иметь дело с большим количеством разных товаров и услуг, многостраничный сайт станет для вас оптимальным решением.

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

Эту форму веб-разработки в статье мы ещё не упоминали. Гибридное приложение нацелено на то, чтобы взять лучшее из двух миров, минимизируя при этом недостатки.

Технически, гибридное приложение – всё ещё SPA, но оно использует якоря URL как синтетические страницы, благодаря чему расширяются возможности встроенной навигации в браузере и функциональность настроек.

Дайте нам знать, если хотите узнать больше о гибридных приложениях, мы напишем о них отдельный текст.

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

Согласно нашим данным, уже сейчас многие виды бизнеса переходят на эту модель в своей стратегии онлайн-продвижения. Тем не менее, некоторые виды проектов просто невозможно воплотить как SPA: в них попросту слишком много контента. Поэтому, по крайней мере в обозримом будущем, модель MPA всё ещё имеет место быть.

ВО: полностью согласен с утверждением про растущую популярность одностраничных приложений. Сейчас SPA-приложения пользуются большим спросом, так как компании постепенно переводят свой софт с десктоп-приложений на приложения, доступные с любого браузера, а не только на ПК с Windows.

, , Комментарии: 0

В обновлении Web Tools 2012.2 для проектов ASP.NET MVC 4 добавился новый шаблон - Single Page Application (SPA). Этот шаблон предназначен для быстрого построения интерактивных веб-приложений на стороне клиента.

"Single Page Application" (SPA) – это основной термин для веб-приложений, которые загружают одну страницу и затем обновляют ее динамически без загрузки других страниц. Загружена основная страница, и дальше приложение общается с сервером с помощью AJAX-запросов.

AJAX – это не новинка, но сегодня существуют Javascript-библиотеки, которые упрощают разработку и поддержку больших и сложных одностраничных приложений. А HTML5 и CSS3 помогают созданию красивого пользовательского интерфейса.

Рассмотрим пример построения веб-приложения, используя одностраничный шаблон. Построим приложение, которое управляет списком запланированных дел (to-do list).

Создаем новое одностраничное приложение

Для создания приложения потребуется:

Visual Studio 2012 или Visual Studio Express 2012 for Web
Обновление ASP.NET Web Tools 2012.2, его можно устьановить отсюда.

В главном меню приложения Visual Studio откроем File-> New -> Project . Из предложенных шаблонов проектов выберем ASP.NET MVC 4 Web Application .

Запустим приложение. Откроется форма для авторизации.

Зарегистрируемся.

После входа в приложение создается список дел по умолчанию с двумя элементами и появляется кнопка "Add Todo List" для добавления нового списка.

Архитектура одностраничного приложения

На диаграмме изображены основные блоки приложения.

На стороне сервера ASP.NET MVC генерирует HTML, а также управляет forms-аутентификацией. ASP.NET Web API обрабатывает все запросы, касающиеся списков дел и элементов этих списков. Это – получение, создание, обновление и удаление. Клиент обменивается данными c Web API в формате JSON.

Entity Framework является слоем ORM (object relational mapping), который связывает объектно-ориентированную архитектуру приложения с базой данных. База данных используется локальная (LocalDb), но можно подключить и свою в файле web.config. Обычно для локальной разработки используется локальная база данных, а потом с помощью миграции EF code-first она переносится на SQL server.

Что такое SPA

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

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

SPA: Плюсы

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

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