HTML / CSS "фреймворки" — памятники невежеству, некомпетентности и неумелости.

Информация о материале: Родительская категория: Программирование; Категория: HTML

Памятники невежеству, некомпетентности и неумелости — это фреймворки HTML / CSS — Фреймворки HTML / CSS — памятники невежеству, некомпетентности и неумелости.

Шокирующее, резкое, наглое и даже оскорбительное заявление.

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

Я понимаю, что для многих из вас это шокирующее, резкое, наглое и даже оскорбительное заявление, но это правда. То, что они продолжают быть "фишкой", которую используют люди, основано больше на пропаганде, риторике, эхо-камерах и общем незнании темы, чем на чем-то, отдаленно напоминающем факты. Мало, если вообще есть, утверждений об этих "фреймворках" - Bootstrap, Tailwind, w3.css и т.д. и т.п. - имеют под собой почву и в большинстве случаев являются наглой ложью!

Правда о HTML.

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

Это видно на каждом этапе. Такие вещи, как "проще" или "экономит время", рассыпаются в прах, когда вы понимаете, что пишете более запутанный код и столько же, если не БОЛЬШЕ, своего собственного кода, чем если бы вы просто писали ванильный HTML и CSS должным образом. Это не лучше для совместной работы, когда людям приходится изучать еще больше, прежде чем они будут готовы к чему-либо. Все, что это делает, лишь ограничивает - и, возможно, даже калечит способность научиться делать что-либо правильно.

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

Для чего предназначен HTML!

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

Это связано с тем, что когда Тим Бернерс-Ли создал HTML, он сделал это для того, чтобы контент можно было передавать на множество различных устройств с разными размерами, возможностями и ограничениями. Основное внимание уделялось доставке контента пользователям в максимально осмысленной форме, независимо от компьютерных или личных ограничений. С первого дня доступность и контент были во главе угла.

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

Мы отошли от этого во время браузерных войн, когда Netscape и Microsoft ввязались в свое маленькое соревнование, кто быстрее, но HTML 4 Strict был призван вытащить нас пинками и криками обратно на свет. Естественно, именно поэтому дышащие ртом люди провели следующие полтора десятилетия, извергая из себя HTML 4 Tranny - буквально при переходе от практики 1997 к практике 1998 года - и сегодня похлопывают по плечу те же устаревшие концепции середины 90-х годов, чтобы похлопать себя по спине за то, какие они "современные".

Как всё это связано с фреймворками?

"Разделение обязанностей" между HTML и CSS - вот почему такие вещи, как class="bg-white focus:outline-none focus:shadow-outline border border-gray-300" - это, как сказано в названии этой статьи, невежественный, некомпетентный и неумелый мусор, который совершенно не догадывается о цели HTML и о том, почему разделение представления и содержания - это главное.

Что, если вы не хотите, чтобы страница имела белый фон на другом экране? Зачем изменять разметку для того, что HTML не касается? Все становится еще хуже и хуже, когда вы попадаете в откровенно идиотский мусор вроде class="col-sm-8 col-md-7 py-4", где вы в конечном итоге накладываете бесконечные бессмысленные классы для каждой точки разрыва ширины, используя произвольные предопределенные классы, которые заставляют вас проектировать содержимое под макет вместо правильного подхода, когда содержимое диктует макет.

В этот момент вы с таким же успехом можете вернуться к использованию тегов FONT/CENTER, TABLE для верстки и прочей презентационной разметки, которой вам так не хватает!

Еще большее разочарование вызывает тот факт, что эти методы разрушают разметку таким образом, что уничтожают цель кэширования. HTML обычно кэшируется меньше - если вообще кэшируется - из-за того, что содержимое может меняться. Размещение статических стилей - даже в виде классов - в разметке - это упущенная возможность кэширования как для текущей страницы, так и для предварительного кэширования вложенных страниц. Если у вас есть что-то более сложное, чем страница с высоким уровнем отказов, размещение ЛЮБОГО стиля в разметке, даже в теге <style> - это полный провал в использовании кэширования для повышения скорости. Зачем заставлять каждую подстраницу загружать одну и ту же информацию каждый раз, если в этом нет необходимости?!

Единая монолитная таблица стилей для каждой медиа-цели, практическое отделение представления от содержания, использование селекторов и значимых классов/id'ов, вместо того чтобы вставлять в разметку презентационные классы, позволит вам не только лучше кэшировать одну страницу, но и предварительно кэшировать внешний вид для всех ваших вложенных страниц. В результате сайт будет загружаться быстрее, особенно если вы достаточно компетентны, чтобы понять, что у подавляющего большинства сайтов нет НИКАКОГО законного оправдания тому, чтобы иметь более 48k собственного CSS для всего сайта... до минификации и сжатия gzip. Полностью отформатированный, одна пара атрибутов в строке, 48k. Если только это не действительно огромный сайт, где каждая страница уникальна, нет причин для любого компетентного кодера иметь больше, чем 48k.

Отсюда следует, что 157k минифицированного Bootstrap и лишние препроцессорные BS и NPM-мусор Tailwind являются потрясающими примерами заголовка этой темы.

В ЛУЧШЕМ СЛУЧАЕ, все, что делают эти фреймворки - это учат вас мышлению в стиле 1990-х годов, и писать столько же собственного кода, сколько вы написали бы без них, перенося то, что должно быть в таблице стилей, в разметку.
В ХУДШЕМ СЛУЧАЕ, они учат вас плохой практике, подмешивая внешний вид в разметку, заставляют вас писать еще больше кода, чем без них, и раздувают вашу страницу, превращая ее в медленно загружающийся и медленно отрисовывающийся бардак.

Доказательство.

Посмотрите на примеры, которые предоставляют эти фреймворки. Давайте воспользуемся только header из примера Bootstrap "album".

<body>
    <header>
  <div class="collapse bg-dark" id="navbarHeader">
    <div class="container">
      <div class="row">
        <div class="col-sm-8 col-md-7 py-4">
          <h4 class="text-white">About</h4>
          <p class="text-muted">Add some information about the album below, the author, or any other background context. Make it a few sentences long so folks can pick up some informative tidbits. Then, link them off to some social networking sites or contact information.</p>
        </div>
        <div class="col-sm-4 offset-md-1 py-4">
          <h4 class="text-white">Contact</h4>
          <ul class="list-unstyled">
            <li><a href="#" class="text-white">Follow on Twitter</a></li>
            <li><a href="#" class="text-white">Like on Facebook</a></li>
            <li><a href="#" class="text-white">Email me</a></li>
          </ul>
        </div>
      </div>
    </div>
  </div>
  <div class="navbar navbar-dark bg-dark shadow-sm">
    <div class="container d-flex justify-content-between">
      <a href="#" class="navbar-brand d-flex align-items-center">
        <svg xmlns="http://www.w3.org/2000/svg" width="20" height="20" fill="none" stroke="currentColor" stroke-linecap="round" stroke-linejoin="round" stroke-width="2" aria-hidden="true" class="mr-2" viewBox="0 0 24 24" focusable="false"><path d="M23 19a2 2 0 0 1-2 2H3a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h4l2-3h6l2 3h4a2 2 0 0 1 2 2z"/><circle cx="12" cy="13" r="4"/></svg>
        <strong>Album</strong>
      </a>
      <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarHeader" aria-controls="navbarHeader" aria-expanded="false" aria-label="Toggle navigation">
        <span class="navbar-toggler-icon"></span>
      </button>
    </div>
  </div>
</header>

Бесконечные бессмысленные DIV ни для чего, бесконечные бессмысленные презентационные классы, теги BUTTON как элементы для JavaScript "мобильного меню гамбургера" - то, что даже не требует присутствия JavaScript - статическое изображение, вставленное в разметку для того, что, вероятно, должно быть символом UTF-8 или чем-то еще лучше, например font-awesome... и это только вершина айсберга.

Нелогичный порядок документов, первый несущий содержимое элемент на странице - H4, так что структура документа полностью перевернута, STRONG выполняет работу H1... До боли очевидно, что тот, кто написал этот HTML - даже если он не использовал bootstrap - не знает достаточно о семантике, чтобы написать это, и уж тем более не обладает наглостью указывать другим, как это делать.

Весь этот беспорядок для того, чтобы сделать такую работу:

<body>
  <header id="top">
    <div class="widthWrapper">
      <h1><a href="#"><i class="fas fa-camera"></i> Album</a></h1>
      <input type="checkbox" id="toggle_headerNav" class="toggle" hidden>
      <label for="toggle_headerNav"></label>
      <nav>
        <section>
          <h2>About</h2>
          <p>
            Add some information about the album below, the author, or any other background context. Make it a few sentences long so folks can pick up some informative tidbits. Then, link them off to some social networking sites or contact information.
          </p>
        </section><section>
          <h2>Contact</h2>
          <ul>
            <li><a href="#">Follow on Twitter</a></li>
            <li><a href="#">Like on Facebook</a></li>
            <li><a href="#">Email me</a></li>
          </ul>
        </section>
      </nav>
    </div>
  </header>

1.8k разметки делают работу по перелистыванию 803 байт. Я называю header #top как легкую ссылку на последующие href="#top", и хотя widthWrapper звучит презентабельно, он не говорит, КАКОЙ ширины, а только то, что он здесь для ширины. Тонкое, но важное различие.

"Но мне все равно придется писать CSS?". Да... и если простой код уже выполнен и шрифт установлен на BODY, если вам нужно более 1k кода, чтобы стилизовать это, вы не имеете права писать HTML или CSS!

Дальше будет еще тупее?!?

Я имею в виду такое:

<main role="main">

Это так же глупо, как и <form role="form">, поскольку означает, что эти клоуны используют роли aria, даже не удосужившись прочитать чертову спецификацию WAI! Поскольку предполагается использовать роли только тогда, когда вы не можете использовать правильный тег - например, при использовании div вместо <main> или <form>. Вот насколько совершенно необразованными и неквалифицированными являются люди, создающие эти фреймворки. Хотя это лишь часть того, почему я не понимаю, что должны делать роли aria, которые не могли бы сделать простое использование правильной разметки.

Даже не заставляйте меня начинать с их CSS, где они добавляют статические стили в разметку, произвольно смешивают и сопоставляют em/rem/px, используют PX медиа-запросы и ширины с EM размерами шрифтов, что приводит к нарушению макетов для таких пользователей, как я, у которых машины не настроены на 1REM == 16px, и т.д., и т.п.

Так что же будет лучше?

Чтобы полностью проиллюстрировать этот момент, я переписал шаблон "album" здесь:

Index of /for_others/medium_articles/frameworks/album_4.5/

6.37k HTML разметки, 4.99k CSS, 687 байт JavaScript... итого 12k для той же страницы, что и разметка в 16k. Даже если убрать то, чего у меня не было, например, встроенный CSS, и заменить SVG идентичными тегами IMG, лучшее, до чего вы сможете довести их разметку - это 14k HTML.

Позвольте мне повторить это снова, их разметка, ТОЛЬКО их разметка, в лучшем случае на 2k больше, чем HTML+CSS+Скриптинг, необходимые для такой страницы!

Скажите мне еще раз, насколько это "облегчает" работу. Все, чему вас учат, это как не писать HTML или CSS.

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

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

Потому что механизм действия для чего-то подобного не должен быть на JavaScript!

Если бы это был один из моих собственных проектов, это был бы modal, которому вообще не нужны скрипты, а не slide-in.

Ещё хуже.

Эти фреймворки становятся все более ужасными, чем больше вы их используете. Поскольку сам фреймворк должен быть неизменным, минифицированным кодом, который вы никогда не измените, чтобы изменить даже такую простую вещь, как цвета, вы либо переопределяете их стиль, используя существующие классы, либо придумываете все новые классы представления. Это приводит к "аду спецификаций", где становится все труднее и труднее накладывать слои и переопределять стиль, особенно когда многие из этих дрянных фреймворков используют !important повсюду, заставляя вас также использовать его... когда 99.99% (извините, пока я вытягиваю процент из своей задницы) времени вы никогда не должны использовать !important.

Вот почему даже их пример имеет свой собственный <style>, встроенный в него, а также целую отдельную таблицу стилей!

Конечно, это даже не полкило кода, но как это "легче" или "проще"? Это точно не "лучше".

В итоге.

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

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

Как только вы видите класс типа w3-red, bg-white или col-m-8, вы видите три "Н" веб-разработки. Невежество, некомпетентность и неумелость, которые должны заставить вас обратиться в бегство. Бежать, спасая свою жизнь.

Заметьте, я не считаю невежество оскорблением. Невежество можно исправить. Нам нужно беспокоиться о двух других "Н".

Перевод с английского:
medium.com

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