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

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

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

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

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

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

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

Зачем? (X)HTML без JS отлично выглядит.

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

А пацаны приколисты ;)

https://hypermedia.systems/book/part/hypermedia-concepts/

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

Astro это лишь оболочка метафреймворк поверх.

Вам мало фрейверков, вы ещё и фреймверки поверх фрейверков изобретайте, серьёзно?

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

А в чем новизна? ПХП же уже есть

Сейчас для программирования с ограниченным использованием и JavaScript становится модной технология web assembly,

Блин, третий комментарий подряд, все рассказывают о современных трендах и о том как правильно сейчас

А у твоей технологии какие киллер фичи?

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

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

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

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

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

Это победа

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

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

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

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

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

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

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

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

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

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

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

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

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

Кому это - «Вам»? Я - бэкендер. Вижу, что можно вместе использовать SSG и SPA, и всё это чисто с небольшой прослойкой в одной экосистеме со всем другим зоопарком. Было бы круто эту штуку View Transitions API заиспользовать в шаблонах..

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

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

Сейчас для программирования с ограниченным использованием и JavaScript становится модной технология web assembly

Не становится. У wasm скоро юбилей, а не-helloworld’ы на ней можно посчитать на пальцах одной ноги.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вам мало фрейверков, вы ещё и фреймверки поверх фрейверков изобретайте, серьёзно?

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

Yo Dawg

Уточню. Это я не в защиту Реакт портянок и ДжиЭс. Просто оцениваю теор. перспективность выкидывания 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>

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

Зумеры придумали ASP.NET Web Forms

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

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

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

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

Но нет.

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

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