Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 14
Любая непонятная технология - магия )
Для полного сравнения примера счётчиками интересно было бы видеть их реализацию на чистом JS, vue и $mol )
Круто! Но зачем доллары?
Критическая проблема данного подхода — это неподсвечиваемые, невалидируемые (через линт) и неформатируемые выражения внутри строк. Собственно, для решения этой проблемы и появился JSX. Он позволяет использовать все возможности JS без ограничений, и при этом всё ещё иметь выразительный язык шаблонов. Ангуляр, кстати, тоже от этой проблемы страдает, но это уже просто наследие ранних подходов.
Но если так хочется совместить строки и pure JS, почему не воспользоваться Lit? (точнее, lit-html, веб компоненты тянуть не обязательно). Lit как раз отлично решает проблему: это прямые строки, никакой компиляции, и в то же время можно свободно пользоваться возможностями языка
Для мелких проектов может и подойдёт, но вот в чем же тогда разница с упомянутым реактом? Где тут роутинг, работа с формами и т.п.? Я пишу на ангуляре и выбираю его как раз за то, что там не нужны тонны зависимостей, чтобы реализовать приложение полностью. А с появлением сигналов и ресурсов со временем и от rxjs откажутся. Проект интересный, но я не вижу пока практического ему применения.
Да, по той же причине Angular мне больше нравится чем React
Роутер есть https://cruzo.org/#/docs/router, скоро будут children
Тогда неплохое начало. Но у меня все еще складывается ощущение, что не соблюден баланс меджу “простым” и “функциональным”. Невозможно простым и лаконичным набором команд описать сложную функциональность. Можно конечно всё запихнуть под условный вызов одной функции, но как только конфигурация начинает отличаться от стандартно задуманной заканчивается лаконичность.
Вообще, было бы интересно увидеть сравнение еще и в производительности одинаковых проектов на разных языках. Как я понимаю, Cruzo предназначен для не особо сложных проектов, но также себя позиционирует тот же $mol и еще пачка других (Vue, Ember и т.п.).
Я считаю, что важно выбрать нишу и в этой нише показать в чем превосходство над другими фреймворками, иначе есть банальный риск утонуть среди других.
Тут сильно зависит от того как пишешь и как строится архитектура фронт-энда. Вообще задуман cruzo для энтерпрайза. Для этого и писалась стековая vm для выражений. Если сервер отдает Content-Security-Policy: script-src 'self', тогда не будет работать eval или new Function.
RxBucket решает проблемы props drilling. Ну сторы как бы тоже их решают, но как. До сих пор с содроганием вспоминаю NgRx и все эти сторы и редьюсеры... Куча обслуживающего кода пишется.
Это пока вводная статья, но будет думаю еще цикл статей в т.ч. про архитектуру приложений на Cruzo. Постараюсь сделать сравнение с Angular, React, $mol
Немного оффтопа. У меня до сих пор есть классические NgRx сторы с редьюсерами, эффектами и всеми вытекающими. Но в новых проектах есть signalStore от NgRx и как же всё стало удобнее. А за Cruzo понаблюдаю. Едва ли в ближайшее время буду его использовать, т.к. не хватает функционала, но наблюдать интересно. Наперёд отвечу, что именно лично мне в моих проектах нужно для начала, чего не хватает пока что тут:
работа со стилями. Я понимаю, описывать логику и структуру компонента - это уже половину дела, но нельзя опускать такой большой пласт как стили.
формы. Полноценная работа с валидацией. Можно, конечно, на сторонние зависимости откупиться и собрать своего Франкенштейна, по крайней мере с формами это возможно.
i18n. Зачастую это добавляется в самом начале, чтобы потом было не так больно переделывать. И оно есть почти всегда. Поэтому это довольно важная часть. К сожалению, сторонние библиотеки тут не помогут.
библиотека компонентов. Я видел несколько стандартных, но этого безумно мало.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cruzo — минималистичный UI-фреймворк без лишней сложности