Ivan Bogachev

gulp cheerio как то странно работает, он портит некоторые svg иконки, их не видно, у них нет цвета и fill(заливка) на них не работает, может вообще его не использовать?

Вы несколько раз используете метод removeAttr, чтобы удалить атрибуты fill у элементов (если у них черная заливка, заданная в формате #000 или #000000), а также все атрибуты stroke и style из кода. А теперь вы задаете вопрос, а почему у вас пропадают цвета? Очевидно они пропадают потому, что вы сами написали код, который их удаляет.

Ошибки вида

... MIME type (‘text/html’) is not Executable ...

или

... MIME type ('text/html') is not a supported stylesheet MIME type ...

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

Учитывая, что в тегах вопроса значится kali, можно предположить, что вы запускаете браузер из-под рута, и он запускается в режиме песочницы, без доступа к реальной файловой системе. Защита от дурака, так сказать. Можно попробовать добавить флаг --no-sandbox при его запуске, или, что более безопасно, запустить его из-под обычного пользователя.

Вебпак - сборщик. Может взять много файлов и собрать в один. Ну или в несколько, как мы настроим. В js действительно есть модули, которые как бы уже нативно работают в современных браузерах, но есть ряд проблем:

• Файлов с кодом может быть много. Сотни. Если использовать нативные импорты и загружать сотни файлов в браузер одновременно - накладные расходы будут заметными. Было бы хорошо уменьшить количество файлов. Плюс там могут быть не только скрипты, но и другие файлы, которых тоже может быть много.
  
• Большое количество инструментов были написаны еще до появления нативных модулей в JS. Они все еще работают, выполняют свои задачи, но простым словом import их не импортировать. Там очень разные чудеса встречаются. Придумывать для каждого инструмента персональный костыль, как его импортировать, вроде как не хочется.
  
• К предыдущему - иногда удобно в скрипты на JS импортировать что-то не на JS из отдельных файлов. В контексте моей работы - шейдеры на GLSL. Их нельзя просто так нативным import загрузить.
  
• Часть зависимостей мы ставим с помощью npm. Это удобно. Но мы легко получаем папку node_modules на сотни мегабайт, при том, что в нашем проекте реально используется пара файлов оттуда. Загружать все это целиком на сервер - зачем? Ставить зависимости, а потом копировать нужные файлы откуда-то из глубин node_modules к себе в проект? Можно, но не то, чтобы удобно. Обновлять сложно будет, да и действий лишних что-то много.
  
• Не всегда нам нужен полный функционал инструментов, которые мы используем. Часто в пример приводят lodash. Там много готовых функций на разные случаи жизни, но все используются редко. Было бы прям здорово в браузер загружать только то, что там на самом деле будет использоваться. А то, что не используется - не загружать.
  

Как-то так. То есть нативные модули - это здорово. Но они далеки от совершенства. Не все проблемы решают. Поэтому сборщики все еще актуальны. И будут актуальны еще долгое время.

Плюс webpack имеет возможность встроить в процесс сборки дополнительные процессы, которые долго делать руками. Код можно минифицировать. Уменьшит время загрузки страниц. Можно запустить w3c validator, stylelint, eslint, sonar и.т.д. - всякие проверялки, чтобы убедиться, что к пользователям улетит валидный код. Можно какие-то картинки сжать, сконвертировать в другие форматы. Можно typescript превратить в javascript, less, sass и.т.д. - в css. Много чего можно сделать. В целом сборщик сам по себе - это перпендикулярный ко всем этим процессам инструмент. И раньше люди использовали отдельный класс инструментов, чтобы запускать все это - таск раннеры. Grunt, gulp - вы скорее всего про них слышали. Можно писать npm-скрипты или даже по старинке делать makefile под сложную сборку. Но в webpack вроде как есть функционал плагинов, и можно эти процессы запускать и через него тоже. Вроде как он не для этого изначально придуман, но многие люди находят удобным иметь все в одном месте.

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

В тегах вопроса значится Three.js, но в целом ради таких штук можно и не притягивать килотонны скриптов. Логики тут куда меньше, чем кажется на первый взгляд. Плюс можно и обычные HTML-элементы подвигать. Как пример:


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