LINUX.ORG.RU
Форум — Web-development  

Зачем нужно генерировать одинаковый DOM на фронте и бэке?

 ,


0

3

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

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

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

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

★★★★
← Энциклонгов тред
  1 2 3 →
Ответ на: комментарий от masa

вы похоже нашли друг друга ребята «нинужнисты», ток вы настоко далеки от реальности, что у меня рука от лица не отрывается

К сожалению, да, его подход сомнителен в плане эффективности, но мне нравится задор. По крайней мере я вижу перспективу в плане «давайте сделаем динамику в стиле jQuery... хм-м-м, чот получается много одинаковых телодвижений, надо сократить» — примерно здесь находятся все самые прогрессивные мыслители 2025.

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

Фейсбук делал браузер в браузере, это в принципе сложная задача, особенно учитывая то, какие всратые браузеры были в то время. Зачем им браузер в браузере? Затем, что это фейсбук, ему надо.

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

Я сделал пост с фразой про «Redux не нужен» на реддите и мне накидали минусов там. Какие ещё доказательства нужны?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Redux действительно неудачное решение, но на тот момент для Реакта не было ничего лучше. Были довольно монструозные решения типа Flux, Reflux и т.п. Redux был написан на коленке как частное простое решение для демонстрации доклада, но неожиданно зашёл аудитории.

фреймворк вяжет по рукам и ногам кодера

Это сущность и цель любого фреймворка.

static_lab ★★★★★
()
Ответ на: комментарий от static_lab

Redux действительно неудачное решение, но на тот момент для Реакта не было ничего лучше. Были довольно монструозные решения типа Flux, Reflux и т.п. Redux был написан на коленке как частное простое решение для демонстрации доклада, но неожиданно зашёл аудитории.

Ты знаешь, я чётко помню моё первое впечатление от Redux. Оно было «какой наркоман это писал? почему в этой модели все логически связанные сущности максимально разделены друг от друга?». Это его ещё поправили со временем, а в оригинале оно было реально «говна поел». Каких бабуинов они собрали на этой конференции — для меня загадка. Для меня не перестаёт быть загадкой реакция публики, которая аплодирует самой наркоманской поделке, а когда кто-то начинает указывать на технические изъяны — возражают «ты пессимист» и «ты не понимаешь, это преимущество».

MobX был выпущен одновременно с Redux. Мне нужно объяснять, что выбрали мухи?

Это сущность и цель любого фреймворка.

Нет. Svelte/Solid комбинируются со всем чем угодно. Я кроме Angular и React такой степени ограничений со стороны фреймворков больше не припомню.

byko3y ★★★★
() автор топика
Ответ на: комментарий от masa

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

masa ★★★
()
Последнее исправление: masa (всего исправлений: 1)
Ответ на: комментарий от deep-purple

Здрассти )) HTML — это текстовое представление DOM.

HTML -это язык разметки. То что браузер интерпретирует его в DOM это другой вопрос.

Если не требовать интерактивности, то отрисовывать HTML можно и без DOM.

Psilocybe ★★★★★
()
Ответ на: комментарий от Psilocybe

Если не требовать интерактивности, то отрисовывать HTML можно и без DOM.

Если не требовать интерактивности, то как ты собрался без DOM стилизовать узлы? Расчёт шаблона в HTML настолько сложен, что его нереально без объектной модели сколь бы то ни было эффективно делать. Боты-парсеры — да, могут без объектной модели жить.

byko3y ★★★★
() автор топика
Ответ на: комментарий от Psilocybe

Opera(Presto) строила DOM без элементов #text если были пробельные символы между тегами. Другие движки добавляют #text.
Какая же это сериализация если результат разный?

Что тут радикально разного? Обработка пробельных символов между тэгами — это рак, который перекочевал из HTML аж в XML. До сих пор в XML нет единого способа обработки пробелов. Так и живём.

byko3y ★★★★
() автор топика

1. Устал уговаривать фронтэндеров нарисовать страничку с выводом отладочной информации по записям и связям в БД. Пока они там свой vue расчехлят, пока всю эту современную лапшу развесят.

2. Написал процедуру в PostgreSQL - на вход получает uuid, сама ищет в какой таблице такой встречается, и формирует json с отчетом - что за запись, какие связи и прочее.

3. Написал вторую процедуру в ПГ, которая из json делает готовый HTML. Через json_each, string_agg и т.д. С парой-другой стилей для красоты.

4. В конфиге nginx создал location на определенный путь, с проверкой регуляркой, что дальше следует какой-то валидный uuid.

5. Из этого location, при условии путь+uuid вызывается из shell 'psql -c «SELECT proc(uuid);»' и выплевывается в браузер.

---------

Ни тебе куберов, ни тебе гитов, ни тебе бэкэндеров, ни тебе фронтэндеров. Никого уговаривать не надо. Вводим http://bla.bla/debug/00000000-0000-0000-0000-000000000000 - смотрим, что это за хрень лежит в БД.

Toxo2 ★★★★★
()
Ответ на: комментарий от Toxo2

Пока они там свой vue расчехлят

vue вооще дно. Как-то потребовалось GUI-подобный интерфейс сделать под веб. Ну, думаю, пацаны с LOR плохого не посоведуют, часто vue рекомендуют. Кроме vue там оказывается много чего нужно и, как оказалось, там всё на node.js ориентировано, со своей атмосферой. Да и сам vue срёт шаблонами прямо в DOM.

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

Плюнул и за неделю наваял на webix.

Psilocybe ★★★★★
()
Ответ на: комментарий от Psilocybe

Ну, думаю, пацаны с LOR плохого не посоведуют, часто vue рекомендуют. Кроме vue там оказывается много чего нужно и, как оказалось, там всё на node.js ориентировано, со своей атмосферой. Да и сам vue срёт шаблонами прямо в DOM.

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

element-ui или @webtides/element-js? Если последнее, то выглядит как-то грустновато, много ручной работы требуется.

Плюнул и за неделю наваял на webix.

Как ты ставишь в один ряд Vue и Webix? Это даже не одного класса инструменты, как лифт и автомобиль.

byko3y ★★★★
() автор топика
Ответ на: комментарий от Psilocybe

Ну так задача сериализации -однозначное воспроизведение. Тут есть неоднозначность, значит html не сериализация DOM

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

До сих пор в XML нет единого способа обработки пробелов.

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

В стандарте есть понятие «Validating XML processor» (https://www.w3.org/TR/xml/#dt-validating), который уже ближе к реальным парсерам, и он уже пытается интерпретировать значение во что-то, что может обработать приложение. То есть, это всё ещё не приложение, приложение уже дальше будет делать интерпретацию поверх парсерной. Так вот этот «Validating XML processor» имеет право пропускать пробелы:
https://www.w3.org/TR/xml/#sec-white-space

byko3y ★★★★
() автор топика

Я сейчас делаю на vue приложения для терминалов в ТЦ… Вот тебе один из примеров наряду с разными личными кабинетами в банках и тп. Я не знаю как твой вымер комментировать. Ты идиот и не знаешь элементарных вещей. Никто повторно разметку не формирует, бекенд только джисон отдает

anonymous
()

Не эксперт, ни претендую на истину. ИМХО: bundler пробывали использовать? «ТЗ» именно про запаковать «байт-код» и в «продакшн».

anonymous
()
  1 2 3 →
← Энциклонгов тред
Web-development