HTMX? Фронтенд без js?

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

Если уж рассматривать технологии HTML без JS (на самом деле нет), то тот же LiveView смотрится интереснее (если не учитывать, что оно не может работать в оффлайне).

WebComponents

Как данные к этой хрени подключать? ngFor где?

man functional components

Компоненты на классах уже несколько лет никто не пишет.

Поделки класса «первые шаги электричества»

Так реакт не заставляет смешивать бизнес-логику и разметку. По-хорошему, бизнес-логику пишут не в самом компоненте, а где-то в другом месте (если хочется максимально изолировать, можно вообще взять redux, но можно и просто вынести бизнес-логику в отдельный файл). В самом функциональном компоненте только непосредственно логика отображения.

И от этого не уйти. В любой более-менее сложной разметке есть какая-то логика. Всякие forEach, ветвления (если таблица пустая, отрендерить «Нет элементов», иначе отрендерить строки, причём, например, строки одного типа должны быть красные, а строки другого типа - зелёные). Плюс разметка в React интерактивная, ибо можно назначать всякие обработчики событий и т. д.

ngFor это куски бизнес-логики в шаблонах и в html в котором этого овна быть не должно, если вам надо отрендерить выбираете элемент селектором и делаете в него insertAnjacentHTML в цикле своего жс кода или что там у вас

Когда на странице больше пары элементов, встаёт вопрос инкрементального обновления (потому что пересоздавать на каждый чих всю веб-страницу очень дорого). Вручную задолбаешься зависимости отслеживать, какие части страницы должны обновиться при изменении состояния. А React по сути и берёт на себя этот расчёт дельты и обновление DOM.

Так реакт не заставляет смешивать бизнес-логику и разметку

заставляет, то что вы называете там разметкой это фактически бизнес-логика c захардкоженой разметкой

можно вообще взять redux

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

Плюс разметка в React интерактивная

ну это сложно было сделать во времена жквери, но сейчас можно обойтись тем что предоставляют стандарты HTML/WebComponents безо всяких фреймворков. Фреймворки или библиотеки тут имеют смысл если они сделаны поверх стандартов веб-компонентов, а иначе это кривые, беспонтовые, полные антипаттернов и шизы, велосипеды

если вам надо отрендерить выбираете элемент селектором и делаете в него insertAnjacentHTML в цикле своего жс кода или что там у вас

И получается нечитаемая, неподдерживаемая лапша кроме за исключением совсем уж миниатюрных приложений.

Отрендери список таких элементов.

Если список пустой, должна быть надпись «Список пуст». Также у каждого элемента name или color опциональные поля и не должно быть пустого тега в случае отсутствия значения.

Бонусное задание: сделать каждый третий элемент жирным.

А когда ты это сделаешь, чем это принципиально отличается от React, кроме необходимости учить ещё один язык разметки (всякие forEach, if и т. д.).

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

нечитаемая лапша это восновном про «архитектуры» на рякте, там все файлы называются одинаково, нет классов и следовательно контрактов и наследования, зато полно фимозов обслуживающих самое себя. Если у вас есть компонентная модель, модули и шаблоны в HTML/JS, что мешает сделать нормально?

Ничто не мешает обернуть input в отдельные компоненты и в свою форму встраивать уже их, а не голые input. Соответственно, они уже будут стилизованы как надо, иметь общее кастомное поведение и т. д.

Также для всех популярных CSS фреймворков типа Bootstrap/Semantic UI/Material UI/etc есть React обвязки и ты вставляешь не голые div, а всякие Navbar, Container, Card и т. д. А там уже внутри заданы нужные стили/классы.

Ну и стили элементов отделять от кода научились ещё со времён царя гороха. Описываешь классы в css файле, а в HTML/React пишешь только class=«my-cool-control». Возможность насовать inline стили есть не только в React, но и в самом HTML. Но нормальные люди знают, что в 99% случаев этим не надо пользоваться (а 1% случаев, где стиль создаётся на лету типа color picker, которому нужно показывать выбранный юзером цвет, а не заданный дизайнером).

заставляет, то что вы называете там разметкой это фактически бизнес-логика c захардкоженой разметкой

Смотря как писать. Если прям из компонента делать AJAX запросы, конечно, да.

А если в функции компонента писать только логику связанную непосредственно с отображением (ну вот как раз всякие вещи типа «если список пуст, отобразить надпись об этом, иначе отобразить список»), то тогда нет.

Бизнес-логика или не бизнес-логика определяется не тем на каком языке она написана, а с чем она работает.

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

Ну вот для этого и сделали React. Зачем изобретать свой аналог React, когда можно взять готовый. Если React кажется слишком тяжёлым, есть preact весящий 3 КБ в минифицированном виде. Свой велосипед вряд ли будет принципиально лучше.

но сейчас можно обойтись тем что предоставляют стандарты HTML/WebComponents безо всяких фреймворков

Цена этого - написание собственного велосипеда для лапши из кода и разметки.

Фронтенд без JS называется HTML. Это древнее искусство было давно утеряно, вместо этого теперь плодят пердяще-тормозящий JS.

Нет

заставляет, то что вы называете там разметкой это фактически бизнес-логика c захардкоженой разметкой

Во времена только появления реакта одним из шаблонов разработки на нём был - использование компонент-контейнер и внутри него компонент-«вьюха». Первые только с логикой, вторые только с разметкой.

Потом, с появлением хуков и функциональных компонент это всё сместилось к требованию «чистых» компонент, в которых сайд-эффекты распиханы по обработчикам, формально являясь частью компонента не влияют не рендеринг и в хуках типа useEffect.

Использование GUI, аппаратного ускорения, высокоуровневых языков – это тоже тренд.

{% for option in options %}
  <p>{{ option }}</p>
{% endfor %}

Это принципиально отличается тем что ты в результате получаешь нормальный проект, а не свалку из говна и говнища, которые проще переписать чем поддерживать.

Как нормально делать шаблоны придумали уже давно и ничего лучше пока не придумали.
Потуги быть нитакими потому что выучить один яваскрипт проще чем несколько языков и синтаксисов — от полнейшей технической безграмотности.

А не смущает, что это не frontend без JS, а просто DSL в рилтайме?

А если серьезно, то чем так не угодил JS для frontend приложений в web? Если все правильно готовить и не писать лютый говнокод - все в целом нормально

Не нужно. React это венец творения.

Так толсто, что даже тонко.

Бог создал человека, чтобы человек создал React.

Для этого человека мог создать только сотона)

Ничего лучше уже не придумать.

Поэтому авторы React назвали его говном и сделали Svelte

заставляет, то что вы называете там разметкой это фактически бизнес-логика c захардкоженой разметкой

А приведите пример такого компонента, к примеру в каком-нибудь open source проекте? Это правда, что тесная связь с JS позволяет добавить в компонент какую угодно логику. Но если кто-то пишет подобный код, то проблема на его стороне.

сейчас можно обойтись тем что предоставляют стандарты HTML/WebComponents безо всяких фреймворков

Можно - не значит нужно. Люди пишут на том, что им хорошо знакомо, и на чём они могут быстро и без труда решить поставленную задачу. За фанатизм денег не платят.

JSP это ровно такая же генерация строк..

Я вас удивлю. ВЕСЬ frontend в целом - это просто генерация встрок и вкорячивание их в DOM. Если посмотреть на задачу с достаточно высокого уровня абстракции. В том числе и React

Текстовых шаблонизаторов по 10 штук для каждого языка, а где и больше.

И что? Вы только подтвердили тезис комрада.

Там действительно ничего ничего интересного.

Как и в любом шаблонизаторе.

Суть React в том, что он генерирует дерево, а не текст.

React генерит дерево чего?) Подскажу - VDOM лишь проекция DOM, а DOM есть проекция того, что болтается в памяти и в какой-то мере является текстом (как и любой файл, например).

И при этом псевдо-XML встроен в язык, максимально органично.

Вкусовщина. React мало того, что смешивает V, M и C, так еще и считает это нормой. Обычно за такую органичность бьют лопатой и не по спине. В привычном обществе.

Это во-первых даёт тебе «шаблон» в языке,

Что является во всех приличных домах worse practice. Нормальные люди давно осознали, что шаблонизатор должен быть logicless, а не как React.

тебе не надо учить все эти <c:forEach, если ты уже знаешь, как работает forEach в стандартной библиотеке.

Кошмар. Это такая большая цена за то, что шаблон останется шаблоном, а не наполненным логикой нейпойми чем.

Во-вторых даёт тебе проверку синтаксиса до запуска.

Возьмем Handlebars, Vue, Glimer, ставим обесы на VSCode. Ставим модули на NPM. Получаем то же самое.

В JSP ты можешь писать что угодно.

В render для React тоже. И?

Если у тебя IDE умная, может и подсветит.

React тоже не подсветит «глупая» IDE.

В итоге будешь в браузере искать, где у тебя там тег не закрыт.

Если такие ошибки возникают - вопрос в профпригодности. Возможно гуманитарный склад ума и в ИТ делать нечего.

Да кстати, как насчет традиционного вопроса: кто из агитирующих здесь за Реакт на самом деле на нем пишет? По работе и за деньги?

Я за реакт не агитирую, я использую его время от времени - обычно mvp, потому что я по бэку, но пару разу было и требование от заказчика.

Ага, первый пошел . vbr полагаю тоже использует на уровне mvp?

Без претензий, просто подтверждается теория «любим и знаем то что реально не используем».

Без претензий

Да как, так-то, написал, что использую, как можно было иначе понять. Я не фронтендер, но если предлагают, то не отказываюсь, поэтому и время от времени.

написал, что использую

Используешь да, но «временами».

Это не тоже самое что ваять на Реакте большой проект будучи фронтэнд-девелопером, не 10 рабочих часов в день в течение 3-5 лет подряд.

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

Интересное наблюдение, вообщем.

что используют десяти-часовые фронтендеры?

Да, они обожают свой инструмент, фанатеют от него, всячески защищают от притязаний. Но при этом толком не используют.

обожают

фанатеют

всячески защищают

Ты сейчас про кого, про меня? Если так, то что-то у тебя перепуталось.

Реакт мной был выбран для заполнения пробела в разработке клиентской части сознательно, при определённых условиях и я им пользуюсь, пока он меня устраивает. И я считаю его нормальным вариантом для веб-разработки.

Как тут можно высмотреть обожание и фанатизм?

А где в этом треде прям фанатская защита?
Были какие-то очень странные нападки, на которые дали вполне адекватные ответы.

Дело не в конкретном инструменте а в длительности использования.

Если тебя заставить осмысленно стучать молотком по 10 часов в день то получится опытный плотник.

Но от молотка будет тошнить.

Чем это принципиально лучше, чем это?

const MyComponent({options}) => (<ul>
    {options.map(option => 
        <li>{option}</li>
    )}
</ul>);

Зато можно всякие усложнённые требования делать типа моего примера с каждым третьим элементом с особым стилем (или каждым десятым), потому что тебе доступен индекс и условия по нему.

Принципиально

Так почему ж тогда 99% код на реакте - фимоз головного мозга? Может потому, что писать разделяя логику и разметку там архисложно?

Вы не поняли. Я не предлагаю хтмл-макакам переходить на что-то другое. Я говорю про то, что все это реакты/ангуляры/флафферы смешивают html/css/js прямо внутри кода. Ни один фреймворк не предлагает - вот тебе лейаут разметки, вот тебе контент, вот тебе типы контролов, вот тебе стили контролов и их поведение. Нажми на кнопку, получишь страницу.

Но нет, во всех вышеперечисленных надо руками дивы создавать

лет 7-10 (может поболее того) был некоторый движ - вываливаем в броузер семантические страницы на xml, броузер xsl-stylesheet варит из них xhtml c semantic-web, дальше css задаёт стили, js подправляет dom и обеспечивает интерактив..

Красиво звучит, всё разделено; но hello-word резко пучится объёмом, а как устроены чуть более сложные страницы могут понять не только лишь все :-)

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

js подправляет dom и обеспечивает интерактив

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

А что делать с реально сложными интерфейсами,

Скажу неожиданное: не надо делать «реально сложные интерфейсы».

Для того чтобы пилот самолета мог быстро оценивать состояние по приборной доске, где куча всяких индикаторов и мигающих лампочек - его годами натаскивают и тренируют.

Ожидать что простой пользователь «разберется», выкатывая интерфейс в стиле приборной панели самолета это зло, это плохо.

В результате такого подхода, заказ билета на самолет и бронь в гостинице - неподъемная задача для например людей старше 70ти. И не надо рассказывать что «дедам и бабкам» место лишь на кладбище, куда самолеты не летают.

В чем проблема поставлять в систему контент на условном JSON, декларативно объявить в нормальном виде цвета и контролы отдельно и просто сгенерировать страницу на основе данных?

«Удаление гланд через жопу автогеном. Там, где достаточно простого промывания.» (c) Вы на пару с Syncro даже не понимаете, что в итоге делаете ровно то же самое – смешиваете разметку с кодом, только на порядок более заумным способом.

Чтобы программисту вообще было насрать, в чем будет выхлоп - хоть html, хоть латех, хоть майкросовт паур поинт.

А стоит такая задача, чтобы программисту было насрать? Или мы всё ещё рисуем «HTMX? Фронтенд без js»? Впрочем, программисту насрать в любом случае не будет: за дико переусложнённый код придётся платить.

А правильно не смешивать.

«Мышки, станьте ёжиками! - А как? - Моё дело стратегия.»

Не смешивать код и разметку можно только в одном случае: если мы отдаём статические странички, в которых есть только разметка, но вообще нет кода.

Into the trash it goes. React FTW.

4.2

В мире был один шанс сделать альтернативу React - это Scala с её XML-литералами. Но академики увлеклись моноидами и не разглядели за ними жемчужины.

ЕМНИП все кому надо было – разглядели. И академиков заваливали баг-репортами про эту подсистему. Но в конечном счёте, при всей своей красоте, она была ДИКО неэффективной: XML-литерал при компиляции превращался в конструирование DOM. На кой ляд мне конструировать DOM, чтобы тут же его сериализовать взад в строку?! Помнится, я даже пробовал запилить макрос, чтобы превращал XML-литерал в нормальную сериализацию строк вперемешку с выражениями; но что-то там было не гладко.

Пффф. Моё кун-фу круче: в игнор. :)

Кто что думает о новой революционной технологии?

Использую, в некоторых ситуациях удобная штука

Фронтенд теперь без js

Так эта штука на js. Другое дело что js приходится писать меньше. Ещё в этом плане alpine.js помогает. В простых ситуациях может заменить vue, но скрипты писать не нужно

пока первый коммент по делу