Качество веб-сайтов

В настоящей статье я хотел бы обсудить технологии создания хороших веб-сайтов.

1. Сначала напишу как именно я это себе представляю.
2. Потом каждый желающий может написать своё мнение.

Общий посыл начинается с вопроса:

Что если хочется создать большой и крутой сайт, то как это сделать?

Хорошие веб-сайты

Прежде всего дам определение, что такое хороший веб-сайт.

В текущем обсуждении под ним будет пониматься.
1. Информационно насыщенный веб-сайт.
2. Веб-сайт не перегруженный лишней информацией.

Примеры хороших веб-сайтов.
1. Документация к языкам программирования или библиотекам алгоритмов.
2. Интернет магазин с каталогами, товарами и их характеристиками.
3. Энциклопедия книг, игр, фильмов, анимаций, музыки.

Особенности хороших веб-сайтов.
1. Классифицированная и структурированная информация.
2. Фильтрация и сравнение данных.

Плохие веб-сайты

Плохой веб-сайт представляет из себя набор слабо связанной информации.

Примеры плохих веб-сайтов.
1. Созданные рерайтерами на основе других веб-сайтов или книг.
2. Созданные с помощью больших языковых моделей.

Спорные веб-сайты

К спорным веб-сайтам относятся созданные для общения.

Примеры спорных веб-сайтов.
1. Вопросы и ответы.
2. Тематические форумы.

Технологии веб-сайтов

Небольшой обзор технологий, чтобы было более понятно о чём речь.

Браузеры

Чтобы просмотреть веб-сайт нужны веб-браузеры.
1. Firefox
2. Tor.
3. Chrome.
4. Opera.
5. Edge.
6. Safari.
7. Links.
И так далее.

Вид содержимого сайтов

Как бы не создавалось содержимое сайтов в конечном итоге оно примет вид.
1. HTML.
2. HTML+CSS.
3. HTML+CSS+JS.

Запрещённые символы HTML

Для текста в HTML стоит заменять символы.
Тегов.
1. <. &lt;.
2. >. &gt;.
Специальных символов.
3. &. &amp;.
А для значений атрибутов HTML ещё кавычки и апострофы.
4. ". &quot;.
5. '. &apos;.
Хотя самый фатальный символ это конечно <.

Преобразование данных в оформление

Но это больше
1. оформление и взаимодействие с пользователем,
а не все
2. исходные способы хранения и обработки данных.

Способы хранения и обработки данных.
1. HTML+CSS+JS.
2. XML => HTML+CSS+JS.
3. DATABASE => HTML+CSS+JS.

Теги против атрибутов в XML

Читал два противоположных мнения, когда применять теги, а когда атрибуты.

Разница содержимого тегов и атрибутов тегов.
1. Символы содержимого.
В тегах запрещённый символ меньше <, не желательные больше > и амперсанд &.
В атрибутах плюс к тем, что в тегах кавычки " и апострофы '.
2. Структура данных.
Теги это древовидная структура значений данных.
Атрибуты это одно значение данных.
3. Видимость содержимого HTML (можно скопировать).
Содержимое тегов это то, что видно как текст.
Содержимое атрибутов это то, что не видно.
4. Диаграмма отношений.
Теги это сущности.
Атрибуты (признаки) это связи выше, на себя и ниже по иерархии.
Причём так же как и в XML в диаграмме отношений возможно разложить связи на сущности и собрать их обратно.

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

Как и в далёком прошлом я по прежнему не могу оценить технологию семантической паутины.

Мне не нравится, что.
1. Семантическая паутина создана с помощью предопределённых английских слов.
2. У неё странный и на мой взгляд не нужный синтаксис.
Я, кстати, после неё стал сомневаться в синтаксисе XSLT.

Короче странно и непонятно, кому надо читайте.
OWL, язык веб-онтологий. Руководство. Рекомендация W3C 10 февраля 2004
Или что в интернете отыщется.

Записал я это главным образом чтобы не забыть, что такое вообще существует.

Отличия CMS

А теперь о главном отличии систем управления содержимым (CMS).
1. Готовых CMS.
2. Самописных CMS.

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

Примеры CMS.
1. Wordpress.
Схема базы данных заточена под хранение статей.
Дополнительные возможности таксономия и комментирование статей.
2. OpenCart.
Схема базы данных заточена под хранение товаров.
Дополнительные возможности таксономия и комментирование товаров.

Схемы базы данных

Хотя в конечном итоге кажется, что и то и другое выглядит примерно одинаково, но в базе данных это не так. Именно базы данных дают возможности CRUD, а следовательно функционал SQL DML, то есть языка манипулирования данными.

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

Мораль здесь в том, что специализированное решение созданное под конкретную задачу эффективнее, чем подгон решения которое могло бы работать даже на чистом HTML. И в этом плане нужна самописная CMS в виде плагина к готовой CMS или отдельно написанной CMS. Для Wordpress чтобы он начал выполнять функцию магазина как в OpenCart таким примером может быть WooCommerce. Опять же эффективность такого решения никто не гарантирует.

Пример энциклопедия игр

Чисто для примера возьмём энциклопедию игр.

Персонажи игр.
1. Дозор (Overwatch). Ангел (mercy — милосердие)
2. Командная крепость 2 (Team Fortress 2). Медик (medic)

Ангел как известно слизана с медика вплость до эффектов оружия. Чтобы отфильтровать или сравнить одного персонажа с другим понятия должны быть сравнимыми. В некотором роде такую функциональность даёт CMS магазина, но не страничника или блога. В страничнике или блоге максимум можно установить какие-то элементы таксономии вроде ссылок на нечто похожее, вроде смотри так же (see also), но на этом всё.

Проблемы CMS на базах данных

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

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

И здесь начинаются импорты и экспорты из одного в другое. Для тех же магазинов это типично для товаров и преобразование в бухгалтерские или иные системы. Это может быть собственный интернет магазин владельца и его бухгалтерия вроде 1C. Или каталог товаров владельца магазина и какой-нибудь Яндекс.Маркет.

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

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

Лично мои выводы

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

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

Получается люди пытающиеся создать свой сайт как придётся проигрывают ещё не начав. С самого начала у них нет никакой тактики и они её не придерживаются. Что делать и кто виноват? Может начать создание данных для сайта с ручного XML, а может ещё что-то. И здесь уже как раз есть повод для обсуждений.