Языки программирования созданы для формального описания решения конкретной задачи кратчайшим способом. Языки человеческие гораздо более многословны и не точны для этого.
Еще ни разу не встречал исследования где сравнивалось бы количество усилий и там и там для не шаблонных задач.
Подозреваю что любые операции с SVG должны быть значительно медленнее других видов графики в силу того что SVG работает через DOM+(Rendering Pipeline) броузера со всеми вытекающими от этого накладными расходами.
В графикакх оказывается нужно следить за цветами мааленьких точечек вместо того чтобы смотреть на цвета больших линий. И кому пришла эта "гениальная" мысль разделить цвет линии и точек? В общем графики не юзабельны!
Если кратко описать Фьюзор - то это один уровень абстракции над document.createElement, который упрощает создание элементов и их обновление впоследствии, без встроенного по умолчанию стейт-менеджера. Это библиотека служащая только одной цели, а не фреймворк и уж точно не платформа.
Для меня было бы актуально распознавание лиц и категоризация по ним. Также создание облака тегов чтобы была стратовая страница с ними. Также поиск дубликатов фотографий, чтобы удалить лишнее.
Ну это как всегда зависит от задачи. Например примерно 90% проблем уже моно решить через АПИ обычного броузера. Остальные 10% решаются с использованием микро-сервера запущенного на localhost (микро относительно electron). Если сервер написан на ноде или питоне, то проблема системных библиотек не актуальна. Бесплатные фреймворки без ререндеров и диффов тоже имеются.
Обрисую крайнюю степень этого явления. Веб приложение, вместо того чтобы использовать в имеющемся у пользователя броузере, поставляют с electron-ом (копией броузера с доп-функциями), потом заворачивают это все в snap/flatpack (копию операционной системы), и все это работает через несколько слоев виртуализации. Не говоря уже про грмоздкие вэб-фрейворки который ре-рендерят и делают diff-инг DOM дерева на каждый чих.
Вы же русифицировали также все методы для строк, цифр, и тд и тп, все АПИ на 100%? Или нам придется как бешеным скакать туда-сюда с с английской на русскую раскладку теряя миллион времени и невелируя все выше сказанное про поток мысли и незнание английского.
map, filter, toString, substr, trim, length, isNaN - тысячи их, и они постоянно пополняются, спецификация живет, как вы собираетесь это все поддерживать? Документация у вас есть в актуальном состоянии с русскими названиями и поиском?
Не говорю уже что на русском будет примерно в 1.5-2 раза больше символов писанины.
По мне так наилучший вариант это быть хорошим специалистом в одном стеке, чем середничком в двух и более, отсюда вытекает единственный стек который может и в фронт и бэк - JavaScript и друзья.
Фреймворк управляет вашим кодом, ваш код управляет библиотекой - вот разница между фреймворком и боблиотекой. Реакт - тоже фреймворк, так как вы не управляете тем когда и как вызываются ваши компоненты и хуки, этим управляет движок Реакта когда вы передаете управление в createRoot.
С другой стороны Фьюзор - это библиотека. В ней функция-компонент сразу создает DOM и запоминает в каком месте есть динамические данные (в виде фунций-обновителей c указателем DOM ноды), и далее только обновляет эти участки DOM без их поиска и DIFF-инга. Управление никуда не передается, все делается явно и в ручном режиме - async/await, try/catch, filter/map, только JavaScript и ничего лишнего.
Достаточно будет написать одну функцию "маунтер" для каждой библиотеки стейт менеджера, и проблема решена, тем более это очень простая функция - одна строка в примере.
Добавить обновление только для текстовых нод без элемента, есть такая идея, но пока в реальных кейсах не пригождалось, нужно собрать больше данных в каких сценариях это может быть полезно.
Если вы приглядитесь к примеру, то обнаружите функцию usubscribe, которая передается в mount, которая в свою очередь и вызовет ее на событии unmount. Так что нет утечки.
Автроматическое обновление подключается на пропсу mount. Причем можно использовать лучший алгоритм для каждого компонента, а не один "средний" для всех. Поддержка Typescript есть на сколько хватило моих в нем компетенции - уверен что можно допилить ее на много лучше, также как и автодополнения IDE.
Лучше слушайте старых линуксятником малята, а то старые виндузятники вам на наговорят тут всякое)
Языки программирования созданы для формального описания решения конкретной задачи кратчайшим способом. Языки человеческие гораздо более многословны и не точны для этого.
Еще ни разу не встречал исследования где сравнивалось бы количество усилий и там и там для не шаблонных задач.
более-менее адекватным выглядит https://redmonk.com/sogrady/2025/06/18/language-rankings-1-25/
Этот рейтинг на столько оторван от реальности, что даже язык реального первого места у них не в первой пятерке.
Си - нет!
Берем Раст - пишем в unsafe - профит!
Только мне кажется что забирать такой большой и важный проект из экосистемы JS рискует потерять синергию двух языков, идей и разработчиков?
Подозреваю что любые операции с SVG должны быть значительно медленнее других видов графики в силу того что SVG работает через DOM+(Rendering Pipeline) броузера со всеми вытекающими от этого накладными расходами.
В графикакх оказывается нужно следить за цветами мааленьких точечек вместо того чтобы смотреть на цвета больших линий. И кому пришла эта "гениальная" мысль разделить цвет линии и точек? В общем графики не юзабельны!
Если кратко описать Фьюзор - то это один уровень абстракции над
document.createElement, который упрощает создание элементов и их обновление впоследствии, без встроенного по умолчанию стейт-менеджера. Это библиотека служащая только одной цели, а не фреймворк и уж точно не платформа.Для меня было бы актуально распознавание лиц и категоризация по ним. Также создание облака тегов чтобы была стратовая страница с ними. Также поиск дубликатов фотографий, чтобы удалить лишнее.
А вы видели такого робо-пса, с колесами на концах лап? Он очень проходимый, может и ходить и ездить.
Ну это как всегда зависит от задачи. Например примерно 90% проблем уже моно решить через АПИ обычного броузера. Остальные 10% решаются с использованием микро-сервера запущенного на localhost (микро относительно electron). Если сервер написан на ноде или питоне, то проблема системных библиотек не актуальна. Бесплатные фреймворки без ререндеров и диффов тоже имеются.
Обрисую крайнюю степень этого явления. Веб приложение, вместо того чтобы использовать в имеющемся у пользователя броузере, поставляют с electron-ом (копией броузера с доп-функциями), потом заворачивают это все в snap/flatpack (копию операционной системы), и все это работает через несколько слоев виртуализации. Не говоря уже про грмоздкие вэб-фрейворки который ре-рендерят и делают diff-инг DOM дерева на каждый чих.
Не забудьте про склонения и рода, а то кривая русификация получается.
Вы же русифицировали также все методы для строк, цифр, и тд и тп, все АПИ на 100%? Или нам придется как бешеным скакать туда-сюда с с английской на русскую раскладку теряя миллион времени и невелируя все выше сказанное про поток мысли и незнание английского.
map, filter, toString, substr, trim, length, isNaN- тысячи их, и они постоянно пополняются, спецификация живет, как вы собираетесь это все поддерживать? Документация у вас есть в актуальном состоянии с русскими названиями и поиском?Не говорю уже что на русском будет примерно в 1.5-2 раза больше символов писанины.
А где можно подробнее почитать про 2% в Кыргызстане? Нужно ли жить там? 2% там + патент тут можно платить?
По мне так наилучший вариант это быть хорошим специалистом в одном стеке, чем середничком в двух и более, отсюда вытекает единственный стек который может и в фронт и бэк - JavaScript и друзья.
Фреймворк управляет вашим кодом, ваш код управляет библиотекой - вот разница между фреймворком и боблиотекой. Реакт - тоже фреймворк, так как вы не управляете тем когда и как вызываются ваши компоненты и хуки, этим управляет движок Реакта когда вы передаете управление в
createRoot.С другой стороны Фьюзор - это библиотека. В ней функция-компонент сразу создает DOM и запоминает в каком месте есть динамические данные (в виде фунций-обновителей c указателем DOM ноды), и далее только обновляет эти участки DOM без их поиска и DIFF-инга. Управление никуда не передается, все делается явно и в ручном режиме - async/await, try/catch, filter/map, только JavaScript и ничего лишнего.
Достаточно будет написать одну функцию "маунтер" для каждой библиотеки стейт менеджера, и проблема решена, тем более это очень простая функция - одна строка в примере.
Добавить обновление только для текстовых нод без элемента, есть такая идея, но пока в реальных кейсах не пригождалось, нужно собрать больше данных в каких сценариях это может быть полезно.
Если вы приглядитесь к примеру, то обнаружите функцию
usubscribe, которая передается вmount, которая в свою очередь и вызовет ее на событииunmount. Так что нет утечки.Автроматическое обновление подключается на пропсу
mount. Причем можно использовать лучший алгоритм для каждого компонента, а не один "средний" для всех. Поддержка Typescript есть на сколько хватило моих в нем компетенции - уверен что можно допилить ее на много лучше, также как и автодополнения IDE.FYI @artptr86