Платформа 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. Так можно получить ответ на вопрос: есть ли фича в определённом браузере. Но кроме формального внедрения фичи стоит учитывать:

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

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

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

• сообщать о багах разработчикам браузеров: Mozilla, WebKit, Chromium;
• решать баги в тестах или писать новые тесты: ишью в репозитории WPT;
• решать баги в спеках: ишью WHATWG, ишью CSSWG.

Веб-Платформа

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

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

Веб-Платформа используется в

• интернет-магазинах
• корпоративных сайтах
• интернет-порталах
• социальных сетях

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

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

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

Системные модули — представляют информацию, доступную всем пользователям

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

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

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

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

Специальные модули — обслуживают специализированные задачи, обычно используются в узконаправленных сайтах. Пример специального модуля — Project Tracking System (PTS), который может предложить эффективное управление задачами и проектами.

Каждая группа модулей включает в себя ряд модулей, направленных на эффективное представление данных веб-сайта. Наша компания создала ряд продуктов с помощью Веб-Платформы, такие как Finance, Project Tracking System, Inventory, Social, eCommerce. Ниже вы можете увидеть подробную структуру Веб-Платформы. Возможности и варианты системы могут меняться в зависимости от особенностей и целей проекта.

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

Современная 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:

        Hi, I am your header. 
Hello World! This is content.
 And I am your footer.    

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

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

class MyLayout extends HTMLElement < constructor() < // Сперва вызываем конструктор суперкласса HTMLElement: super(); // Cоздаем ShadowDOM элемента - его локальную, // закрытую от внешнего мира область разметки, но доступную для JS: this.attachShadow(< mode: 'open', >); // присваеваем нашему элементу свой шаблон: this.shadowRoot.innerHTML = ` :host < display: block; >.header < position: fixed; top: 0; left: 0; right: 0; height: 40px; line-height: 40px; padding-left: 20px; padding-right: 20px; background-color: #000; color: #fff; >.menu < position: fixed; top: 0; bottom: 0; right: 0; width: 240px; padding: 20px; background-color: #eee; box-shadow: 0 0 8px rgba(0, 0, 0, 0.4); z-index: 1000; >.content < padding-top: 60px; padding-bottom: 60px; >.footer `; > > // Регистируем созданный элемент: window.customElements.define('my-layout', MyLayout); // Теперь браузер знает о существовании нового тега . 

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

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

Хозяйке на заметку

VS Code — пока не умеет автоматически подсвечивать HTML-синтаксис внутри ES6-строк. Для работы с большими участками разметки внутри JS-файлов, вы можете временно переключать синтаксис открытого файла в режим HTML (нижний правый угол окна): вам станет доступна подсветка, подсказки и автодополнение в HTML и CSS.

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

class MyMenu extends HTMLElement < constructor() < super(); this.attachShadow(< mode: 'open', >); this.shadowRoot.innerHTML = ` :host < display: block; >a < display: flex; align-items: center; justify-content: center; background-color: #fff; cursor: pointer; height: 40px; text-decoration: none; color: currentColor; font-size: 1.2em; margin-bottom: 4px; border: 1px solid #fff; >a:hover Page 1 Page 2 Page 3 `; > > window.customElements.define('my-menu', MyMenu); 

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

class MyHeader extends HTMLElement < constructor() < super(); this.attachShadow(< mode: 'open', >); this.shadowRoot.innerHTML = ` :host < display: block; >span Text inside ShadowDOM. `; > > window.customElements.define('my-header', MyHeader); 

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

class MyFooter extends HTMLElement < constructor() < super(); this.attachShadow(< mode: 'open', >); this.shadowRoot.innerHTML = ` :host < display: block; >::slotted(*) < display: inline-block; >span © 2018, Vasya Pupkin `; > > window.customElements.define('my-footer', MyFooter); 

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

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

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

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

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

• Жизненный цикл Custom Element в DOM
• Тег template
• Оптимизация производительности, динамическое обновление
• Custom Elements и ООП
• HTML-атрибуты, работа с общими данными
• ShadowDOM и CSS: инкапсуляция, селекторы, нативные CSS-переменные, нативные CSS-выражения
• SVG и Custom Elements — практические советы
• Организация и структура кода: модули, точки подключения, динамическая загрузка, http/2 Server Push
• Новый подход к прототипированию, созданию, тестированию и внедрению дизайна
• Нестандартные стандарты: браузеры, полифиллы, ShadyDOM, HTML-imports
• Существующая экосистема: библиотеки и готовые компоненты, реальные проекты
• Custom Elements и серверный рендеринг
• Custom Elements и SEO
• PWA

Интернет-платформа

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

Освойте профессию «Веб-разработчик»

Веб-разработчик с нуля

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

Профессия / 12 месяцев
Веб-разработчик с нуля

Создавайте нужные любому бизнесу сервисы

Что такое платформа сайта?

Написание кода сайта (даже простого одностраничника или лендинга) с нуля сегодня практически не используется. На то есть несколько причин.

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

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

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

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

Станьте веб-разработчиком и найдите стабильную работу на удаленке

Какие существуют платформы?

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

Фреймворки. Такие интернет-платформы представляют собой каркас, на который «навешиваются» дополнительные функциональные блоки, интерфейс сайта и т.д. Именно фреймворк можно сравнить с «фундаментом» веб-ресурса, потому что его «стены», «крышу», «фасад» и другие элементы придется «достраивать» (то есть программировать) самостоятельно.

Тем не менее, это гораздо легче, чем писать весь код с нуля, поэтому даже на таких низкоуровневых системах создаются блоги, интернет-магазины, информационные порталы и другие веб-ресурсы. Более того, именно фреймворки лучше всего подходят для реализации крупных проектов или специализированных сервисов. Типичные представители веб-фрейворков — Django на языке Python, Express.js на Java Scipt, ASP.Net (использует специализированные языки Microsoft) и т.д.

Системы управления контентом (content management system — CMS). Это электронные платформы более высокого уровня, которые предоставляют разработчику весь комплект инструментов для создания и последующей поддержки сайта. В CMS уже есть все основные функциональные модули, необходимые для веб-ресурса того или иного типа. Разработчику остается лишь добавить или, наоборот, убрать их в режиме администратора через удобный визуальный редактор. То есть непосредственно написание кода сводится к минимуму — в основном для добавления нетиповых функций, дополнительных онлайн-форм и т.д. Впрочем, даже их можно добавить с помощью внешних подключаемых плагинов. Наиболее популярные CMS для разработки сайтов — 1С-Bitrix, NetCat, WordPress.

Читайте также Топ конструкторов сайтов 2023 года

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

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

SaaS-платформы (Software as a Service — ПО как услуга). Владельцы облачных онлайн-платформ предоставляют клиентам на условиях аренды доступ к сервисам, с помощью которых они создают собственный сайт. Преимущественно облачные сервисы используются для разработки простых интернет-ресурсов — блогов, информационных порталов, небольших интернет-магазинов. Основное преимущество платформ в том, что клиент получает весь комплекс услуг, необходимых для создания и технической поддержки сайта — хостинг, CMS, набор функций, дизайн-шаблоны и т.д. То есть можно сразу приступать к работе, для этого не нужно быть программистом. Достаточно просто собрать свой веб-ресурс в визуальном редакторе из готовых модулей, загрузить текст, картинки, видео. Наиболее распространенные конструкторы сайтов — Tilda, WIX, uCoz.

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

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

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

• Тип сайта. Несмотря на то, что разработчики многих платформ стремятся сделать их максимально универсальными, на 100% это невозможно. Одни веб-системы больше заточены под интернет-магазины, другие — под информационные порталы, третьи — под блоги и т.д. Поэтому нужно сразу определиться с типом будущего сайта, продумать его функциональность и только потом подбирать подходящую платформу.
• Эксклюзивность сайта. Платформы, предлагающие готовые решения (CMS и конструкторы сайтов), не всегда позволяют учесть специфику будущего веб-ресурса. Если на нем планируется реализовать какие-то необычные пользовательские механики, эксклюзивный дизайн, уникальные функции, лучше подобрать подходящий веб-фреймворк. Если же планируется открыть простой интернет-магазин или блог, достаточно возможностей CMS и конструктора сайта.
• Бюджет. Создание и техническая поддержка сайта требуют денег и времени. И здесь веб-фреймворки, безусловно, проигрывают, потому что веб-ресурс на их основе будет стоить дорого. Наиболее финансово выгодны конструкторы сайтов — вам не придется нанимать специалиста, веб-ресурс можно «собрать» самому. Где-то между ними и фреймворками по затратам находятся CMS. Они тоже предлагают готовые решения, но для работы с ними все же потребуются услуги штатного сотрудника или аутсорсингового разработчика.

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