Платформа сайта: что это такое и как её узнать
Зачастую, для потенциального клиента сайт является отправной точкой знакомства с Вашим бизнесом. Как и СЕО-продвижение сайта в Интернете, продвижение Вашего ресурса очень важно. Достигнуть этого как раз возможно с помощью создания сайта, с впечатляющим веб-дизайном, удобным интерфейсом и информативным макетом. Для этого ряд компаний предлагают различные платформы, о которых мы и поговорим.
Что такое платформа сайта
Расскажем о том, что такое платформа сайта, ведь от её выбора зависит то, какой функционал сайта будет реализован и дальнейшее развитие ресурса в целом. Коротко говоря, платформа сайта – это те программные решения и скрипты, при выборе которых создается полноценный функционирующий ресурс. Как правило, для создания веб-сайта выбирается одна из следующих платформ: CMS, фреймворк и Saas.
Наиболее популярной платформой для создания ресурса является CMS. Плюсом здесь станет то, что функционал ресурса может расширяться по усмотрению его владельца за счёт модульной системы. Существуют как платные, так и бесплатные версии, среди которые наиболее популярными выступают: Joomla, WordPress, 1-С Bitrix и Umi. О том, какими преимуществами обладает Joomla, Вы можете прочитать здесь, так как их существует огромное количество.
Плюсов у CMS платформ явно больше, чем минусов. Поэтому, множество небольших и средний веб-сайтов делают выбор именно в их пользу. С экономической стороны такой выбор является наиболее целесообразным, так как технические требования не очень высоки и большинство встроенных модулей в таких платформах соответствуют предъявляемым требованиям.
А вот что не содержит в себе готовых программных модулей, так это платформы фреймворк. Мы уже упоминали об этом, когда рассказывали о том, что такое СMS сайта и отличии её от фреймворка. Использование фреймворк-платформ требует значительных затрат на программирование, так как вместе с созданием публичной части ресурса так же программируется базы данных, интерфейс для управления проектом и различные модульные алгоритмы.
Несмотря на преимущества CMS, в настоящее время популярность приобретает создание веб-сайтов на SaaS-платформах. Такие платформы строятся на работе с облачными технологиями. Лучше всего они подойдут для простых сайтов, временных проектов без каких-либо специфических модулей. Создание сайта на SaaS-платформе не требует знаний в области языков программирования и является достаточно дешевой услугой.
Как узнать платформу сайта
Точного ответа на вопрос, как узнать платформу сайта, так же как стоимость создания сайта-визитки под ключ нет. Но существует ряд сервисов, которые способны распознать платформу, на которой создан веб-сайт.
Есть такой сайт: itrack.ru, на котором Вы можете просто ввести адрес сайта, после чего будет показано, на какой именно платформе был создан сайт. Но, как и везде, существуют исключения. Существуют специально созданные платформы, которые отсутствуют в базе.
Как сделать сайт на платформе
Перед тем, как сделать сайт на платформе, стоит изучить основную информацию о различных сервисах, понять какую CMS выбрать, чтобы Ваш ресурс успешно развивался.
Во-первых, WordPress – это одна из самых популярных платформ для создания веб-сайтов в мире. Почти половина Интернет-сайтов работают именно на ней. WordPress так же является бесплатным конструктором, имеющим открытый исходный код. То есть Вы имеете максимальный контроль над своим сайтом.
Во-вторых, Joomla. Она является одной из самых популярных систем управления контентом, которая используется в течение длительного времени. Это предпочтительный инструмент для разработки веб-сайтов с несколькими функциональными возможностями и мощными веб-приложениями. Быстрая и простая в редактировании среда Joomla предлагает сильный веб-дизайн, который обеспечивает целостность данных.
В-третьих, Wix. Это еще одно популярное облачное программное обеспечение для создания веб-сайтов. Оно известно своей простотой в использовании и значительным набором функционала, что весьма облегчает создание веб-сайта. Здесь Вам, к тому же, не придется платить за хостинг. Для выбора дизайна предлагается доступ к множеству шаблонов, которые являются полностью редактируемыми.
В данной статье мы дополнительно рассказали о том, какие платформы существуют и привели ряд популярных среди них примеров. Какую именно платформу выбрать, решать только Вам, всё зависит от целей и срока создания ресурса.
Как организована веб-платформа
Вы наверняка слышали про веб-платформу, спецификации, 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. Так можно получить ответ на вопрос: есть ли фича в определённом браузере. Но кроме формального внедрения фичи стоит учитывать:
Как контрибьютить в веб-платформу Скопировать ссылку
Самый простой вариант, как въехать в тему — подтянуть английский и заняться багами:
Платформы для создания сайтов: CMS, фреймворки и SaaS-решения
От выбора платформы для разработки зависит как сама по себе реализуемость необходимого функционала, так и возможности дальнейшего развития веб-проекта.
Для создания сайта, как правило, выбирается одна из платформ: CMS, фреймворк или SaaS-решение. У каждого из типов платформ есть как плюсы, так и минусы.
Самый простой вариант — SaaS
SaaS-платформы еще часто называют «конструкторами сайтов». Из примеров — Тильда и Wix для простых сайтов, Shopify и inSales для электронной коммерции. Основное преимущество этого варианта — весьма хороший уровень качества за очень небольшие деньги. Обычно цены на SaaS-решения составляют порядка 6 000 рублей по тарифам начального уровня и редко превышают 60 000 рублей в год по «старшим» тарифам в линейке. По сути, заказная разработка в этом ценовом сегменте обеспечивает реализацию проектов, сильно уступающую по всем характеристикам.
Но SaaS решения недостаточно гибкие: они допускают только минимальную настройку бизнес-логики и имеют ограниченный функционал по визуальному оформлению. Если требования к оформлению или к функциональности проекта достаточно высокие, то «конструктор сайтов» по характеристикам уже может не подойти, так как реализация некоторых вещей на этих платформах просто невозможна.
Наиболее распространённый вариант — это разработка на CMS
Система управления сайтом (Content Management System) — это программный продукт, который служит для разработки некоторых стандартных разновидностей сайтов. Почти все CMS модульные, а модули многих из них собраны в комплекты (или редакции), предназначенные для тех или иных видов сайтов. Есть коробочные CMS для простых сайтов, для каталогов, для интернет-магазинов, для блогов, для новостных порталов и для других видов сайтов.
Много небольших и средних сайтов строится именно на CMS-платформах, так как это наиболее целесообразный с экономической точки зрения подход: требования к таким сайтам с технической точки зрения невысокие, а встроенные в CMS модули обычно удовлетворяют выдвигаемым к ним бизнес-требованиям.
Самая гибкая и наиболее мощная платформа — фреймворк
Фреймворк — это программный продукт, который служит основой для сайта, но обычно не содержит в себе готовых программных модулей для реализации конкретных бизнес-процессов. Выражаясь техническим языком, фреймворк — это более низкоуровневое решение, нежели CMS. Разработчики, при создании сайта на фреймворке, создают не только публичную часть сайта, но и проектируют базу данных, разрабатывают алгоритмы для модулей системы, а также создают административный интерфейс для управления проектом. Необходимость серьёзных затрат на программирование делает разработку более дорогой, но и результат получается более индивидуальным.
Этот вид платформ используют почти все крупные веб-проекты (на CMS построена лишь очень малая часть действительно серьёзных проектов), а также подавляющее большинство веб-приложений и веб-сервисов (коробочных решений для уникальных бизнес-процессов просто не существует, а использование не очень подходящих CMS в качестве основы для кастомизации очень усложняет разработку).
Мы, например, разрабатываем серьёзные веб-проекты на фреймворке Ruby on Rails. Данный фреймворк позволяет создавать действительно сложные сайты, бизнес-приложения и веб-сервисы. Скорость работы и устойчивость к нагрузкам у таких решений на порядок выше (в сравнении с CMS), а сопровождаемость и стоимость владения при этом не сильно отличаются.
CMS-платформы
CMS на рынке существует много и они очень разные:
Фреймворки
Фреймворки — это платформа для сложных сайтов или веб-приложений, которая оптимально подходит для создания сайтов и веб-приложений по индивидуальному проекту, которые должны работать быстро и выдерживать серьёзные нагрузки. Надо быть готовым к тому, что при выборе фреймворка в качестве платформы для разработки, придётся достаточно много времени и ресурсов потратить на разработку бизнес-логики, это плата за гибкость.
Какая платформа лучше: CMS или фреймворк?
Ответ на это вопрос очень прост — смотря что именно надо разработать: если проект простой и требования к нему самые обычные, то выбирается CMS, а если проект сложный, то проще его на фреймворке делать.
SaaS-платформы
Также сейчас «набирает обороты» создание сайтов на SaaS-платформах. SaaS-платформа для создания сайтов — это возможность запустить достаточно простой веб-проект очень быстро и крайне дёшево (причём еще и на условиях аренды). Решение подходит для простых сайтов, временных проектов и для проверки бизнес-идей. SaaS-платформы, как и CMS, бывают специфическими (только для интернет-магазинов, например) и универсальными (для всех типовых видов сайтов).
SaaS — самое простое, быстрое и недорогое решение для старта простых проектов
CMS — оптимальный выбор для достаточно типовых проектов, но где уже есть необходимость в незначительной кастомизации
Фреймворки — правильное решение для сложных проектов под высокие требования к надёжности, нагрузкам и скорости работы
Выбор между CMS и фреймворком
С технической точки зрения любой функционал может быть реализован или на CMS, или на фреймворке, или реализован без использования каких-либо платформ на чистом языке программирования.
Однако некоторые проекты проще сделать на CMS, некоторые — на фреймворке, а разработка без использования платформ редко бывает рациональным решением с точки зрения бизнеса. В большинстве случаев, выбор платформы стоит основывать на экономических критериях. В статье приведены основные критерии, которые позволят принять обоснованное решение по этому вопросу.
Простые проекты проще, быстрее и дешевле делать на коробочных CMS, а сложные проекты эффективнее разрабатывать на фреймворках
Рекомендации по выбору CMS и фреймворков
При выборе конкретной платформы для разработки часто возникают сложности. Бывает непросто принять взвешенное решение, в этом случае будет полезен следующий алгоритм выбора.
Если устраивает уже существующая платформа — не «изобретайте велосипед». Но не доверяйте полностью маркетинговым заявлениям вендоров — «коробочную» функциональность всегда надо изучать и проверять.
Опыт и знания команды — также очень важный фактор в выборе платформы. Лучше использовать те технологии, которые хорошо знакомы команде.
Современная 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 и т. д. Это то, чего мы так долго хотели? По моему, да.
Дальше — больше
В дальнейшем мы рассмотрим следующие темы (не обязательно в указанном порядке):