Имеется в виду предложение по поддержке технологии внутри Яндекс.браузер: функциональное расширение синтаксиса HTML - это такой антипод JSX. Есть у меня ещё со времен появления Senda (насколько я помню, её создатель сейчас в Яндекс), диз.док расширителя xml/html синтаксиса, до состояния функционального языка. Я тогда думал: вот будет клёво, создавать страницы без JS, используя при этом Sedna как БД и web-сервер. Ну естественно интерпретатор, я так и не написал, а потом и Sedna был заброшен создателем. Расширение думал назвать SednaML. С учётом роста популярности noSQL СУБД, и JSX, данная технология вполне могла бы стать успешной.

Почему не форкнул?

В тот момент времени достаточно большая рабочая нагруженность была, поэтому и отложил в "долгий ящик". Сейчас когда есть более/менее свободное время и в браузерах прописался WASM, подумываю сделать рабочий прототип в виде WASM библиотеки. Да и синтаксис надо пересмотреть - я подозреваю людям будет более удобно работать с аналогом JSX, но без JS. А вот что делать с серверной частью пока не решил, и возможно до неё не доберусь от слова совсем. Да и смысл делать форк появился только сейчас, ранее рынок веб-технологий особо к этому не располагал - учитываю тенденции, которое происходят.

люди начинают усложнять себе жизнь на сложных проектах когда сложность проекта превышает вновь создаваемую сложность или если проще - когда вновь создаваемая "сложность" упрощает проект

на простом маленьком проекте иногда нет смысла все усложнять если с этим еще не знаком, а только пытаешься делать как взрослые дядьки)

Панируется ли хоть какое-то финансирование?

Планируется OpenSource как есть - со своего кармана я могу только код и свободное время инвестировать. Ну и капаю на мозги с этом проектом, как компаниям которые являются гигантами в веб, так и стандартизаторам веб (W3C). А там как получится.
Сам работаю в компании производителе плазморезов и плазмотронов, работаем в т.ч. на росатом. На работе, данный проект поддержки не сыскал, а он предлагался как замена фронтэнд на JS - ибо один из руководителей фирмы ярый сторонник JS. Я являюсь ярым противником JS: имея в под "опекой" малоопытных сотрудников пришедших из вузов, убеждаюсь, что чтение исходников написанных на JS, JSX, PostScript вперемешку, с несоблюдением правил хорошего тона программиста, увеличивает порог вхождения вновь пришедших раз в двадцать, а заодно и мою работу, за которую мне не доплачивают. Вот как-то так. Благо сейчас хотя-бы стали переползать на ReactQML, но опять-таки рерайтить надо мне - другим просто не позволяет уровень компетенции. Именно из-за того, что меня припекло, решил, что надо вернуться к своей идее, и любыми путями её проталкивать в массы, - авось когда-нибуть JS must die, со всеми своими потрахами.

Что такое reactqml?

Тогда в Яндексе поддержки вряд ли найдешь)

Ну не найду в Яндекс, где-нибудь найду. Сейчас попутно общаюсь с ребятами из Mozilla (к слову сама Mozilla делает сейчас ставку на WASM и отошли от развития JS). А если кому-то нужен финансируемый проект, то в принципе есть и такой, правда в отрасли деревопереработки, и инвестирование производится капитализацией интеллектуальной собственности в NFT RC988 - я не думаю, что Яндекс это тоже будет интересно =)))

React QML - это частный случай React технологии, оптимизированной для Qt QML или Qt QMLweb, аналог ReactPHP, или же исконного ReactJS. В отличии от последних двух за ним не стояли авторы оригинального React - Facebook.

ReactPHP это фреймворк про асинхронное программирование в PHP. Он не связан с фреймворком про компоненты и декларативный рендер

Вот кстати по поводу компонентов я бы с Вами поспорил (т.к. используется компонентная модель, для ext-acync), а про остальное целиком и полностью согласен. ReactPHP для PHP(что логично), соответственно, он не связан с рендером в любом случае.

Help guys

Здравствуйте, есть какой-то style fixer для классического стека?

CSS Container Queries, или адаптация по-новому: контейнер вместо вьюпорта. Вадим Макеев на практике пробует черновую спецификацию выражений от контейнера, реализованную в Chrome Canary → https://youtu.be/bP3ceQEXMhU

Всем привет. Снова вопрос по i-bem.
Если не подключать "init_auto" в "i-bem-dom", то по "document.ready" будут созданы объекты блоков и элементов, но при этом им не поставиться "js_inited". Зачем это нужно? Ведь если верить документации, то триггер на "js_inited" - формально конструктор, но в приведенной выше ситуации он не вызывается при создании объекта. Более того, "js_inited" поставиться, если соответствующий объекту dom-элемент будет как-либо затронут, из другого объекта либо через событие. Т.е. насколько я вижу, мы имеем включенный везде по умолчанию "lazyInit", но с созданием объектов. Так зачем объектам висеть и засорять память, если они все равно ничего не делают?

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

Так а зачем вообще тогда эти объекты создавать? Почему не сделать по аналогии с lazyInit?

так там так и сделано