шаблонизатор с плейсхолдерами это явление из времен докомпонентного фронтенда и поэтому оно построено на тех примитивных методах и идиомах, что надо в хтмл затаскивать разные костыли
Если уж рассматривать технологии HTML без JS (на самом деле нет), то тот же LiveView смотрится интереснее (если не учитывать, что оно не может работать в оффлайне).
Так реакт не заставляет смешивать бизнес-логику и разметку. По-хорошему, бизнес-логику пишут не в самом компоненте, а где-то в другом месте (если хочется максимально изолировать, можно вообще взять redux, но можно и просто вынести бизнес-логику в отдельный файл). В самом функциональном компоненте только непосредственно логика отображения.
И от этого не уйти. В любой более-менее сложной разметке есть какая-то логика. Всякие forEach, ветвления (если таблица пустая, отрендерить «Нет элементов», иначе отрендерить строки, причём, например, строки одного типа должны быть красные, а строки другого типа - зелёные). Плюс разметка в React интерактивная, ибо можно назначать всякие обработчики событий и т. д.
ngFor это куски бизнес-логики в шаблонах и в html в котором этого овна быть не должно, если вам надо отрендерить выбираете элемент селектором и делаете в него insertAnjacentHTML в цикле своего жс кода или что там у вас
Когда на странице больше пары элементов, встаёт вопрос инкрементального обновления (потому что пересоздавать на каждый чих всю веб-страницу очень дорого). Вручную задолбаешься зависимости отслеживать, какие части страницы должны обновиться при изменении состояния. А React по сути и берёт на себя этот расчёт дельты и обновление DOM.
Так реакт не заставляет смешивать бизнес-логику и разметку
заставляет, то что вы называете там разметкой это фактически бизнес-логика c захардкоженой разметкой
можно вообще взять redux
не стоит, он нахлобучивает бестолковые говнокоды и течет, вобщем создает больше проблем чем решает как обычно в рякте
Плюс разметка в React интерактивная
ну это сложно было сделать во времена жквери, но сейчас можно обойтись тем что предоставляют стандарты HTML/WebComponents безо всяких фреймворков. Фреймворки или библиотеки тут имеют смысл если они сделаны поверх стандартов веб-компонентов, а иначе это кривые, беспонтовые, полные антипаттернов и шизы, велосипеды
Если список пустой, должна быть надпись «Список пуст». Также у каждого элемента 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 КБ в минифицированном виде. Свой велосипед вряд ли будет принципиально лучше.
заставляет, то что вы называете там разметкой это фактически бизнес-логика c захардкоженой разметкой
Во времена только появления реакта одним из шаблонов разработки на нём был - использование компонент-контейнер и внутри него компонент-«вьюха». Первые только с логикой, вторые только с разметкой.
Потом, с появлением хуков и функциональных компонент это всё сместилось к требованию «чистых» компонент, в которых сайд-эффекты распиханы по обработчикам, формально являясь частью компонента не влияют не рендеринг и в хуках типа useEffect.
{% for option in options %}
<p>{{ option }}</p>
{% endfor %}
Это принципиально отличается тем что ты в результате получаешь нормальный проект, а не свалку из говна и говнища, которые проще переписать чем поддерживать.
Как нормально делать шаблоны придумали уже давно и ничего лучше пока не придумали.
Потуги быть нитакими потому что выучить один яваскрипт проще чем несколько языков и синтаксисов — от полнейшей технической безграмотности.
заставляет, то что вы называете там разметкой это фактически бизнес-логика c захардкоженой разметкой
А приведите пример такого компонента, к примеру в каком-нибудь open source проекте? Это правда, что тесная связь с JS позволяет добавить в компонент какую угодно логику. Но если кто-то пишет подобный код, то проблема на его стороне.
сейчас можно обойтись тем что предоставляют стандарты HTML/WebComponents безо всяких фреймворков
Можно - не значит нужно. Люди пишут на том, что им хорошо знакомо, и на чём они могут быстро и без труда решить поставленную задачу. За фанатизм денег не платят.
Я вас удивлю. ВЕСЬ 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.
В итоге будешь в браузере искать, где у тебя там тег не
закрыт.
Если такие ошибки возникают - вопрос в профпригодности. Возможно гуманитарный склад ума и в ИТ делать нечего.
Да как, так-то, написал, что использую, как можно было иначе понять. Я не фронтендер, но если предлагают, то не отказываюсь, поэтому и время от времени.
Это не тоже самое что ваять на Реакте большой проект будучи фронтэнд-девелопером, не 10 рабочих часов в день в течение 3-5 лет подряд.
Просто это третий тред за неделю, где сторону фанатской защиты выбирают скажем так любители. Да, они обожают свой инструмент, фанатеют от него, всячески защищают от притязаний. Но при этом толком не используют.
Да, они обожают свой инструмент, фанатеют от него, всячески защищают от притязаний. Но при этом толком не используют.
обожают
фанатеют
всячески защищают
Ты сейчас про кого, про меня? Если так, то что-то у тебя перепуталось.
Реакт мной был выбран для заполнения пробела в разработке клиентской части сознательно, при определённых условиях и я им пользуюсь, пока он меня устраивает. И я считаю его нормальным вариантом для веб-разработки.
Зато можно всякие усложнённые требования делать типа моего примера с каждым третьим элементом с особым стилем (или каждым десятым), потому что тебе доступен индекс и условия по нему.
Вы не поняли. Я не предлагаю хтмл-макакам переходить на что-то другое. Я говорю про то, что все это реакты/ангуляры/флафферы смешивают html/css/js прямо внутри кода. Ни один фреймворк не предлагает - вот тебе лейаут разметки, вот тебе контент, вот тебе типы контролов, вот тебе стили контролов и их поведение. Нажми на кнопку, получишь страницу.
Но нет, во всех вышеперечисленных надо руками дивы создавать
лет 7-10 (может поболее того) был некоторый движ - вываливаем в броузер семантические страницы на xml, броузер xsl-stylesheet варит из них xhtml c semantic-web, дальше css задаёт стили, js подправляет dom и обеспечивает интерактив..
Красиво звучит, всё разделено; но hello-word резко пучится объёмом, а как устроены чуть более сложные страницы могут понять не только лишь все :-)
Есть видимо дифферциальная сложность - предел, если делить ниже него, то сложность резко растёт вверх, хотя по всем теориям должно наступить вселенское блаженство
А что делать с реально сложными интерфейсами, где нужно полстраницы ререндерить в зависимости от действий пользователя и запросов к бэку, да еще и делать это быстро? Все равно придется что-то вроде реакта переизобретать.
Скажу неожиданное: не надо делать «реально сложные интерфейсы».
Для того чтобы пилот самолета мог быстро оценивать состояние по приборной доске, где куча всяких индикаторов и мигающих лампочек - его годами натаскивают и тренируют.
Ожидать что простой пользователь «разберется», выкатывая интерфейс в стиле приборной панели самолета это зло, это плохо.
В результате такого подхода, заказ билета на самолет и бронь в гостинице - неподъемная задача для например людей старше 70ти. И не надо рассказывать что «дедам и бабкам» место лишь на кладбище, куда самолеты не летают.
В чем проблема поставлять в систему контент на условном JSON, декларативно объявить в нормальном виде цвета и контролы отдельно и просто сгенерировать страницу на основе данных?
«Удаление гланд через жопу автогеном. Там, где достаточно простого промывания.» (c) Вы на пару с Syncro даже не понимаете, что в итоге делаете ровно то же самое – смешиваете разметку с кодом, только на порядок более заумным способом.
Чтобы программисту вообще было насрать, в чем будет выхлоп - хоть html, хоть латех, хоть майкросовт паур поинт.
А стоит такая задача, чтобы программисту было насрать? Или мы всё ещё рисуем «HTMX? Фронтенд без js»? Впрочем, программисту насрать в любом случае не будет: за дико переусложнённый код придётся платить.
В мире был один шанс сделать альтернативу React - это Scala с её XML-литералами. Но академики увлеклись моноидами и не разглядели за ними жемчужины.
ЕМНИП все кому надо было – разглядели. И академиков заваливали баг-репортами про эту подсистему. Но в конечном счёте, при всей своей красоте, она была ДИКО неэффективной: XML-литерал при компиляции превращался в конструирование DOM. На кой ляд мне конструировать DOM, чтобы тут же его сериализовать взад в строку?! Помнится, я даже пробовал запилить макрос, чтобы превращал XML-литерал в нормальную сериализацию строк вперемешку с выражениями; но что-то там было не гладко.
Так эта штука на js. Другое дело что js приходится писать меньше. Ещё в этом плане alpine.js помогает. В простых ситуациях может заменить vue, но скрипты писать не нужно