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

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

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

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

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

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

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

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

старый добрый html 1.0 с фреймами

Наверняка, кто-нибудь из местных знает пример современного сайта так сделанного. Было бы любопытно глянуть)

https://www.gnu.org/ (Без фреймов, правда. А зачем они?)

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

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

Дошло?

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

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

Зачем же токсы, у нас Web-development есть.

Выпадающий список с 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, это уже зубр какой-то. Редкий зверь.

Чем оно лучше Mavo?

В смысле? 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 но сам концепт другой - нет перемешивания кода и шаблона.

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

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