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

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

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

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

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

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

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

забыли

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 где?

Так реакт не заставляет смешивать бизнес-логику и разметку. По-хорошему, бизнес-логику пишут не в самом компоненте, а где-то в другом месте (если хочется максимально изолировать, можно вообще взять 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 безо всяких фреймворков

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

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

Я за реакт не агитирую, я использую его время от времени - обычно 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

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

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

Ну то есть половина супер-популярных продуктов гугла сразу не нужны, все эти 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 фрейверков что-то устаревает?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первый тред был про 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>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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