Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Сравнение методов исключения разработки на JavaScript для веб технологий"	+/–
Сообщение от auto_tips (??), 07-Дек-21, 10:21
++ Преамбула К [[https://www.opennet.dev/opennews/art.shtml?num=56140 статье]] о публикации [[https://pusa.catlair.net фрэймворка Pusa]] авторы получили полезные для дальнейшей работы над проектом отклики. Наиболее важным нам показалась беседа с создателем проекта [[https://github.com/fomkin/korolev Korolev]], реализующего аналогичную парадигму но принципиально иными методами. Так как, у нас была возможность не только познакомится с исходным кодом Korolev, но и пообщаться с его создателем, считаем возможным показать принципиальное отличие концепции Pusa, именно на примере Korolev. ++ Задача Оба проекта реализуют разработку web-приложений без необходимости написания клиентского кода JavaScript  конечным разработчиком. ++ Решение Korolev Реализация scala. При открытии страница браузер клиента скачивает базовый JavaScript-код приложения. Тот открывает WebSocket-соединение с сервером Korolev. На стороне сервера формируется DOM-структура. Клиентские события направляются через websocket на сервер. Получив очередное событие Korolev выполняет необходимую бизнес логику, вносит изменения в DOM на стороне сервера, далее выполняется построение дифференциального обновления которое направляется на клиент. Благодаря оптимизированному механизму построения дифов, эффективность обработки DOM на стороне Korolev высока. Клиентское приложение получив изменения, отражает их в DOM браузера. Пользователь получает необходимый контент. ++ Решение Pusa Реализация PHP. При старте приложения браузер скачивает базовый JavaScript-код приложения Pusa (6кб). Приложение выполняет AJAX запросы на основе событий браузера. Каждый запрос содержит данные о событийном DOM-элементе и служебную информацию. Сервер Pusa получая очередное событие, определяет и выполняет контроллер с бизнес логикой, и возвращает набор инструкций согласно протоколу Pusa (https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/src/la... как результат AJAX запроса. JavaScript-клиент отрабатывает полученные инструкции, внося изменения в клиентский DOM. Пользователь получает необходимый контент. ++ Общее в концепциях ** Клиентские приложения требуют JavaScript как основу работы приложения. ** От разработчика не требуется работа над клиентским кодом JavaScript ни в каком виде. ** Бизнес логика и работа с DOM выполняется на стороне сервера на имеющихся средствах разработки. ** Клиент получает необходимый контент. ** Код приложения находится в безопасном серверном окружении и не присутствует на стороне клиента. ** Клиентский код JavaScript   минималистичен и стабилен. ** С разработчика снимается проблема сериализации при передаче данных. ++ Особенности Korolev ** Сервер обладает отражением DOM-объекта для каждого клиентского соединения. ** Korolev направляет клиенту дифференциальный, хорошо оптимизированный контент. ** Korolev использует WebSocket, как основной высокопроизводительный метод взаимодействия. ** В силу архитектуры сервер Korolev имеет возможность инициировать изменение клиентского контента. ++ Особенности Pusa ** Сервер не требует и не подразумевает хранение состояния клиента, те реализуется чистый [[https://ru.wikipedia.org/wiki/REST REST]]. ** Pusa направляет клиенту команды в ответе AJAX через XMLHttpRequest, что значительно снижает требования к браузеру. ** Pusa относится к клиенту как удаленному конечному автомату без обратной связи. ** Технология Pusa не имеет возможности инициировать событие со стороны сервера. Инициатором событий является исключительно клиент (таймер возможен). [[IMG /opennews/pics_base/0_1638858402.jpg]] ++ Выводы. Технологии, основывающиеся на необходимости хранения состояния клиента потенциально ограничены ростом клиентских подключений, и как следствие предполагают централизацию аппаратных ресурсов.  Возможность инициации событий со стороны сервера является необходимой опцией для внутренних решений. Три перечисленных фактора определяет рынок корпоративных решений, как наиболее привлекательный для технологий, аналогичных Korolev. Качественная оптимизация Korolev явно демонстрируют стремление к минимизации накладных расходов на хранение клиентских состояний, но не устраняет их. Pusa, принципиально следуя парадигме чистого REST, нацелена на рынок открытых решений, со значительным количеством клиентских подключений. Pusa предполагает использование множества независимых инстансов, с минимальными требования, без необходимости их общего взаимодействия. Запросы одного и того же пользователя к Pusa могут обрабатываться различными инстансами в рамках одной сессии, что позволяет использовать решение под значительными нагрузками. ++ Ссылки *** [[https://github.com/fomkin/korolev Korolev]] *** [[https://pusa.catlair.net Pusa]] *** [[https://pusa.catlair.net/?image=images/KorolevPusa.jpg сравнительная схема]] *** [[https://www.opennet.dev/opennews/art.shtml?num=56140 Анонс публикации Pusa]] URL: https://github.com/fomkin/korolev Обсуждается: http://www.opennet.dev/tips/info/3197.shtml
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 07-Дек-21, 10:21	+2 +/–
Решения для создания невообразимо отвратительных проприетарных шпионских сайтов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #39

2. Сообщение от stillswamp (ok), 07-Дек-21, 11:05	+2 +/–
Отвратительность и шпионство создают не решения а люди. Любой сайт можно сделать отвратительным и шпионским вне зависимости от технологии.
Ответить | Правка | Наверх | Cообщить модератору

3. Сообщение от Linuxoid (?), 07-Дек-21, 13:13	+/–
Хорошая статья. Если обратиться к исследуемым библиотекам, то нужно быть либо скалистом, либо пиэйчпистом. Маловероятно, чтобы один человек, достаточно хорошо разбирался бы в обоих языках одновременно. По поводу исключения js-из разработки, думаю это не правильный пусть. Нужно наоборот, вовлекаться в js-технологии. Зачем придумывать велосипеды? Есть замечательный пример с языком Dart. Есть и другие примеры. Нужно принять, что js-это уже экосистема, которую не получиться игнорировать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4

4. Сообщение от stillswamp (ok), 07-Дек-21, 14:02	+1 +/–
Суть указанных подходов - сокращение средств разработки. Так как избавиться от девелопинга на бэке невозможно, следует логичное стремление сократить девелопинг на фронте. При этом не просто переместить на бэк JS, а принципиально исключить его. На чем написан бэкэнд - уже не принципиально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #12

5. Сообщение от Аноним (5), 08-Дек-21, 10:58	+/–
Подход Korolev мне больше нравится. Было бы офигенно, если бы кто-то сделал что-то подобное, но независимое от языка бэкенда.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #47

6. Сообщение от Glushko (?), 09-Дек-21, 11:51	+/–
бредовый подход. но история повторяется: раньше гоняли ajax-ом сгенеренные куски хтмл, теперь пошли дальше: оверинжинирят то же самое через вебсокет и дом-дифф. а потом эти же люди ноют в комментах к очередному js-фреймворку, якобы вебмакаки зря утилизируют ресурсы компьютеров. в этих поделках из статьи всё, что можно было применить не по назначению - применено не по назначению. вобщем, не только в германии сумрачные гении сидят. у нас тоже имеются доктора франкенштейны.. особенно в южных губерниях
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

7. Сообщение от stillswamp (ok), 09-Дек-21, 23:23	+/–
1. Прошу конкретику. Что применено не по назначению? Готовы исправить. 2. Прошу осмотреть вот это изделие без строчки JS кроме самого фреймворка. https://engram.catlair.net/ 3. Прошу изложить вашу концепцию решения аналогичного изделия с применением по назначению JS с сопоставлением результатов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #8

8. Сообщение от Glushko (?), 10-Дек-21, 11:27	+/–
1. "не по назначению" - это про концепцию. совершенно безумная идея перенести реакцию на события браузера на сервер. 2. "кроме самого фреймворка" - это прекрасно, что вам подходит для своих задач. только сдаётся мне, что будет очень больно сделать из этого что-то кастомное (не ваше), даже приняв безумную концепцию 3. react, vue, для любителей экзотики - svelte, google incremental dom. ну и что там по списку в этом году.. даже vanilla js или jquery подойдёт - у вас там совсем немного функциональности. все эти россказни про "ни строчки js" улетучиваются, когда клиенту нужно срочно что-то сделать не так, как вы придумали. тогда бедолаги, наслушавшиеся про "ни строчки js" срочно ищут js-макаку и г-нокодят "идеальную" систему. далее, я уже писал про древние подходы - так вот они намного выигрышней вашего, т.к. не утилизируют с безумной силой сеть. в вашем демо-приложении из п.2 очень мало контролов и нет зависимостей между ними и то на каждый клик в options как минимум 2 http запроса. если взять более-менее приближенный к реальности вариант, то это будет провал. вам в комментариях к новости писали про тонну запросов ютуба - это же в основном обязательная аналитика, всякое seo и прочий маркетинг (для публичных сайтов - это, к сожалению, уже неизбежно). если к этому потоку данных прибавить ещё по 2 запроса на каждый клик интерфейса (а если клик вызывает изменения, затрагивающие не один контрол, а какое-то сложное изменение интерфейса), то 3g соединение может и потянет, но будет очень больно. можете даже на своём tiny-demo сайте из п.2 в chrome dev tools выставить ограничение соединения и посмотреть как ваш примитивный интерфейс в options работает:) после этого пройдите на реально здоровые сайты.. даже не будем о больном - о фейсбуках.. зайдите на алиэкспресс. если мне не изменяет память, там всё взаимодействие висит на старых добрых jsonp-колбэках. не спорю, что подход пуси, а тем более korolev - это ново и самобытно, лысенко тоже новые и самобытные вещи утверждал в своё время
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #9, #10

9. Сообщение от stillswamp (ok), 10-Дек-21, 19:22	+/–
... skip
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

10. Сообщение от stillswamp (ok), 10-Дек-21, 19:25	+/–
Благодарю за подробный ответ. Перенос событий из браузера на сервер практичен. Утилизацию следует обсуждать на цифрах. Таковых от вас ожидать мы не в праве, а потому обсуждение лишне. Pusa сейчас для эксперимента трудится на сервере стоимостью 2евро в месяц. Завалить не трудно, но едва ли она покажет себя хуже предложенных вами технологий (скорее всего лучше) :) В приведенном примере каждый клик отправляется на сервер, так как логика сборки таблицы размещена на сервере. Ее нет в браузере. Касательно скорости соединения, выставив ограничение скорости в первую очередь пострадает загрузка озвучки в mp3. Реакция на события будет минимальной проблемой. Так же учтите факт, что на медленном соединении вы получите для JS решения задержки загрузки фрэймворка и прочей графики. Если у вас будет желание и возможность, прошу представить случай где Pusa не будет комфортно. Сразу оговорюсь: один из участников обсуждения желал от нас получить сразу некое готовое решение под свои задачи. Естественно мы не стали выполнять чужую работу. Но мы крайне заинтересованы, если вы назовете объективную задачу с которой Pusa не справится. Canvas и массированные mousemove (etc) не являются таковой, это оговорено в ограничениях Pusa. *** Если вы представите разумный case - мы постараемся сделать демонстрацию решения. Критерий разумности - 1 час исполнения. И самое главное... Pusa - это радикальное упрощение разработки. Поверьте - вопросы нагрузки на сервера - мелкая мелочь по сравнению с предлагаемыми возможностями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #13, #21

12. Сообщение от Аноним (12), 11-Дек-21, 10:30	+/–
> сократить девелопинг на фронте Нет, теперь бэку, помимо своей основной работы, придется выполнять также и работу фронтендеров, столь заботливо переложенную на них фреймворком Pusa.     DOMBody()->DOMChilds('GUID', self::ID)->DOMValue(clGUID()); Здесь нет ничего, что бы относилось к "бизнес-логике", здесь исключительно гуйная логика, которая выполняется не там, где должна бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #15

13. Сообщение от Аноним (12), 11-Дек-21, 10:32	+/–
> на медленном соединении вы получите для JS решения задержки загрузки фрэймворка и прочей графики Да, один раз. При самом первом заходе на сайт. Дальше браузер все закэширует. > Если вы представите разумный case - мы постараемся сделать демонстрацию решения. Критерий разумности - 1 час исполнения. Предлагаю написать todo list, потому что его я в демках не нашел. При сравнении гуйных фреймворков todo list является хелловорлдом, позволяющим оценить базовый концепт фреймворка. При этом хочется увидеть демонстрацию виртуализированного скролла, потому что в реальном энтерпрайзе данных будет много. А поскольку постулируется, что задача "не просто переместить на бэк JS, а принципиально исключить его", то виртуализированный скролл следует сделать исключительно средствами Pusa, без дополнительных клиентских библиотек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #14, #41

14. Сообщение от stillswamp (ok), 11-Дек-21, 12:32	+/–
>> на медленном соединении вы получите для JS решения задержки загрузки фрэймворка и прочей графики > Да, один раз. При самом первом заходе на сайт. Дальше браузер все > закэширует. Я давно и много смотрю на логи пользовательских запросов. Пользователям нет дела до нюансов реализации и нет дела до времени жизни страницы. Запросы на обновление всей страницы прилетают многократно чаще ожидаемого разработчиком. И... быстродействие продуктового сайта оценивается потребителем по загрузке первой страницы. >> Если вы представите разумный case - мы постараемся сделать демонстрацию решения. Критерий разумности - 1 час исполнения. > Предлагаю написать todo list, потому что его я в демках не нашел. > При сравнении гуйных фреймворков todo list является хелловорлдом, позволяющим оценить > базовый концепт фреймворка. При этом хочется увидеть демонстрацию виртуализированного > скролла, потому что в реальном энтерпрайзе данных будет много. А поскольку > постулируется, что задача "не просто переместить на бэк JS, а принципиально > исключить его", то виртуализированный скролл следует сделать исключительно средствами > Pusa, без дополнительных клиентских библиотек. Case Todo обсуждался нами для демки, но был отклонена в тч мной, так как кода чуть более чем надо для представления элементарных основ. Демка todolist была разбита на форму авторизации (отправка POST), подгружаемый список элементов GUID, и интерактивное добавление элементов графики: https://dev.pusa.catlair.net/?section=Examples. Тем не менее, с учетом нового внешнего мения о необходимости todo list в демонстрации, мы еще раз обсудим это и возможно выложим. Все же от вас ожидался примитивный но показательный тест, убивающий концепцию Pusa.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

15. Сообщение от stillswamp (ok), 11-Дек-21, 12:39	–1 +/–
>> сократить девелопинг на фронте > Нет, теперь бэку, помимо своей основной работы, придется выполнять также и работу > фронтендеров, столь заботливо переложенную на них фреймворком Pusa. >     DOMBody()->DOMChilds('GUID', self::ID)->DOMValue(clGUID()); > Здесь нет ничего, что бы относилось к "бизнес-логике", здесь исключительно гуйная логика, > которая выполняется не там, где должна бы. Поясню принцип: если работу можно выполнить одному специалисту одним инструментом без потери качества и времени, это лучше сделать именно так, так как исключает расходы на координацию. Pusa не про то что "ай бэку нужно делать фронт". Pusa - техническое средство решающее финансовые вопросы унификацией инструментария и специализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #16, #49

16. Сообщение от Аноним (12), 11-Дек-21, 19:01	+/–
При этом предполагается, что у проекта будет только веб-клиент (причем один, а не несколько альтернативных). Как только понадобится десктоп- или мобильный клиент, всю работу с домом из бэка придется убрать. Потому что фреймворк поощряет идти неверным путем, когда бэк не дает вменяемого интерфейса/схемы и возвращает в ответе черт-те что, прибитое гвоздями к пользовательскому стейту. Далее, как только будет необходим шаг вправо/влево, что-нибудь не предусмотренное фреймворком, ничего не останется, кроме как обратиться к разработчикам фреймворка => отсюда лишняя зависимость от сторонних чуваков, их занятости и заинтересованности. Заинтересованность скорее всего придется банально покупать. Так не проще ли платить своему же фронтендеру, сидящему за соседним столом? Далее, фреймворк предполагает, что бэк-разработчик, помимо своей основной специализации, также владеет как минимум HTML и CSS, а также понимает, в какой аналогичный JS-код выполнятся все эти DOMXxx()-вызовы. Что, очевидно, далеко не всегда так. Если скомпилировать все веб-стандарты (фронт-онли) в единую книгу, получится талмуд, на порядки толще стандартов для целых операционных систем. Поэтому я бы не говорил про отсутствие потери качества. Далее, постоянно приводится пример, когда работает всего "один специалист": "работу можно выполнить одному специалисту одним инструментом" — в связи с этим фреймворк выглядит как временное решение на самом старте бизнеса, от которого постараются избавиться, как только у компании найдутся деньги на найм фронтендера. Далее, для фреймворка такого типа выбран странный транспорт - XHR, когда как веб-сокеты не предполагают переподключения на каждый чих (а чихов будет много -- реакция на гуйные события как-никак). Можно же задействовать XHR в качестве фолбэка в конце концов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #17

17. Сообщение от stillswamp (ok), 11-Дек-21, 20:16	+/–
1. Контекст отображения не имеет принципиально никакого значения с точки зрения фэймворка. Прошу пояснить каким образом конечное устройство влияет на бэк и почему его придется убрать? 2. Повторю ранее заданный в этой же ветке вопрос. Представьте case который не реализуем в Pusa на текущий момент. Он будет либо сделан либо явно включен в ограничения. 3. Разработчк на Pusa НЕ РАБОТАЕТ с DOM. Он оперирует крайне ограниченным набором инструкций которые могут формировать DOM, при этом об его фактическом устройстве знать не обязательно. DOM* функционал Pusa - не более чем набор конечных инструкций. Если вы занимались разработкой под opengl, то подход для вас будет знаком. Разраб работает с инструкциями а не с контекстом. Это принципиально важно. 4. Один разработчик - это крайний пример плоской схемы, когда у вас в наличии вместо нескольких направлений с необходимостью координации линейные бэки. Не погибнет эта схема с расширением бизнеса. Pusa создана масштабированием и под оное. 5. XHR выбран в качестве САМОГО примитивного варианта для демонстрации схемы и доказательства ее работоспособности. Так же была выполнена реализация на iframe, но была отклонена что бы не пугать людей. Мы планируем представить реализации как минимум на ws для golang, java, node.js. При этом мы по прежнему будем настаивать на исключении хранения состояния клиента на бэке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #18

18. Сообщение от Аноним (12), 11-Дек-21, 21:06	+2 +/–
DOMChilds('GUID', self::ID) -- этот код может не сработать. Потому что у альтернативного веб-клиента такого инпута может не оказаться. DOMParent()->DOMParent() -- требует жесткой иерархии элементов. Если оформлять таким образом весь апи бэка, то в конце придем к ситуации, когда малейшее изменение в HTML повредит половину функционала. В реактах это не так, там явно прописываешь <span>{age}</span>. Ни один из этих примеров не сработает для мобильного клиента. Вот как мне выдрать person name из примера "Read data parameters"? Pusa[3][1].Values.innerHTML? Бред же. > Представьте case который не реализуем в Pusa на текущий момент А очень просто. Берешь вот эту страницу: https://developer.mozilla.org/en-US/docs/Web/API И сверяешься с тем, есть ли аналогичный апи в протоколе: https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/src/la... Мне например интересно, как будет организована кнопка копирования в буфер обмена. Вдуматься только: чтобы скопировать в буфер, нужно будет послать сигнал бэку, чтоб тот прислал ответ: "хорошо, копируй в буфер то, что у тебя в клиент-стейте выделено, я хз, че у тебя выделено, но скопируй". А при медленном соединении полагаю, будет что-то типа, что пользователь жмет Copy, немедленно переключается альт-табом в ворд, вставляет -- а там старое содержимое. Потому что ответ бэка пришел слишком поздно, в момент, когда браузерная вкладка уже не в фокусе, так что браузер запретит записывать в буфер. (А в некоторых браузерах в клипбоард можно записывать только и только из event handler; ставишь setTimeout или ждешь бэка? -- откажут в доступе к клипбоарду.) > Разработчк на Pusa НЕ РАБОТАЕТ с DOM Семантика. Хорошо, JavaScript-разработчик тоже не работает с домом. Он просто посылает в браузер файл с расширением ".js", а браузер его интерпретирует как хочет, в том числе меняет дом. Прямо сейчас в протоколе я вижу императивные команды: DOMSelect, DOMCreate... Это вполне себе работа с домом, просто все команды сериализованы для передачи по сети. DOMParent говорит о том, что бэк в курсе, че там как устроено в доме. Ну и интересно, как выводить текст типа "Подождите, операция выполняется". Допустим, в примере "CRUD Form" я хочу, чтобы нажатие на кнопку выводило где-нибудь throbber. Как это сделать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #19, #31

19. Сообщение от stillswamp (ok), 11-Дек-21, 22:53	+/–
1. Что такое альтернативный веб клиент? Если это один проект, то следует задать вопрос его создателям каким образом в проекте не учитывается отсутствие элемента. Если ваш JS нацелен на наличие этого элемента а его нет, то что тогда? 2. Вы всегда имеете жесткую иерархию элементов. DOM - это жесткая иерархия. Если вы ее создали то вы на нее можете опереться. Тем не менее, методы обращения к элементам без иерархии в Pusa ничем не отличаются от нативного JS только запись короче и не нужен JS :) DOMBody() -> DOMSelect('myelement'); document.getElementsByClassName( 'myelement' ); 3. Я вынужден еще раз уточнить, почему вы делаете различие между мобильными клиентом и каким либо иным. Это всего лишь DOM, управление которым находится в ваших руках. 4. Pusa[3][1].Values.innerHTML - подробнее, это двумерный массив в котором лежит некий элемент Values? Если да, то Pusa не работает в JS. Или ваш пример о чем то другом? Плс... 5. Сравнение спецификаций WebAPI не очень. Предлагаю общностями не оперировать. Только конкретика показывает проблемы и позволяет их решить. 6. Copy() функция копирования будет вычищена из родительского проекта и добавлена в Pusa (код pusa.js возможно уменьшится...). Copy() положит выделенный контент в буфер. Касательно соединения, обратите внимание на это: https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/src/la... это. Pusa умеет делать своеобразные "замыкания", которые не требуют обращения к back: $this -> DOMSelect('CopyButton')->EventFront( $this -> Clone() -> Copy() ); Это красиво :) 7. Повторюсь. Бэк не в курсе как устроен DOM. Бэк обладает набором последовательных инструкций. Как они сложатся в DOM - проблемы браузера а не бэка. Те все то же самое как и в вашем примере, только нет лишнего средства JS. 8. Касательно сообщений и оконного интерфейса. Документацию пишем усиленно НО с тем как это устроено можете ознакомится https://gitlab.com/catlair/pusa/-/blob/main/php/web/win.php. Там и попапы, и диалоговые окна и прочий оконный ифейс с минимизациями максимизациями. Это так же красиво. С благодарностью ожидаю конкретных кейзов закатающих Пусу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #22

20. Сообщение от морошка ягодка такая (?), 12-Дек-21, 11:50	+1 +/–
а нельзя просто дотнет + wasm взять?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #30

21. Сообщение от Sw00p aka Jerom (?), 12-Дек-21, 12:13	+/–
>Поверьте - вопросы нагрузки на сервера - мелкая мелочь по сравнению с предлагаемыми возможностями. мелочь говорите? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #24

22. Сообщение от Аноним (12), 12-Дек-21, 14:14	+/–
> Что такое альтернативный веб клиент? Все, что угодно. Еще одна веб-страница, созданная с нуля, с другой версткой, но тем же бэком. Если бэк грамотно опишет свои интерфейсы, например в виде GraphQL-схемы, то выводить ответ бэка можно хоть в дом, хоть не в дом, хоть на принтер, хоть в консоль, хоть лазером на стену собора парижской богоматери. > различие между мобильными клиентом и каким либо иным Под мобильным клиентом подразумевались нативные андроид- и айос-приложения, где вообще нет никакого дома. Сценарий: допустим уже функционирует сайт на этом фреймворке. Компания решается разработать мобильное приложение и приглашает соответствующего специалиста. Как ему достать person name? Прямо сейчас -- парсить JSON-ответ и доставать person name по страшному пути "Pusa[3][1].Values.innerHTML". Заходи на свой Examples, жми кнопки, мониторь сетевую активность в F12 и подумай, как этот ответ выводить НЕ в дом. Когда это сделает андроид-разработчик, у него зашевелятся волосы сразу во всех местах: const personName = JSON.parse(response).Pusa[3][1].Values.innerHTML. > Сравнение спецификаций WebAPI не очень. Ты требуешь у меня списка того, что твой фреймворк не умеет. Я его тебе дал. Из этого длинного списка (толщиной в книгу) можешь вычеркнуть getElementById, getElementsByClassName, classList.add, classList.remove и еще парочку методов. Всё остальное не поддерживается. > Бэк не в курсе как устроен DOM В курсе, если он делает DOMParent и прочие штуки. Если бэк употребляет слово DOM, если он хоть как-то оперирует дом-терминами (parent, child, attr &cetera), то он знает про то, куда будет выводиться ответ. > Бэк обладает набором последовательных инструкций Причем не просто инструкций, а дом-инструкций. Если бы дом не знал про дом, он бы присылал просто {personName: "Andy"}, а не сериализованные команды инсёрта в дом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #23

23. Сообщение от stillswamp (ok), 12-Дек-21, 21:11	+/–
> Все, что угодно. Еще одна веб-страница, созданная с нуля, с другой версткой... Вы выставляете правильное требование и именно оно породило MVC концепцию, когда приложение имеет слои. Есть слой логики, слой отображения. Ваше приложение должно получить реализацию новой верстки. А Pusa поможет это сделать на единой платформе. >> Сравнение спецификаций WebAPI не очень. > Ты требуешь у меня списка того, что твой фреймворк не умеет. Я > его тебе дал. Из этого длинного списка (толщиной в книгу) можешь > вычеркнуть getElementById, getElementsByClassName, classList.add, classList.remove > и еще парочку методов. Всё остальное не поддерживается. JS на ОЧЕНЬ значительную часть состоит из обслуживания самого JS, который и составляет книгу. А на выходе ограниченный функционал, который Pusa и реализует. Между требованием типового функционала и возможностями Pusa есть некий люфт. Моя задача сделать его минимальным, потому я и веду эту переписку с вами с целью узнать ваши пожелания. > В курсе, если он делает DOMParent и прочие штуки. Если бэк употребляет > слово DOM, если он хоть как-то оперирует дом-терминами (parent, child, attr > &cetera), то он знает про то, куда будет выводиться ответ. Приведу пример - вы получаете инструкцию: - зайдите в комнату. - включите свет. От того кто пишет инструкцию - не требуется ни понимания комнаты, ни понимания как включается свет. При этом вы МОЖЕТЕ выполнить эту инструкцию. От кодера Pusa НЕ требуется понимания реализации DOM. Только понимание последствий инструкций. и да... DOM команды названы исключительно вас, так как вы знаете что такое DOM. Для человека не представляющего что такое DOM это просто набор инструкций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #26

24. Сообщение от stillswamp (ok), 12-Дек-21, 21:20	+/–
>>Поверьте - вопросы нагрузки на сервера - мелкая мелочь по сравнению с предлагаемыми возможностями. > мелочь говорите? :) Оцените по вашему опыту сумму затрат для публичного ресурса с постоянной доработкой функционала для 1k 10k 100k уникальных визитов ежемесячно по статьям: - стоимость команды разрабов включая налоги а так же затраты на их координацию; - стоимость ресурсов для работы проекта на прод; Данные если пожелаете, можно сложить сюда. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #27

25. Сообщение от stillswamp (ok), 12-Дек-21, 21:23	+/–
> а нельзя просто дотнет + wasm взять? С удовольствием обсужу в телеге если у вас есть опыт реализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

26. Сообщение от Аноним (12), 12-Дек-21, 22:10	+/–
Не увидел ответа, как к существующему сайту на фреймворке прикрутить нативное мобильное приложение. > не требуется ни понимания комнаты, ни понимания как включается свет Зато требуется понимание того, что на клиенте будет и комната, и свет. А в случае с Parent это выглядит так: "переместись на два этажа выше, выдвинь ящик №83, там будет листок бумаги, запиши туда то-то". Все развалится, едва ящик переедет на этаж выше. Или если в определенный момент вместо бумаги туда положат степлер. А в больших проектах, где над ним трудится от 1000 человек, такие правки появляются не ежедневно, а ежеминутно. В итоге, если потребуется просто немного перевестать страницу, нужно потрогать и бэк. Признаком дурно пахнущего кода является то, что какое-то незначительное изменение ведет к правке сразу нескольких файлов в самых неожиданных местах (в данном случае они вообще на разных полюсах - фронт и бэк). Правильная архитектура: - бэк отдает минимум информации, и отдает именно данные, а не "команды", - клиенты эти данные выводят так, как им заблагорассудится, хоть в дом, хоть еще черт-те куда. Имея такую архитектуру, можно распараллеливать разработку: если бы я был мобильным разработчиком, мне бы вообще не пришлось у себя разворачивать LAMP, мне бы просто скинули URL тестового стенда, и я бы спокойно пилил клиент без необходимости правок в бэк. Какой-нибудь фронтендер в это время бы пилил свою часть, имея ровно тот же URL стенда. И никто друг с другом не пересекается (меня например на работе вообще никто в лицо не видел).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #28

27. Сообщение от Sw00p aka Jerom (?), 13-Дек-21, 00:13	+/–
>Оцените по вашему опыту сумму затрат зачем мне оценивать сумму затрат, меня интересует вопрос нагрузки, какую нагрузку способно держать ваше решение для минимум одной ноды (одной запущенной версии приложения).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #29

28. Сообщение от stillswamp (ok), 13-Дек-21, 10:00	+/–
Мы перешли от обсуждения реализации Pusa к архитектурным вопросам. > Не увидел ответа, как к существующему сайту на фреймворке прикрутить нативное мобильное > приложение. Ответ по существу. Бэк содержит три уровня: - Логика приложения - (источник данных для API) - API - (данные) - View - (строит вывод на основе API) Кому не нужна вьюха берут данные с API. > И никто > друг с другом не пересекается (меня например на работе вообще никто > в лицо не видел). Это нормальная практика. При этом на координацию бэков и фронтов тратятся ресурсы. Чудес не видел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

29. Сообщение от stillswamp (ok), 13-Дек-21, 10:08	+/–
>>Оцените по вашему опыту сумму затрат > зачем мне оценивать сумму затрат, меня интересует вопрос нагрузки, какую нагрузку способно > держать ваше решение для минимум одной ноды (одной запущенной версии приложения). 1. Потому что я, отвечая на комент (мелочь говорите?), сопоставлял стоимость разработки (которую возможно сократить) за счет стоимости инфраструктуры (которую возможно расширять не придется). 2. В каких попугаях мерять нагрузку? Текущие сервера ценой 2.7евро в мес PHP реализации отдают средний запрос от 30 до 70 мс (можно сократить до 10-15мс). Сервера паралелятся путем простого копирования. Распределение запросов между серверами - nginx зонтик. Сколько вам нужно обработать запросов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #33

30. Сообщение от username (??), 13-Дек-21, 13:12	+/–
Просто взять http://www.rebol.com/docs/cgi2.html и http://www.rebol.net/plugin/tests/plugin-guide.html :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #32

31. Сообщение от stillswamp (ok), 13-Дек-21, 13:50	+/–
> А при медленном соединении полагаю, будет что-то типа, что пользователь жмет > Copy, немедленно переключается альт-табом в ворд, вставляет -- а там старое > содержимое. Потому что ответ бэка пришел слишком поздно, в момент, когда > браузерная вкладка уже не в фокусе, так что браузер запретит записывать > в буфер. (А в некоторых браузерах в клипбоард можно записывать только > и только из event handler; ставишь setTimeout или ждешь бэка? -- > откажут в доступе к клипбоарду.) Добавлен пример Copy в буффер - https://pusa.catlair.net/?section=Examples - https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/php/pu... Благодарим за идею.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

32. Сообщение от stillswamp (ok), 13-Дек-21, 13:52	+/–
> Просто взять http://www.rebol.com/docs/cgi2.html и http://www.rebol.net/plugin/tests/plugin-guide.html > :) Читать умею. Поиском пользоваться тоже. Интересен реальный опыт использования. А еще смущает вот это: 2. System requirements In order to use REBOL/Plugin, end-users viewing your web site must have: Windows 95 or higher. Linux, and Macintosh are currently not supported. Internet Explorer 4.0 or higher. Netscape and other browsers are currently not supported.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

33. Сообщение от Anonimus (??), 16-Дек-21, 22:48	+/–
> Текущие сервера ценой 2.7евро в мес PHP реализации отдают средний запрос от 30 до 70 мс (можно сократить до 10-15мс). И не только php, а также nodejs, go, rust и большая туча других языков. > 2. В каких попугаях мерять нагрузку? RPS и latency на одном и том же оборудовании: https://www.techempower.com/benchmarks/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

34. Сообщение от mos87 (ok), 17-Дек-21, 10:14	+/–
т.е. он всю клиентскую часть хранит на сервере, а на клиент спускает её в готовом виде. отлично. остался 1 вопрос - нафейхуа нам этот Веб вообще, если фактически мы уже честно признаёмся себе, что желательно все его концепции обходить вокруг? Может пусть ОС будет ОС, а эту прослойку выкинуть уже
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #36, #48, #50

35. Сообщение от gred (ok), 19-Дек-21, 13:21	+/–
я бы сказал, что для каких-то чисто внутрикорпоративных вещей, почти идеально. осталось накрутить вокруг этого какой-то действительно удобный RAD.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

36. Сообщение от gred (ok), 19-Дек-21, 13:26	+2 +/–
вот, кстати, да...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

37. Сообщение от Аноним (-), 23-Дек-21, 06:51	+/–
Судя по описанию - сделано ящерами с планеты ниибиру, видимо на js у них аллергия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

38. Сообщение от онанимус (?), 27-Дек-21, 12:59	–1 +/–
шикарная идея, подобные сайты будут быстро работать даже на сименсе м65. меня волнует совместимость с кравлерами поисковых движков - гугол сотоварищи нормально их индексирует? в яваскрипт все кравлеры умеют, даже богомерзкий wix хорошо индексируется. а вот будет ли кравлер заполнять и отправлять все аяксовые формы - вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #42

39. Сообщение от Аноним (39), 27-Дек-21, 17:31	+/–
А в чем невообразимость? Js при данных подходах все равно нужен, который ещё нужно вытянуть с соответствующих доменов. Достаточно забанить клиентскую часть и все эти свистоперделки превращаются в тыкву.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

40. Сообщение от 18d75a8d3a9b403d82e5f66cdc5d204a (?), 29-Дек-21, 12:50	+/–
Что люди только не делают, чтобы Blazor не использовать.
Ответить | Правка | Наверх | Cообщить модератору

41. Сообщение от stillswamp (ok), 29-Дек-21, 19:36	+/–
Ваше мнение принято. Выложили helloworld (todo) на Pusa. Ссылка: https://dev.todo.catlair.net/ Контейнер c готовым проектом: https://hub.docker.com/r/catlairnet/pusa_todo_demo Ну и исходники: https://gitlab.com/catlair/pusa/-/tree/main/site/todo Жаль что аноним... а то бы посчитали в списке благодарностией.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

42. Сообщение от stillswamp (ok), 29-Дек-21, 19:37	+/–
> шикарная идея, подобные сайты будут быстро работать даже на сименсе м65. > меня волнует совместимость с кравлерами поисковых движков - гугол сотоварищи нормально > их индексирует? > в яваскрипт все кравлеры умеют, даже богомерзкий wix хорошо индексируется. а вот > будет ли кравлер заполнять и отправлять все аяксовые формы - вопрос. Да. Pusa работает даже на "тапке". Причем как клиент так и сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

43. Сообщение от stillswamp (ok), 29-Дек-21, 19:39	+/–
> я бы сказал, что для каких-то чисто внутрикорпоративных вещей, почти идеально. > осталось накрутить вокруг этого какой-то действительно удобный RAD. Если вы храните состояние DOM на сервере - то действительно это не для выпуска наружу. Держать DOM для каждого внешнего пользователя крайне затратно. Но Pusa как раз не хранит состояния пользователя на сервере. Чистый REST.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

44. Сообщение от морошка ягодка такая (?), 01-Янв-22, 10:40	+/–
Можно же на c# писать, через blazor.
Ответить | Правка | Наверх | Cообщить модератору

45. Сообщение от CHH (?), 28-Янв-22, 15:44	+/–
...у нас была возможность не только познакомиТЬся с исходным... У меня всё.
Ответить | Правка | Наверх | Cообщить модератору

46. Сообщение от ford153focus (ok), 04-Фев-22, 12:15	+/–
если цель в выбрасывании js из разработки, то что на счёт PIB? https://github.com/oraoto/pib
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #53

47. Сообщение от DD (??), 04-Фев-22, 23:25	+/–
Here is a solution to you - JavaScript in browse!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

48. Сообщение от DD (??), 04-Фев-22, 23:26	+/–
+100500
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

49. Сообщение от Бывалый смузихлёб (?), 14-Мрт-22, 07:01	+1 +/–
Если речь не о самом примитивном конструкторе страниц из готовых блоков, то задача становится совсем непростой. И тот «один специалист-бэкендер-скалист( такие вообще в природе существуют в ощутимых количествах? )» вмиг превращается в фуллстека, притом не самого плохого с необходимостью понимания очень многих штук. Нюанс в том, что можно хоть треснуть, но стили на клиенте в итоге все равно будут в CSS ( лучше в файлах, инлайн плохо кешируется и обработка его жрет много ресурсов ) Равно как и основная «динамическая» работа будет на JS. И «не работать» с ним удастся только при применении готовых блоков( в которых уже кто-то поработал ), в иных случаях - по многим причинам придётся ещё и жс как-то заталкивать чтобы он не сломал систему. И ещё один, но фундаментальный нюанс в том, что сетевые запросы требуют времени и немалого. В этом смысле нет большой разницы, весит ли скрипт 6кб или 60 - скорее всего, само время сетевых запросов будет больше длительности скачивания. В данном же случае пользователю, чтоб увидеть первую норм страницу, потребуется ожидание нескольких запросов и отработки скриптов, сама реакция на изменения будет с лагом. Особенно это критично в случае разных анимаций и проч, завязанных на действия пользователя( где-то что-то начал вводить, где-то провёл мышкой или пальцем по тачскрину - это ж сколько запросов полетит на сервер, итд ) Хотя сама идея, в общем и целом, весьма интересна. Есть подозрение что для внутренних корпоративных систем будет очень даже годно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

50. Сообщение от Аноним (50), 13-Апр-22, 11:49	+/–
Web нужен для связи - это связь. Всё. Веб - только канал передачи данных. "Все его концепции" - это придумки способа использования канала связи. Затеи отдельные от веба. Часто затеи невыгодны конечному клиенту, т.к. приводят к необоснованным тратам. Люди исследуют альтернативные способы. Существование альтернативы развивает и укрепляет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #52

51. Сообщение от Аноним (51), 27-Апр-22, 09:08	+/–
Опять пытаются сэкономить на разработчиках за счёт комфорта пользователя. Теперь сетевые лаги будут на каждый клик и ховер? И да, разделение труда не просто так придумали.
Ответить | Правка | Наверх | Cообщить модератору

52. Сообщение от mos87 (ok), 13-Май-22, 18:21	+/–
вэб [единственное что щас примечательно в нём технологически] - это реализация той самой "мечты" о компонетном погромировании. Все эти лежащие на публичных хостах жабаскрипты которые можно заюзать у себя. COM done... не right конечно, а просто done. Со всеми ужосами (в первую голову безО) которые и предрекали компонетнке. он в такое развился просто потому что был распространён вэб в своём изначальном виде. и поверх него выросло нынешнее чудо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

53. Сообщение от rex (??), 15-Июн-22, 14:21	+/–
избавиться от клиентского кода, чтобы абстрагировать писателя бизнес-логики от сети
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема