Содержимое подобного сайта подгружается с сервера при помощи AJAX — асинхронного JavaScript и XML . Для реализации работы через AJAX нужна также реализация части приложения на серверной стороне. Обычно используются скриптовые языки. Для удобства работы и масштабирования системы выбирают REST (архитектура взаимодействия частей приложения).
Одностраничное приложение и JavaScript-фреймворки
Для построения одностраничных приложений используют различные фреймворки:
- backbone.js (рус .)- легкий библиотека, написана автором CoffeeScript и используемая для разработки SPA-страниц с поддержкой REST архитектуры
- ember.js (рус .)- тоже бесплатный JavaScript-фреймворк основанный на модули Модели-Представления-Контроллера (шаблон разработки — MVC)
- angular.js (рус .) — фреймворк, MVC. Один из авторов продолжается заниматься фреймворком, работая в Google.
Одностраничный сайт html
Можно построить используя работу с селекторами по идентификатору и целевому селектору :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; }
Одностраничный статичный сайт
Посмотреть пример работы . Со страницами, использующими JS-фреймворки работа строится другим способом.
Введение
Недавно довелось столкнуться с проектом по доработке когда-то написанной CRM. Цель доработки была в том, чтобы увеличить быстродействие системы при взаимодействии с пользователем и добавить немного нового функционала, а также победить обнаруженные предыдущими разработчиками и так и не побеждённые утечки памяти в JavaScript"е, на котором и был реализован весь пользовательский интерфейс.
Начав заниматься проектом, покопавшись в недрах огромного количества используемых и не очень дружно взаимодействующих между собой библиотек и framework"ов, проведя ряд экспериментов, мы пришли к неожиданному для себя выводу о том, что виной всему… SPA-архитектура.
Пара слов об SPA-архитектуре
Говоря о современном Web"е, всё чаще можно услышать о технологии Single Page Application (SPA), хотя если быть точным, SPA – это собирательное название набора технологий, позволяющих реализовать WEB-приложение, исполняемое WEB-браузером как одна WEB-страница, как, например, реализован сервис Gmail от Google. С точки зрения пользователя, данная технология привлекает в первую очередь быстротой отклика на действия в пользовательском интерфейсе, так как не требуется полной или даже частичной перезагрузки WEB-страницы с сервера, а все визуальные элементы конструируются прямо в браузере с помощью JavaScript путем манипуляций с DOM-структурой документа.
Таким образом, WEB-приложения становятся очень похожи на обычные приложения для рабочих станций, загружающих информацию из сети Интернет, только средой исполнения для них является не операционная система, а браузер, который в результате вынужден нести на себе всю нагрузку, связанную с исполнением стороннего кода, а именно управление памятью, обеспечение безопасного окружения, предоставление функционала для работы с системными функциями и аппаратным окружением и т. п.
Центральное место SPA-архитектуры занимает представление (View) – то, что видит и с чем взаимодействует пользователь. Результатом работы представления является самый обычный HTML, отображаемый браузером. В отличие от «переходных» «WEB 2.0»-приложений, активно работающих с DOM-структурой документа, например, с помощью jQuery или underscore, SPA-приложение использует DOM только для записи изменений, но не для чтения, то есть не для хранения данных. Для хранения данных теперь используется ещё один компонент SPA-архитектуры – модель (Model).
Модель представляет собой совокупность данных, функций для манипуляции с данными и событиями. Все данные модели полностью хранятся в памяти. Для того, чтобы данные, находящиеся в модели, и данные, отображаемые представлением, сохраняли целостность, представление подписывается на события модели, отслеживая таким образом изменения данных в модели. В свою очередь, модель также реагирует на уведомления представления и обеспечивает неразрывную связь WEB-приложения с сервером, выполняя запросы для получения или отправки данных (в частности с применением методологии REST).
Но вернёмся к представлению. Представление - это самая важная и наиболее сложная часть современных SPA. Обычно представления построены вокруг так называемых шаблонов – заготовок, преобразующихся в HTML. Также представление обновляет полученный HTML при изменении модели и наоборот – уведомляет модель о действиях пользователя с представлением, например, о клике мышкой, вводе с клавиатуры или повороте устройства, в результате чего модель может выполнить манипуляции с данными и затем вновь уведомить представление об изменении данных для того, чтобы представление обновило или сгенерировало новый HTML.
Работа классического WEB-приложения (или WEB-сайта) полностью строится поверх кэширования данных: на сервере, на прокси-сервере и на клиенте. Если данные и состояние приложения обновляются очень часто, преимущество от использования кэширования практически нивелируется. Теоретически одностраничное приложение должно меньше эксплуатировать кэш, так как данные загружаются один раз во время жизненного цикла страницы, но на практике это не всегда так, и об этом поговорим ниже.
Особенности CRM, не укладывающиеся в SPA-реализацию
Посмотрим, как мы можем использовать технологию SPA для реализации простой системы управления взаимоотношениями с клиентами, или CRM. В первую очередь нас интересует операционный и аналитический уровни обработки информации.
Возьмём для примера сильно упрощённый набор разделов несложного CRM:
Рабочий стол (Dashboard) - сводка всех данных системы, имеющих смысл для конкретного пользователя.
События - просмотр совместных действий пользователей отделов маркетинга, продаж и производственных отделов.
Клиенты - управление клиентской базой, контактами и компаниями.
Проекты и сделки - управление взаимоотношениями с клиентами.
Задачи - управление рабочим процессом по реализации.
Отчёты - просмотр и управление аналитическими отчётами по накопленной информации.
Профиль - управление профилем пользователя.
В каждом разделе пользователь работает с выборками часто изменяемых данных. Одно из критичных требований к CRM на операционном уровне - это высокое быстродействие при взаимодействии с пользователем при выполнении таких операций, как частое обращение к реестру информации, активное использование сложной фильтрации и сортировка большого объема результатов. Также на аналитическом уровне требуется быстро получать отчёты, статистику, анализ и прогнозирование по различным метрикам и показателям.
В одностраничном приложении вместо страниц мы оперируем «экранами». Каждый экран является частью подсистемы со своим набором шаблонов, модулей, контроллеров, маршрутом и моделью. Когда пользователь осуществляет переход на другой раздел приложения, загружаются данные, шаблоны и модули, требуемые для работы этого раздела, при этом важно, что пользователь находится на той же странице, и текущее состояние во время загрузки нового экрана сохраняется.
Общая модель всей системы является комплексной, состоящей из независимых моделей для каждого экрана. Переключение между экранами вызывает очищение текущего слоя представления и генерации нового слоя, что довольно часто реализовано таким образом, что предыдущий слой просто становится невидимым и вместо него отображается новый, то есть процесс переключения между экранами устроен таким образом, что уже готовые представления после первоначальной загрузки в дальнейшем просто скрываются и отображаются.
Это сильно отличается от классического способа работы с WEB-приложением, где переходы по ссылкам вызывают полную загрузку страниц, что автоматически вызывает освобождение ресурсов и обновление данных, и пользователь может ожидать, что данные всегда актуальны. В условиях быстро меняющихся данных в CRM, чтобы подтвердить ожидания пользователя при SPA-реализации, в процессе перехода между экранами также возникает необходимость заново загружать все данные с сервера, что сводит на нет преимущество хранения всех данных на клиенте, а, следовательно, и применение самой SPA-архитектуры.
Возникающие проблемы при использовании SPA в CRM
Технология SPA вынуждает разработчика писать код крайне осторожно, так как любая ошибка или недосмотр может привести к утечками памяти, и как следствие – к «тормозам» всей системы.
Почему течёт память?
Огромное количество данных, накапливаемых на клиенте в процессе длительной работы, очень быстро становятся неактуальными. Но между тем, эти данные сохраняются в модели, а представления сохраняются в DOM-структуре документа, если не заниматься очисткой целенаправленно. Для того, чтобы держать модель и DOM «в чистоте», необходимо заниматься периодической «уборкой мусора», так как на встроенный сборщик мусора JIT полагаться в данном случае не стоит, ведь ссылки на объекты, как правило, остаются достижимыми, следовательно, ранее созданные и уже не нужные объекты по-прежнему остаются в памяти. Также необходимо учесть, что в JavaScript всегда есть риск потерять все ссылки, но данные так и не будут очищены.
Почему всё тормозит?
К замедлению работы страницы в основном приводят утечки памяти и сложная модель с большим количеством обработчиков событий. При переходе с экрана на экран, при открытии каждой новой формы в процесс браузера загружаются данные, а также исполняемый код (в случае с AMD), который не редко внедряется с помощью конструкций eval(). Модульные framework"и для построения SPA также имеют свою инфраструктуру со своими издержками. Наиболее частая причина – это ошибки и недоработки разработчика, которые допустить очень легко, а отследить крайне сложно. Профилирование и отладка сложных SPA - это дорогое удовольствие: хотя на сегодняшний день инструменты для отладки уже достаточно развитые, сложность отладки с ростом сложности приложения растёт экспоненциально. В результате, проблема решается только модульной отладкой и тестированием, что в свою очередь увеличивает затраты на разработку.
Как эти проблемы находят своё отражение в разработке CRM?
При разработке CRM большое количество экранов и форм, различающаяся логика в зависимости от типа пользователя, его прав и разрешений, очень быстро устаревающие данные, необходимость в периодическом обновлении состоянии всей системы – основные факторы, усложняющие разработку CRM на технологии SPA. Кроме того, в процессе эксплуатации с ростом объёма данных разрастается модель, и, следовательно, увеличивается время на обработку данных, в результате система начинает тормозить даже там, где на тестах вела себя приемлемо.
Проблема «нескольких экранов»
Пользователи браузеров с вкладками, находясь на одной странице, часто открывают отдельные страницы по ссылкам в отдельных вкладках браузера, совмещая их с переходами по ссылкам внутри одной вкладки. Подобную возможность хотелось бы иметь, работая с WEB-приложением: например, чтобы открывать страницу проекта в отдельной вкладке и держать её «на пульсе». В случае с SPA это также возможно, но в таком случае накладные расходы на разработку резко увеличиваются – там, где была экономия в случае загрузки страниц, теперь получается перерасход, так как в каждой вкладке приложение будет загружать весь нужный ему для работы код; теряется смысл SPA как одностраничного приложения, ведь для пользователя Интернет очевидно, что работая в браузере, ссылка должна открывать новую страницу, а не вести себя как обычное приложение.
Таким образом, при разработке CRM-систем SPA-архитектура является, по нашему мнению, менее предпочтительной, чем классическая архитектура многостраничного приложения с активным использованием AJAX для обновления данных.
Изложение проблемы получилось достаточно обширным, поэтому рассказ о ее решении мы оставим для отдельного материала. Всем спасибо, кто прочитал, следите за публикациями.
май 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 десятка строк.
Но с другой стороны, конфиги позволили нам создать структуру, легко расширяемую при добавлении новых страниц. Плюс уже в следующей статье мы увидим важность этого немаленького конфига, когда мы будем учить поисковики индексировать наш одностраничник. Ну а стили нужны, чтобы просто выглядело симпатичнее:-)
Есть и третья сторона. Для не знакомых с одностраничными сайтами - это ни фига не простая вещь. И я думаю, это здорово, когда изначально кажущаяся сложной тема, при подробном рассмотрении оказывается вполне себе решаемой, причем без великих усилий с нашей стороны.
Дальше наш демо-сайт будет понемногу развиваться. В следующей статье мы начнем готовить сайт к индексации поисковиками, потому как известно, что одностраничники индексируются из рук вон плохо, если не предпринять специальных действий. Но это из следующих статей серии.
И небольшой опрос
Облачные веб приложения набирают популярность. Множество ИТ компаний видят эту тенденцию и все больше программных продуктов разрабатывают на основе удаленного доступа. Существует много аналогов 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:
- Высокая скорость. Так как SPA не обновляет всю страницу, а только нужную часть, это существенно повышает скорость работы.
- Высокая скорость разработки. Готовые библиотеки и фреймворки дают мощные инструменты для разработки веб приложений. Над проектом могут параллельно работать back-end и front-end разработчики. Благодаря четкому разделение они не будут мешать друг другу.
- Мобильные приложения. SPA позволяет легко разработать мобильное приложение на основе готового кода.
При всех своих достоинствах, Single Page Application имеет некоторые недостатки, которые сдерживают рост популярности:
- Плохая SEO оптимизация. SPA работает на основе javascript и загружает информацию по запросу со стороны клиента. Поисковые системы с трудом могут имитировать данное поведение. Потому большинство страниц попросту недоступны для сканирования поисковыми ботами.
- Не активный javascript. Некоторые пользователи отключают javascript в своих браузерах, а без него ваше приложение не будет работать.
- Низкий уровень безопасности.
JavaScript имеет низкий уровень безопасности, но если использовать современные фреймворки, они могу сделать ваше веб приложение безопасным. Но стоит обратить внимание, что использование jQuery может существенно понизить безопасность вашего проекта.
Одностраничные веб приложения хорошо подходят для разработки динамических платформ, с небольшим объемом данных. Кроме того, если Вам потребуется в будущем построить мобильное приложение , SPA отлично подойдет как основа. Основным недостатком, который сдерживает стремительный рост популярности SPA это плохая SEO оптимизация. Проекты, где SEO имеет важнейший приоритет, стоит использовать MPA. 
Multi Page Application (MPA)
Многостраничные приложения имеют более классическую архитектуру. Каждая страница отправляет запрос на сервер и полностью обновляет все данные. Даже если эти данные небольшие. Таким образом тратится производительность на отображение одних и тех же элементов. Соответственно это влияет на скорость и производительность. Многие разработчики, для того чтобы повысить скорость и уменьшить нагрузку, используют JavaScript/jQuery. Хороший пример, обновление товаров без перезагрузки страницы, при использования фильтров в интернет магазине. Это намного удобней и главное быстрее. Главные преимущества Multi Page Application (MPA):
- Легкая SEO оптимизация. Архитектура MPA позволяет достаточно легко оптимизировать каждую страницу под поисковые системы.
- Легкая разработка. Как правило для разработки многостраничного приложения требуется меньший стек технологий.
- Множество решений.
Используя MPA вы можете найти подходящее коробочное решение. Например использовать Magento, OpenCart для разработки e-commerce веб приложения или Dolphin, Elgg для разработки социальных сетей . Недостатки MPA:
- Для разработки мобильных приложений потребуется намного больше времени. В большинстве случаев потребуется написание back-end с нуля.
- Сложно разделить front-end и back-end. Как правило они очень тесно взаимодействуют друг с другом. Усложняется работа front-end и back-end разработчиков.
Основным преимуществом МПА является хорошая SEO оптимизация и огромные количество коробочных решений.
, , Комментарии: 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.
