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

React это венец творения

Если реакт это венец творения то я - вестник апокалипсиса.

Советую присмотреться к тому, как генерить HTML на стороне сервера с помощью React

И можно с удивлением обнаружить обычный статичный шаблонизатор времен PHP 3.X

Реакт это терновый венец творения.

Советую присмотреться к тому, как генерить HTML на стороне сервера с помощью React

И можно с удивлением обнаружить обычный статичный шаблонизатор времен PHP 3.X

У PHP не было проверки выдаваемых шаблонов, включая даже проверку типов (если использовать TypeScript) во время компиляции (да там даже самой компиляции не было). Ты путаешь AST и тупую строку. Это две большие разницы.

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

Реакт это терновый венец творения.

Напомню непричастным как выглядит код на реакте:

class Cat extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      humor: 'happy'
    }
  }
  render() {
    return(
      <div>
        <h1>{this.props.name}</h1>
        <p>
          {this.props.color}
        </p>
      </div>
    );
  }
}

Чтобы примерно понимали о чем речь. Остальные присутствующие тоже считают что тут все хорошо и это «венец творения»?

Ты что-то не то написал. Это из 90-х что-то? Сейчас так пишут:

function Cat({name, color}) {
  return (
    <div>
      <h1>{name}</h1>
      <p>{color}</p>
    </div>
  );
}

У PHP не было проверки выдаваемых шаблонов, включая даже проверку типов (если использовать TypeScript) во время компиляции (да там даже самой компиляции не было).

Хорошо, возьми более новую джаву или шарп - JSP/ASP делают такую же «генерацию HTML» на сервере.

Только это не подается как революция и венец творения.

Проблема с реактом в том что в нем слишком много маркетинга, один из примеров - тот же SSR (Server Side Rendering) который подается как «революция» для поколения фронтэндеров, никогда не писавших никакого бекэнда.

Еще есть люди, серьезно полагающие что бекэнд это только REST.

И что тут все хорошо? Синтаксис не смущает?

Ты отстал лет на 5.

Хуки и функциональные компоненты уже давно заменили компоненты-классы.

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

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

Приведи свой пример максимально корректного кода на реакте тогда.

Приведи свой пример

Выше vbr показал функциональный компонент.

Хорошо, возьми более новую джаву или шарп - JSP/ASP делают такую же «генерацию HTML» на сервере.

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

Только это не подается как революция и венец творения.

Текстовых шаблонизаторов по 10 штук для каждого языка, а где и больше. Там действительно ничего ничего интересного. Суть React в том, что он генерирует дерево, а не текст. И при этом псевдо-XML встроен в язык, максимально органично. Это во-первых даёт тебе «шаблон» в языке, тебе не надо учить все эти <c:forEach, если ты уже знаешь, как работает forEach в стандартной библиотеке. Во-вторых даёт тебе проверку синтаксиса до запуска. В JSP ты можешь писать что угодно. Если у тебя IDE умная, может и подсветит. А может и нет. В итоге будешь в браузере искать, где у тебя там тег не закрыт.

Проблема с реактом в том что в нем слишком много маркетинга, один из примеров - тот же SSR (Server Side Rendering) который подается как «революция» для поколения фронтэндеров, никогда не писавших никакого бекэнда.

Маркетинг не может быть проблемой.

Еще есть люди, серьезно полагающие что бекэнд это только REST.

Ну есть и есть.

Я не проверял, может где опечатался, но вроде всё правильно.

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

Где про это почитать?

И что тут все хорошо? Синтаксис не смущает?

Как будто бы есть способ лучше, чтобы объединить код и разметку. А если, мы говорим о js, то этого (смешивать код и разметку) в принципе не избежать.

На странице проекта, не зря убрали официальную поддрежку create-react-app.

Ага, вижу, спасибо.

https://react.dev/learn/start-a-new-react-project

If you want to build a new app or a new website fully with React, we recommend picking one of the React-powered frameworks popular in the community. Frameworks provide features that most apps and sites eventually need, including routing, data fetching, and generating HTML.

Но, хорошо, что есть https://vitejs.dev/

забыли

import react from 'http://..react-cdn-package..'; 

ну и листинг всего того что оно отдает

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

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

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

А как правильно? Может поменять слагаемые местами и смешивать разметку с кодом?

Все это делают, в той или иной мере, и не только в веб. Взять flutter, что от декларативного описания интерфейса код стал сильно приятнее? Нет, та же самая свалка из вложенных компонентов и скобочек-скобочек-скобочек. Хотя, о чём это я, флаттер же вдохновлялся реактом! ))

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

правильно не смешивать, т.к. иначе получается трудноподдерживаемые авгиевы конюшни по мере развития. Есть шаблоны native templates - в них должен быть html, есть компоненты custom elements - в них бизнес-логика еще конечно стили в css. И вобщем-то никак иначе делать не стоит.

Есть способ лучше, и он уже не первое десятилетие как есть.
Выглядит примерно вот так:

<div>
  <h1>{{ name }}</h1>
  <p>{{ color }}</p>
</div>

А правильно не смешивать.
Смешивают только рукожопые.
Флуттер — тоже от рукожопых для рукожопых.

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

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

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

UPD: ещё своё сетевое оборудование надо будет выпустить и свои протоколы придумать и организовать свой хипстернет.

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

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

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

Нет

это разделение и компонентная модель уже есть в стандартах WebComponents и популярные колхоз-фреймворки в связи с этим стали устаревшими

Для этого надо взять CMS и переименоваться из программиста в клавиатурную обезъяну.

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

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 безо всяких фреймворков

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

Нет

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

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

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

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

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

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

заставляет, то что вы называете там разметкой это фактически бизнес-логика 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»? Впрочем, программисту насрать в любом случае не будет: за дико переусложнённый код придётся платить.

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

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

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

4.2

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

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

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

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

Ну то есть половина супер-популярных продуктов гугла сразу не нужны, все эти gmail, calendar итд? И с которыми у пользователей из ца нет никаких проблем?

А где в почтовике есть сложность? Если там нафиговертили сложность - то это они недалекие.

Надо две панели - список и текущее открытое. Наверху кнопки управления, каждая с одной простой функцией.

Да там страница настройек уже куда сложнее, чем то что ты описал.
Прибавь wysiwyg-редактор, поиск, категории, контакты, все это с drag'n'drop и прочими свистелками.

Вот уж у гугла эталонно дерьмовые интерфейсы

Абсолютно любая страница настроек должна выглядеть как группированные списки со следующим элементом: Caption - Active Control (drop down list, checkbox, input field). Все эти элементы есть по дефолту. Если кто-то пытается впихнуть в настройки что-то еще - это вые***ны.

А потом мы связываем простой интерфейс на реакцию настроек и…

Это должно быть описано в бизнес логике, которая никак не должна быть завязана на конкретную реализацию результата - никаких div/p/class = там быть не должно.

А как это описать языком разметки? Где мне схоронить состояние?

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

Круто. Вот тебе страница. А вот там интересный кусочек, реле. И вот кусочек поймал некое событие. Он (наверное) радостно послал POST запрос серверу, что дальше? Мы вклеиваем в DOM новую инфу? Или перегружаем из-за кусочка весь, в данном случае, интерфейс? А если вклеиваем, то чем? Языком разметки?

почитай про htmx

То что вы говорите называется AJAX. Страница должна быть поделена на динамические виджеты, которые сервер может рендерить отдельно. И снова программист не лезет в div-руками. Он получил POST, поменял стейт лампочки. AJAX на странице спросил у сервера новое состояние виджета. Сервер сгенерировал виджет.

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

Еще раз - у нас есть (пусть будет JSON, насрать на самом деле):

Контент:

{
    "title" : "Relay #24",
    "content" : {
        "relay34" : "off",
        "relay35" : "on",
        "relay36" : "off",
        "relay37" : "on"
    }
}

Разметка:

{
    "layout" : {
        "type" : "horizontal",
        "sections" : 1,
        "content" : {
            "layout" : {
                "type" : "matrix",
                "sections" : 4,
                "content" : {
                    "relay34" : "ajaxtext",
                    "relay35" : "ajaxtext",
                    "relay36" : "ajaxtext",
                    "relay37" : "ajaxtext"
                }
            }
        }
    }
}

Экшены:

{
    "ajaxtext" : {
        "type" : "ajax",
        "period" : 5,
        "method" : "POST",
        "uri"    : "/actions/relayupdate",
        "params" : [
             "name"
        ]
    }
}

Стили : <..лень писать..>

Всё, сожмите это в кучу, получить матрицу из 4 элементов, каждый отображает on/off состояние реле. Раз в 5 секунд каждый виджет сам спрашивает у сервера своё состояние и перезаписывает блок.

Сервер по POST /actions/relayupdate?name=relay34 рендерит конкретный виджет, содержащий on/off - получая на вход мини версию того, что я написал выше.

Всё, это максимально абстрагированно от платформы. Хоть десктопное приложение рендери, хоть страницу html, хоть в консоль

Пока ты исполнитель, что требует заказчик, то и делаешь.

Если свой проект, то сам хозяин барин, пока не захочешь показать миру. Показал - лови обратную связь ;)

javascript fatigue:
longing for a hypertext
already in hand 

Да, годно. Буду читать дальше.

То что вы говорите называется AJAX.

А тут надо читать их чёрную-чёрную книгу. Потому, как без JS это сейчас на языке разметки не сделать.

Вы сообщение через строчку читаете или как? Сервер, который сожрал декларативные данные сгенерировал всё это в том виде, в котором это сожрет браузер - html, css, js. Потому что никто не будет переписывать этих монстров на что-то годное. Суть посыла в том, чтобы программист вообще не касался того, что срендерится в итоге. Ни div, ни js. Потому что что DOM, что JS - всё параша, по недоразумению ставшая стандартом.

Я тут как раз дочитываю, ну да ладно. Пацаны предлагают простое делать просто. И это хорошо.

Почитал, что-то как-то не вызывает.

Суть посыла в том, чтобы программист вообще не касался того, что срендерится в итоге. Ни div, ни js. Потому что что DOM, что JS - всё параша, по недоразумению ставшая стандартом.

Сразу вопрос, а что не параша? Вот у тебя есть соединение и программа, которая установлен у всех (браузер). Что можно предложить? Абстрактно = устройство, программа (браузер), канал связи. Выводи что и как хочешь.

Программа понимает даже набор разных устройств.

Пацаны говорят о важных щах дальше, да, рак, да, надо что-то делать. Но пока их решения хитрят «простотой» и своим раком

Browsers aren’t the only hypermedia clients out there, however. In the last section of this book we will look at Hyperview, a mobile-oriented hypermedia. One of the outstanding features of Hyperview is that it doesn’t simply provide a hypermedia, HXML, but also provides a working hypermedia client for that hypermedia. This makes building a proper Hypermedia-Driven Application with Hyperview extremely easy.

Что-то тут мне поплохело.

Ну то есть половина супер-популярных продуктов гугла сразу не нужны

Все не так просто.

Есть культурный код и проистекающие из него паттерны использования. До недавнего времени (и наверное до сих пор, но не уверен) если стояла задача сделать софт «для всех» - его надо было создавать строго под англоязычную аудиторию.

Проблема только в том что такое «усреднение» для всех конечных пользователей в чем-то но неудобно.

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

На столь старой штуке как почта это не так видно, но например в Инстаграме и Тик-Токе это проявляется в полный рост.

Да там страница настройек уже куда сложнее, чем то что ты описал.

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

Есть использование а есть «настройка», в случае «домашнего» софта для широкой аудитории, настройка не должна бросаться в глаза вообще и иметь явное предупреждение о последствиях.

Типа такого:

WARNING: EXPERIMENTAL FEATURES AHEAD! By enabling these features, you could lose browser data or compromise your security or privacy. Enabled features apply to all users of this browser. If you are an enterprise admin you should not be using these flags in production.

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

Еще разработчикам это трудно объяснить, но пользователи с трудом понимают саму концепцию файла или каталога, могут не знать что такое путь и расширение файла.

Вот пример из моей долгой жизни:

ООочень многие секретари-референты не ассоциируют PDF документ и расширение .pdf, тем более что современные ОС это любят скрывать. И как только вы вводите в программе настройку «фильтр расширений» - немедленно получаете вал вопросов в техподдержку «все пропало», «куда делись файлы» и «ничего не работает».

Понимаю что вопрос плевый и ответ тривиальный, но представьте что вам нужно ответить на него пару тысяч раз за сутки, еще и на разных языках. А не отвечать нельзя - будет refund (возврат средств), если у вас тысяча человек сразу попросит вернуть свои $50 то вы попадете на $50к и непростой разговор с банком.

vbr полагаю тоже использует на уровне mvp?

Я эникейфуллстак разработчик и реакт это один из моих инструментов. Я на нём и мобильные приложения (native) писал и несколько традиционных фронтэндов. Сейчас эмбеддед устройство с интерфейсом на реакте потихоньку попиливаю. Прекрасная технология. При этом у меня был опыт и на ангуляре и почти на всех популярных GUI-фрейморках, сравнить есть с чем. Правильно настроенная среда разработки на реакте это максимальная производительность разработчика. Это просто кайф.

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

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

И вы будете утверждать что не поехали там кукухой в своём вебе?

То есть надо использовать фреймверки, который будет компилировать я в код на другом фреймверки (реакте), который будет компилировать я в код на JS, который уже будет выполняться браузер ом?

Это - рекомендация разработчиков? Да это ж просто праздник какой-то

Маркетинг не может быть проблемой.

Это победа

популярные колхоз-фреймворки в связи с этим стали устаревшими

Как часто в мире js фрейверков что-то устаревает?

Я серьёзно, как вообще можно работать, если технология устаревает за 15 минут?

React выпустили 10 лет назад, какие 15 минут.

а когда начали говорить что он устарел?

Ты ж вот только что парню тыкал, что так как он делает, уже не делают, а делать надо вот так-то. Получается, реакт устаревает и внутри себя?

а когда начали говорить что он устарел?

Не знаю, я никогда не говорил, что он устарел.

Ты ж вот только что парню тыкал, что так как он делает, уже не делают, а делать надо вот так-то. Получается, реакт устаревает и внутри себя?

Ну естественно апи меняется, как в любой библиотеке. Старый подход в реакте работает и поддерживается, но - да, сейчас принято использовать функциональные компоненты. С какой-то точки зрения можно сказать, что старый подход реакта устарел.

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

Но это же здорово. Постоянно есть что переписывать.

Ну я не знаю :) это – вопрос дискуссионный

Ты бы видел чё на ютубе стало. Там щас окно с видео сбоку с закруглёнными углами=)))
Ска в квадратном!!! в прямоугольном!!! в мониторе с ПРЯМЫМИ МАТЬ ЕГО УГЛАМИ они делают элемент с закруглёнными краями. Это же не шарик посредине картины. Так бы и дал в харю тому дегенерату кто эту срань подхватил.

Недавно кстати открыл приложение megasync и там у края экрана углы закруглённые) лол кек чебурек

Я на нём и мобильные приложения (native) писал и несколько традиционных фронтэндов. Сейчас эмбеддед устройство с интерфейсом на реакте потихоньку попиливаю.

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

Поэтому еще раз: миниум три года непрерывной разработки на твоем Реакте. Большой проект, где ты не единственный фронтэндер.

Есть такой опыт?

Не твои личные домашние проекты, сделанные в свободное время а полноценная длительная работа.

Это - рекомендация разработчиков? Да это ж просто праздник какой-то

Реакт - не фреймворк.

К примеру, если вас не смущает, что FastAPI в основе своей использует Starlette, то откуда тогда такая реакция?

Надеюсь, что на питоно-примере понятна разница между фреймворком и библиотекой?

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

Да лор как бы не выглядит местом, где основная масса народу фанатеет и зинмается фронтендом в принципе, если присмотреться к обсуждаемым техническим топикам. Какая выборка, такие и результаты.

Первый тред был про Rust, второй про NixOS если что.

Но это не только на ЛОРе так.

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

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

Какие сейчас аргументы помимо эстетики?

Уточню. Это я не в защиту Реакт портянок и ДжиЭс. Просто оцениваю теор. перспективность выкидывания HTML, CSS на мороз, о котором грезят многие разработчики. Сам я симпатизирую идее использовать один ЯП для всего. С другой стороны, а не уход ли это от разделения труда, которое, на минуточку, основа современной экономики и причина взрывного роста продуктивности. Вместо дизайнера, верстальщика и бекендера становится нужен специалист по всему.

Просто оцениваю теор. перспективность выкидывания HTML, CSS на мороз, о котором грезят многие разработчики.

Вы только учитывайте, что React - это в первую очередь про декларативное описание и построение интерфейса. А JSX, как попытка объединить код и разметку в HTML-подобном синтаксисе - это всего лишь способ для описания структуры интерфейса.

Реакт, он про декларативное программирование.

Какие сейчас аргументы помимо эстетики?

Когда к вам завтра придет дизайнер и скажет что стратегия поменялась то вам надо будет бегать по всему коду и менять условный <div class = "button">%%CONTENT%%</div> на <div class = "btn-container"><div class = "btn_shadow">%%CONTENT%%</div><div class = "btn_content">%%CONTENT%%</div>

Привёл для примера, но суть вы уловили. Смена дизайна не такая редкая операция - раз, таких вариантов когда надо сменить верстку для какого-то элемента много - два, выше в треде есть пример реактового кода где программист сам руками пишет дивы.

Надеюсь, что на питоно-примере понятна разница между фреймворком и библиотекой?

Не понятно: я на питоне умудрился никогда не работать.

Без шуток, поясни разницу между фреймверком и библиотекой и почему реакт - не фреймверк

поясни разницу между фреймверком и библиотекой

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

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

Поэтому next.js - фреймворк, а react - библиотека.

Поэтому next.js - фреймворк, а react - библиотека.

Пользуясь случаем спрошу: С next.js кто куда переезжал если использовал?

Они Россиюшку невзлюбили после известных событий, вроде даже баннер вылезал при сборке.

Есть на нем проект, средний по размеру, вот думаю на что теперь переводить. Да и от pm2 устали уже все.

Htmx

Короче всё твоё решение — это так заабстрагировать задачу, чтобы были абстракции поверх абстракций, а как это будет рендериться для реального клиента — тебя не касается. Тогда как это и есть основной вопрос зачем и почему придумали эти библиотеки для рендеринга.

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

А вот кстати нет. Если обвес на проверку стоит на VSCode, то, во-первых, ваш код нужно будет явно открыть и проверить в этом самом десктопном VSCode, а не на CI, во-вторых, это вендор-лок сразу на редактор и плагин. И да, Handlebars, Vue, Glimmer не позволяют типизировать свои шаблоны через TypeScript.

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

Отлично, давай решим практическую задачу. У нас есть список сотрудников (например, 5-10 человек), которым на следующий месяц нужно назначить дни, в которые они работают. Заказчику было бы удобно в том числе устанавливать рабочие дни по дням недели (например, Пете — понедельник, среда, Васе — вторник, четверг) или промежутком (со среды по воскресенье), но выставлять дни можно вообще произвольно на конкретную дату. Ещё было бы хорошо в datepicker сразу показывать выходные и праздники. И сразу бы показывать, сколько рабочих дней в месяце у каждого из сотрудников. В перспективе может понадобиться, чтобы в каждый из дней работало 2 сотрудника. Разумеется, могут возникнуть и новые хотелки, интерфейс может потребовать доработки.

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

Это сложный или простой интерфейс?

Хм. Наши понимания библиотечности/фрейверчности совпадают.

Тогда расскажи, пожалуйста в двух совах про реакт - в чем смысл. Я в серости своей из всего этого пользовался ангуляром (заставили) но и то я потом плюнул, переписал все руками и стало быстрее и лучше и теперь я искренне недоумеваю чего людям в обычном браузер ном js не хватает

Тогда как это и есть основной вопрос зачем и почему придумали эти библиотеки для рендеринга.

Вот только все они заставляют руками писать div-кашу, никак не отделяя разметку от логики.

Это сложный или простой интерфейс?

вы решением таких задач на фронте занимаетесь?

И к чему тут клоун?

Почему мне за эн лет так никто и не смог объяснить зачем нужен реакт, хотя я все время спрашиваю – у вас там тайное общество какое-то? Что это за концепция такая, которую нельзя объяснить парой абзацев? Про орбитальную станцию – можно, про ядерный ректор – можно, а когда спрашиваешь зачем нужен реакт, если JS и так уже предельно высокоуровневый: вот тебе ДОМ-дерево, в нем все объекты, вот тебе все их методы и свойства, вот тебе все события браузера – велкам, программируй что хочешь – так это идиотский вопрос?

Разметку можно инкапсулировать в компоненты, и дальше можно работать уже с высокоуровневой структурой.

Не конкретно этой, но вполне такая задача может быть на фронтенде. А что в ней необычного?

Для практических целей создания интерфейсов DOM — весьма низкоуровневый. Создание одного элемента в дереве требует собственно создания элемента через createElement, множества вызовов setAttribute, множества вызовов addEventListener, затем встраивания элемента в дерево. При этом вплоть до стандартизации WebComponents не было стандартного способа инкапсулировать множество DOM-элементов в сколько-нибудь высокоуровневые компоненты, не говоря уже о том, чтобы работать с ними тем же самым API, что и с низкоуровневыми компонентами. Наконец, одна из важнейших фич: даже в WebComponents нельзя удобно делать динамические и быстрые for и if по элементам.

И к чему тут клоун?

Есть документация с примерами, есть статьи на разных языках и для разной степени подготовленности аудитории. А своё отношение я в этой теме в паре абзацев уже высказывал.

Но, могу еще раз

зачем нужен реакт

Декларативный подход к построению интерфейсов.

Эта задача называется «рабочий календарь» и ты ее описал не полностью и не совсем верно. Вернее описал «по-программистки», сведя все до одного графического элемента datepicker. Именно так и получаются плохие интерфейсы.

В чем суть.

Самое первое тут это переодичность, те типовой кейс использования: составили график один раз а дальше он повторяется и Петя все также выходит по понедельникам и средам а Вася - вторник и четверг. Неделя за неделей.

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

Второе. Составляет график отдельный менеджер, не Вася с Петей, поэтому интерфейсов на самом деле два и разных: у менеджера отображаются все графики по всем сотрудникам а у Васи с Петей лишь «путевой лист» на свою неделю. Где очевидно никаких календарей нет.

Вообщем вся сложность в итоге сводится к стандартному input select multiple с названиями дней недели. То что ты описал как «но выставлять дни можно вообще произвольно на конкретную дату.» на самом деле неправильно ввиду описанной выше повторяемности графика. Поэтому это тоже отдельный кейс, конкретные даты вводятся отдельно и используются разово , те однажды введенная дата означает лишь одну отработку.

Еще ты пропустил логику с больничными и отпусками, с переносом и остановкой работ и все подтверждение выполнения - что Вася или Петя на самом деле работу сделали.

Во-первых, я описал только требования. Во-вторых, одним датапикером эта задача не решается.

Ну надеюсь хоть пост прочитал и идею понял.

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

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

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

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

Дошло?

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

Так, ещё раз: каков будет интерфейс ввода сменного графика сотрудников?

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

Ну и зачем тут выпадающий список, если сотрудник всего один?

Выпадающий список с днями недели.

На всякий случай перечислю, а то вдруг не знаешь: понедельник, вторник, среда, четверг, пятница, суббота и воскресенье.

Я имею в виду, что мы открываем страницу сотрудника, а там одинокая выпадайка с выбором дней? Почему не 7 тогглов ПВСЧПСВ?

мы открываем страницу сотрудника, а там одинокая выпадайка с выбором дней? Почему не 7 тогглов ПВСЧПСВ?

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

Ты хочешь чтобы я за тебя полностью спроектировал конечную систему? Это стоит денег вообще-то.

Я хотел всего лишь выяснить, простой интерфейс требуется для такого задания или сложный. Оказывается, там ещё аналитить и аналитить, и сходу задача не решается. Значит, интерфейс будет хоть визуально и простой, но в нём будет много нюансов. Вот хотя бы появилась идея диалога. А это значит, что это будет асинхронная форма с валидациями.

И да, а как назначить сотрудникам режим работы 2/2, когда у них на каждой неделе будут разные рабочие и выходные дни?

А это значит, что это будет асинхронная форма с валидациями.

Совсем необязательно, достаточно классики в виде сообщения об ошибке при попытке отправки формы.

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

И да, а как назначить сотрудникам режим работы 2/2, когда у них на каждой неделе будут разные рабочие и выходные дни?

Это называется «рабочий календарь», вернее его вариация. Есть в каждой системе где ведется учет рабочего времени. В такой календарь закладываются все выходные и празничные дни, которые затем автоматически убираются из выдачи дней при назначении.

«Рабочий календарь» с точки зрения фронтенда как интерфейс или бекенда как подсистемы? И всё равно: если интерфейс распадается на кучу экранов, то оператору всё равно потребуется обучение, чтобы хотя бы понимать возможности системы и где искать нужные операции. Или хотя бы как сделать какие-нибудь штуки вроде обмена графиков между двумя сотрудниками. Ведь нельзя просто так в лоб вбить первому сотруднику график второго, а второму — первого из-за продекларированной выше атомарности изменений графика: на первом же шаге будет ошибка валидации.

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

Слушай вообщем, давай на этом закончим. Я не готов за тебя проектировать систему постами на форуме. Если на коммерческой основе - пиши в личку.

Это слишком большой оверхед для примеров, которые кинули выше:

class Cat extends React.Component {
  constructor(props) {
    super(props);

    this.state = {
      humor: 'happy'
    }
  }
  render() {
    return(
      <div>
        <h1>{this.props.name}</h1>
        <p>
          {this.props.color}
        </p>
      </div>
    );
  }
}

Ой, так получилось что эта каша не сплиттится на логику и разметку. Поэтому никто её и не разделяет.

Почему же, всё можно засплиттить

const Card = ({title, text}) => (
    <div>
        <h1>{title}</h1>
        <p>
            {text}
        </p>
    </div>
);

const Cat = ({name, color}) => (
    <Card title={name} text={color} />
);

И, в дальнейшем, если дизайнер решит перерисовать Card, то изменения применятся везде.

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

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

Нет не оказывается. Есть куча технологий и фреймворков (JSF, GWT), где программист опериует абстрактными компонентами, не привязывась к разделению на бекэнд и фронт. Т.е при разработке большую часть времени люди занимаются бизнес-логикой системы, лишь малая часть времени уходит на огрехи реализации.

И логично отрисовку выносить во фронтендный проект с точки зрения разделения ответственности.

Нет не логично. Зависит от многих факторов: цель проекта, деплой, наличие full-stack разработчиков и тд.

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

Нет не оказывается. Есть куча технологий и фреймворков (JSF, GWT), где программист опериует абстрактными компонентами, не привязывась к разделению на бекэнд и фронт.

А если потом понадобятся мобилки?

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

«Нормальный» программист обязан быть фуллстеком? Или работать чисто бекендером на уровне «абстрактных компонентов» со всеми их ограничениями? А на андроид и айос будут эти же программисты писать или какие-то другие, «ненормальные»? :)

А если потом понадобятся мобилки?

С мобилками и/или планшетами на самом деле много вариантов, опять же все зависит от задачи.

Может быть просто нативное приложение, с локальной базой и фоновой синхронизацией, если приложение будет использоваться на производстве рабочими.

Может быть оболочка + WebView , где основной интерфейс загружается сервера - используется для отвязки от обновлений мобильного приложения, чтобы можно было быстро апдейты выкатывать и не просить пользователя обновляться постоянно.

Может быть оно же, но статичный контент сайта пакуется вместе с оболочкой а удаленно вызывается только REST.

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

«Нормальный» программист обязан быть фуллстеком?

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

Может быть оболочка + WebView , где основной интерфейс загружается сервера

Тогда придётся поддерживать адаптивную вёрстку через ненативные технологии (JSF, GWT, Vaadin) в условиях глючных мобильных компонентов. То есть, поддерживать, как минимум, десктопный Chrome, андроидный WebView и айосный WKWebView (или даже устаревший UIWebView). Это может быть больно.

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

Это ортогональное разделение.

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

Только бекендеры могут осилить SQL, а фронтендные технологии почему-то не осиливают.

То есть, поддерживать, как минимум, десктопный Chrome, андроидный WebView и айосный WKWebView (или даже устаревший UIWebView). Это может быть больно.

Это если не осознавать что с другой стороны спектра вариантов - нативный клиент с длительным циклом релиза и публикации. Плюс требования к пользователям на обязательное обновление.

Последнее в случае B2C - практически гарантия просрать бизнес, поскольку даже бесплатная порнография не заставит пользователя обновляться.

Только бекендеры могут осилить SQL, а фронтендные технологии почему-то не осиливают.

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

А я не обобщаю, но таких очень много. Вот даже в треде задаются вопросом, зачем нужны фронтендные абстракции, если есть document.createElement.

бекендеры могут осилить SQL

Часто на уровне select * from table, более продвинутые могут написать модельки для ORM и дальше молиться, что оно как-то вывезет. Если кодер реально хорошо владеет конкретным диалектом SQL, это уже зубр какой-то. Редкий зверь.

В смысле? HTML хардкодом в исходниках - это венец творения? Ещё несколько лет назад тех же php-шников за такое было принято по рукам бить линейкой.

И чем это лучше bash'а, например?

#!/bin/bash

function Cat() {
        NAME=$1
        COLOR=$2
        cat << EOF
        <div>
                <h1>$NAME</h1>
                <p>$COLOR</p>
        </div>
EOF
}

В смысле? HTML хардкодом в исходниках - это венец творения?

У тебя в любом случае HTML будет хардкодом в каких-то исходниках.

Ещё несколько лет назад тех же php-шников за такое было принято по рукам бить линейкой.

Я PHP знаю плохо, комментировать тут не могу. Но в случае с React никаких проблем с этим нет.

И чем это лучше bash’а, например?

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

Кроме того вместо JS можно и нужно использовать TS. И это даст полноценную проверку типов на всех этапах. Что вообще круто.

У тебя в любом случае HTML будет хардкодом в каких-то исходниках.

Совершенно не обязательно, стандартная практика это как раз разделение на шаблон и код:

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "https://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="https://www.w3.org/1999/xhtml"
      xmlns:h="https://java.sun.com/jsf/html">
<h:head>
<title>Hello World JSF Example</title>
</h:head>
<h:body>
       #{helloWorld.s1}
<br /><br />

</h:body>
</html>

и код:

@ManagedBean(name="helloWorld")
@SessionScoped
public class HelloWorld implements Serializable{
    private String s1 = "Hello World!!";
    public String getS1() {
        System.out.println(s1);
        return s1;
    }
    public void setS1(String s1) {
        this.s1 = s1;
    }  
}

Это два разных файла, причем исходник на джаве еще и компилируется. Пример выше это JSF, а еще есть очень похожий JSP, на котором работает ЛОР.

Хотя бы тем, что у тебя тут не проверяется корректность HTML, а в реакте проверяется.

Это тоже ооочень давняя практика, в том же JSF проверяется каждая страница через XML валидатор, поэтому никаких незакрытых кавычек быть не может.

стандартная практика это как раз разделение на шаблон и код:

Шаблон это и есть код. Причём большинство (все?) шаблонных языков тюринг-полные и обычно нетривиальная разметка превращается в адскую лапшу на этом недоязыке.

Это тоже ооочень давняя практика, в том же JSF проверяется каждая страница через XML валидатор, поэтому никаких незакрытых кавычек быть не может.

JSP не проверяется. JSF не использовал, но подозреваю, что там тоже далеко не всё проверяется. #{helloWorld.s1} если я тут вместо helloWorld напишу helloWord - в какой момент ошибка вылетит?

Помимо этого React даёт полноценный JS в этих шаблонах. Я могу написать mylist.filter(i => i.n == 0).map(i => <div>{i.s}</div>). Это простой и понятный любому жаваскриптеру код, из новых концепций тут только XML-подобные литералы. Попробуй подобный код на JSF сделать. Думаю, будет лапша строк на 10.

Шаблон это и есть код.

Ну нет, в том и был смысл что есть отдельно шаблон на декларативном языке и отдельно код. Чтоб шаблон можно было хотя-бы формально валидировать.

и обычно нетривиальная разметка превращается в адскую лапшу на этом недоязыке.

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

. #{helloWorld.s1} если я тут вместо helloWorld напишу helloWord - в какой момент ошибка вылетит?

В рантайме при открытии страницы.

Но это всегда компромисс, либо долгая и сложная компиляция с валидацией либо часть ошибок будут в рантайме.

Попробуй подобный код на JSF сделать

Там конечно есть и c:foreach и ui:repeat но сам концепт другой - нет перемешивания кода и шаблона.

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

Чтобы даже идеальное решение сработало нужен комплекс мероприятий, не один только факт существования такого решения.

Но это всегда компромисс, либо долгая и сложная компиляция с валидацией либо часть ошибок будут в рантайме.

Но ведь авторы JSP могли сделать условно

<%@ page language="java" implements="InterfaceName" %>

Чтобы, например, при компиляции шаблона компилятор сразу бил по рукам, если мы пытаемся передать неитерируемый объект в <c:foreach items="">. Или при вызове неправильного шаблона из сервлета. Опять-таки, не пришлось бы передавать множество нетипизированных параметров через setParameter.

Я уже не говорю про скобки <% %>, которые позволяют засунуть в шаблон любой код, хоть запрос к БД, как здесь: https://www3.ntu.edu.sg/home/ehchua/programming/java/JSPByExample.html Это ж ничем от классических PHP bad practices не отличается.

Одно из ключевых отличий JSP и JSF как раз в этом моменте. JSP станица компилируется в сервлет либо при первом обращении либо заранее, а JSF - нет. В JSF прям жесткое разделение на шаблон и логику. Шаблон валидируется как XML, код лежит отдельно.

Между ними Expression Language (EL) - язык выражений, достаточно простой чтобы не быть проблемой.

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

Опять-таки, managed bean выдёргивается тупо по имени, и какой у него интерфейс — абсолютно неизвестно до запуска страницы.

Но это что касается полноценных страниц. И на фронтенде в принципе со страницами тоже можно было сделать аналогично через тот или иной DI. А как быть с отдельными компонентами?

managed bean выдёргивается тупо по имени, и какой у него интерфейс — абсолютно неизвестно до запуска страницы.

Я ж говорю: без фанатизма.

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

Как только доходит до усложнения - пиши пропало. Поэтому простоту необходимо поддерживать всеми силами. Сложное сделать просто, простое - сложно.

Отдельные компоненты в JSF это тоже комбинация из шаблона и кода, с точно таким же разделением.

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

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

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

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

Кстати, а как в JSF делается родительский шаблон, который отвечает за общие части разных страниц?

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

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

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

Форма->заполнение->отправка->отображение - как это было еще в 80х так и осталось сейчас для большинства бизнесового софта.

Кстати, а как в JSF делается родительский шаблон, который отвечает за общие части разных страниц?

Наверное наиболее грамотным способом из всех виденных:

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
                template="./template.xhtml">
 
    <ui:define name="top">
        Top Content
    </ui:define>
 
    <ui:define name="left">
        Sidebar Content
    </ui:define>
 
    <ui:define name="content">
        Main Content Goes Here!
    </ui:define>
 
    <ui:define name="bottom">
        Footer goes here
    </ui:define>
 
</ui:composition>

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

<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns:ui="http://xmlns.jcp.org/jsf/facelets"
                template="./template.xhtml"
                xmlns:h="http://xmlns.jcp.org/jsf/html"
                xmlns="http://www.w3.org/1999/xhtml">
 
     
    <ui:define name="top">        
        Title : #{bean.title}
    </ui:define>
 
    <ui:define name="content">
        <h:form>            
            <h:panelGrid columns="2">
                <h:outputLabel value="First Name" class="label"/>            
                <h:inputText value="#{bean.person.firstName}"/>            
                <h:outputLabel value="Last Name" class="label"/>
                <h:inputText value="#{bean.person.lastName}"/>
                <h:outputLabel value="Customer Notes" class="label"/>                           
                <h:inputTextarea  value="#{bean.person.notes}"/>
            </h:panelGrid>
        </h:form>
    </ui:define>
 
    <ui:define name="bottom">
        Footer goes here
    </ui:define>
 
</ui:composition>

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

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

Суть в том, что компоненты Реакта не описывают только страницы, а для промежуточных компонентов строгая типизация — это хорошо. Точно так же, как строгая типизация в Java — это хорошо.

а для промежуточных компонентов строгая типизация — это хорошо

Вот это тоже смешной момент: получается что на бекэнде тенденция идет к отказу от строгой типизации в сторону duck typing и lazy evaluation, а на фронте ровно наоборот - идет переход от динамической к строгой.

Т.е ровно то за что на бекэнде не любят джаву - за это же на фронте обожают тайпскрипт.

Смешно.

Я бы не сказал, что на бекенде прям тенденция. Даже питон и пхп внедряют средства статического описания и проверки типов. И разве есть повальное бегство с джавы/шарпа на динамическую типизацию в суровом энтерпрайзе?

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

В любом обсуждении Rust/Go/Elixir/Clojure/Scala и любой другой новомодный язык.

И разве есть повальное бегство с джавы/шарпа на динамическую типизацию в суровом энтерпрайзе?

Не могу говорить за всех, но есть «говорящие головы», которые ходят и агитируют за новые технологии, а значит есть процесс «миграции идей».

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

Rust/Go/Elixir/Clojure/Scala

Но это же всё строго типизированные языки, и, в основном, с развитой системой вывода типов (на уровне TypeScript или выше).

Ну вот например:

https://doc.rust-lang.org/book/ch19-04-advanced-types.html https://medium.com/journey-to-rust/my-first-insight-into-rust-type-system-601cdfd0b81f

Rust type system allows arbitrary amount of dynamic typing. If you want, you can write totally dynamic everything, and get all type errors in runtime (there is a dyn keyword for this).

Or, you can completely stop using any dynamic features and get all typechecking in a compile time.

Вообщем это опять такое современное «да но нет» или «вставить но на полшишечки».

Не хочу снова погружаться в обсуждение этих теологических вопросов, потому как сейчас опять набегут «идолопоклонники» и начнут всех поучать как правильно.

Вообщем это опять такое современное «да но нет» или «вставить но на полшишечки».

Ой, ну не за это же выбирают Раст для бекенда. В JVM и C# тоже есть поддержка динамической типизации, ну и что?

А что в ней необычного?

Ну как-то странно: фронт у тебя занимается вычислениями у кого какой выходной когда. ИМХО, фронт должен только взаимодействовать с пользователем, а логику и расчеты – в зад

Создание одного элемента в дереве требует собственно создания элемента через createElement, множества вызовов setAttribute, множества вызовов addEventListener, затем встраивания элемента в дерево.

Ну так оберни в удобный тебе способ. JS позволяет

Наконец, одна из важнейших фич: даже в WebComponents нельзя удобно делать динамические и быстрые for и if по элементам.

Ну когда создаешь – запоминай нужные тебе в массив. Или вообще как и что там тебе удобно

Мое недоумение только от того что кому-то мало того что предоставляет ЖС. Да делай что хочешь и при том никакой низкоуровневой запары. Ну да ладно: это, видимо, вкусовщина

Есть документация с примерами, есть статьи на разных языках и для разной степени подготовленности аудитории.

По филологии тоже есть статьи, есть книги и форумы. От этого вопрос «объясни в двух словах зачем нужна Ё, когда уже есть ЙО» становится идиотским?

зачем нужен реакт

Декларативный подход к построению интерфейсов.

– почему в соборе святого Патрика звонят колокола?

– это как-то связано с религией!

Мое недоумение только от того что кому-то мало того что предоставляет ЖС

Любой «велосипед» (в хорошем смысле слова) на JS рано или поздно доходит до состояния, когда:

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

Ну, вот, в частности реакт эти вопросы и разруливает.

👆

Ну, вот, в частности реакт эти вопросы и разруливает.

Ну я приблизительно так и представляю, но все эти вещи актуальны и для всего остального программирования, однако, все в один голос твердят что в вебе без реакта и ему подобных жизни нет, а в каком-нибудь системном программировании что-то как-то все как писали руками так и пишут. (или может я опять в танке)

Ну я приблизительно так и представляю

К чему тогда вопросы «объясни в двух словах зачем нужна Ё, когда уже есть ЙО»?

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

Только в одной этой теме есть сторонники прямо противоположного мнения. Нет «одного голоса», а есть тренды, появится что-то ещё интересное и будут твердить и про него. Вот, даже дошли до трендовых рекомендаций не использовать реакт, а уже пользоваться фреймворками на его основе.

К чему тогда вопросы «объясни в двух словах зачем нужна Ё, когда уже есть ЙО»?

Да потому что никто и никогда не объяснил никак, кроме как общими фразами. Совсем общими, настолько общими – что они ко всему программированию применимы.

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

Ладно, молчу. Бог с ним, с вашим реактом. Спасибо за ответы

Ага. И С++ тоже чисто динамический – ачотакова, можно же интерфейсы туда-сюда передавать, а то и вовсе std::any. Про void* вообще молчу.

В описанном ТЗ не предусматривается особых вычислений на клиенте. Автораскладка людей по дням может быть реализована и на бекенде. Но на фронте остаётся возможность отредактировать график.

Ну так оберни в удобный тебе способ. JS позволяет

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

const UserInfo = ({name, jobTitle, avatar}) => (
  <div className="userinfo">
    <div className="userinfo__leading">
      <img className="userinfo__avatar" src={avatar} alt="name" />
    </div>
    <div className="userinfo__content">
      <div className="userinfo__name">{name}</div>
      <div className="userinfo__job">{jobTitle}</div>
    </div>
  </div>
);

const UserInfo = ({ name, jobTitle, avatar }) => (
  React.createElement("div", { className: "userinfo" },
    React.createElement("div", { className: "userinfo__leading" },
        React.createElement("img", { className: "userinfo__avatar", src: avatar, alt: "name" }),
    ),
    React.createElement("div", { className: "userinfo__content" },
        React.createElement("div", { className: "userinfo__name" }, name),
        React.createElement("div", { className: "userinfo__job" }, jobTitle),
    ),
  ),
);

Ну когда создаешь – запоминай нужные тебе в массив. Или вообще как и что там тебе удобно

Суть в том, что не стоит пересоздавать элементы в списке, если он уже созданы — это дорого, а нужно только добавить или удалить то, что изменилось. И для этого в самом JS есть только низкоуровневые appendChild и insertBefore. Например, можно сохранять массив ранее выведенных элементов, затем сравнивать его с новым и находить точки изменений. Будет та же самая реконсиляция, что и в React.

, а нужно только добавить или удалить то, что изменилось.

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

Может поменяться порядок элементов, может быть обновление отдельных полей, часть может исчезнуть, часть появиться - на уровне самих данных, полученных с сервера а не DOM элементов.

Поэтому временами логика «удалить все и заново сгенерировать список элементов» является оптимальной, пусть и не с точки зрения скорости то с точки зрения верифицируемости.

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

Ты же сам знаешь, как эти варианты решают фреймворки, в частности, React и Vue.

Поэтому временами логика «удалить все и заново сгенерировать список элементов» является оптимальной, пусть и не с точки зрения скорости то с точки зрения верифицируемости.

А если на компоненте для каких-то целей сделана обработка mount и unmount, то это будет ещё тяжелее.

как эти варианты решают фреймворки, в частности, React и Vue

Нет, видимо ты из тех редких программистов, доживших до своего опыта, которых никогда в жизни сильно не били.

Представь что твоя зарплата зависит от рендера компонента на реакте - готов так подставиться?

Но полагаю этого мало, ладно. Представь что ты гражданин США и компонент на реакте будет решать сколько тебе придется платить по страховке в клинике: $5000 или $500000. Причем даже если произойдет ошибка - судиться с клиникой тебе не под силам - денег нехватит.

Готов сиграть в такую игру когда на кону собственное очко?

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

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

Это все что вам нужно знать про Реакт в частности и MVVM концепцию в целом - это просто игрушка, с которой будут «играться», разумеется за ваш счет.

Чем тебе паттерн проектирования не угодил?

Я мало знаю о современном фронтенде и тем более о React, поэтому не совсем понимаю дискуссию. Но у меня вопрос: не мог бы ты развернуть мысль с примером про страховку? С твоей точки зрения неприемлемо то, что доменные правила приводятся в действие кодом на клиенте в принципе? Или проблема именно в React? То есть в составе React есть какой-то модуль/инструмент у которого проблемы с корректностью? Или у него недетерминированное поведение? Или поведение этого инструмента не было нормально формализовано?

Попробую объяснить.

Реакт работает через события, те ты не можешь что-либо отобразить без отработки события. Помимо событий, в реакте есть биндинги полей: ты объявляешь набор полей, вставляешь их в шаблон а затем присваиваешь им значение - в этот момент отрабатывает проверка состояния и если фреймворк видит что поле поменялось - перестраивает DOM. Только после этого ты визуально на экране видишь изменения.

Это все упрощенно, в реальности все куда сложнее, особенно если знать что реакт работает не с реальной DOM моделью а со своей виртуальной - shadow DOM.

Отсюда получается что есть очень сложная логика с момента получения значения $5000 с сервера и до его отображения в браузере.

Поэтому для важных данных все также стараются показывать готовый html, сгенеренный на серверной стороне. Ну я стараюсь по крайней мере.

shadow DOM != virtual DOM

Судя по всему, alex0x08 считает, что React по каким-то причинам может неправильно отобразить данные, но практически подтвердить это не может.

А как ты себе это представляешь? Что я выдам 0day где вместо $5000 показывает ноль во всех случаях?

Это банальный инженерный подход - сокращение точек отказа. В инженерных ВУЗах такому учат.

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

Нет, речь лишь про сам контент, который легко валидируется. То что с сервера прилетело $5000 ты увидишь даже в логах nginx при желании.

Тут суть в том что убирается логика преобразования ответа сервера в представление на экране, чем и занимается реакт.

А браузер не занимается логикой преобразования ответа сервера в картинку?

И что мешает провалидировать условный JSON, который прилетает от сервера?

Не сильно стало яснее, но всё равно спасибо. Ну то есть он должен по изменениям в input сформировать и применить такой набор изменений, который переведет дерево то же состояние как если бы input изначально был таким. Твоя критика наводит на мысли, React это видимо какой-то полукривой типа дата-байндинг, который в силу каких-то объективных причин incomplete, поэтому некоторых гарантий дать не может. В результате сложность переместилась в ментальную область и вероятность ошибок возрастает.

А браузер не занимается логикой преобразования ответа сервера в картинку?

Занимается. Но я и не говорил что браузер как средство отображения тоже стоит исключить (хотя так тоже делают, да)

И что мешает провалидировать условный JSON, который прилетает от сервера?

Это ничего не даст при ошибке на стадии отображения.

Это ничего не даст при ошибке на стадии отображения.

Однако можно протестировать сервер и клиент по-отдельности

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

Еще есть интересный момент: банку (как и любой другой финансовой организации) на самом деле выгодны сложные ошибки в ПО, особенно если они приводят к списанию средств в пользу банка. Поскольку судиться и возвращать средства долго и сложно, далеко не все будут этим заниматься.

Эту же тактику взяли на вооружение операторы большой тройки кстати.

Однако можно протестировать сервер и клиент по-отдельности

Если немного подумать то окажется что эмулировать тестовую среду и окружение близкое к реальному пользователю невероятно тяжело, а синтетика нужна лишь для отчетности и успокоения нервов.

Так и пользовательский браузер может легко «начудить», в том числе не в пользу клиента: https://output.jsbin.com/rewofotozi

Здесь нет ни «сложных», ни вообще каких-либо ошибок. Только эксплуатация вероятного окружения реального пользователя, у которого, скорее всего, стоит адблок.

Я не говорю что можно легко убрать все риски, лишь их сократить.

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

Но клиентские программы тоже нужно писать, и это тоже большая точка отказа. Да и на практике получается, что с учётом зоопарка потенциальных клиентских платформ (Windows, Linux, macOS, Android, iOS) и бутылочного горлышка в виде необходимости обновлений клиентов, оказывается, что фронтенд в виде SPA-приложения и, дополнительно, мобильных приложений, — не так уж и плохо.

банку (как и любой другой финансовой организации) на самом деле выгодны сложные ошибки в ПО, особенно если они приводят к списанию средств в пользу банка

Кстати тут хороший момент в том, что если ошибка произошла в пользу банка, то клиенту нужно будет ещё посудиться, чтобы вернуть отобранное по ошибке, а если ошибка произошла в пользу клиента, то банк может или дополнительно списать недостачу, или заблокировать счета, или тоже подать в суд за «необоснованное обогащение». А у банка штат юристов всё-таки будет посильнее. А клиенту выбор интерфейса не предоставляют.

Я вот кстати уже больше полугода вяло воюю с техподдержкой своего банка, у которой из-за ошибки неправильно формируется строка моего адреса проживания. То есть в БД адрес корректен и разложен по разным полям, а бекенд формирует абсолютно кривую строку. При этом они каждый раз отвечают «Работы провели — ошибка исправлена». Так что даже без фронтенда простор для косяков остаётся огромный.

Но клиентские программы тоже нужно писать, и это тоже большая точка отказа.

Отдельная клиентская программа куда надежнее браузера, поскольку убирается вся проблематика отрисовки html.

Да и на практике получается, что с учётом зоопарка потенциальных клиентских платформ

Был период (до эры java) когда универсальность и кроссплатформенность вообще считали признаком низкого качества, а самым лучшим считалось поставлять свое железо со своей ОС. SGI - как эталонный пример.

Сейчас на практике все тоже сводится к одной-двум платформам, еще и в жестких границах поддерживаемых конфигураций.

А дичь вроде SPA на мобилках собственно дальше прототипов и не уходит, это слишком неудобно. Даже PWA неудобны по сравнению с нативными приложениями.

не так уж и плохо.

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

Отдельная клиентская программа куда надежнее браузера, поскольку убирается вся проблематика отрисовки html.

А какая у HTML для прикладного программиста «проблематика отрисовки»? Условный программист на React возьмёт готовую библиотеку компонентов вроде MaterialUI и будет пилить бизнес-логику. Если потребуется standalone — завернёт в Electron. Условный программист на Java возьмёт Swing или JavaFX, и будет пилить бизнес-логику. Аналогично поступят дотнетчик, делфист и плюсовик на Qt.

А дичь вроде SPA на мобилках собственно дальше прототипов и не уходит, это слишком неудобно. Даже PWA неудобны по сравнению с нативными приложениями.

Да, вот на мобилках всплывают проблемы с UX у ненативных тулкитов. Притом не только на основе браузеров.