Платформа web что это

Как ор­га­ни­зо­ва­на веб-плат­фор­ма

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

Веб-платформа Скопировать ссылку

«Веб-платформа» — это набор стандартизированных API (HTML, CSS, JavaScript, SVG…), которые разработчики используют для построения сайтов и веб-приложений. Помимо «корневых» технологий платформа включает ещё и локальные браузерные API, которые добавляют в браузер новую функциональность: DOM, Console, Fetch и другие.

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

Как всё работает в браузере, описано в специальных документах — спецификациях. Это подробные инструкции для разработчиков, как должна работать какая-то определённая фича. Например, как должны строиться сетки на флексах или как должен работать console.log .

Спецификации Скопировать ссылку

Спецификаций в веб-платформе много. Спеки создаются в специальных организациях: W3C, WHATWG, Ecma International, OpenJS Foundation и другие — в них и создаются HTML, CSS, SVG, JS, Node.js. Дальше мы подробнее поговорим о том, как работают W3C и WHATWG.

W3C Скопировать ссылку

World Wide Web Consortium — международная организация, в штате которой примерно 60 человек из мировых университетов (MIT, ERCIM, Keio University, Beihang University). Также в W3C есть членство для внешних компаний.

На апрель 2021 в W3C состоит 438 компаний-членов: производители браузеров (Mozilla, Google, Apple, Samsung), софтверные компании (Adobe, Zoom), технологические гиганты (Amazon, Facebook, Visa, Alibaba), сервисы (Airbnb, Netflix, Shopify), железо (Huawei, Intel) и другие.

Чтобы иметь членство W3C, компании нужно платить членские взносы (для бедных стран — меньше, для богатых — больше). Например, если небольшая российская компания захочет вступить в «клуб» W3C, то это в 2021 году будет стоить минимум 1950 € в год (для больших компаний в 10 раз больше).

Компании отправляют своих сотрудников для работы в W3C. Вместе со штатными сотрудниками W3C приглашённые делегаты формируют рабочие группы (WG, Working Group).

Работа в FAANG (аббревиатура из названий крупнейших компаний Facebook, Amazon, Apple, Netflix, Google — прим. редактора) — не единственный способ попасть в рабочую группу W3C. Группа может включать и приглашённых экспертов (Invited Expert), которые никак не аффилированы с бизнесом, но являются крутанами в своей области. Все рабочие группы собираются на ежегодной сходке TPAC (Technical Plenary), которая проходит осенью.

Рабочая группа CSS в W3C Скопировать ссылку

Как устроена рабочая группа, на примере CSS Working Group.

В ней есть председатели, штатные сотрудники W3C, делегаты из внешних компаний (FAANG и другие) и приглашённые эксперты, например: Рэйчел Эндрю, Элика Этемад, Лия Веру, Джонатан Нил. Внешние эксперты приглашаются по предложению участников рабочей группы.

Среди всех участников выделяется три роли:

1. Редакторы спецификаций — отвечают за модули спецификаций, следят за ишью, получают фидбек, пишут спеку и тащат прогресс по своим модулям спек (иногда у спеки только один редактор, иногда — несколько);
2. Остальные члены рабочей группы (не редакторы) — участвуют в дискуссии, брейнштормят, принимают коллективные решения;
3. Сообщество сочувствующих www-style — это как непосредственно участники группы, так и в целом все заинтересованные в CSS люди: они комментируют и критикуют предложения, запрашивают фичи и объясняют юзкейсы, поднимают вопросы, участвуют в обсуждениях и дают фидбек редакторам спек.

Контент CSS-спецификаций живёт в репозитории github.com/w3c/csswg-drafts. Там же заводятся ишью и проводятся публичные дикуссии по контенту. Вот, например, увлекательное обсуждение CSS-нестинга.

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

Спецификации в W3C Скопировать ссылку

Все спецификации W3C опубликованы в одном месте по адресу w3.org/TR.

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

1. Working Draft (WD) — зафиксированная версия черновика спеки для ревью сообществом.
2. Candidate Recommendation (CR) — сигнал для финального ревью сообществом, сбор опыта реализации спеки в браузерах.
3. W3C Recommendation (REC) — все довольны, спека доделана, опубликована финальная версия.

Текущая версия черновика называется Editor’s Draft (ED) и может быть достаточно сырой, но она самая живая из всех — над ней работает редактор спеки.

Спецификации по CSS Скопировать ссылку

Если отфильтровать все спеки по тегу CSS, то получится больше сотни. Большая часть из них — черновики WD, меньшая — рекомендации REC и CR.

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

К примеру, в CSS 2.1 был раздел Color. Поэтому в рамках CSS 3 появился отдельный модуль — CSS Color Level 3. Дальше он будет двигаться к Level 4, потом к 5 и так далее.

Если в спеке CSS 2.1 изначально какой-то фичи не было, например, кастомных свойств или флексов, то новые спецификации начинают нумероваться с первого уровня: например, CSS Custom Properties for Cascading Variables Module Level 1 или CSS Flexible Box Module Level 1.

Чтобы не потеряться в обилии спек, рабочая группа CSS время от времени публикует «срез» состояния CSS — Snapshot. Последний из опубликованных — CSS Snapshot 2020. Это список всех спек, про которые в 2020 году можно сказать, что это и есть весь современный стабильный CSS.

Процесс работы над спеками CSS Скопировать ссылку

Как показала практика, работа над CSS-спеками не всегда укладывается в формальную линейную однонаправленную схему WD → CR → REC. Иногда развитие спеки в ответ на полученный фидбек двигается назад, а не вперёд. Поэтому есть более неформальное и близкое к жизни описание стадий работы над спеками, которое показывает стабильность спецификации:

1. Exploring (ранний WD): нестабильная версия, где всё ещё устаканивается и меняется. Нужен для совместной работы редактора спеки и рабочей группы.
2. Revising (средний WD): модуль в основном готов, но спека ещё нуждается в нескольких циклах публикации и ревью. В конце этой стадии рабочая группа фиксирует контент спеки перед переходом на формальный CR.
3. Refining (поздний WD): спека уже в основном стабильна и готова для перехода на CR, но ещё нуждается в шлифовке и полировке.
4. Testing (ранний CR): на этом этапе рабочая группа уверена, что спека достаточно полна и точна, чтобы её начинать имплементировать и писать тесты, так как для дальнейшего развития спеки нужен уже опыт имплементации в браузерах и тест-кейсы.
5. Stable (поздний CR): на этой стадии у рабочей группы есть достаточно полученного опыта тестирования и имплементации спеки, сама спека стабильна и надёжна, минорные ишью появляются нечасто. Такая версия спеки может быть включена в Snapshot.
6. Completed (PR, REC): тесты и отчёты об имплементации готовы, изменений больше не предвидится (кроме листинга опечаток).

Все CSS-спеки, сгруппированные по таким стадиям, опубликованы на странице CSS current work.

WHATWG Скопировать ссылку

Но не W3C единым жива веб-платформа. В 2004 году от W3C из-за разногласий по поводу будущего HTML откололась группа разработчиков стандартов. Эта группа назвалась WHATWG — Web Hypertext Application Technology Working Group. В W3C собирались остановить работу над HTML в угоду XHTML 2 — новой версии XHTML, обратно не совместимой с HTML 4 и XHTML 1. В WHATWG считали, что нужно продолжать развивать HTML и стандарты для создания веб-приложений. Они форкнули HTML и развили его до того самого HTML 5, тем самым выиграв у W3C.

До 2019 существовало две разные параллельные спецификации HTML, но потом W3C и WHATWG помирились и договорились работать вместе над «вечнозелёной» спекой HTML.

Помимо HTML в WHATWG работают над такими фичами: Compatibility, Console Object, DOM, Encoding, Fetch, Fullscreen, URL и XHR. Все спецификации опубликованы на сайте spec.whatwg.org.

Спеки WHATWG живут в репозитории github.com/whatwg.

Процесс работы WHATWG Скопировать ссылку

В отличие от W3C, WHATWG — открытое и бесплатное сообщество. Любой желающий может участвовать в развитии спек. Работа ведётся на Гитхабе.

Все стандарты WHATWG — «вечнозелёные», то есть не имеют версий, а всегда «доделаны». В WHATWG сравнивают разработку спек с разработкой ПО — софт тоже постоянно разрабатывается и меняется.

У каждого стандарта в идеале есть:

• редактор или несколько;
• активное сообщество контрибьюторов;
• лог изменений;
• ишью-трекер;
• тесты.

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

Всего в организации на Гитхабе в июне 2021 состоит 81 человек.

Тесты веб-платформы Скопировать ссылку

Когда рассказывают о веб-спецификациях, мало говорят про тесты. Вот есть текст спеки, вот её внедрили в браузере, это ок. А как узнать, что ничего старого при этом не поломалось? Как оценить, что внедрение корректное и спеку поняли правильно?

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

Реалии таковы, что браузеры не проходят все тесты на 100% и вряд ли будут когда-то их проходить. Новые фичи появляются в браузерах, а за ними приходят баги, спеки и внедрения допиливаются — всё это нормально. К примеру, в июне 2021 из 41761 тестов в Chrome не проходят 510 тестов, в Firefox — 1377, а в Safari — 3859.

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

Тесты, помимо пользы для разработчиков браузеров, дают и обычным разработчикам возможность оценивать фичи перед использованием. Обычно разработчики смотрят на статистику внедрения фич на сайте Can I Use. Так можно получить ответ на вопрос: есть ли фича в определённом браузере. Но кроме формального внедрения фичи стоит учитывать:

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

Как контрибьютить в веб-платформу Скопировать ссылку

Самый простой вариант, как въехать в тему — подтянуть английский и заняться багами:

Что такое платформа сайта и и почему вы должны это знать.

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

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

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

Что такое платформа для веб-сайтов?

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

• Платформа веб-хостинга
• Языки программирования
• Инструменты для создания веб-сайтов

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

Платформа веб-хостинга

Хостинги предлагают различные типы платформ. Как правило, это два типа операционных семейств: Linux и Windows.

Linux

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

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

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

Windows

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

Эти типы сайтов разрабатываются с использованием программного обеспечения, такого как Microsoft ASP.net и базы данных MSSSQL, которые относятся к Windows.

Отмечу, что в Windows есть панель инструментов под названием Plesk, которая имеет аналогичные функции с cPanel.

Языки программирования.

В операционных системах Linux и Windows используются разные языки программирования. Если с помощью HTML и CSS создаются простые, статичные сайты, то с помощью языков программирования, эти сайты становятся интерактивными. Пользователь может взаимодействовать с различными формами, в том числе, что-то искать на сайте, регистрироваться, фильтровать информацию и многое другое.

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

• PHP
• ASP.net
• C ++
• Python
• JavaScript
• Java

PHP — это аббревиатура от препроцессора гипертекста (hypertext preprocessor) и он специально был разработан для веб-проектов.

PHP может генерировать HTML для веб-страниц, обрабатывать формы и многое другое. Самым распространенным примером использования PHP, является система управления контентом, известная как WordPress, которая является самой распространенной CMS в мире.

ASP.net

ASP.net — это платформа для веб-приложений на стороне сервера (есть ещё платформы на стороне клиента), разработанная Microsoft и которая используется для создания веб-сайтов.

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

Python

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

JavaScript

JavaScript, используется наряду с HTML и CSS. Это язык, используемый в веб-браузерах.

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

Не путать с JavaScript, — это язык программирования, используемый во многих программах и приложениях. Это немного похож на программирование на C и C ++, но имеет ресурсы более низкого уровня.

Да, всё это может может сбить с толку. Каждый из языков имеет своё назначение. Но если говорить про более принципиальные вещи, то ASP.net может работать только под операционной системой Windows. Тогда как другие языки программирования, работают и под Windows, и под Linux.

Для большинства владельцев веб-сайтов, при разработке своего сайта, вам понадобится возможность использовать HTML, PHP и MySQL.

Инструменты для создания веб-сайтов

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

Примеры инструментов для создания веб-сайтов:

• Системы разработки
• Системы управления контентом (CMS)
• Конструкторы шаблонов сайтов

Системы разработки.

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

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

Системы управления контентом.

Система управления контентом (Content Management System), также известная как CMS, представляет собой специально разработанное программное обеспечение, которое позволяет владельцу веб-сайта, создавать большинство типов веб-сайтов, таких как блоги, сайты электронной коммерции, бизнес сайты и другие.

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

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

Из этих трех CMS, WordPress считается наиболее удобным и лёгким в освоении. Возможно, именно поэтому его используют всё больше людей по всему миру. На октябрь 2020 года, на WordPress работает примерно 35% от всех сайтов в интернете. Так же почитайте статью про CMS онлайн магазинов.

Конструкторы сайтов.

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

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

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

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

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

Почему так важен выбор правильных платформ для веб-сайтов?

Теперь, вы знаете, что такое платформы веб-сайтов, но почему это важно знать?

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

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

Сменить конструктор сайта на систему управления контентом, также невероятно сложно и трудоёмко.

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

Так, для простейшего сайта с небольшими интерактивными элементами на PHP, вам будет достаточно любого дешевого хостинга с поддержкой PHP и MySQL. Если же вы собираетесь создавать сайт на CMS WordPress, то требования будут чуть выше, вам понадобиться больше оперативной памяти, больше постоянной памяти, больше ресурсов процессора. Ну а если собираетесь создать крупный корпоративный сайт, то здесь вам уже потребуется Windows, и возможно, ASP.net, C ++, Python, или Java.

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

Что теперь?

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

1. Определите, какой тип веб-сайта вы хотите запустить.
2. Определитесь со своим бюджетом.
3. Изучите различные веб-хостинговые компании.
4. Если у вас возникнут какие-либо вопросы, обращайтесь напрямую в службу поддержки веб-хостинга, заодно, как раз протестируете поддержку хостинга, что тоже имеет значение.

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

Что такое веб-платформа?

Существенное преимущество построения Web приложений для поддержки стандартных функций браузера заключается в том, что функции должны выполняться независимо от операционной системы данного клиента. Вместо того чтобы писать различные версии для Microsoft Windows, Mac OS X, GNU/Linux и других операционных систем, приложение создается один раз для произвольно выбранной платформы и на ней разворачивается. Однако различная реализация HTML, CSS, DOM и других спецификаций в браузерах может вызвать проблемы при разработке веб-приложений и последующей поддержке. Кроме того, возможность пользователя настраивать многие параметры браузера (например, размер шрифта, цвета, отключение поддержки сценариев) может препятствовать корректной работе приложения.

Другой (менее универсальный) подход заключается в использовании Adobe Flash или Java-апплетов для полной или частичной реализации пользовательского интерфейса. Поскольку большинство браузеров поддерживает эти технологии (как правило, с помощью плагинов) , Flash- или Java-приложения могут выполняться с легкостью. Так как они предоставляют программисту больший контроль над интерфейсом, они способны обходить многие несовместимости в конфигурациях браузеров, хотя несовместимость между Java или Flash реализациями на стороне клиента может приводить к различным осложнениям. В связи с архитектурным сходством с традиционными клиент-серверными приложениями, в некотором роде «толстыми» клиентами, существуют споры относительно корректности отнесения подобных систем к веб-приложениям; альтернативный термин «Богатое Интернет приложение» (англ. Rich Internet Applications).

Современная Web-платформа: как расслабиться и получать удовольствие? Практическое руководство, часть 1

Помните эту статью? Раньше мы могли быстро собрать статичную HTML-страничку в каком-нибудь FrontPage и сайт был готов. С этим мог справится любой студент. В более сложном случае, мы писали пару строк на PHP и получали уже целый портал, собранный из разных элементов шаблона на сервере. Затем мы захотели, чтобы наш сайт как-то выделялся на общем фоне и умел чуть-чуть больше. Трон занял его-величество jQuery. Теперь же, мы оказались погребены под завалами фреймворков и библиотек, инструментов сборки, менеджеров зависимостей, препроцессоров и постпроцессоров, особых форматов, языков и стилей программирования, чтобы иметь возможность стряпать простые лэндинги. Все стало слишком сложно. Спикеры на конференциях стали соревноваться в изощренности того, каким еще образом можно сломать нам мозг. Как мы докатились до жизни такой? Чем «раньше» так сильно отличается от «сейчас»? Что нас ждет «потом»? Есть ли в современной веб-разработке некий дзен-стайл, блюдя который, можно, как в старые добрые времена, собрать себе уютный сайтик «на коленке» за пару вечеров, без ковыряния в документации десятка хипстерских технологий-однодневок? Насколько доступны нам простые решения в серьезной промышленной разработке? Куда движется веб-платформа? Предлагаю разобраться.

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

Предпосылки и решение

Когда я делал свои первые сайты (в конце 90-х — начале 2000-х), первое, что мне показалось странным и ужасно неудобным в обычном HTML — невозможность описать «заголовок», «подвал» и «главное меню» сайта в одном месте для всех страниц сразу. Я мог вставить одну картинку или один скрипт во многих местах, но не банальный кусок разметки. Также, я не мог описать общий макет страницы, без необходимости повторять его в каждом отдельном HTML-файле. Я думаю, многих эти-же причины подтолкнули к первым экспериментам с серверными технологиями. Но для всего серверного нужен соответствующий сервер, а это новый уровень усложнения задачи, казавшейся сперва такой простой. Так или иначе, эта проблема решалась множество раз и множеством способов. Мы пытались использовать iframe, пытались динамически управлять видимостью фрагментов, содержащихся на одной странице; как только не издевались над собой и здравым смыслом. В итоге, мы пришли к современному набору мета-платформ типа React или Vue.js, которые, среди прочего, позволяют нам создать структуру модулей, отражающую структуру того, что мы видим на экране. Но и сама веб-платформа не стоит на месте и, о чудо, теперь у нас есть нативная возможность создавать больше чем просто многократно используемые куски разметки: теперь мы можем создавать свои собственные настоящие HTML-теги! Причем, каждый такой тег может быть как примитивным контейнером, содержащим только необходимое оформление (или быть интерактивным UI-элементом), так и макетом всей страницы. Он даже может содержать в себе целое сложное приложение с кучей, необходимой вам, клиент-серверной логики. Да, я говорю о новом стандарте Custom Elements (Living Standard). И он действительно многое меняет.

Пробуем на вкус

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

Файл index.html:

Обратите внимание на именование кастомных тегов: по стандарту оно обязательно должно содержать дефис (один или более). Также, вы, наверное, заметили атрибут «slot» — о нем немного позже.

Теперь перейдем к файлу, описывающему основной макет страницы elements/my-layout.js:

Прошу прощения за избыток стилей в данном примере: они нужны только для наглядности при отображении результата в браузере.

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

Создадим остальные элементы. Файл elements/my-menu.js:

Файл elements/my-header.js:

И последний файл нашего нано-проекта elements/my-footer.js:

Та-дам! Можно открывать наш index.html в браузере. Внимательный читатель заметил, что стили для тега «span» были напрямую определены сразу в двух местах (для разных элементов), однако они не повлияли друг-на-друга и отобразились правильно.

Что мы увидели?

Мы увидели пример настоящей модульной разработки без подключения каких-либо внешних библиотек, без настройки окружения, без ожидания сборки проекта, даже без необходимости запускать локальный сервер. В инструментах разработчика браузера мы видим непосредственно свой JS-код и свою собственную разметку, а не результат работы скриптов, создающих за нас DOM. Контент нашего главного HTML-файла находится в нем-же и сразу доступен, опять-же, без какого-либо предварительного рендера. Мы можем повторно использовать наши кастомные теги в этом-же проекте или в любых других. Мы не загрузили ничего лишнего и отобразили страницу практически мгновенно. Объем дополнительного JS-кода, который нам понадобился для этого — микроскопический. При этом, каждый наш новый элемент — это такой-же полноправный DOM-элемент как и любой стандартный div. Для него доступны те-же самые стандартные атрибуты, свойства, события и методы типа addEventListener, appendChild, remove и т. д. Это то, чего мы так долго хотели? По моему, да.

Дальше — больше

В дальнейшем мы рассмотрим следующие темы (не обязательно в указанном порядке):