Pull to refresh

Comments 39

Любая непонятная технология - магия )

В будущем выпущу статью про lifecycle компонента. Там на самом деле все просто как автомат калашникова)

Для полного сравнения примера счётчиками интересно было бы видеть их реализацию на чистом JS, vue и $mol )

Спасибо, по делу. Один и тот же пример в разных реализациях был бы нагляднее — возможно, сделаю отдельное сравнение, в последующих статьях. Это была вводная статья, на что хватило сил, так сказать

Круто! Но зачем доллары?

Это на выбор, просто я для себя сам таким образом выделяю rx переменные

Критическая проблема данного подхода — это неподсвечиваемые, невалидируемые (через линт) и неформатируемые выражения внутри строк. Собственно, для решения этой проблемы и появился JSX. Он позволяет использовать все возможности JS без ограничений, и при этом всё ещё иметь выразительный язык шаблонов. Ангуляр, кстати, тоже от этой проблемы страдает, но это уже просто наследие ранних подходов.

Но если так хочется совместить строки и pure JS, почему не воспользоваться Lit? (точнее, lit-html, веб компоненты тянуть не обязательно). Lit как раз отлично решает проблему: это прямые строки, никакой компиляции, и в то же время можно свободно пользоваться возможностями языка

Я написал extension для visual studio code. Есть подсветка, подсказки и форматирование самого шаблона в getHTML
Lit интересен. А там можно выполнить частичный пересчет шаблона? Я именно про калькуляцию спрашиваю, а не про применение изменений к dom

Он там частичный абсолютно всегда. Любое изменение дёргает только конткретные атрибуты/поля/ивенты. Изначальный код HTML заворачивается в template, далее в местах разрыва tag literal регистрируются "дырки" (holes или values), которые при повторном рендере обновляются по изменению value по конкретному индексу. В общем, все преимущества Virtual DOM без его недостатков. Свои caveats там, конечно, тоже есть (например, нельзя вдруг поменять имя тэга, это требует пересчёта всего элемента и теряет все преимущества), но по сравнению с virtual dom они гораздо менее существенны. И работает безо всякой транспиляции, прямо в браузере.

Я написал extension для visual studio code

А если я пользкюсь Intellij IDEA? )

Еще раз, я не говорил про изменения в dom. Lit меняет dom частично и cruzo тоже, но в cruzo вдобавок частичный пересчет, что экономит CPU

https://github.com/lit/lit/blob/main/dev-docs/design/how-lit-html-works.md
“Update: Iterate over the dynamic JS values and associated Lit Part only committing the values that have changed to the DOM.”
Как вы трактуете эту строку? Я понимаю что он lit бежит по всем значениям (жрет CPU неимоверно, что плохо для смартфонов в первую очередь) и делает апдейт только по тем которые изменились. А cruzo может работать по другому, пересчет может быть частичный

Ммм, вы говорите про shallow check, что ли? Если сильно (очень сильно!) упрощать, то он выглядит как-то так:

const registry = new WeakMap<TemplateStringsArray, TemplateResult>();

function html(strings: TemplateStringsArray, values: readonly unknown[]): TemplateResult {
    if (registry.has(strings)) {
        const result = registry.get(strings)!;

        for (let i = 0; i < strings.length; i++) {
            if (result.get(i).value !== values[i]) {
                result.update(values[i]);
            }
        }
    } else {
        // Init code
    }
}

function exec(txt: string) {
  render(html`<div>${txt}</div>`, document.getElementById('root'));
}

Что тут может нагружать CPU, да ещё и неимоверно?

Обход по всем значениям это не круто, в большом шаблоне их может быть много, и еще к тому же это могут быть функции

Функции в шаблон Lit передавать не рекомендуют. Для реакции на события есть @-поле, оно там отдельно оптимизировано (там используется объект { handleEvent }, который заведует подпиской на событие, и у которого просто заменяется функция, так что на слушателей shallow check не распространяется).

Обход по всем значениям это не круто

Это уже экономия на спичках. Цикл — одна из самых оптимизированных операций в JS, тем более тот, который не использует итераторы. Вряд ли вы будете создавать шаблон с миллионом значений, а с таким объёмом JS справляется за миллисекунды.

Вы в комментариях выше доказывали мне что частичный всегда, а оказалось нет… Опять же в реальной жизни легко сделать приложение которое будет тормозить с подходом 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. Зачастую это добавляется в самом начале, чтобы потом было не так больно переделывать. И оно есть почти всегда. Поэтому это довольно важная часть. К сожалению, сторонние библиотеки тут не помогут.

  • библиотека компонентов. Я видел несколько стандартных, но этого безумно мало.

Насчет форм согласен. Формошлепство важная сфера, нужно добавить какой-нибудь инструмент для этого) Я работал в проектах где ~90% функционала – это формы)

А чем другие не устроили, Vue например или Svelte? Svelte как по мне выигрывает у всех этих

Касательно Svelte, я его рассматривал. Но его синтаксис далек от обычного html (#if, #each, #key...). Одна из идей Cruzo – это дать возможность писать в привычной модели: HTML + немного JavaScript, с добавлением реактивности и контролируемого исполнения

Как опознать сгенерированную статью:

Без лишнего пафоса

Во времена нейрослопа можно на каждого пальцем показать и попробуй докажи потом что ты не верблюд... А до LLM как будто люди не использовали эту фразу?

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

Ну да, понимаю, о чём ты. Тут, наверное, просто кому как звучит.

Круто! но я бы добавлял кодстайл больше похожий на React, мб дело вкуса

О боже зачем???)))) Если есть реакт типизированный html. Представляю вашу боль)

А что за реакт типизированный html? JSX?

Ну да

JSX это не разметка, это код который генерирует разметку. Не задавались вопросом почему вместо class в JSX className? Еще один уровень абстракции, это и меня не устраивало

Не задавались вопросом почему вместо class в JSX className?

Потому что разрабам реакта было влом переименовать переменную. Все остальные фреймворки спокойно пользуются class и в ус не дуют, это только реакт такой особенный.

Потому что jsx это js, а там class зарезервированное слово

Так я не про js. А то что там можно использовать теги html внутри.

Мне он нравится за html типизацию, а не красивые глаза.

Это не так, иначе бы JSX не могли использовать другие фреймворки. А оно спокойно существует и в SolidJS, и в Stencil, и в Vue, кстати говоря (по крайней мере, можно было в той версии, с которой я знакомился). И если мне память не изменяет, из всех них только реакт использует className. И да, даже если вы в реакте напишете class, он не умрёт на этапе компиляции, а честно создаст объект с полем class.

Примеры:

https://react.dev/learn/writing-markup-with-jsx
Since class is a reserved word, in React you write className instead, named after the corresponding DOM property (Выдержка с официального сайта)
Далее
https://www.typescriptlang.org/docs/handbook/jsx.html
JSX is an embeddable XML-like syntax. It is meant to be transformed into valid JavaScript
Просто скажите что связи не видите, так проще всего... Это в какой-то мере снимает с вас ответственность за ваши слова

А я-то в кои-то веки думал цивилизованную дискуссию вести... Глупый, глупый я 😔

А всего-то стоило немного погуглить и найти пост Дэна Абрамова. Который TL;DR: "Мы подумали, что так будет лучше, а когда поняли, что не будет, было уже слишком геморно всё менять".

Учитесь гуглить, уважаемый.

JSX — это не HTML и не чистый JS, а синтаксический слой, который транспилируется в JavaScript что ли. Если люди работая с таким инструментарием это понимают, ничего против не имею, но кто-то постоянно пытается доказать обратное (я не про вас, таких людей очень много)

Sign up to leave a comment.

Articles