Comments 12
В статье не запрещено использовать подсветку синтаксиса, нормальное оформление абзацев. Честно, честно.
Такое чувство, что статью. верстал бэкендер:)
SSR и SSG при таком подходе будут поддерживаться?
И мне больше нравится вариант отрисовки компонентов через функции, как в Compose Multiplatform (в котором есть компиляция в js) или SwiftUI
Все это хорошо, но вы же понимаете, что HTML во Vue/React - не HTML в привычном виде. Эта разметка компилируется в JS, и вам вообще никто не мешает использовать чистый js, например:
Vue.component('anchored-heading', {
render: function (createElement) {
return createElement(
'h' + this.level, // имя тега
this.$slots.default // массив дочерних элементов
)
},
props: {
level: {
type: Number,
required: true
}
}
})И так везде. HTML - это просто синтаксический сахар, потому что это проще, удобнее и нагляднее.
Дело не в том, чтобы использовать чиcтый js. Второй подход позволяет абстрагироваться от HTML, от рендеринга и от всплывающих или опускающихся событий, связанных с HTMLElement-ом. Разработчик оперирует не HTML элементами, а элементами управления на форме.
Хотя, наверное, полностью абстрагироваться не удастся. Все равно, разработчик будет использовать css, да и в сложных формах трудно выверить все до пикселя.
При этом автор вообще ни слова не написал про механику парсинга представления
Второй подход очень похож на ext js. Который довольно печальный. Даже если убрать из внимания то, что он закрытый, очень многие жалуются на него. Именно на сам подход и архитектуру. Если приложение ложится на то, что фреймворк предлагает, то все хорошо. Но шаг в сторону и начинаются мучения.
И ели глянуть, то все популярные фреймворки исповедуют первый подход, и видимо не случайно.
Честно говоря, сравнение не самое привлекательное. Осталось много вопросов. А слоты. А сложносоставные события. А как вообще без референсов жить я вообще не понимаю. Про реактивность и стейт менеджмент не написано ничего.
Какой вообще может быть разговор о другом подходе если подход точно такой же. Те же самые компоненты, состояния и события. Просто инкапсулированы на порядок хуже чем у вью.
Да у вас в статье сабмит запрашивает пользовательские данные. Прочитайте что за бред вы в абзаце о формах написали. У меня этим утром на завтрак вместо кофе кровь из глаз, спасибо
Нашел сабмит, который запрашивает пользовательские данные - раздел 6.2 первый абзац.
Да, что касается форм авторы смешали понятия формы html и формы библиотеки. А они отличаются. Не знаю насколько это хорошо, но, как сказано, в библиотеке ui-organizer элементом формы может быть список, таблица, или любой другой элемент. Да, это не html форма.
Поправим, чтобы было понятней.
Что касается функционала, то не было задачи сравнить весь функционал, хотелось обсудить подходы. Да и библиотеки нельзя сравнивать, ui-organizer пока еще прототип.
Спасибо Вам за замечания.
GWT каким-то повеяло. А вообще как уже писали выше, проблемы с такими инструментами начинаются когда хочется сделать что-то сложнее формы с парой инпутов и таблицы с простым текстом.
на первом месте идет язык разметки - html, а javascript так и остался на подхвате
Это просто так кажется из-за
frontend framework предлагает свой, так называемый, декларативный язык
Это да, так во Vue, Angular, Svelte... Вам нужно попробовать React, там такого нет, мне тоже не нравятся все эти DSL и лишняя ментальная нагрузка с этим связанная
мы потеряем все то многообразие вариантов красочного и анимированного оформления
Совсем не обязательно его терять, CSS может жить своей своей жизнью в отдельном файле
ui-organizer не предназначен для создания компонентов
Похоже на JSX, только в виде объекта.
когда данные на странице, связаны с данными компонента
Хотел предложить другой подход, когда данные на странице <div>{() => count}</div> связаны с данными JavaScript let count = 0
Или же, если вы хотите чистый JavaScript, то так div(() => count), назвал функциональной нотацией
Оба подхода будут работать в https://github.com/fusorjs/dom
Спасибо за вашу разработку, пишите еще!
Два frontend фреймворка. Два подхода