Фреймворк SNDL

Ну так вы это не мне, вы это ТСу донесите)))

Если я правильно понял глубокую концепцию, лежащую за идеей ТСа, то он пишет свою Node.js c каким-то Js-фреймворком в придачу (React.js или Vue).

Ну, или в конце концов придёт к чему-то похожему. Может пока что у него нода ещё не проглядывается, но когда упрётся в реалии требований разработки, а не сферического сайта в вакууме, то нужен будет сервер, который будет пересобирать вот этот "xml" во что-то работоспособное.

Это всё есть уже и более того, оно нужно. Но не на уровне проектов, которые делаются в большинстве своё на сёрче, где jQuery - покрывает процентов 95% сложности. Это больше для Js-приложений. Если интересно и ранее не сталкивались, гляньте Routing в React.js. При компиляции можно задать настройки, что при загрузке разных "страниц" (который генерируются через JS) подгружался только необходимый на этой странице JS-код или CSS.

Как раз один из кейсов, когда можно сделать, чтобы вначале загрузились react-вские либы, а затем общие для вашего приложения, а потом уже отдельные изменения погружать по мере обновления страниц (и/или js-кода).

Каждый программер должен написать свою cms. И нефиг тут ломать традиции :) На выходе это дает офигенный опыт своих велосипедов и скилл наколхозить нужный код в любом пакете.

А деньги платят за результат между прочим :)

Stek, ну, это да. Я первым делом решил был форум немного доделать, который нашёл в инете. В итоге чуть ли не с нуля его переписал. Правда, от этого он лучше в плане кода не стал. :)

Но общее понятие дало, как оно в вебе вообще всё работает.

Хотя сейчас бы, если начинать с нуля, то можно два варианта:

1) я взял бы какой-то фреймворк уже готовый и пробежался бы по мануалу по созданию чего-то простого, но готового на нём. Вхождение будет быстрее и, по-крайней мере, плавать в формулировках не будет.

2) онлайн-курсы на Udemy, Coursera или чем-то подобном.

У меня для одного проекта программер по как раз по реакту прошёл подобный курс, и я просил его пересказывать мне своими словами, после каждого значимого куска, чтобы потом хотя бы на общем языке смогли говорить :). Ибо js за последние годы ушёл вообще за горизонт. В итоге реально толчок дают такие курсы, даже если это вроде сходу и не заметно, но от преподавателя зависит, конечно.

Это как генерировать. (в смысле методика)

если на лету, то конечно да, результат будет печальным. Очень печальным.

Мы же один раз, в релиз, собираем цсс-хи и кладем их в кэш, после чего из кэша и берем.

стили разбиты по назначению:

1. Ядро /базовая сетка/ - они тянутся прямо в голову

2. Базовые стили, которые не влияют на стартовый рендеринг, но использование которых необходимо. они идут сквозняком через весь сайт.

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

4. специфические стили. (например обстил раздела новости/статьи или раздела с законами/нормами/правилами )

---

1. как я сказал грузится в голове (один раз, потом страница тоже кэшируется)

2. грузится обычным способом.

3 и 4 вынесены вниз документа

---

подобная структура создана для того, чтобы увеличить скорость загрузки и для получения большего кол-ва "попугаев" в google pagespeed

Если всё собрать в один файл, то гугл снижает рейтинг из-за большого кол-ва неиспользуемых стилей, загружаемых в начале. (сайты огромны, обстил за годы разработки набрался очень тяжелый, рефакторить в ближайшие года 3-4 тоже вряд ли кто будет) Вот поэтому и пошли путем сборки боевых цсс-ок из пары сотен мелких кусочков перед релизом

ArbNet,

Не в качестве пиара, а просто для сведения https://www.umi-cms.ru/product/system/modernarch/ , почитайте, будет полезно.

В топике вроде не упоминалось еще почему-то.

Опять, вы не понимаете. UMI в xml находятся данные объектов, то есть как в базе, это не есть гуд, это устаревший метод(если есть необходимость хранить данные объекта в файле, то лучше уж в JSON).

У меня просто разметка(xml выбран для наглядности редактирования) где что будет, движок подключает узлы и те возвращают либо шаблоны(в которые будут вставлены данные дочерних элементов), либо уже готовую разметку с данными.

edogs, Упоминалось, но ЮМИ сами ушли от этого в последних релизах. сосредоточившись на обычном php, в угоду скорости

Непонятно... у вас есть некий веб-ресурс... откуда у вас сотни мелких кусочков ?

Он на всяких модных нынче ангулярах итп, он "по смыслу" не html ?

Обвешан говноплагинами "как ёлка" ?

Вот посмотрел я ИМ свой... там аж на 15кб css... в нём всё.

Отдельно есть на 2-3кб для главной, ибо она сильно отличается от остальных.

Чего тут собирать-то ?

На самом деле мог бы быть и 5кб... засрано всё безмерно.

Нет, если хочется всякие бутстрапы итп к себе "всосать", то там да, без танцев с бубнами потом не обойтись.

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

_SP_, когда пишется какой-то новый функционал, то стили к нему собираются в отдельном файлике. за 8 лет разработки он зело так разожрался.

Понимаете. тут проблема в том, что есть магазин с аж 15 кб стилями, а есть Озон. Так вот. наш сайт, это озон - но только в другой области.

---------- Добавлено 08.11.2019 в 13:56 ----------

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