Что такое SPA или одностраничный портал
Сайтостроение | создано: 11.06.2014 | опубликовано: 12.06.2014 | обновлено: 13.01.2024 | просмотров: 38010 | всего комментариев: 13
В этой статье речь пойдет о 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) вам придется писать самостоятельно, впрочем, как и управление навигацией и историей навигации в том числе.
С другой стороны, вы в праве выбрать Ember или BreezeJS, или даже AngularJS от Google как основу своего сайта или даже как основу своего собственного фреймворка, факт остается фактом, недостающие принципы составляющие концепцию SPA вам придется реализовывать самостоятельно.
Альтернативой предыдущему решению может послужить выбор уже готового полноценного фреймворка (помечены в таблице зеленым фоном). У каждого варианта существуют свои “плюсы” и “минусы”.
Заключение
Примеров приложений построенных по принципам Single Page Application очень много. Одним из самых мощных и общеизвестных является GMail – почтовый сервис компании Google.
Я же хочу привести в пример фреймворк DurandalJS, который использовал для построения своего сайта “Что значит имя”. Я начинаю цикл статей посвященных изучению DurandalJS на основе программирования сайта “Что значит имя”.
Полезные ссылки
- DurandalJS – полноценный фреймворк для построения MVVM-приложения на JavaScript.
- BreezeJS – работа на JavaScript с данными посредствам WebAPI или OData
- AngularJS – фреймворк от Google
- KnockoutJS – MVVM для HTML и JavaScript.
- HotTowel – Фреймворк от John Papa (MVP Microsft, Regional Director)
Комментарии к статье (13)
> Первым плюсом стоит отметить тот факт, что приложения на SPA отлично работают на устройствах как стационарных, так и мобильных.
SPA и поддержка устройств никак не связаны вообще.
> Далее второй “плюс” – богатый пользовательский интерфейс, так называемый User Experience.
Не связано вообще.
> SPA: Минусы
> Если вы программируете на C#, то единственным минусом SPA является необходимость изучения JavaScript. Во всяком случае, других глобальных проблем мне выяснить не удалось.
SPA вынуждает писать код на js очень осторожно, т.к. если будут утечки памяти, то приложение будет нереально тормозить. Надо писать аккуратно и профилировать.
И просто словоблудие:
> Как мы знаем, HTML5 это нечто иное как HTML + CSS3 + JavaScript + [несколько новых тегов]. Таким образом, SPA - это приложения написанные на языке JavaScript.
Однако статей про фронтенд-разработку вам лучше не писать, очень в кучу, нет ясного понимания что как и отчего. Как будто SPA -- очередной buzzword.
Vladimir Gordeev, давайте вы не будете за меня решать что делать, а что нет. Это хорошо, что вы уже понимаете тот факт, что поступаете не тактично. В свою очередь могу сказать, что моя статья, в большей её части, является переводом нескольких статей одного из евангелистов (экспертов так называют в Microsoft) Джон Папа.
Цикл статей - http://www.johnpapa.net/spa/,
а приведенные метофоры - http://www.johnpapa.net/pageinspa/
А мой перевод этих статей говорит о том, что мое мнение (частично или полностью) совпадает с его видом вещей. Что же касается ваших замечаний, то следуя вашей логике, на других языках, отличных от javascript можно писать код "как попало" и утечек будет? Ну, раз вы, откровенно говоря, заявили себя гуру программирования (в отличие от нас, от дилетантов) может вы напишите статью сами? Или дадите почитать уже написанные? Я с удовольствем размещу вашу статью на своем сайте :)
Это говорит о том, что автор этих слов никогда в жизни не только не написал ни одного рабочего SPA приложения, но и вряд ли выходил из границ примитивнейших ванильных примеров. Если бы я подобное услышал от взрослого человека, всерьёз считающего себя разработчиком, я бы решил что он больной.
Тот факт, что автор либо не знает, либо тупо игнорирует наличие значительного числа минусов, полностью нивелирует все восторженные фанатичные отзывы. История повторяется, достаточно открыть любую книжонку 90-х об ООП, чтобы почувствовать лёгкий приступ дежавю — перед ООП точно также преклоняли адепты свои колени, не находя в нём решительно ни одного минуса... Ну кроме того, что надо потратить время, изучив ООП. И к чему пришли в итоге? ООП действительно мощный инструмент, но таит в себе множество опасностей и минусов.
Что до SPA, то у него при всех очевидных плюсов, есть свои пределы применения. С увеличением сложности приложения, рациональность в выборе SPA резко снижается. На учебных примерах видны лишь сплошные плюсы. Но в реальности всё несколько иначе. Разрабатывать SPA приложения действительно очень тяжело, хотя на первый взгляд как раз выглядит иначе. Имеется ощутимый болевой порог сложности, после которого SPA можно смело слать лесом, ничуть не заморачиваясь. И почему-то все евангелисты об этом молчат. Ну конечно, они же евангелисты :)
А за статью конечно спасибо, критика относится к автору, а не к переводчику.
Ну, что вы все привязались к евангелисту, он как хвалил, так и будет хвалить, на то он и евангелист! Но мне как переводчику, было бы очено интересно узнать о каких таких геморроидальных проблемах при разработки на SPA идет речь? Что есть "болевой порог сложности" для SPA?
Без конкретных примерах (ссылки на статьи, проект на мыло, ссылки на видео и т.д.) весь этот обвинительный монолог больше похож на выкрик из кустов, мол, "жираф большой - ему виденей". В ответ на который, любой уважащий себя евангелист парирует "просто вы не умеете их готовить"!
Если со SPA действительно так всё плохо, и как выразились на одном из сайтов (http://www.sql.ru/forum/1123778/single-page-application-ili-odnostranichnyy-portal-ovchinka-vydelki-stoit) это "детская песочница", кстати, тоже без основания, то приведите хоть один достойный внимания пример, опровергающий высказывания евангелиста!
Полностью несогласен с данным утверждением. Последний год занимаюсь переводом на SPA оооочень большого приложения, построенного на Sencha ExtJS 5. Сотни страниц, сложная клиентская логика, разноплановые сложные интерфейсы, десятки запросов к серверу на некоторых страницах. И все это нормально перевелось на SPA без каких либо проблем.
Если правильно спроектирована архитектура приложения, позволяющая корректно добавлять новый код и удалять отработанный код, при смене страницы (без утечек и т.д.), то это дает неограниченную масштабируемость проекта. Это я к тому, что порога сложности нет вообще как такового. А развитие SPA приложение ничем не отличается от развития обычного многостраничного приложения.
Но надо сказать честно, что перед тем, как стали получаться правильные архитектурные решения под SPA, копьев было поломано изрядное количество...
В статье есть полезная информация, наверно, но! Но это местами просто не возможно читать - статья распадается на фрагменты - из-за грамматической и логической несвязности. Как Вы правильно выразились - "Получается немного скомкано" и запутано.
Комментарий, конечно же, о Вашей статье. <br />Евангелист Ваш автор или простой смертный - это не важно. Ваша цель - не перевод ради перевода (надеюсь), а донести что-то до жаждущих.<br />Разбили бы на части (структурировали, то есть), добавили бы связки (Вы же тоже специалист в СПА, а статья - не заказанный перевод - Ваша инициатива).<br />Но и это пол-беды! Синтаксис и орфография статьи - к переводу не имеют ни какого отношения! Но ощущение - Вы НИРАЗУ не перечитывали то, что написали!