Комментарии 66
Технологии и инструменты появились не на ровном месте. Да, 20 лет назад HTML и CSS было достаточно, но сейчас, когда нужен интерактив, когда нужно решать значительно более сложные задачи чем просто вывод информации, нужны и другие, более сложные инструменты.
Современные сложные и тяжелые инструменты это попытка решить новые технические вызовы, и Электрон не исключение. Любые велосипеды со словами "нам это не нужно" в конце концов приведут к реализации аналога уже существующего инструмента, просто потому что готовые решения от сообщества уже прошли эти 1000 грабель и создали возможность решить весь спектр задач, а новый велосипед только поехал по этому пути, и поэтому он пока проще и легче, но для любого развивающегося продукта это временно.
Вопрос лишь в правильности реализации, архитектуре, и как и любое сложное решение, неправильная архитектура может приводить к серьезным просадкам по производительности, поэтому я бы сказал что не время такое, а общая техническая сложность современных задач такая, что простыми средствами её уже не реализовать, а любой рост сложности требует соответствующих навыков и инструментов.
Отсюда и растут ноги и просадок по производительности, и роста приложений.
Если программист 20 лет назад мог открыть блокнот и сделать страницу, и это было достаточно, то сейчас программист должен знать и уметь оперировать сразу N-инструментами с самого начала, и это только базис для старта.
но сейчас, когда нужен интерактив
Нужен?
То есть нет, в каких-то случаях безусловно нужен, но в каких-то других случаях не нужен, но используется. Для якобы красоты.
когда нужно решать значительно более сложные задачи чем просто вывод информации, нужны и другие, более сложные инструменты
Верно. Для каких-то задач нужен микроскоп. И им пользуются. Да так, что разучились пользоваться молотком и гвозди - самые обычные такие гвозди, тоже забивают микроскопом.
Если программист 20 лет назад мог открыть блокнот и сделать страницу, и это было достаточно, то сейчас программист должен знать и уметь оперировать сразу N-инструментами с самого начала, и это только базис для старта.
Снова верно. Но не совсем. Задачи, которые успешно решали раньше в блокноте, сегодня тоже можно решать точно так же. Все, что сверх, как правило всего лишь украшательство, иногда приятное, часто сомнительное, но всегда ресурсоемкое.
Прошу понимать сказанное мною схематично, не придираясь к частностям.
Хоть самую идеальную архитектуру делай на электроне, но решение будет требовать мощного железа. Хоть строчку выводи. Но электрон на старте съест 100+ озу и пару сотен цпу, у нас же реактивные страницы 60 фпс и т.д
Просто взяли разметку текста, и начали костылить со всех сторон. Результат то есть, и оно работает. Но требует овер мощностей.
Интересно, а скольким т.н. корпоративным сайтам\лэндингам\интернет-магазинам реально необходимо под 100 мегабайт всевозможных JS-библиотек?
Работал я в одной студии. Так там в отделе разработки больше всех денег получал "придумыватель графических эффектов". Чувак который придумывал то, как анимировать страницы. Зачем? А затем, что были продажники которые говорили заказчику "Ну-у-у такое у всех есть. Чем вы будете отличаться? И так дорогой сайт заказываете. Так выделитесь из общей массы конкурентов!". И клиент начинал верить в то, что пол сотни PNG-картинок через JS сменяющих друг друга и образующих 3D-модель вращающейся молекулы реально может склонить покупателя к покупке именно его БАДа. А по факту покупатель не то, что не склонялся. Покупатель бежал без оглядки с сайта который грузится по 10 секунд! И вот дальше маркетологи: "А давайте проведём ресёрч, поставим таски разработке и поиграем со шрифтами. Ну ещё анимацию текстовому блоку добавим!".
Спрашиваешь у верстальщика "а чего ты себе комп для работы 2 дня готовил? Тыж только вёрстку делаешь. В PHP не лезешь, с базами не работаешь...". А он и говорит "Ну CSS-компилятор надо поставить\настроить, библиотеки скачать и пр." Дожили... Чтобы сделать лэндос нам надо компилятор для CSS!
- Чувак! А чего у тебя в настройках таймауты для PHP выкручены до 360 секунд и памяти ты разрешаешь до 256 мегабайт?!
-А чтобы все отрабатывало и не падало с Segfault\Timeout
И это магазин с 2 десятками позиций всего и с аудиторией в 1 город. При этом специфика товара не подразумевает посещалку более 100 чел./сутки
-Чувак! А может как-то пооптимизировать? А то жирновато получается
-Не, время программиста дороже!
Все абсолютно так и есть. Просто мы живем в эпоху маркетинга и все решения сейчас (ну не все, большинство) как раз продиктованы тем, что маркетинг победил инженерию.
И тренды задают маркетёры, а не разработчики. Последние просто стараются успевать исполнять хотелки маркетолога.
Тема стара как хабр. Риторика местами с имплицитным "теплое=мягкое", но минимализм это хорошо
"почему все так всрато ч2"?
Помню после очередного обновления Skype на iOS (весьма давно) стала люто тормозить прокрутка контактов. Какой-то простой список из 20 строк с аватарками тормозит, как они этого добились?! Про новые версии ничего не скажу - примерно тогда и покинул сервис, видимо так и уходят пользователи
Раньше простенький сайт писали за пять минут в блокноте.
Вот с этого началось. Сначала копипаста общего кода, потом добавление вариативности, далее изменчивость самих страниц, в блокноте потребовалось писать клиент-серверные гостевые страницы, понадобился другой блокнот...
Но я всё равно прослезился.
Потому что противоречащие параграфы в требованиях.
Личным сайтам можно оставаться в одном файле.. если это не портфолио дизайнера. И пока размер этого файла не вынудит к модульности.
К сожалению, у большинства сайтов основная функциональность конверсия и шпионаж, а всё остальное замануха в "воронку продаж". Оптимизацию по времени загрузки невозможно продать среднему заказчику с деньгами.
И "раньше такой херни не было" - оттого наблюдаемое замедление отклика со временем.
Личным сайтам можно оставаться в одном файле.. если это не портфолио дизайнера.
Вот уж как раз хороший дизайн можно показать и на статике, без вот этой карусели, когда крутишь колёсико мыши и начинается слайд-шоу твориться, где меняется текст, ползают картинки и вообще видео на фоне на полный экран, дёргающееся, потому что подгружаться не успевает, и бывает что на старом маленьком мониторе видны артефакты растягивания из низкого разрешения, что тоже в минус.
Оптимизацию по времени загрузки невозможно продать среднему заказчику с деньгами
Ещё как можно. Существуют исследования, которые это подтверждают. Цифр не помню, но там чёткие цифры типа "за каждую дополнительную секунду загрузки, N% пользователей валят."
Когда вы в последний раз заходили на сайт, который загрузился за 200мс и мгновенно реагирует на ввод? Не прыгает? Не тормозит? На котором не страшно, если случайно кликнул по ссылке, потому, что пока сообразил, что ты кликнул не туда, страница уже загрузилась и загрузка при переходе обратно займёт 0.2 секунды? Давно ли появлялось желание кликнуть по вызывающему заголовку, но "да ну его", потому, что оно будет грузиться 40 сек?
Меня бесит на сайтах, верхний раздел. К примеру сайт загрузился я кликнул на кнопку, но до этого шапка прогрузилась и вся страница сместилась вниз и я тыкаю на банерную рекламу или подобное. И прям бесит. В основном такое происходит при серфинге со смартфона.
И на их исследования обычно ссылаются.
Все (относительно) успешные торговые площадки - eBay, Авито, Amazon, Ozon, Мешок (простите, если кого забыл, это не реклама).
Когда поменяли дизайн сайта Юлмарта все плевались. Но им объясняли: "Вы ничего не понимаете. Сайт жутко тормозит, но он очень прогрессивный. Через несколько лет, когда у всех будет мощное железо и жирные интернет-каналы, вы поймёте, насколько это удобно". Что произошло через несколько лет, все знают.
Единственное преимущество Electron и React Native Desktop — что даже двухлетний ребёнок может сляпать простое приложение. Речь идёт об удешевлении разработки
Похоже, вы не совсем правильно понимаете причино-следственные связи и зачем и почему создаются современные решения для разработки.
Поймите, сейчас не 2004-й год, когда существует только Intel и только Windows XP.
Сейчас есть ноутбуки, планшеты, настольные ПК, смартфоны. Есть Windows, macOS, Linux, Android и iOS.
Сейчас есть ARM и Intel. Есть как ПК на ARM, так и мобильные устройства на Intel.
Это огромный зоопарк архитектур и систем. Традиционное нативное приложение, нужно комплировать под каждую систему отдельно и использовать хуки и хаки каждой системы отдельно.
Современные средства разработки нужны для декомпозиции проблем и разделения ответственности.
Electron позволяет разработчику решать проблему бизнеса, а не решать проблему совместимости того что нужно бизнесу с зоопарком систем и архитектур.
Бизнес хочет что бы иконка мигала когда приходит сообщение - разработчик делает иконку и прописывает ей мигание при наступлении события, после чего фокусируется на следующей задаче бизнеса.
А отображение иконки и её мигание становится проблемой тех, кто разрабатывает CEF. При этом разработчики CEF абсолютно не парятся бизнесом, но заняты тем что бы мигало одинаково что на ARM под Windows 11, что на Intel под Ubuntu, что на M1 и iOS или еще чем-то там.
Возьмем приложение Skype. У него есть версия для Linux, macOS и Windows. Кроме того, есть веб-версия которую можно открыть с любого современного браузера.
Везде оно выглядит одинаково. Используется один и тот же код, одно и то же отображение. Человек может без установки чего либо открыть страницу в браузере и получить полноценный опыт работы с сервисом.
Вот зачем это нужно, а не для того что бы двухлетний ребенок мог что-то сделать. Уж поверьте, накидать на форму кнопочки в конструкторе ребенок мог и 20 лет назад используя Delphi 7. И сделать что-то на Электроне ему будет как минимум не легче.
Да, есть Qt, Avalonia и другие UI фреймворки которые позволяют сделать UI который будет +- одинаково работать на винде и например маке, но у них свои нюансы и недостатки, главный - отсутствие поддержки веба и нужно будет тратить в несколько раз больше ресурсов что бы это всё взлетело.
Когда-то в конце 90х делал домашний сайт на html/perl. Потихоньку добавлял какие-то java-апплеты. Потом переехал на js.
А потом взял и поставил joomla и было все удобно и удачно. Сайт совершенно персональный (онлайн может 1-2 человека в месяц). Поэтому поддерживать его естественно лень, и в какой-то момент при обновлении хостера понял что джумла на новой версии php просто так не заведется.
Думал развернуть все на wordpress, потом еще подумал и за 3 вечера склепал на html/css/парочка js скриптов (учитывая что я не разработчик). Дописал на php простой скрипт для счетчика. И все, теперь поддержка не нужна годами. То, что там написано на php я перепишу под новые версии за час, если вдруг что. Уязвимостей нет, ибо в базе только счетчики, никакой инфы, регистрации нет.
Я совершенно поддерживаю, что очень многие "для упрощения", ставят CMS там, где это делать не обязательно.
Да, на чистом html\css\js вручную сложно сделать красивую верстку, если ты не специалист, но мне кажется что заказать один раз верстку не так дорого, особенно учитывая что ее не надо натягивать на CMS.
Сайтам-визиткам и персональным сайтам без функционала это однозначно рекомендуется
А исходники сайта с простыми счетчиками можно глянуть, они открыты?
Hidden text
if (isset($_GET['file'])) {
$file=SQLite3::escapeString($_GET['file']);
$result = $mydb->query("select count from humour where name = '$file'");
$res=$result->fetchArray()[0];
if ($res) {
$mydb->exec("UPDATE humour SET count = count + 1 WHERE name = '$file'");
} else {
$mydb->exec("INSERT into humour(count,name) VALUES(1,'$file');");
}
Основной кусок. Дальше просто вывод списка статей. При клике на статью, увеличивается счетчик. Никакой защиты от накликивания нет в силу отсутствия необходимости.
База - sqlite
Что тут говорить, если просто обновление Windows занимает восемь часов!Что тут говорить, если автор не удосужился прочитать материал, на который ссылается.
Речь там вовсе не о том, что какое-то обновление устанавливается 8 часов. А о том, что если устройство редко подключается к интернету, то и обновления, закрывающие, скажем, уязвимости, ведущие к локальному повышению прав, оно своевременно не получает.
По задержкам ситуация хорошо разобрана тут https://habr.com/ru/company/vk/blog/594633/
На самом деле, из-за особенностей протоколов, проблема серьезнее, чем принято считать. К сожалению решения как правило принимает менеджмент, а он смотрит только на доступность в Москве, остальной мир не интересен. В итоге получается полный бред.
Насчет задержки между нажатием на клавишу и отображением символа на экране... Как бы сравнение не слишком корректно.
В 1980-х годах для этого нужно было обработать прерывание от клавиатуры, положить символ в буфер и отобразить на экране с заранее запрограммированным шрифтом.
Сейчас нужно сделать откровенно дофига: получить это нажатие системой, проверить, не является ли оно служебной комбинацией клавиш, оповестить приложения о этом нажатии, преобразовать нажатие в символ на нужном языке, обработать этот символ в самом приложении (всякие подсказки и автодополнения), отобразить на экране с нужным красивым шрифтом в hi-dpi... ну как-то так. И все это в условиях многозадачности.
Компьютеры стали на порядки мощнее, но и задачи тоже нехило усложнились - пусть мы их временами не замечаем, и для нас это все такое же нажатие на клавишу и отображение символа.
по поводу git ждем когда и этот сервис падет под санкциями :-)
политика дискредитировала уже многие социальные сервисы и добирается до ит (сертификаты вот уже стали обнулять :-)
То же самое происходит в вебе, где поверх HTML нагромоздили несколько уровней абстракции. Node, NPM, Webpack, Babel, фреймворк для разработки SPA, фреймворк CSS, транспилятор CSS, приложение для запуска тестов, библиотека функций тестирования...
Хоть я и начинающий разработчик, но вот до сих пор не понимаю (не стреляйте пож.) смысл доп. библиотек/фреймворков react, vue и т.п., если можно это делать на native js (ну еще node.js могу понять, мол, серверный вариант, для событийно-ориент. и асинхронного программирования).
Понятно. Меня смущало то, что под каждую библиотеку начинаются танцы с документацией, хоть синтаксис практически одинаковый (js как-никак). Зато да, тогда на spa-проектах упростит задачи.
Спасибо за разъяснения!
> А вот когда у вас десятки форм с десятками элементов разных типов
Разве ж можно юзеров пугать таким количеством форм?
Юзера и от одной-то формы бегут быстрее, чем от сайта, загружающегося 10 секунд.
Ведь при виде формы они думают, что кто-то хочет спалить их информацию, да не просто спалить, а украсть финансовую информацию, доступ к банковским счетам да картам и т.п, чтобы затем укрсть их деньги и прочие ресурсы.
И всё это при виде только одной формы.
А если их на странице десяток-другой? Да это ж сразу паника будет у юзера...
Когда я показал своему преподу курсовую в минималистичном стиле он отправил меня добавлять на неё слайдеры(
Всё именно так. Ненужные уровни абстракции, мегабайтные гиф/флеш/видео и дебри небезопасного кода с ссылками неизвестно на какие скрипты.
Сайт из блокнот+Word+CSS написан 15 лет назад и вполне себя хорошо чувствует. Смотрел я на эти пляски с php, js, ruby, что там ещё было...и не трогал ничего. Короче, web0 это экологично)
Hugo просто топ, но для личного сайта, а не для энтерпрайза.
NPM, Webpack, Babel, фреймворк для разработки SPA, фреймворк CSS, транспилятор CSS, приложение для запуска тестов, библиотека функций тестирования и ещё куча всяких мелочей — минимальный стартовый набор самых необходимых инструментов, чтобы запустить простенький сайт с небольшой интерактивностью.
Всё это заменяется на один $mol и получаете возможность легко создавать экосистемы сложных динамичных порталов.
Не малую роль в распухании интернет-страниу сыграли рекламщики. Да и не только интернет-страниц.
Переусложненность веба на лицо. Миллионы лет эволюции, покорение огня, рек, атомной энергии, создание высокотехнологичных вещей. А в итоге, вот это вот всё.)
Про описанное в начале: по сути это всё уже было в WAP 1.0 и WML, страница делилась на карточки, между которыми осуществлялась мгновенная навигация по ссылкам. Для статичных сайтов такого хватало.
Там ещё и картинки только в wbmp были, чёрно-белые.
Ожирение всего вокруг приобретает какие-то космические масштабы. Такое чувство, что все вокруг сошли с ума и начали изобретать «революционные новые способы» делать привычные вещи.
Я извиняюсь, но на вашем сайте из вашей предыдущей статьи "Ключ на старт: взлетаем с новым дизайном FirstVDS" 28 (двадцать восемь) favicon-ов!
Забавно получается. Изначально свой блог написал на Vue.
Простоты ради я переписал его на django, да мне действительно стало проще.
После краша бд в следствии неудачной миграции (осилить тогда я это не смог) я плюнул на все и переехал на Wordpress,
Казалось, бы что проще, но теперь после прочтения статьи пора на Github Pages?
Смотря какие цели преследуете от сайта и хотите ли его развивать. Тут уже в вопрос не только в простоте. Например вы хотите настроить тегирование статей или сортировку. Хотел бы я посмотреть как это будет выглядеть в web0. На мой взгляд главное компромисс. Я был знаком с сайтами на python лет 5-6 назад, это было удручающее зрелище. Один жутко тормозил, по второму не смогли сделать доработки, потому что не было разработчика под python. Мне кажется разработчики, дизайнеры, проджекты заигрались и сайты становятся на франкенштейна. Надо еще учесть, что в идеале спустя 2-4 года сайт надо обновлять, в том числе дизайн. а если в сайт вбухано 500 тыс - 1 млн рублей?
Через xslt это всё прекрасно делается на клиенте без скриптов.
На самом деле для блога, я считаю Wordpress почти идеальной CMS.
И менять ее в обозримом будущем не собираюсь.
Я не представляю сколько усилий потребуется сделать правильное SEO на web0, имеется ввиду различные фиды, AMP - страницы google и турбо-страницы яндекс например, и это еще самая малость.
Один раз решил сделать «по-современному», нашел шаблон (вроде, Bootstrap), наполнил контентом. Больше так не делал. Во-первых, мне просто не нравится весь этот летающий цирк и современный дизайн. Во-вторых, малейшее изменение дизайна и поведения «под себя» излишне трудоемко и непредсказуемо. Периодически наблюдаю такие же проблемы у коллег из других городов. Крутой дизайн, два слова на странице, одно из них закрыто поехавшей шапкой.
Снова делаю всё в блокноте. Ничего лишнего и всё ровно так, как хочется. Немного JS приходится использовать — для адаптивности (на мобильном спрятать меню в гамбургер и т.д.). Рад новым тенденциям.
Я мог бы освоить что-то новое, но для своего хомяка именно что пошёл и в блокноте код написал. Обновлять только не очень удобно, но т.к. делаю это раз в полтора года - сойдёт.
Хех, если бы все именно ПИСАЛИ сайты, тогда ситуация была по лучше. Сейчас всё больше сайтов делают в криэйторах по типу вордпресса и остальной мутни. Реклама вроде: сделай свой сайт за пару кликов и "насри" в дерево и стили равноценны. Если б меньше людей пользовались подобными вещами, то и говнокода в сайтах стало бы меньше. Типо да, не спорю что удобно, но если смотреть со стороны разработчика, то это хрень голимая.
в соседней теме про 5 трендов дизайнов сайта совсем другое , вы хоть там сами с сообй определитесь
Подготовка к контр-санкциям? Это хорошо. Дефицит полупроводников - плохо
Для меня в свое время стали открытием 64kb demo. Может и в веб разработке есть похожие "соревнования"?
Я думаю что тут свою роль еще играет как низкий порог входа, так и наличие массы обучающего материала. Этот материал, как правило, сильно специализирован, заточен на быстрое решение типовой задачи. Чтобы дать достаточно матчасти для получения видимого, осязаемого результата. StackOverflow Driven Development - наше все.
Снижение входного порога заставляет весь рынок идти по пути наименьших трудозатрат и повышения скорости разработки. Поэтому множество абстракций, и высокая степень интегрированности.
Хотя, если посмотреть, какую задачу, например, решают веб-фреймворки? Они дают шаблон для разработки масштабного ортогонально-интегрированного приложения. Разделение, скажем, представления и бизнес логики. Писать один раз, использовать в нескольких местах и т.п. Это хорошие архитектурные принципы.
Вот был я сегодня на предоперационном обследовании в больнице. Там нужно было с дюжину разных формуляров заполнить. Некоторые вопросы повторяются, но вынесены в отдельный формуляр по той инстанции которой требуется эта информация. Казалось бы, разве не было бы лучше задавать все вопросы один раз, а потом кому надо берут ту информацию которая их интересует? Ну, скажем в бумажном варианте такое не реализовать, но в цифровом - вполне. Вот мы и приходим к теме информационной архитектуры. А когда мы реализуем инфромационную архитектуру, то становится логичным, что мы хотим наполнять части этой архитектуры независимо друг от друга, и легко менять ее структуру. Т.е. нам нужна эта изменяемость, расширяемость. И также простота поддержки.
Поговаривают, что код игры Counter Strike Global Offensive настолько запутаный, что когда разработчики выкатывают что-то новое потом три патча в догонку летит, чтобы залатать созданные обновлением проблемы и эксплойты. Фреймворк противоборствует такой запутанности. Но приходится таскать его с собой. А это снижает производительность.
Может таки надежда на WebAssembly? И будет все равно какой развесистый код. Компилятор его оптимизирует и упакует так, что потери эффективности при выполнении будут сведены к минимуму.
В реальности вообще весь сайт вообще можно поместить в одном HTML-файле.
Формально этот сайт состоит из нескольких файлов
Синглпейдж - это почти один файл, только не файл, а пейдж. То, что автор и описывает.
То же самое происходит в вебе, где поверх HTML нагромоздили несколько
уровней абстракции. Node, NPM, Webpack, Babel, фреймворк для разработки
SPA, фреймворк CSS, транспилятор CSS, приложение для запуска тестов,
библиотека функций тестирования и ещё куча всяких мелочей — минимальный
стартовый набор самых необходимых инструментов, чтобы запустить
простенький сайт с небольшой интерактивностью.
Ну, давайте разбираться.
Node, NPM
Если речь идет о синглпейдж из большой тройки реакт-ангулар-вью, то Node, NPM используется для управления библиотеками - не попадает в код на проде, а облегчает жизнь разраба тем, что доставляет ему либы, например Webpack, Babel
Webpack, Babel
Помогают использовать современные фичи javascript, не заглядывая в can i use и не подключая самостоятельно полифилы. Это сейчас querySelector - стандартное и давно всеми поддерживаемое апи, а все девайсы такие страшно ожиревшее, и слово "кросбраузерность" не ассоциируется с каким-то гемороем. Ну ничего. Завта станет дико модно пользоваться электронными книгами (для примера), с малыми ресурсами и специфичным поведением браузера. Руками будете совместимости добиваться? От es6+ отказываемся, привет es5? Вы так писали вообще когда-нибудь? Но опять же, все это не входит в бандл для прода т.е. не раздувает размер сайта. Все это помогает сформировать бандл и не паритсья о важном вручную.
фреймворк для разработки
SPA
Минимальную реактивность в студию, для которой не нужен спа. Ну, речь же не о сайтах из примера выше, с парой страничек небольшого текста.
фреймворк CSS, транспилятор CSS
Опять же, помогают не париться о префиксах браузеров, что позволяет легче добиваться кроссбраузерности, плюс дают еще ряд удобных фич для разработчика. Фреймворк также помогает не париться о чем-нибудь, в чем не разбираешься, типа типографики. Добавляешь на сайт и он становится красивым - клево же. На выходе у нас скомпилированный и минифицированный файл.
приложение для запуска тестов, библиотека функций тестирования и ещё куча всяких мелочей
Тут такое, если все-таки сайт не за пять минут написан, то удобно иметь тесты, чтобы знать, что ты и правда ничего не поломал. Но их редко кто правда пишет )) Опять же, "вот есть сайты с контентом на пару твитов и каждый твит - отдельная страничка, мы это сделали на css" не совсем аргумент. Очертите яснее сферу применения, что вы собираетесь делать и будет ясно, нужны там тесты, фреймворк spa, транслятор css или нет.
Запускайте блог на любом стеке, будь это произвольная CMS, генератор статических сайтов типа Hugo или Gatsby, или что угодно. Неважно. Самое главное: Сохраняйте весь контент в самых простых форматах, в которых возможно.
Вот отличный совет. Добавляейте сложности для создания сайта путем дополнительной процедуры, со временем сделайте инструмент, который облегчает подобное сохранение, занимайтесь его популяризацией и теперь в список из вебпака, спа-фреймворка, css-препроцессоров добавится и ваша новинка.
Из цитаты выше также следует, что автор знает о генераторах статичных сайтов. Как бы отличный способ сохранять данные в маркдауне и минимизировать используемые технологии, разве нет?
Я тоже ненавижу тяжёлые сайты, и для себя сделал облегчённую версию сайта БО без JavaScript и без каких-либо реклам. Даже на стареньком леново А6000 быстро все грузится.
Простые сайты снова в моде. Минимализм возвращается