Что такое платформа web
Как организована веб-платформа
Вы наверняка слышали про веб-платформу, спецификации, W3C, CSSWG и другие организации, которые создают технологии, которыми мы пользуемся каждый день для создания веб-интерфейсов. Но от этого всегда веяло какой-то тайной, всё казалось переусложнённым и не вызывало доверия. Давайте разберёмся, как устроено создание спецификаций и как можно принять участие в развитии веб-платформы.
Веб-платформа Скопировать ссылку
«Веб-платформа» — это набор стандартизированных API (HTML, CSS, JavaScript, SVG…), которые разработчики используют для построения сайтов и веб-приложений. Помимо «корневых» технологий платформа включает ещё и локальные браузерные API, которые добавляют в браузер новую функциональность: DOM, Console, Fetch и другие.
Стандарты Скопировать ссылку
Спецификации Скопировать ссылку
Спецификаций в веб-платформе много. Спеки создаются в специальных организациях: 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 и другие) и приглашённые эксперты, например: Рэйчел Эндрю, Элика Этемад, Лия Веру, Джонатан Нил. Внешние эксперты приглашаются по предложению участников рабочей группы.
Среди всех участников выделяется три роли:
Контент CSS-спецификаций живёт в репозитории github.com/w3c/csswg-drafts. Там же заводятся ишью и проводятся публичные дикуссии по контенту. Вот, например, увлекательное обсуждение CSS-нестинга.
Также у рабочей группы есть еженедельные собрания, на которых обсуждаются и решаются ишью, ведётся лог обсуждения. Ссылки на лог публикуются в блоге и в Твиттере. Вот, к примеру, о чём договорились на прошлой неделе.
Спецификации в W3C Скопировать ссылку
Все спецификации W3C опубликованы в одном месте по адресу w3.org/TR.
Спеки проходят такие формальные стадии развития (некоторые промежуточные технические стадии упростил):
Текущая версия черновика называется 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. Иногда развитие спеки в ответ на полученный фидбек двигается назад, а не вперёд. Поэтому есть более неформальное и близкое к жизни описание стадий работы над спеками, которое показывает стабильность спецификации:
Все 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. Так можно получить ответ на вопрос: есть ли фича в определённом браузере. Но кроме формального внедрения фичи стоит учитывать:
Как контрибьютить в веб-платформу Скопировать ссылку
Самый простой вариант, как въехать в тему — подтянуть английский и заняться багами:
Web Platform Installer: обзор третьей версии
Совсем недавно выпущена третья финальная версия Web Platform Installer (WebPI) – инструмента, который позволяет быстрее всего развернуть рабочее место веб-разработчика и проще всего установить необходимые веб-приложения из большого набора готовых шаблонов.
В этой статье дается обзор третьей версии WebPI с перечислением изменений по сравнению со второй версией и описанием функционала, который будет полезен каждому веб-разработчику (и не только).
Что такое Web Platform Installer?
Повседневная работа веб-разработчика состоит из использования ряда инструментов для создания новых проектов или работы со структурой одного большого проекта. В качестве таких часто используемых инструментов можно перечислить следующие: среда разработки (IDE), сервер баз данных и инструменты по работе с базами данных, сервер приложений и сопутствующие инструменты, шаблоны готовых приложений (CMS, форумы, блоги, wiki-движки и так далее).
Со временем, разработчики накапливают большое количество этих инструментов, которые представлены дистрибутивами, архивами, просто полезными ссылками на загрузку и так далее. Совершенно естественно, что часть этого собранного инструментария устаревает (так как на сервере выпущено обновление) или теряет актуальность по другим причинам. Таким образом, разработчику постоянно приходится держать руку на пульсе и следить, чтобы его любимые инструменты были актуальными, последних версий.
Следить сразу за всем возможно, но утомительно. И тут очевидной идеей является реализация некоего удаленного единого хранилища подобных инструментов, которое некто будет поддерживать в актуальном состоянии, а мы только обращаться к нему по мере надобности за очередным, необходимым нам, инструментом.
Таким удаленном хранилищем и является Web Platform Installer. C помощью WebPI вы всегда имеете доступ к самым последним версиям инструментов веб-разработки, создания и редактирования баз данных, шаблонам веб-приложений самых последний версий. Кроме того, при всем богатстве выбора WebPI предлагает все инструменты бесплатно.
Установка Web Platform Installer
Для того чтобы быть самым быстрым Web Platform Installer должен обладать минимальным размером. И этого действительно так, размер WebPI 3 составляет всего 1.3 мегабайта (1.5 Мб в случае 64-битной версии). Выпущенная недавно финальная версия доступна для загрузки по следующей ссылке. Тут вы можете выбрать локализацию продукта (доступно 14 языков) и версию, которая соответствует вашей операционной системе: 32-битную или 64-битную.
Существует другой способ загрузки WebPI последней версии – это официальная страница продукта, доступная по адресу http://www.microsoft.com/web/downloads/platform.aspx (вторая картинка). На этой странице можно получить чуть больше информации о продукте и загрузить актуальную версию для вашей версии операционной системы.
Установка WebPI 3 происходит за считанные секунды:
После установки все готово для развертывания вашего рабочего места, доступа к последним версиям инструментов, средств разработки и шаблонов веб-приложений.
Работа с Web Platform Installer 3
Web Platform Installer третьей версии встречает обновленным интерфейсом:
В зависимости от локализации вашей операционной системы будет выбрана локализация продукта. В данном случае – это английская версия.
Новый интерфейс в чем-то похож на Metro UI – инициативе Microsoft по построению современных пользовательских интерфейсов. Можно смело сказать, что по сравнению со второй версией, интерфейс WebPI 3 стал еще удобнее.
WebPI 3 содержит три основных раздела: Spotlight (предложения), Products (продукты) и Applications (приложения). Первая вкладка Spotlight предлагает ознакомиться с последними релизами, обновлениями или самыми заметными выпусками приложений. Например, на скриншоте выше – это последние версии ASP.NET MCV 3, Drupal CMS, инструмента по созданию веб-ферм, движка Orchard и другие.
Здесь же доступны некоторые важные действия, которые стоит рассмотреть отдельно:
Поиск
С помощью поля ввода строки поиска можно быстро найти необходимый компонент для установки. Например ниже я выполнил поиск по ключевому слову “forum” (первая картинка) и второй поиск по фразе “sql compact” (вторая картинка):
Как можно убедиться, поиск предлагает самую быструю возможность найти необходимый функционал для установки. Работает поиск мгновенно.
Опции
Настройки Web Platform Installer 3 доступны через ссылку Options (Опции). Эта ссылка ведет на окно настроек, в котором можно указать несколько важных параметров:
В первую очередь, здесь можно добавить пользовательскую ссылку на пакет установки стороннего компонента. Эта возможность – большой плюс WebPI, который позволяет расширять и без того большую базу устанавливаемых инструментов сторонними пакетами. Например, мы можем добавить ссылку на последнюю “ночную” сборку Orchard CMS, просто добавив ее в окне настроек:
после добавления (Add Feed) и закрытия окна настроек мы получим дополнительную вкладку с доступом к нашему пользовательскому набору пакетов:
Таким образом мы получим возможность устанавливать самую последнюю сборку Orchard CMS прямо из WebPI. Формат такой конфигурации пользовательских пакетов открыт, что дает возможность сторонним компаниям использовать его для собственных нужд для быстрого развертывания собственных пакетов внутри компании.
Другая настройка доступная в окне опций позволяет выбрать предпочитаемый сервер приложений, устанавливаемый при конфигурировании приложений и инструментов. Вы можете задать использование полноценного сервера IIS, либо выбрать облегченный, но полнофункциональный сервер IIS Express. По умолчанию предлагается именно IIS Express, как новое средство разработки и отладки веб-приложений.
Другая важная настройка, доступная в окне опций – это выбор предпочитаемого языка локализации при установке инструментов и веб-приложений. Установите “русский” для автоматической загрузки русских версий пакетов, инструментов и приложений.
И последняя возможность окна настроек – это управление кэшем WebPI. Web Platform Installer 3 автоматически кэширует загруженные пакеты для более быстрого доступа к ним в будущем. Вы можете отслеживать размер этого кэша и в случае надобности очищать его, удаляя пакеты.
Выбор и установка продуктов и приложений в Web Platform Installer
Что бы продолжить обзор, я выбрал раздел Applications (Приложения), в котором выбрал подраздел Blogs (Блоги), среди всех представленных шаблонов приложений для создания блогов, я выбрал движок BlogEngine.NET:
Перечисление всего, что мы выбрали для установки можно увидеть если перейти по ссылке “Items to be installed” (пакеты готовые к установке).
Web Platform Installer – это умный механизм, который автоматически обнаружит зависимости устанавливаемого пакета и добавит в список установки те инструменты, без которых выбранный вами пакет не будет работать. В нашем случае были добавлены следующие пакеты (первый скриншот).
Выбор для установки WebMatrix и IIS Express связан с тем, что в настройках WebPI мы выбрали средой разработки IIS Express и WebMatrix, что определяет необходимость установить недостающие в данный момент инструменты, в том числе Web Deploy 2.0.
Если мы переключим в настройках предпочитаемую работу на сервер IIS, то получим следующий список зависимостей (второй скриншот). Здесь выбраны только пакеты конфигурации IIS сервера, который в моем случае еще не был сконфигурирован для работы с ASP.NET приложениями. WebPI 3 выполнит такую конфигурацию автоматически.
Представленные списки зависимостей выводятся исключительно для информации. Вам не нужно предпринимать никаких действий, все пакеты будут загружены и установлены автоматически без вашего участия.
Я выбрал первый вариант работы с WebMatrix и IIS Express как наиболее простой и удобный способ работы с веб-приложениями. Все что мне потребовалось – это нажать кнопку Install (Установить). WebPI 3 предлагает ознакомиться с устанавливаемыми пакетами и оценить размер загружаемых данных. Кроме того, тут же я могу прочитать лицензионные соглашения и для установки всех инструментов подтвердить, что я согласен с ними.
После инспекции списка устанавливаемых пакетов следует нажать I Accept (Я согласен) и просто дождаться когда WebPI загрузит и установит пакеты из удаленного хранилища. И здесь WebPI поступает разумно и устанавливает загруженные пакеты параллельно загрузке остальных.
Время необходимое на загрузку и установку пакетов зависит от многих параметров, в том числе скорости вашего интернет-соединения, числа пакетов, производительности вашего компьютера. В среднем этот процесс занимает несколько минут, если есть какие-то зависимости и меньше, если зависимостей нет и необходимо установить только один пакет.
В любом случае, вы можете заняться своими делами, поскольку вся загрузка, установка и первичная настройка проходят автоматически.
В конце установки вы получите сообщение о том, что все выбранные инструменты были установлены успешно:
Теперь, по приглашению WebPI вы можете перейти к работе с проектом BlogEngine.NET просто нажав на ссылку Launch (запустить). Это приведет к запуску WebMatrix с загруженным проектом BlogEngine.NET:
Теперь все что вам надо – это нажать Run для запуска вашего приложения-блога.
Как вы можете убедиться, среда разработки, сервер приложения IIS Express и выбранное мной приложение – все это было загружено и настроено автоматически так, что мне осталось лишь запустить приложение на выполнение.
Итоги
Web Platform Installer 3 – это простейший и наиболее быстрый способ развертывания рабочей среды веб-разработчика, загрузки необходимых компонент, инструментов и приложений.
Работа с WebPI 3 не требует никаких особенных знаний. Интерфейс WebPI 3 выполнен в удобном стиле Metro UI и предлагает простой и быстрый доступ к необходимой информации. Требуемые пакеты и инструменты легко найти с помощью поиска.
WebPI 3 просто конфигурируется и настраивается. Этот инструмент достаточно умен для того, чтобы разрешать зависимости и автоматически их загружать и настраивать. Во время загрузки нескольких пакетов WebPI ведет себя умно и выполняет установку загруженных пакетов параллельно остальной загрузке.
Установка и первичная настройка всех инструментов происходит автоматически и без участия пользователя. По завершению установки нам достаточно перейти к готовым инструментам и начать работать.
Третья версия Web Platform Installer предложила новый интерфейс, новые приложения в репозитории и возможность управлять средой разработки: с помощью полноценного сервера IIS или с помощью упрощенной версии IIS Express и WebMatrix.
В итоге, можно сказать, что Web Platform Installer 3 – это надежный, простой и обязательный инструмент для любого веб-разработчика, который делает жизнь значительно проще.
Современная Web-платформа: как расслабиться и получать удовольствие? Практическое руководство, часть 1
Всем привет!
Помните эту статью? Раньше мы могли быстро собрать статичную HTML-страничку в каком-нибудь FrontPage и сайт был готов. С этим мог справится любой студент. В более сложном случае, мы писали пару строк на PHP и получали уже целый портал, собранный из разных элементов шаблона на сервере. Затем мы захотели, чтобы наш сайт как-то выделялся на общем фоне и умел чуть-чуть больше. Трон занял его-величество jQuery. Теперь же, мы оказались погребены под завалами фреймворков и библиотек, инструментов сборки, менеджеров зависимостей, препроцессоров и постпроцессоров, особых форматов, языков и стилей программирования, чтобы иметь возможность стряпать простые лэндинги. Все стало слишком сложно. Спикеры на конференциях стали соревноваться в изощренности того, каким еще образом можно сломать нам мозг. Как мы докатились до жизни такой? Чем «раньше» так сильно отличается от «сейчас»? Что нас ждет «потом»? Есть ли в современной веб-разработке некий дзен-стайл, блюдя который, можно, как в старые добрые времена, собрать себе уютный сайтик «на коленке» за пару вечеров, без ковыряния в документации десятка хипстерских технологий-однодневок? Насколько доступны нам простые решения в серьезной промышленной разработке? Куда движется веб-платформа? Предлагаю разобраться.
Для того, чтобы поэкспериментировать с практической частью, вам понадобится любой удобный редактор кода (например Visual Studio Code) и актуальная версия браузера Chrome. Для начала этого будет вполне достаточно. Впоследствии (я планирую целый цикл публикаций на эту тему), все неминуемо усложнится, но мы будем стараться оставаться «в рамках» — это наша цель.
Предпосылки и решение
Когда я делал свои первые сайты (в конце 90-х — начале 2000-х), первое, что мне показалось странным и ужасно неудобным в обычном HTML — невозможность описать «заголовок», «подвал» и «главное меню» сайта в одном месте для всех страниц сразу. Я мог вставить одну картинку или один скрипт во многих местах, но не банальный кусок разметки. Также, я не мог описать общий макет страницы, без необходимости повторять его в каждом отдельном HTML-файле. Я думаю, многих эти-же причины подтолкнули к первым экспериментам с серверными технологиями. Но для всего серверного нужен соответствующий сервер, а это новый уровень усложнения задачи, казавшейся сперва такой простой. Так или иначе, эта проблема решалась множество раз и множеством способов. Мы пытались использовать iframe, пытались динамически управлять видимостью фрагментов, содержащихся на одной странице; как только не издевались над собой и здравым смыслом. В итоге, мы пришли к современному набору мета-платформ типа React или Vue.js, которые, среди прочего, позволяют нам создать структуру модулей, отражающую структуру того, что мы видим на экране. Но и сама веб-платформа не стоит на месте и, о чудо, теперь у нас есть нативная возможность создавать больше чем просто многократно используемые куски разметки: теперь мы можем создавать свои собственные настоящие HTML-теги! Причем, каждый такой тег может быть как примитивным контейнером, содержащим только необходимое оформление (или быть интерактивным UI-элементом), так и макетом всей страницы. Он даже может содержать в себе целое сложное приложение с кучей, необходимой вам, клиент-серверной логики. Да, я говорю о новом стандарте Custom Elements (Living Standard). И он действительно многое меняет.
Пробуем на вкус
Для первого знакомства давайте воспроизведем вышеописанный кейс с общим макетом, хедером, футером и навигационным меню, в самом примитивном виде:
Обратите внимание на именование кастомных тегов: по стандарту оно обязательно должно содержать дефис (один или более). Также, вы, наверное, заметили атрибут «slot» — о нем немного позже.
Теперь перейдем к файлу, описывающему основной макет страницы elements/my-layout.js:
Прошу прощения за избыток стилей в данном примере: они нужны только для наглядности при отображении результата в браузере.
В части шаблона, где находится сама разметка, мы снова встречаем слово «slot» — это специальный тег, который работает в сочетании с ShadowDOM — он определяет позиции в разметке для частей контента нашего элемента. Соответствие определяется тем самым атрибутом «slot», который я упомянул ранее. Если у тега «slot» нет атрибута «name» — в него попадет контент «по умолчанию», который, в свою очередь, не имеет атрибута «slot». Это очень простой, но очень мощный нативный инструмент шаблонизации на «клиент-сайде».
Создадим остальные элементы. Файл elements/my-menu.js:
И последний файл нашего нано-проекта elements/my-footer.js:
Та-дам! Можно открывать наш index.html в браузере. Внимательный читатель заметил, что стили для тега «span» были напрямую определены сразу в двух местах (для разных элементов), однако они не повлияли друг-на-друга и отобразились правильно.
Что мы увидели?
Мы увидели пример настоящей модульной разработки без подключения каких-либо внешних библиотек, без настройки окружения, без ожидания сборки проекта, даже без необходимости запускать локальный сервер. В инструментах разработчика браузера мы видим непосредственно свой JS-код и свою собственную разметку, а не результат работы скриптов, создающих за нас DOM. Контент нашего главного HTML-файла находится в нем-же и сразу доступен, опять-же, без какого-либо предварительного рендера. Мы можем повторно использовать наши кастомные теги в этом-же проекте или в любых других. Мы не загрузили ничего лишнего и отобразили страницу практически мгновенно. Объем дополнительного JS-кода, который нам понадобился для этого — микроскопический. При этом, каждый наш новый элемент — это такой-же полноправный DOM-элемент как и любой стандартный div. Для него доступны те-же самые стандартные атрибуты, свойства, события и методы типа addEventListener, appendChild, remove и т. д. Это то, чего мы так долго хотели? По моему, да.
Дальше — больше
В дальнейшем мы рассмотрим следующие темы (не обязательно в указанном порядке):