Разработка современных web сайтов – . . — HTML 5, CSS 3 Web 2.0. Web-

Читать онлайн HTML 5, CSS 3 и Web 2.0. Разработка современных Web сайтов

Практическое руководство по созданию современных Web-сайтов, соответствующих концепции Web 2.0. Описаны языки HTML 5 и CSS 3, применяемые, соответственно, для создания содержимого и представления Web-страниц. Даны принципы Web-программирования на языке JavaScript с использованием библиотеки Ext Core. Рассказано о создании интерактивных Web-страниц, приведены примеры интерактивных элементов, позволяющие сделать Web-страницы удобнее для посетителя. Раскрыты вопросы реализации подгружаемого и генерируемого содержимого, семантической разметки, применения баз данных для формирования Web-страниц. Показаны способы расширения функциональности Web-сайтов с использованием Web-форм, элементов управления, свободно позиционируемых эле- ментов и программного рисования средствами HTML 5.

Содержание:

• Введение 1

• ЧАСТЬ 1. Содержимое Web-страниц. Язык HTML 5 2

• ЧАСТЬ 2. — Представление Web-страниц. Каскадные таблицы стилей CSS 3 19

• ЧАСТЬ 3. Поведение Web-страниц. Web-сценарии 39

• ЧАСТЬ 4. Подгружаемое и генерируемое содержимое. Семантическая разметка 60

• ЧАСТЬ 5. Последние штрихи 67

• Заключение 84

• ПРИЛОЖЕНИЕ — Расширения CSS 84

HTML 5, CSS 3 и Web 2.0. Разработка современных Web-сайтов.

Введение

Мир Web-дизайна в очередной раз лихорадит. Шутка ли — новые интернет-технологии на подходе!

Что грядет нового в Web-дизайне

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

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

Но уже готовятся новые стандарты, которые описывают очередные версии этих языков: HTML 5 и CSS 3. Они обещают принести в Web-дизайн много нового.

— Упрощенную вставку на Web-страницу аудио- и видеоматериалов.

— Возможности рисования на Web-страницах.

— Многоколоночную верстку текста.

— Поддержку работы в оффлайновом режиме (при отключении от Интернета).

— Дополнительную поддержку мобильных устройств.

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

— И, как водится, многое-многое другое.

Звучит заманчиво, но… Сейчас эти стандарты существуют только в виде «черновых» редакций, и когда выйдут «чистовые», окончательные, никто не знает.

Так отчего же разгорелся весь сыр-бор?

Разработчики Web-обозревателей, не дожидаясь, пока их коллеги, «сочиняющие» интернет-стандарты, завершат работу над HTML 5 и CSS 3, уже внедряют поддержку некоторых их возможностей в свои творения. Так, Mozilla Firefox, Opera, Google Chrome и Apple Safari уже поддерживают интернет-мультимедиа в стиле HTML 5, программное рисование на Web-страницах и работу в оффлайновом режиме. Пусть и не в полной мере, но все-таки поддерживают!

«Не в теме» пока еще Microsoft Windows Internet Explorer. Однако Microsoft уже довольно давно объявила о разработке новой версии своего Web-обозревателя под номером 9. И в плане поддержки всех «горячих» интернет-новинок грозит заткнуть за пояс всех конкурентов. Что ж, у автора есть причины верить: даже предварительная версия Internet Explorer 9, совсем-совсем «сырая», на момент написания этой книги выглядит очень даже неплохо.

Но даже возможности действующих на сегодняшний день версий HTML и CSS на деле используются не в полной мере:

— подгружаемое содержимое — загрузка части содержимого вместо целой Web-страницы — практически не применяется;

— генерируемое содержимое — программное создание части содержимого Web-страницы после ее загрузки — применяется мало;

— разделение содержимого, представления и поведения Web-страниц также почти не реализуется.

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

О чем эта книга

В книге описываются:

— Язык HTML и принципы создания содержимого Web-страниц.

— Язык CSS и принципы создания представления Web-страниц.

— Возможности HTML 5 и CSS 3, уже поддерживаемые современными Web-обозревателями.

— Основы Web-программирования, язык JavaScript и принципы создания поведения Web-страниц.

— Библиотека Ext Core — инструмент, призванный упростить труд Web-программиста.

— Создание интерактивных Web-страниц с конкретными примерами.

— Реализация подгружаемого и генерируемого содержимого и семантической раз- метки данных средствами JavaScript.

— Использование специальных средств — Web-форм, элементов управления и свободных контейнеров — для обеспечения дополнительной функциональности Web-сайтов.

— Реализация программного рисования на Web-страницах средствами HTML 5.

В результате читатель создаст полнофункциональный Web-сайт — справочник по HTML и CSS. Конечно, это только пример — данные технологии можно применить и для разработки любого другого Web-сайта.

Какие программы используются в этой книге

Вопрос далеко не праздный, учитывая то, что за программы сегодня приходится платить… Так что же за программы использовал автор?

Только бесплатные!

— Блокнот — простейший текстовый редактор, стандартно поставляемый в составе Windows.

— Firefox версий 3.6.* — Web-обозреватель. Все примеры тестировались на нем.

— Opera 10.52 и Apple Safari 4.* — Web-обозреватели. На них автор тестировал некоторые примеры.

Другие программы автор в работе практически не применял.

Типографские соглашения

В этой книге часто приводятся форматы написания различных тегов HTML, атрибутов стилей CSS и выражений JavaScript. Нам необходимо запомнить типографские соглашения, используемые для их написания.

ВНИМАНИЕ !

Все эти типографские соглашения автор применяет только в форматах написания тегов HTML, атрибутов стилей CSS и выражений JavaScript. В коде примеров они не имеют смысла.

В угловые скобки (<>) заключены названия значений атрибутов, параметров или фрагментов кода, которые, в свою очередь, набраны курсивом. В код реального Web-сценария, разумеется, нужно подставить реальное значение, конкретный параметр или код.

Пример:

<MAP NAME=» <имя карты> «>

</MAP>

Здесь вместо подстроки <имя карты> нужно подставить конкретное имя карты. Пример:

<FORM>

<теги, формирующие элементы управления>

</FORM>

Здесь вместо подстроки <теги, формирующие элементы управления> следует подставить реальные HTML-теги, формирующие элементы управления.

В квадратные скобки ([]) заключены необязательные фрагменты кода:

<LEGEND [ACCESSKEY=» <быстрая клавиша> «]> <текст заголовка> </LEGEND>

Здесь атрибут тега ACCESSKEY может присутствовать, а может и отсутствовать. Символом вертикальной черты (|) разделены фрагменты кода, из которых в данном месте должен присутствовать только один:

SHAPE=»rect|circle|poly»

Здесь в качестве значения атрибута тега SHAPE должна присутствовать только одна из доступных строк: rect, circle или poly.

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

Пример:

var s = «<LI><CODE><A HREF=\»» + aDataBase[i].url + «\»>» + aDataBase[i].name + «</A></CODE></LI>»;

Приведенный код разбит на две строки, но должен быть набран в одну. Знаки переноса при этом нужно удалить.

Благодарности

Губиной Наталье Анатольевне, начальнику отдела АСУ Волжского гуманитарного института (г. Волжский Волгоградской обл.), где работает автор, — за понимание и поддержку.

Всем работникам отдела АСУ Волжского гуманитарного института — за пони- мание и поддержку.

Родителям — за терпение, понимание и поддержку. Архангельскому Дмитрию Борисовичу — за дружеское участие.

Шапошникову Игорю Владимировичу — за содействие.

Рыбакову Евгению Евгеньевичу, заместителю главного редактора издательства «БХВ-Петербург», — за неоднократные побуждения к работе, без которых автор давно бы обленился.

Издательству » БХВ-Петербург» — за издание моих книг.

Разработчикам Web-обозревателей Firefox, Opera, Chrome и Safari и библиотеки Ext Core, если они меня слышат, — за замечательные программные продукты.

Всем своим читателям и почитателям — за прекрасные отзывы о моих книгах. Всем, кого я забыл здесь перечислить, — за все хорошее.

dom-knig.com

Современные технологии веб-разработки: особенности тенденций 2018-го года

От автора: знаете ли вы об основном отличии специалиста web-разработки от любого другого представителя IT-профессий? Он больше остальных осознает, как быстро устаревают его инструменты. Самые прогрессивные разработчики погружаются в технологии веб разработки, отслеживая их развитие и изменения. Но даже несмотря на постоянный мониторинг, шанс упустить что-либо велик. Держим руку на пульсе прогресса — расскажем сегодня о тенденциях текущего года.

Приложение — новый стандарт сайта

Об этой технологии сегодня расскажем больше, чем об остальных. Причина — нам кажется, что тренд продержится дольше всех современных направлений разработки. Имя ей — Progressive Web-Application, сокращенно PWA. Ее суть в том, чтобы ресурс мог быть сохранен на домашний экран смартфона, подобно нативному приложению. Даже взаимодействие с ними похоже, но веб-приложения такого формата имеют ряд преимуществ перед «нативом» и обычным ресурсом в закладках. Основные отличия:

кроссбраузерность и кроссплатформенность. Когда вы создаете мобильное приложение, то вынуждены проводить web-разработку версий для основных операционных систем: Android, iOS, Windows. Это затратный процесс, особенно если сам проект рассчитан на небольшую аудиторию и не сулит баснословной прибыли. Но с PWA вы просто делаете что-то вроде ссылки, которую нужно красиво оформить;

экономия ресурсов. Нативы используют немало оперативной и физической памяти, в то время как PWA размещены на сервере и могут выполнять те же функции;

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

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

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

Спрос на PWA объясняется и недавним исследованием, проведенным Recode. В последние несколько лет пользователи склонны к удалению обычных приложений. Они занимают место в памяти, на экране, а их установка/удаление отбирает время. Похоже, что спрос на них падает. Особенно это коснулось социальных сетей и Messenger, о котором говорилось выше.

Создавать PWA легко, особенно, если у в ваших руках уже есть адаптивно сверстанный ресурс. Тем более, что web-разработка облегчена широким выбором инструментов. Вооружившись ими, к созданию может приступить даже специалист без широкого стека навыков.

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

PHP: второе дыхание на седьмой версии

Язык гипертекстового препроцессора очень напоминает селебрити: о нем постоянно говорят. Иногда хорошее, чаще плохое. Но суть в том, что он популярен среди разработчиков. Согласно данным компании Google, на нем работает более 80% процентов всех ресурсов в сети (ранее эта цифра была больше).

Те, кто только добавил в свой скилл-стек PHP 5, наверняка задаются вопросом, почему сразу седьмая, а не шестая версия? Но ответ очень прост: PHP 6 была настолько неудачной, что забвение — лучшее, что могло подарить ей общество. В той версии создатели сконцентрировались на поддержке Unicode, что весьма круто для web-разработки. Сначала все смотрели на идею с энтузиазмом, но вскоре он разбился о физические возможности: портирование всех библиотек занимало время, и это тормозило всю остальную разработку. Конечно, можно было бы назвать седьмую версию шестой, но это было уже невозможно.

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

Основным отличием версии 7 стала производительность: движок под названием Just in Time делает язык почти в два раза быстрее. Все изменения, которые происходили, были построены таким образом, чтобы оптимизировать его работу. Также был усовершенствован синтаксис, причем не совсем так, как того хотели «правильные» программисты. Несмотря на ожидания, «препроцессор» не стал сложнее в освоении. Вместо этого появилась возможность сократить количество написанных строк.

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

WordPress становится стандартом

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

WordPress — это система управления контентом, которая максимально адаптирована под web-разработку, освоить все это возможно без особых знаний в программировании и разметке. Потратив несколько часов на обучение, хорошие сайты на WP может создавать даже новичок с нулевым стеком освоенных технологий. Это привлекает не только самих разработчиков: владельцы ресурсов, «натянутых» на WordPress, могут без труда вносить в него изменения.

Радостно то, что большинство претензий к WordPress Tipton (2017), уже давно не актуальны. Современная версия лишена недостатков старых версий, среди которых:

низкая производительность сайта;

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

перегруз хостинга при большом количестве посещений. Можно дать комментарий сразу по двум этим пунктам: это ошибка. На самом деле, Tipton не перегружает хостинг, а ресурсы, управляемые им, работают быстро и стабильно. Вы и сами можете в этом убедиться: столько топовых страниц работает на WordPress. Это и BBC America, и Rolling Stones (издание), и даже официальный портал с новостями о Star Wars. Их посещаемость варьируется от четырех до трехсот тысяч в день. Разве стали бы такие мощные компании доверять «плохой» системе? Конечно, нет;

на WP невозможно создать уникальный дизайн. Это правда, но разве для версии 2017-го года? Вовсе нет. Сегодня существует плагин Visual Composer. C ним можно создавать шедевры web-разработки, даже не вникая в базу HTML/CSS. Кстати, установка дополнения бесплатна, вопреки ожиданиям. А еще новичок может приобрести уникальные шаблоны, на основе которых разработает свой сайт. Стоит это совсем недорого;

поисковик не «видит» сайты на WordPress — популярный слух. Классический пример вывода из недоказанного. Основан на предположении, что на бесплатных и легких в освоении CMS пишут плохие ресурсы, а значит, поисковый движок должен игнорировать страницы на таких CMS в принципе. Проверяется с помощью любого современного поисковика — скажем, Google. Сделайте любой распространённый запрос, и большинство отображенных ресурсов, веб-приложений будут созданы на WordPress и Joomla — самых популярных бесплатных CMS.

Преимущества WP для web-разработки очевидны. Самое важное из них — масса удобных шаблонов. Их достаточно, а цены уютны даже для бюджетного стартапа — основной целевой аудитории. Кроме того, в WordPress легко создать адаптивы — версии для устройств с нестандартным разрешением экрана (мобильные девайсы).

Но новые версии радуют не только новичков, они также имеют существенные улучшения для профессионалов. Например, теперь система инспектирует код и уведомляет разработчика о допущенных ошибках. Также WР имеет плюсы в плане безопасности. Но и это не новость: большинство CMS хвастаются неуязвимостью, которая близка к абсолюту.

Блокчейн и виртуальная реальность: от концепта до применения в web

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

Блокчейн всему голова

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

Больше всего это затронуло сферу финансов: теперь только ленивый стартап не использует блокчейн в своих бизнес-процессах. Это может быть страхование, как в компании Black Insurance, или полноценный банк, как у Bankera. Весь спектр услуг, которые раньше предлагали большие компании с физическими представительствами, теперь полностью обслуживается веб-приложениями. Сегодня это уже серьезные разработки, а не просто идея, которая звучала на форумах.

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

Еще одна реальность

Существует ошибочное мнение о том, что дополненная и виртуальная реальность — это примерно одно и то же. Но существенные различия все же есть: VR (virtual reality) полностью погружает вас в придуманный разработчиком мир (используются шлемы, вроде Oculus Rift), а AR (augmented reality) накладывает объекты на реальный мир, как в игре Pokemon Go.

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

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

Таргет выбран верно: отслеживание активности

Одной из главных современных тенденций в создании веб-продуктов можно назвать контроль за действиями пользователей в сети. Некоторые считают, что это нарушает базовые права человека. Но посмотрим на жизнедеятельность в Интернете трезво: мы здесь давно под колпаком. Google Analytics собирает метаданные о своих юзерах уже несколько лет подряд. С этой точки зрения, ваша активность на одном только сайте — не такая уж и уникальная информация.

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

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

цена;

качество;

непривлекательный товарный вид.

То же самое, только с точностью наоборот: можно определить, какие свойства привлекают больше всего.

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

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Верстка-Мастер. От теории до верстки популярных шаблонов

Изучите современную верстку сайтов с нуля

Подробнее

webformyself.com

выбери себе приключение / Авито corporate blog / Habr

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

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

upd — немного дополнил текст до ката.

Предположим, что я и мой друг Валерка решили сделать стартап. Uber for X, или там еще что-нибудь в таком духе. Собрались в баре, обсудили эту идею, клёвая тема. Надо сделать. Три месяца не спали, не ели, не выходили из дома. Разрабатывали. Запустили и поняли, что это никому не нужно.

Печаль. Попробуем еще раз. На этот раз мы изучили рынок, посмотрели, какие потребности у пользователей, какие проблемы. Мы сделали какой-то прототип совсем на коленке, быстро и бесплатно за два вечера. Прототип взлетел. Круто, идем дальше.

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

Язык

По порядку. На каком языке писать? Можно взять модный функциональный: Haskell, Erlang, Lisp (очень модный среди дедушек старше 70). Либо очередного убийцу JS, который очень клевый, компилируется в JS, имеет все нужные фичи. Но скорее всего, нам некого будет нанимать через год, потому что очередной убийца JS не взлетит, и придется переучиваться заново или переписывать проект.

Попытка номер два. Можно взять что-нибудь проверенное временем. Например, PHP. Это неплохой язык, его модно иногда критиковать, у него есть свои минусы, но на нем легко делать бизнес-логику, он достаточно быстрый, неплохо масштабируется, можно нанять людей когда угодно и где угодно. Но он не очень производительный. Поэтому нам нужно либо много железа, либо писать свой компилятор, как сделали Facebook или ВК.

Еще варианты? Можно взять Perl, но тогда будет некого нанимать ещё вчера. Ещё?
Java. Java — норм. Как язык не очень, на мой субъективный взгляд, но JVM — отличная виртуальная машина, все ок, быстро работает, но железа все равно нужно много. А ещё пока мы на Java писали абстрактный билдер фабрики стратегий вместо того, чтобы делать фичи, пользователи ушли к конкурентам.

Ладно, у нас есть еще Python. В принципе, у него всё ок. Но мы запускаем приложение на Python, оно использует одно ядро из 56, в остальном… все ок. Либо можно взять что-то современное: Go, Rust, еще что-то. Но они слишком низкоуровневые, и мы просто долго делаем фичи… Какой-нибудь язык нам всё равно придется выбрать. Пусть в итоге это будет JS, сойдет.

База данных

База. JS без документной базы — деньги на ветер. У документных баз есть свои плюсы. Они позволяют нам быстро разрабатывать прототипы, не париться насчет схемы, колбасить данные туда-сюда. Плюсов много, минус один: каша из данных. Когда коллекций у нас становится десять, двадцать или сорок вместо трёх, когда мы без отсутствия схем пытаемся склеить из них что-то хорошее и удобоваримое, становится это делать все сложнее. Опять долго делаем фичи.

Ок, давайте возьмем реляционную базу. MySQL, PostgreSQL, или Oracle, если денег хватит. С реляционными базами можно однажды прийти на работу и обнаружить себя в аду из транзакций и хранимок. Это не обязательно произойдёт с нашим проектом. Но если произойдет, то эти хитросплетения логики будет невозможно тестировать. А ещё если вдруг мы достигнем вертикального предела нашего большого золотого сервера, на котором мы хостим базу, потом будет довольно сложно их разделять. Долго делаем фичи.

Ладно. Базу взяли какую-нибудь, бахнули перед ней ORM, чтобы проще было с одного SQL на другой переезжать. Когда-нибудь (spoiler: никогда).

Архитектура

Какую взять архитектуру? Ребята на Хабре пишут, что микросервисы – это клёво. Олег Бунин говорит: «берите микросервисы».

Если начать с микросервисов, то с восьмидесятипроцентной вероятностью границы у них будут неправильные, потому что не до конца продумали доменную модель и плохо поняли, где надо резать, а где не надо. Плюс все берут микросервисы, деплоят их пачками по всему своему кластеру, и через месяц возникает вопрос: «а как это всё теперь тестировать?». Сервисы уже работают в продакшене, а мы их не тестируем. Используя привычные методологии (пирамида тестирования, ручные интеграционные тесты, end-to-end тесты), тестировать микросервисы сложно. Поэтому мы долго делаем фичи.

Ок, тогда давайте бахнем монолит. Это самая правильная идея для стартапа. Очень долго можно жить с отличным монолитом и не иметь проблем. Но если мы решим сильно расширить команду, то надо быть осторожнее. Монолит нормально масштабируется, пока разработчиков 20, 30, 50. Дальше скорость доставки фич падает экспоненциально, а мы теряем пользователей.

Где запускать проект?

Это всё надо где-то запускать. 2018 год, самый логичный вариант сделать это в облаке. Запустишь не в облаке — пацаны засмеют. Но, во-первых, есть федеральный закон 152, значительно ограничивающий выбор облачных провайдеров, у которых можно хоститься. Во-вторых, очень легко приватный ключ от своего аккаунта на Amazon случайно закоммитить в Github, и кто-то обязательно придёт и потратит все ваши деньги. А если этого не произойдёт, то в какой-то момент вас разорят облачные тарифы.

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

В общем, сепаратизм нам не подходит. Логично переходим к вопросу набора команды.

Разработка

Допустим, мы разобрались с языками, базами и тем, где хостить проект. Настало время набирать команду. Можно взять несколько очень крутых ребят, которые все проблемы решат: стократные разработчики, бэкенд-ниндзи, вы понимаете. Возможно, это прокатит. Но на деле вероятно, что приглашённые звёзды будут:

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

В итоге… да-да, долго делаем фичи. Еще вариант — взять обычных девчонок и ребят, которые просто будут писать код, делать фичи нормально. Но если взять много не очень опытных разработчиков с разным бэкграундом, они могут писать код в разном стиле, делать штуки по-разному, и при достаточном размере команды всем будет тесно, все будут у друг друга фигурные скобочки переставлять в пуллреквестах. Это не очень эффективно. Как это можно решить? Начальник может читать весь код. Я могу читать все пуллреквесты, а мой друг и ко-фаундер Валерка потом второй раз будет перечитывать (на всякий случай, мало ли). Понятно, это не масштабируется и все медленно делают фичи.

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

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

Quality Assurance

Можно сказать, что QA-специалисты нам не нужны. Многие так делают, это иногда работает. Но не все разработчики любят писать тесты. Их можно понять. И стоит их лучше мотивировать, чтобы тесты все-таки писали, но реальность жестока: unit-тесты ловят далеко не все баги. А если какой-то разработчик не любит писать тесты и все-таки начал их писать, то скорее всего это будут unit-тесты.

Плюс еще есть подходы, когда ты минимизируешь mean time between failures вместо mean time to recover. Mean time between failures — это когда QA специалист говорит: «не будем релизить, у меня чутье плохое, баги будут, давайте через две недели выкатим». А mean time to recover — это когда вы катите что-нибудь, сразу видите на метриках, что что-то сломалось, и через две минуты все откатили, пофиксили и все ок. Но чтобы можно было проект через две минуты откатить, надо всё покрыть нормальными метриками, а это не всегда тривиально. А если метрики в плачевном состоянии, и мы выкатим плохой релиз, мы можем узнать об этом после того, как все пользователи уйдут от нас к конкурентам.

Другой вариант: всё-таки сделать отдел QA. Вы помните: отдел — это не очень хорошо, это сепаратизм, это нам не подходит. Сепаратизм можно разрулить с помощью кроссфункциональных команд. Да, они решают проблему того, что у нас админ сидит отдельно, тестировщики отдельно.

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

Как это разрулить? Общаться с коллегами в кружках по интересам. Где-то это называют гильдиями, где-то — коммьюнити. Если мы масштабируем команду кроссфункциональными командами, чтобы они не замыкались в себе, мы просто организуем кружок любителей бэкенда, функциональных языков, секьюрити…

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

А ещё — всё это интересно. Интересно решать проблемы, которые уже кто-то решал, новые проблемы еще интереснее решать. Интересно делиться знаниями.

habr.com

Владимир Дронов — HTML 5, CSS 3 и Web 2.0. Разработка современных Web-сайтов » Книги читать онлайн бесплатно без регистрации

Практическое руководство по созданию современных Web-сайтов, соответствующих концепции Web 2.0. Описаны языки HTML 5 и CSS 3, применяемые, соответственно, для создания содержимого и представления Web-страниц. Даны принципы Web-программирования на языке JavaScript с использованием библиотеки Ext Core. Рассказано о создании интерактивных Web-страниц, приведены примеры интерактивных элементов, позволяющие сделать Web-страницы удобнее для посетителя. Раскрыты вопросы реализации подгружаемого и генерируемого содержимого, семантической разметки, применения баз данных для формирования Web-страниц. Показаны способы расширения функциональности Web-сайтов с использованием Web-форм, элементов управления, свободно позиционируемых элементов и программного рисования средствами HTML 5.

Вл. Дронов

HTML 5, CSS 3 и Web 2.0. Разработка современных Web-сайтов

Мир Web-дизайна в очередной раз лихорадит. Шутка ли — новые интернет-технологии на подходе!

Что грядет нового в Web-дизайне

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

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

Но уже готовятся новые стандарты, которые описывают очередные версии этих языков: HTML 5 и CSS 3. Они обещают принести в Web-дизайн много нового.

— Упрощенную вставку на Web-страницу аудио- и видеоматериалов.

— Возможности рисования на Web-страницах.

— Многоколоночную верстку текста.

— Поддержку работы в оффлайновом режиме (при отключении от Интернета).

— Дополнительную поддержку мобильных устройств.

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

— И, как водится, многое-многое другое.

Звучит заманчиво, но… Сейчас эти стандарты существуют только в виде «черновых» редакций, и когда выйдут «чистовые», окончательные, никто не знает.

Так отчего же разгорелся весь сыр-бор?

Разработчики Web-обозревателей, не дожидаясь, пока их коллеги, «сочиняющие» интернет-стандарты, завершат работу над HTML 5 и CSS 3, уже внедряют поддержку некоторых их возможностей в свои творения. Так, Mozilla Firefox, Opera, Google Chrome и Apple Safari уже поддерживают интернет-мультимедиа в стиле HTML 5, программное рисование на Web-страницах и работу в оффлайновом режиме. Пусть и не в полной мере, но все-таки поддерживают!

«Не в теме» пока еще Microsoft Windows Internet Explorer. Однако Microsoft уже довольно давно объявила о разработке новой версии своего Web-обозревателя под номером 9. И в плане поддержки всех «горячих» интернет-новинок грозит заткнуть за пояс всех конкурентов. Что ж, у автора есть причины верить: даже предварительная версия Internet Explorer 9, совсем-совсем «сырая», на момент написания этой книги выглядит очень даже неплохо.

Но даже возможности действующих на сегодняшний день версий HTML и CSS на деле используются не в полной мере:

— подгружаемое содержимое — загрузка части содержимого вместо целой Web-страницы — практически не применяется;

— генерируемое содержимое — программное создание части содержимого Web-страницы после ее загрузки — применяется мало;

— разделение содержимого, представления и поведения Web-страниц также почти не реализуется.

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

О чем эта книга

В книге описываются:

— Язык HTML и принципы создания содержимого Web-страниц.

— Язык CSS и принципы создания представления Web-страниц.

— Возможности HTML 5 и CSS 3, уже поддерживаемые современными Web-обозревателями.

— Основы Web-программирования, язык JavaScript и принципы создания поведения Web-страниц.

— Библиотека Ext Core — инструмент, призванный упростить труд Web-программиста.

— Создание интерактивных Web-страниц с конкретными примерами.

— Реализация подгружаемого и генерируемого содержимого и семантической разметки данных средствами JavaScript.

— Использование специальных средств — Web-форм, элементов управления и свободных контейнеров — для обеспечения дополнительной функциональности Web-сайтов.

— Реализация программного рисования на Web-страницах средствами HTML 5.

В результате читатель создаст полнофункциональный Web-сайт — справочник по HTML и CSS. Конечно, это только пример — данные технологии можно применить и для разработки любого другого Web-сайта.

Какие программы используются в этой книге

Вопрос далеко не праздный, учитывая то, что за программы сегодня приходится платить… Так что же за программы использовал автор?

Только бесплатные!

— Блокнот — простейший текстовый редактор, стандартно поставляемый в составе Windows.

— Firefox версий 3.6.* — Web-обозреватель. Все примеры тестировались на нем.

— Opera 10.52 и Apple Safari 4.* — Web-обозреватели. На них автор тестировал некоторые примеры.

Другие программы автор в работе практически не применял.

Типографские соглашения

В этой книге часто приводятся форматы написания различных тегов HTML, атрибутов стилей CSS и выражений JavaScript. Нам необходимо запомнить типографские соглашения, используемые для их написания.

ВНИМАНИЕ!

Все эти типографские соглашения автор применяет только в форматах написания тегов HTML, атрибутов стилей CSS и выражений JavaScript. В коде примеров они не имеют смысла.

В угловые скобки (<>) заключены названия значений атрибутов, параметров или фрагментов кода, которые, в свою очередь, набраны курсивом. В код реального Web-сценария, разумеется, нужно подставить реальное значение, конкретный параметр или код.

Пример:

<MAP NAME=»<имя карты>«>

</MAP>

Здесь вместо подстроки <имя карты> нужно подставить конкретное имя карты. Пример:

<FORM>

<теги, формирующие элементы управления>

</FORM>

Здесь вместо подстроки <теги, формирующие элементы управления> следует подставить реальные HTML-теги, формирующие элементы управления.

В квадратные скобки ([]) заключены необязательные фрагменты кода:

<LEGEND [ACCESSKEY=»<быстрая клавиша>«]><текст заголовка></LEGEND>

Здесь атрибут тега ACCESSKEY может присутствовать, а может и отсутствовать. Символом вертикальной черты (|) разделены фрагменты кода, из которых в данном месте должен присутствовать только один:

SHAPE=»rect|circle|poly»

Здесь в качестве значения атрибута тега SHAPE должна присутствовать только одна из доступных строк: rect, circle или poly.

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

Пример:

var s = «<LI><CODE><A HREF=»» + aDataBase[i].url + «»>» + aDataBase[i].name + «</A></CODE></LI>»;

Приведенный код разбит на две строки, но должен быть набран в одну. Знаки переноса при этом нужно удалить.

Благодарности

Автор приносит благодарности своим родителям, знакомым и коллегам по работе.

Губиной Наталье Анатольевне, начальнику отдела АСУ Волжского гуманитарного института (г. Волжский Волгоградской обл.), где работает автор, — за понимание и поддержку.

Всем работникам отдела АСУ Волжского гуманитарного института — за понимание и поддержку.

Родителям — за терпение, понимание и поддержку. Архангельскому Дмитрию Борисовичу — за дружеское участие.

Шапошникову Игорю Владимировичу — за содействие.

Рыбакову Евгению Евгеньевичу, заместителю главного редактора издательства «БХВ-Петербург», — за неоднократные побуждения к работе, без которых автор давно бы обленился.

Издательству » БХВ-Петербург» — за издание моих книг.

Разработчикам Web-обозревателей Firefox, Opera, Chrome и Safari и библиотеки Ext Core, если они меня слышат, — за замечательные программные продукты.

Всем своим читателям и почитателям — за прекрасные отзывы о моих книгах. Всем, кого я забыл здесь перечислить, — за все хорошее.

ЧАСТЬ 1. Содержимое Web-страниц. Язык HTML 5

ГЛАВА 1

Введение в современный Web-дизайн. Web 2.0. Создание Web-страниц 

Всемирная паутина, WWW, Web-дизайн, Web-сайт, Web-страница — все знают, что это такое. Но что такое современная Всемирная паутина, современный Web- дизайн и современная Web-страница? Именно с ответов на все эти вопросы начнется данная книга. Далее мы немного поговорим о принципах функционирования Интернета, Web-страницах и Web-сайтах, создадим нашу первую Web-страницу, начнем изучать язык HTML 5 и подберем программы, которые будем использовать в работе. Так сказать, с места в карьер…

Современный Web-дизайн. Концепция Web 2.0 

Раньше доступ в Интернет можно было получить только с компьютеров. Потом в Интернет стали выходить с мобильных телефонов. Сейчас к Сети подключились мультимедийные плееры, устройства чтения электронных книг и телевизоры. А завтра — кто знает; может быть, мы будем выходить на Web-сайты с утюга или пылесоса…

nice-books.ru

HTML 5, CSS 3 и Web 2.0. Разработка современных Web-сайтов | Дронов В. А.

Практическое руководство по созданию современных Web-сайтов, соответствующих концепции Web 2.0. Описаны языки HTML 5 и CSS 3, применяемые, соответственно, для создания содержимого и представления Web-страниц. Даны принципы Web-программирования на языке JavaScript с использованием библиотеки Ext Core. Рассказано о создании интерактивных Web-страниц, приведены примеры интерактивных элементов, позволяющие сделать Web-страницы удобнее для посетителя. Раскрыты вопросы реализации подгружаемого и генерируемого содержимого, семантической разметки, применения баз данных для формирования Web-страниц. Показаны способы расширения функциональности Web-сайтов с использованием Web-форм, элементов управления, свободно позиционируемых элементов и программного рисования средствами HTML 5.

Мир Web-дизайна в очередной раз лихорадит. Шутка ли — новые интернет-технологии на подходе!

Дронов В. А. HTML 5, CSS 3 и Web 2.0. Разработка современных Web-сайтов. — СПб.: БХВ-Петербург, 2011. — 416 с.: ил. — (Профессиональное программирование) ISBN 978-5-9775-0596-3.

Что грядет нового в Web-дизайне

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

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

Но уже готовятся новые стандарты, которые описывают очередные версии этих языков: HTML 5 и CSS 3. Они обещают принести в Web-дизайн много нового.

— Упрощенную вставку на Web-страницу аудио- и видеоматериалов.

— Возможности рисования на Web-страницах.

— Многоколоночную верстку текста.

— Поддержку работы в оффлайновом режиме (при отключении от Интернета).

— Дополнительную поддержку мобильных устройств.

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

— И, как водится, многое-многое другое.

Звучит заманчиво, но… Сейчас эти стандарты существуют только в виде «черновых» редакций, и когда выйдут «чистовые», окончательные, никто не знает.

Так отчего же разгорелся весь сыр-бор?

Разработчики Web-обозревателей, не дожидаясь, пока их коллеги, «сочиняющие» интернет-стандарты, завершат работу над HTML 5 и CSS 3, уже внедряют поддержку некоторых их возможностей в свои творения. Так, Mozilla Firefox, Opera, Google Chrome и Apple Safari уже поддерживают интернет-мультимедиа в стиле HTML 5, программное рисование на Web-страницах и работу в оффлайновом режиме. Пусть и не в полной мере, но все-таки поддерживают!

«Не в теме» пока еще Microsoft Windows Internet Explorer. Однако Microsoft уже довольно давно объявила о разработке новой версии своего Web-обозревателя под номером 9. И в плане поддержки всех «горячих» интернет-новинок грозит заткнуть за пояс всех конкурентов. Что ж, у автора есть причины верить: даже предварительная версия Internet Explorer 9, совсем-совсем «сырая», на момент написания этой книги выглядит очень даже неплохо.

Но даже возможности действующих на сегодняшний день версий HTML и CSS на деле используются не в полной мере:

— подгружаемое содержимое — загрузка части содержимого вместо целой Web-страницы — практически не применяется;

— генерируемое содержимое — программное создание части содержимого Web-страницы после ее загрузки — применяется мало;

— разделение содержимого, представления и поведения Web-страниц также почти не реализуется.

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

HTML 5, CSS 3 и Web 2.0. Разработка современных Web-сайтов | Владимир Дронов | Профессиональное программирование | Купить книги | ISBN 978-5-9775-0596-3

 Скачать книгу «Дронов В. А. HTML 5, CSS 3 и Web 2.0. Разработка современных Web-сайтов.» бесплатно в ознакомительных целях!

Смотрите также другие материалы:

Изучаем SQL. Бейли Линн.

Начинаем работать с Drupal. Полное практическое руководство.

Хаген Граф. 10 легких шагов к освоению Joomla! 3.0

artageless.com

Семь принципов создания современных веб-приложений / Habr

Эта статья основана на моей презентации с конференции BrazilJS в августе 2014 года. Она базируется на идеях, о которых я писал в блоге недавно, в основном, в связи с UX и производительностью.

Я хочу представить 7 действенных принципов для веб-сайтов, которые хотят применить JavaScript для управления UI. Эти принципы являются результатом моей работы как веб-дизайнера, но также как давнего пользователя WWW.

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

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

• Должен ли JavaScript использоваться как замена функциям браузера: история, навигация, рендеринг?
• Умирает ли бэкенд? Нужно ли вообще рендерить HTML?
• Правда ли, что будущее за приложениями на одной странице (Single Page Applications, SPA)?
• Должен ли JS генерировать страницы на веб-сайте и рендерить страницы в веб-приложениях?
• Нужно ли использовать техники вроде PJAX или TurboLinks?
• Каково точное отличие между веб-сайтом и веб-приложением? Должно ли остаться что-то одно?

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

1. Рендеринг страниц на сервере

tl;DR: Рендеринг на сервере осуществляется не ради SEO, а для производительности. Принимайте в расчёт дополнительные запросы для получения скриптов, стилей и последующие запросы к API. В будущем, принимайте в расчёт использование метода HTTP 2.0 Push.

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

Причины вполне очевидны. Страницы передаются по интернету, у которого есть физические ограничения, что незабвенно проиллюстрировал Стюарт Чешир в знаменитом эссе «Это latency, дурачок»:

Расстояние между Стэнфордом и Бостоном 4320 км.
Скорость света в вакууме 300 x 10^6 м/с.
Скорость света в оптоволокне составляет примерно 66% скорости света в вакууме.
Скорость света в оптоволокне 300 x 10^6 м/c * 0,66 = 200 x 10^6 м/c.
Односторонняя задержка при передаче в Бостон 4320 км / 200 x 10^6 м/c = 21,6 мc.
Задержка при передаче туда и обратно 43,2 мc.
Пинг из Стэнфорда в Бостон в интернете современного образца около 85 мс (…)
Итак, современное оборудование интернета передаёт сигнал со скоростью 0,5 от скорости света.

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

Это особенно важно в связи с ростом популярности JavaScript-приложений, которые обычно содержат только разметку <script> и <link> рядом с пустым полем <body>. Так называемые одностраничные приложения (Single Page Applications, SPA) — сервер возвращает одну страницу, а всё остальное вызывается кодом на клиентской стороне.

Представьте сценарий, когда пользователь напрямую заходит по адресу аpp.com/orders. К моменту, когда ваше приложение получает и обрабатывает этот запрос, у него уже есть важная информация о том, что нужно показывать на странице. Оно может, например, подгрузить заказ из базы данных и добавить его в ответ. А вот большинство SPA в такой ситуации возвращает пустую страницу и тег <script>. Потом придётся ещё раз обменяться запросами для получения содержимого скрипта, и ещё раз — для получения контента.

Анализ HTML, отправляемого сервером для каждой страницы SPA

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

Однако, даже с учётом кеша, имеется определённый проигрыш в производительности, если учесть время на парсинг и выполнение скрипта. В статье «jQuery слишком большой для мобильника?» говорится, как один только jQuery может тормозить некоторые мобильные браузеры на сотни миллисекунд.

Что ещё хуже, обычно пользователь не получает никакого фидбека в то время, как загружаются скрипты. Результат — чистая страница на экране, которая потом внезапно превращается в полностью загруженную страницу.

Самое главное, мы обычно забываем, что наиболее распространённые транспорт для передачи интернет-данных (TCP) стартует медленно. Это почти наверняка гарантирует, что большинство комплектов со скриптами не будут переданы за один раз, делая вышеописанную ситуацию ещё хуже.

TCP-соединение начинается с обмена пакетами для рукопожатия. Если вы используете SSL, что важно для безопасной передачи скриптов, происходит два дополнительных обмена пакетами (один, если клиент восстанавливает сессию). Только после этого сервер может начать отправку данных, но практика показывает, что он делает это медленно и порционно.

Механизм контроля заторов под названием Slow Start встроен в протокол TCP, чтобы отправлять данные, постепенно наращивая количество сегментов. Это имеет два серьёзных вывода для SPA:

1. Большие скрипты загружаются гораздо дольше, чем кажется. Как объясняется в книге «High Performance Browser Networking» Ильи Григорика, требуется «четыре обмена пакетами (…) и сотни миллисекунд задержки, чтобы выйти на 64 КБ обмена данными между клиентом и сервером». Например, в случае быстрого интернет-соединения между Лондоном и Нью-Йорком, требуется 225 мс, прежде чем TCP сможет выйти на максимальный размер пакета.

2. Поскольку это правило действует также для первоначальной загрузки страницы, то очень важно, какой контент грузится для рендеринга на странице в первую очередь. Как заключает Пол Ириш в своей презентации «Доставка товаров», критически важны первые 14 КБ. Это понятно, если посмотреть на график с указанием объёмов передачи между клиентом и сервером на первых этапах установки соединения.

Сколько КБ сервер может отправить на каждом этапе соединения, по сегментам

Веб-сайты, которым удаётся доставить контент (пусть даже базовую разметку без данных) в этом окне, кажутся исключительно отзывчивыми. На самом деле, многие авторы быстрых серверных приложений воспринимают JavaScript как нечто ненужное или что нужно использовать с большой осторожностью. Такое отношение ещё больше усиливается, если у приложения быстрые бэкенд и база данных, а его серверы находятся возле пользователей (CDN).

Роль сервера в ускорении представления контента напрямую зависит от веб-приложения. Решение не всегда сводится к «рендерингу целых страниц на сервере».

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

Исключительно важна качественная оценка скриптов и стилей с учётом информации, которая у сервера есть о сессии, клиенте и URL. Скрипты, которые осуществляют сортировку заказов, очевидно будут важнее для /orders, чем логика страницы настроек. Может быть, не настолько очевидная, но есть разница в загрузке «структурного CSS» и «CSS для оформления». Первый может понадобиться для кода JavaScript, так что требуется блокировка, а второй загружается асинхронно.

Хороший пример SPA, которое не приводит к излишнему обмену пакетами, — концептуальный клон StackOverflow в 4096 байтах, он теоретически может загружаться с первым же пакетом после рукопожатия на TCP-соединении! Автор умудрился добиться такого за счёт отказа от кеширования, используя inline для всех ресурсов в ответе с сервера. Применив SPDY или HTTP/2 server push, теоретически возможно передать весь кешируемый клиентский код за один хоп. Ну а в настоящее время, рендеринг частей или всей страницы на стороне сервера остаётся самым популярным способом избавиться от лишних раундов обмена пакетами.

Proof-of-concept SPA с использованием inline для CSS и JS, чтобы избавиться от лишних roundtrip’ов

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

С моей точки зрения, самый большой недостаток производительности во многих популярных системах в наше время объясняется прогрессивным накоплением сложности в стеке. Со временем добавлялись технологии вроде JavaScript и CSS. Их популярность тоже постепенно росла. Только сейчас мы можем оценить, как их можно использовать по-другому. Речь идёт и об улучшении протоколов (это показывает нынешний прогресс SPDY и QUIC), но наибольшую выгоду несёт всё-таки оптимизация приложений.

Полезно будет вспомнить некоторые исторические дискуссии вокруг дизайна ранних версий HTML и WWW. Например, этот список рассылки от 1997 года предлагает добавить тег <img> в HTML. Марк Андрессен повторяет, насколько важно быстро доставлять информацию:

«Если документ нужно составлять в единое целое на лету, то это может быть сколь угодно сложным, и даже если сложность ограничить, у нас всё равно возникнут крупные проблемы с производительностью из-за структуризации документов подобным способом. Прежде всего, это сразу нарушает принцип одного хопа в WWW (ну, IMG тоже его нарушает, но по очень специфической причине и в очень ограниченном смысле) — уверены ли мы, что хотим этого?»

2. Немедленный ответ на действия пользователя

tl;DR: JavaScript позволяет вообще спрятать сетевую задержку. Используя это как принцип дизайна, мы можем даже убрать из приложения почти все индикаторы загрузки и сообщения “loading”. PJAX или TurboLinks упускают возможности по увеличению субъективной скорости интерфейса.

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

Важный фактор — непредсказуемое качество связи между клиентом и сервером. Если качество связи плохое, то будет происходить повторная передача пакетов. Там, где контент должен загружаться за пару roundtrip’ов, может понадобиться гораздо больше.

В этом главное преимущество JavaScript для улучшения UX. Если на клиентской стороне интерфейс управляется с помощью скриптов, мы можем спрятать сетевую задержку. Мы можем создать впечатление высокой скорости. Мы можем искусственно достигнуть нулевой задержки.

Предположим снова, что перед нами обычный HTML. Документы соединяются гиперссылками или тегами <a>. Если нажать на любой из них, то браузер осуществит сетевой запрос, что занимает непредсказуемо долгое время, потом получает и обрабатывает полученные данные и наконец переходит в новое состояние.

JavaScript позволяет реагировать немедленно и оптимистично на действия пользователя. Нажатие на ссылку или кнопку приводит к немедленной реакции, без обращения в Сеть. Известный пример — это интерфейс Gmail (или Google Inbox), в котором архивация почтового сообщения происходит немедленно, тогда как соответствующий запрос к серверу отправляется и обрабатывается асинхронно.

В случае с формой, вместо ожидания какого-то кода HTML в качестве ответа на её заполнение, мы можем реагировать сразу, как только пользователь нажал “Enter”. Или даже лучше, как делает поиск Google, мы можем реагировать ещё раньше, готовя разметку для новой страницы заблаговременно.

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

Заглавная страница Google вполне подходит в качестве примера, потому что она очень чётко демонстрирует первые два принципа из нашей статьи.

Во-первых, пакетный дамп TCP-соединения с www.google.com показывает, что они специально стараются отправить всю страницу целиком сразу после получения запроса. Весь обмен пакетами, включая закрытие соединения, занимает 64 мс для меня в Сан-Франциско. Вероятно, это было актуально для них с самого начала.

В конце 2004 года, компания Google стала пионером в использовании JavaScript для выдачи подсказок в реальном времени в процессе набора поискового запроса (интересно, что эту функцию сотрудник разработал в свободные от основной работы 20% времени, так же как и Gmail). Это даже стало фундаментом для появления Ajax:

Посмотрите на Google Suggest. Наблюдайте, как обновляются поисковые термины по мере набора текста, практически мгновенно… без задержки на перезагрузку страницы. Google Suggest и Google Maps — это два примера нового подхода к созданию веб-приложений, которые мы в Adaptive Path назвали “Ajax”

И в 2010 они представили Instant Search, в котором JS играет центральную роль, вообще исключая обновление страницы вручную и переключаясь на разметку «поисковые результаты» при первом же нажатии клавиши, как видно на иллюстрации вверху.

Другой видный пример адаптации разметки, возможно, лежит у вас в кармане. С первых же дней iPhone OS требовала от авторов приложений предоставить картинку default.png, которое можно сразу вывести на экран во время загрузки самого приложения.

iPhone OS принудительно загружает default.png перед запуском приложения

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

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

Мы можем зарегистрировать попытку пользователя загрузить файл разными способами: drag-n-drop, вставка из буфера, выбор файла. Затем, благодаря новым HTML5 APIs, мы можем отобразить контент, как будто он уже загружен. Пример такого рода интерфейса — наша работа с загрузками в Cloudup. Обратите внимание, как миниатюра изображения генерируется и рендерится мгновенно:

Изображение рендерится и отображается до окончания загрузки

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

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

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

Но даже в этих случаях, отображение на экране спиннеров или индикаторов загрузки следует прекратить. Их нужно отображать только после того, как пользователь считатиает отклик не мгновенным. В соответствии с часто цитируемым исследованием Nielsen:

Базовый совет по времени отклика остаётся неизменным уже тридцать лет Miller 1968; Card et al. 1991:
* 0,1 секундs является лимитом, чтобы пользователь воспринимал отклик как немедленный, здесь не требуется отображение никакой дополнительной информации, кроме результата операции.
* 1,0 секунды является лимитом на непрерывность потока мысли у пользователя, даже хотя он заметит задержку. Обычно, не требуется никакой дополнительной индикации при задержки более 0,1 секунды, но менее 1,0 секунды, но у пользователя пропадает ощущение прямой работы с данными.
* 10 секунд является лимитом удерживания внимания пользователя на диалоге. При большей задержке пользователи захотят выполнить другую задачу, ожидая отклика от компьютера.

Техники вроде PJAX или TurboLinks, к сожалению, упускают большинство возможностей, описанных в данном разделе. Код на клиентской стороне не «знает» о будущем состоянии страницы до тех пор, пока не состоится обмен данными с сервером.

3. Реакция на изменение данных

tl;DR: Когда на сервере обновляются данные, клиента следует уведомлять без задержки. Это такая форма повышения производительности, когда пользователя освобождают от необходимости совершать дополнительные действия (нажимать F5, обновлять страницу). Новые проблемы: управление (повторным) соединением, восстановление состояния.

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

Уходит в прошлое модель передачи по HTML данных, которые остаются статичными до тех пор, пока пользователь не обновит страницу (традиционные веб-сайты) или не взаимодействует с ней (Ajax).

Ваш UI должен обновляться автоматически.

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

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

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

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

Однопользовательское приложение тоже может получить пользу от «реактивности»

Полезно представлять всю информацию, которая отправляется пользователю как «реактивную». Синхронизация сессии и состояния авторизации — один из примеров универсального подхода. Если у пользователей вашего приложения одновременно открыто несколько вкладок, то окончание рабочей сессии на одной из них должно сразу деактивировать авторизацию на всех остальных. Это неизбежно ведёт к улучшению безопасности и лучшей защите конфиденциальной информации, особенно в ситуациях, когда несколько человек имеют доступ к одному устройству.

Каждая страница реагирует на состоянии сессии и статус авторизации

Как только вы установили правило, что информация на экране обновляется автоматически, важно поработать над новой задачей: восстановление состояния.

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

Пример того, что происходит в случае некорректного обновления связи

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

4. Контроль обмена данными с сервером

tl;DR: Теперь мы можем тонко настраивать обмен данными с сервером. Убедитесь в обработке ошибок, повторных запросах в пользу клиента, синхронизации данных в фоновом режиме и сохранении кеша в офлайне.

Когда появился веб, обмен данными между клиентом и сервером был ограничен несколькими способами:

1. Нажатие на ссылку отправит GET для получения новой страницы и её рендеринга.
2. Отправка формы отправит POST или GET с последующим рендерингом новой страницы.
3. Внедрение изображения или объекта отправит GET асинхронно с последующим рендерингом.

Простота такой модели очень привлекательна, и сейчас всё определённо усложнилось, когда речь идёт о понимании, как получать и отправлять информацию.

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

Вероятно, самый раздражающий артефакт старого веба

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

Сейчас у нас есть множество API (XMLHttpRequest, WebSocket, EventSource, это лишь некоторые из них), которые дают полный и чёткий контроль над потоком данных. Кроме возможности публиковать пользовательские данные через форму, у нас появились новые возможности по улучшению UX.

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

При обнаружении дисконнекта, полезно сохранить данные в памяти (а ещё лучше, в localStorage), так что их можно отправить позднее. Это особенно важно в свете будущего использования ServiceWorker, который позволяет приложениям JavaScript работать в фоновом режиме. Если ваше приложение не открыто, вы всё ещё можете продолжать попытки синхронизировать данные с сервером в фоновом режиме.

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

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

Важно ещё убедиться, что пользователь случайно не прервёт поток данных. Это может случиться в двух ситуациях. Первый и самый очевидный случай — закрытие браузера или вкладки, что мы пытаемся предотвратить обработчиком beforeunload.

Предупреждение beforeunload

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

5. Не ломай историю, улучшай её

tl;DR: Если браузер не будет управлять URL’ами и историей, у нас возникнут новые проблемы. Убедитесь, что вы соответствуете ожидаемому поведению в отношении прокрутки. Сохраняйте собственный кеш для быстрого фидбека.

Если не считать отправки форм, то при использовании в веб-приложении одних только гиперссылок у нас будет полностью функциональная навигация «Вперёд/Назад» в браузере.

К примеру, типичную «бесконечную» страницу обычно делают с помощью кнопки на JavaScript, которая запрашивает дополнительные данные/HTML и вставляет их. К сожалению, немногие при этом помнят о необходимости вызова history.pushState или replaceState как обязательного шага.

Вот почему я использую слово «ломать». С простой моделью первоначального веба такая ситуация была невозможна. Каждое изменение состояния основывалось на изменении URL.

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

Одну такую возможность Дэниел Пипиус назвал Fast Back:

Кнопка «Назад» должна работать быстро; пользователи не ожидают слишком большого изменения данных.

Это как рассматривать кнопку «Назад» в качестве кнопки из веб-приложения и применить к ней принцип № 2: немедленно реагировать на действие пользователя. Главное, что у вас есть возможность решить, как организовать кеширование предыдущей страницы и мгновенно вывести её на экран. Вы можете затем применить принцип № 3, а потом информировать пользователя о поступлении новых данных на эту страницу.

Всё ещё остаётся несколько ситуаций, когда вы не можете контролировать поведение кеша. Например, если вы отрендерили страницу, затем ушли на сторонний сайт, а потом пользователь нажал «Назад». Этому маленькому багу особенно подвержены приложения, которые рендерят HTML на стороне сервера, а потом модифицируют его на стороне клиента:

Некорректная работа кнопки «Назад»

Ещё один способ сломать навигацию — игнорирование памяти о состоянии прокрутки. Ещё раз, страницы, которые не используют JS и ручное управление историей, скорее всего, не будут иметь тут проблем. Но динамические страницы будут. Я протестировал две самые популярные новостные ленты на основе JavaScript в интернете: Twitter и Facebook. У обоих обнаружилась амнезия на прокрутку.

Бесконечное листание страниц — обычно, признак скроллинг-амнезии

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

Изменение вида комментариев нужно сохранять в истории

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

6. Обновление кода через push-сообщения

tl;DR: Недостаточно отправлять через push-сообщения только данные, нужно ещё и код. Избегайте ошибок API и повышайте производительность. Используйте stateless DOM для безболезненной перелицовки приложения.

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

Во-первых, это уменьшает количество возможных ошибок и повышает надёжность. Если вы сделали важное изменение в API бэкенда, то должны обновить код клиентских программ. В противном случае, клиенты могут не воспринять новые данные или могут прислать данные в несовместимом формате.

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

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

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

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

Ещё лучший подход — «горячая» замена кода. Это значит, что не придётся осуществлять полную перезагрузку страницы. Вместо этого, определённые модули заменяются на лету, а их код повторно отправляется на выполнение.

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

Например, в нашем веб-приложении есть модуль, который устанавливает шину для передачи event’ов (как socket.io). Когда событие наступает, состояние определённого компонента меняется и это отражается в DOM. Затем вы изменяете поведение этого компонента, например, так, что он генерирует разные разметки DOM для существующего и нового состояний.

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

Но сразу возникает проблема с тем, как оценить модули без нежелательных побочных эффектов. Здесь лучше всего подходит архитектура вроде той, которую предлагает React. Если код компонента обновляется, его логика может быть просто повторно исполнена, и DOM обновляется. Объяснение этой концепции от Дэна Абрамова читай здесь.

По существу, идея заключается в том, что вы обновляете DOM (или перекрашиваете его), что существенно помогает в замене кода. Если состояние сохранено в DOM или обработчики event’ов установлены приложением, то обновление кода может стать намного более сложной задачей.

7. Предсказание поведения

tl;DR: Отрицательная задержка.

У современного JavaScript-приложения могут быть механизмы для предсказания действий пользователя.

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

Немного более продвинутый метод мониторинга отслеживания движения мыши анализирует её траекторию на предмет будущего «столкновения» с интерактивными элементами, как кнопки. Пример на jQuery:

Плагин jQuery предугадывает траекторию мыши

Заключение

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

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

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

habr.com

Проектирование и разработка веб структуры сайтов и приложений: основные правила

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

Приложение и сайт: есть ли разница в структуре

Многие продвинутые пользователи сети до сих пор не могут определить, чем отличается приложение от сайта. Наверное, это один из самых распространенных запросов относительно веб-разработки, которые вбивают юзеры. И правда, разница размыта настолько, что даже сам создатель перед проектированием не всегда знает, что он будет разрабатывать. Самый распространённый ответ: это почти одно и тоже. Только сайт не всегда приложение, а приложение всегда сайт. Если вы знакомы с кругами Эйлера, то такой рисунок сможет вам немного прояснить ситуацию.

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

По сути, с веб-приложением все так же. Но, проектируя приложение, нельзя забывать, что оно должно выполнять и определенные бизнес-функции. Например, покупка цветов, заказ услуг и прочее. Для приложения характерна динамика — страница в браузере изменяется соответственно с личностью пользователя и его поведенческими реакциями. Для этого нужно правильно обустроить архитектуру системы «вопрос-ответ», которая и будет частью web-структуры, о которой поговорим сегодня.

Но динамический веб-сайт — норма для нашего времени. «Статика» используется лишь на сайтах-визитках, но даже их пытаются украсить динамическими элементами. Конечно, если есть динамика, построенная на HTML-файлах, которые ссылаются друг на друга, это можно называть «чистым» сайтом. Но в целом, если говорить о современной web-структуре, настоящей разницы между сайтом и приложением просто не существует.

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

Многогранная структура

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

Все, из чего состоит сайт

…или приложение, если так удобнее. Несмотря на то, что подходы в разработке совершенно разные, как и инструменты, которыми пользуется создатель, можно выделить три основных элемента при проектировании:

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

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

система управления базой данных. Это компонент web-структуры, который хранит всю необходимую информацию для работы приложения. Новичкам сложно понять, для чего он нужен: можно ведь просто создать папку с нужными файлами и ссылаться на них в коде. Но если бы такой подход использовали при создании ВКонтакте, вы бы увидели этот сайт примерно в 2028 году. К тому же, работал бы он медленно и не всегда корректно. СУБД позволяет не только оперативно работать с готовыми данными, но и постоянно пополнять базу. Наиболее популярными СУБД являются MySQL и MariaDB.

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

Для каждой из сторон этого процесса характерны свои языки программирования. Для фронтенда это формальные HTML/CSS + JavaScript. Для серверной части все гораздо разнообразнее. По сути, на «бэке» можно использовать любой из языков общего назначения, но, как правило, это PHP, Java, Python, Ruby и С-подобные PL.

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Семантическая структура

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

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

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

Наиболее распространенной является древовидная структура. Видели генеалогическое древо? Схема точно такая же, только «родитель» один — главная страница. Здесь все подразделы логически распределены. Такое проектирование наиболее предпочтительно для всех веб-проектов. Даже если у вас простая визитка и несколько ссылок в меню — лучше создавать ее на основе «дерева». Например, у вас сайт тату-салона. Логично будет поделить блоки на мастеров, им дать ссылки на эскизы и работы, а остальные ветки распределить на ценовую политику и отзывы на работу.

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

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

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

Файлы в системе

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

Как вы уже понимаете, здесь находятся различные мультимедийные файлы, которые будет отображать сайт, а также все остальные документы, с которых он состоит. Здесь и HTML/CSS разметка, и клиентские сценарии, с которыми взаимодействуют пользователи.

На самом деле, не существует универсального совета по созданию толковой структуры для сайта. Но некоторым принципам все же нужно следовать. Для начала необходимо распределить данные по категориям. Не стоит хранить музыкальное оформление, иллюстрации и видеоролики в «корне» вместе с index.html. Будет намного лучше, если для каждого вида данных вы создадите отдельную папку. Еще лучше, если внутри таких папок вы создадите еще и подвиды.

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

Толковая web-структура отличается также и тем, что имена папок и файлов в ней несут смысловую нагрузку. Ни к чему называть каталог «one» и помнить его содержание. Если есть возможность разгрузить голову — сделайте это. Тем более, если после вас с проектом будет работать другой разработчик. Ему безымянное проектирование доставит немало хлопот. Также стремитесь называть все английскими словами. Русскоязычный человек без труда поймет, что находится в папке predriyatiye. Но для иностранца это будет бессмысленный набор символов, который он не сможет перевести без посторонней помощи.

Структурный помощник

Для человека, который никогда не работал с web-структурой, ее написание кажется непосильным логическим трудом, особенно если есть трудности с объектным мышлением. Но, как уже говорилось в одной из наших статей, выдумка велосипеда — порок веб-разработчика. Если что-то уже написано до вас — лучше использовать это решение (совершенствуйте его!).

К примеру, вы создаете приложение и знаете, что у конкурента оно уже есть и хорошо работает. Подсмотрите структуру у него! Для таких целей существует специальное ПО, которое скачивает сайт со всеми его элементами. Примером такой программы может служить Teleport Pro для Windows, которая успела себя хорошо зарекомендовать. От аналогов ее отличает корректность скачивания и высокая скорость. Так что некогда придуманную структуру можно рассмотреть и применить для своего кейса.

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

JavaScript. Быстрый старт

Изучите основы JavaScript на практическом примере по созданию веб-приложения

Узнать подробнее

Разработка веб-приложения на PHP

Создайте веб-приложение на PHP на примере приема платежей на сайте

Смотреть

webformyself.com