Опубликован web-фреймворк Pusa с реализацией концепции, переносящей логику фронтэнда, выполняемую в браузере при помощи JavaScript, на сторону бэкенда - управление браузером и DOM элементами, а также бизнеслогика выполняются на бэкенде. Выполняемый на стороне браузера JavaScript код заменяется на универсальную прослойку, вызывающую обработчики, находящиеся на стороне бэкенда. Необходимость разработки с использованием JavaScript для фронтэнда отсутствует. Эталонная реализация Pusa написана на языке PHP и распространяется под лицензией GPLv3. Кроме PHP технология может быть реализована на любому другом языке, включая JavaScript/Node.js, Java, Python, Go и Ruby...Подробнее: https://www.opennet.me/opennews/art.shtml?num=56140
>Pusa-Front посредством Ajax-запросов направляет события браузера (такие как click, blur, focus и keypress) и параметры запроса (элемент вызвавший событие, его атрибуты, URL и т.п.) в серверный обработчик Pusa-Back.Интересно, насколько всё это требовательно к сети? Допустим, на десктопах и на мобильниках в городе проблем не будет, ок, а что на счёт того, когда качество сети плохое?
>Среди достоинств выделяются
А среди недостатков? Сказали а, говорите и б!
Говорили "б", выше по тексту.> Из недостатков метода также отмечается перенос части нагрузки с фронтэнда на бэкенд и увеличение частоты обмена данными с сервером.
.
Там даже безопастный Раст не поддерживается, о чем говорить
> насколько всё это требовательно к сети?Ты посмотри, сколько сейчас современная морда ютуба генерит паразитных запросов через аякс...
идея интересная, но современный веб так откормил своих клиентов, что заднюю просто так не включит, хотя для локальных решений очень даже годно
Ты наверно не улавливаешь как быстро там все меняется. Если тема годная на неё перейдут все и очень быстро. Но это Пуса звучит как не очень годная.
перейдут все если гугл скажет. а годность или не годность технологии практически ни на что не влияет.
Наврядли гуглу это интересно. Все эти JS frameworks типа REACT были придуманы чтобы ослабить нагрузку на сервера+сеть и вынести на клиентскую часть как можно больше, оставив на бэкендах только контроль и данные.
Хотя, времена идут, железо для них не проблема и если события с клиента (т.е. его повидение) как-то можно конвертировать в профит, (а это их главная цель - собрать все, какие только можно данные), то может и взлетит, но только для определенной группы, над кем надо пасти неустанно, иначе загнется и сеть и сервера :) но в будующем, вполне возможно и перейдут на Пузо, уж очень лакомый для них кусок данных
А вот поддерживаю.
Гугл знатно экономит за счёт пользователей, но при их объёмах это, в общем-то, и понятно.
Шиш вам гугл просто так согласится вернуться нагрузку на сервера. Они вон всё сделали, чтобы её оттуда забрать. И сэкономить 2-3 байта на каждом запросе тоже очень постарались. Потому что для сайта с 2 тысячами и даже миллионами посетителей в день пару лишних байт при нынешних скоростях не окажут влияния. А для клиента, как ни странно, всё будет даже быстрее. А вот для гугловской аудитории это огого. Пусть весь жир переваривают компы клиентов. Ну и заодно полирнули мозги неокрепшим умам, что так на самом деле красивее, интерактивнее, нравится пользователю, хотя по факту гугл просто экономит. Но я видел людей, которые на полном серьёзе утверждали, что "так же круче", "смотрите, какая красота" и т.д., и т.п.
Только я наблюдаю такой вот парадок: скорости и мощности растут, а обычные сайты для конечного пользователя становятся всё тормознее и тормознее. Да, удалось создать интересные штуки, типа draw.io например. Но это скорее штучные примеры. При этом для простой инфы вижу отличную скорость загрузки и рендера "простых-тупых" страничек. Но это не модно.
Такая штука из топика - это большой шаг назад для гугла в плане экономии. Разве только что это даст ещё больший контроль над действиями и анализ их, а это может и привлечь.
Ага, а по итогу страницы весят по 100500 мегабайт, ресурсы тупят даже на хорошем канале, а нагрузка на бэкенде не сильно ниже.
То-то же на Ангуляр все перешли (нет)
На ангуляре кстати можно перенести рендеринг на сервер, при желании. Такой проект был. Только не нужен никому, разумеется.
Беда в самом Ангуляре - точнее в его наличии и размерах.
> Pusa-Front посредством Ajax-запросов направляет события браузера (такие как click, blur, focus и keypress) и параметры запроса (элемент вызвавший событие, его атрибуты, URL и т.п.) в серверный обработчик Pusa-Back.Гайд, как самому DDoSнуть свой сервер.
Как только сайтом начнёт пользоваться достаточно большое количество человек, сервер просто упадёт из-за того что пользователи *кликают на веб страницу*. А если кто-нибудь подрубит автокликер, так вообще классно будет.
Я ещё понял бы если WebSockets, но AJAX -- это же новое TCP подключение и TLS-рукопожатие на *каждый эвент страницы*!Отчаянно пытаюсь понять смысл данного проекта.
Главный смысл - уменьшить количество стороннего JS-кода, выполняемого на браузере. Вкладок до OOM-киллинга можно будет открывать значительно больше.
>Главный смысл - уменьшить количество стороннего JS-кода, выполняемого на браузере.Плюс, - иметь полный контроль и надзор над клиентом
Ну, во-первых, об этом уже знаю я. Во-вторых, об этом, разумеется, узнает китаец...Нет, ну ты правда надеешься пользуясь сайтом делать это как-то так чтобы никто не догадался что ты это делаешь? Учти - китаец ЭТОГО дела ооооочень не любит!
> Нет, ну ты правда надеешься пользуясь сайтом делать это как-то так чтобы
> никто не догадался что ты это делаешь?И что? это кого-то останавливает юзать интернет? Все знают что делает гугл и метаморда и ничего, кормят их исправно
> Учти - китаец ЭТОГО дела ооооочень не любит!
У китайцев у самих, еще "лучше" в этом плане, там инернет, такой как мы знаем не имеет популярности, у них большинство сидят на апп в телефоне, без которой там даже чихнуть не получится
В случае HTTP/2 и HTTP/3 — нет.
Да и HTTP/1 нет, если keep-alive используется.
То есть примерно всегда.
Просыпаемся и машем, сейчас не 2008. Все браузеры давным-давно его передают да и я не видел ни одного сайта, который бы отвечал Connection: close. Даже opennet оставляет соединение открытым.
> Да и HTTP/1 нет, если keep-alive используется.KeepAlive не используется.
> KeepAlive не используется.- Используй KeepAlive, Люк! (с)
> Я ещё понял бы если WebSockets, но AJAXТочняк, там предлагают REST или gRPC, а не Websocket. Это полная ж
> Я ещё понял бы если WebSockets, но AJAX -- это же новое
> TCP подключение и TLS-рукопожатие на *каждый эвент страницы*!Ну, на самом деле "keep-alive" никто не отменял, так что для обеьктивности, - то не "на каждый чих"
На вебсокетах тоже есть, правда на эликсире https://github.com/phoenixframework/phoenix_live_view
Смысл проекта - полностью убрать необходимость координации между бэками и фронтами при разработке.
> Я ещё понял бы если WebSockets, но AJAX -- это же новое
> TCP подключение и TLS-рукопожатие на *каждый эвент страницы*!
> Отчаянно пытаюсь понять смысл данного проекта.Pusa - протокол.
Для понимания сути и демонстрации необходима демка.
Демка должна быть простой - AJAX (не WS).Это сделано.
Может быть гуд для нетривиальных интерфейсов, где конкретная визуалка и реакция определяется текущим состоянием сервера. Без костылей в виде рефреша при серьёзном изменении такового состояния.
livewire от laravel Работат на ajaxтут вопрос больше что проще спроектировать архитектуру и отмасштабировать сервер 1 раз (или просто платить облачному провайдеру ) или нанимать дорогих фронтендеров - которые будут переписывать и оптимизировать проект каждый день на новую версию фреймворка
> если кто-нибудь подрубит автокликер, так вообще классно будет.если подрубить даже на сайте SPA которое не сферический конь в вакууме и который не ходит на бекенд - будет то же самое
"сайт" может быть вообще не публичный. Просто несколько сотен разных устройств в пределах предприятия.
Что-то не пойму, это заново изобретен "Web 1.0"?
очередной оборот колеса Сансары
Фигушки ! их сайт https://pusa.catlair.net/ даже не открывается без JS :)
кстати, да, белое пустое место - лучшая антиреклама поделки.
Не просто без js, а без единственноверного js в распоследней версии Браузера (единственноверного, конечно, куда вы тут лезете со своим lynx, плевать нам на слепых)
Разработчикам нет необходимости работать с JS на клиенте.
Сам JS никуда не делся.
> Разработчикам нет необходимости работать с JS на клиенте.
> Сам JS никуда не делся.Я понимаю, просто думаю было бы лучше, если при условии запрещеного ЖС, былo бы какое-то сообшение, костяк, как vue, ну или на худой конец пихуть tag <noscript> вместо пустой страницы.
А вообще, спасибо за продукт, я уверен, он найдет свое место, особено учитывая, что в отличии от GWT, Zk, вы сделали попытку стандартизировать процессинг на бэкенде
да проект интересный
есть аналоги - но слишком много тащат - например blazor тащит рантайм .net скопмилированный в wasmбыло бы неплохо поддержку SSR - например включать режим полного ренддера страницы на сервере - а затем уже погружать если js функционирует
для тех кому нужно сео или например хотят поддержку функционирования в браузерах без js
Pusa может ПОЛНОСТЬЮ собрать всю страницу на голом html и отдать готовую.
Это один из вариантов внутренней организации.пример:
TemplateMain.html
<html>
<body>
<cl content="BodyContent.html">
</body>
</html>TemplateBody.html
Hello WorldРезультат:
<html>
<body>
Hello World
</body>
</html>Работает шикарно.
Так ета, а зачем еще один шаблонизатор? Их уже и так выше крыши наштамповали. Есть же PHP. Или по вашему шаблонизатор написанный на шаблонизаторе работает эффективнее? Или это по принципу "этот мир придуман не нами, потому сварганим другой"?
> Так ета, а зачем еще один шаблонизатор? Их уже и так выше
> крыши наштамповали. Есть же PHP. Или по вашему шаблонизатор написанный на
> шаблонизаторе работает эффективнее? Или это по принципу "этот мир придуман не
> нами, потому сварганим другой"?Простые вещи проще делать самим.
Нет, X.
Это ответ на слишком умные, настраиваемые и контроллируемые пользовталеем браузеры. Если во времена IE страница что сказала, то и происходит - вся рекламка прогружается например, Активексы всякие, то сейчас у пользователй в арсенале есть всякие настройки разрешения страницам, фильтры и блокировщики. А это, как показала практика, изрядно раздражает сайтоделов.Вот пример - сделали поддержку видео в браузере и сразу появились видеобаннеры и даже встроенные рекламные видеоролики. Естественно запускались они сами сразу же и с орущей громкостью. Гугл сказал - "Хром будет блокировать автозапуск роликов с звуком" (уже нарушение идеальных стандартов как бы) и все были вынуждены звук убрать. Другие браузера разрешили блокировать автозапуск даже без звука и теперь рекламщики изгаляются чтобы ролик все таки запустить (и у них к сожалению получается).
Отсюда и все эти подвижки в сторону "контроллировать целостность страницы", "не давать показывать код".
Схема такая же как с Google Stadia или Geforce Now - если игры в облаке то пиратсво невозможно. Если сайты будет рендерить сервер, то у пользователя контроля не будет.
>Гугл сказал - "Хром будет блокировать автозапуск роликов с звуком"А можно было просто исключать сайты, где такое происходит, из выдачи. Разумеется, за исключением ютюба.
Сайты не контролируют рекламу, которую они показывают. Google контролирует её. Гугл мог бы на своей стороне заблокировать доставку рекламных роликов со звуком, но это с его стороны было бы деятельностю вида мухи против гoвнa. Ему выгоднее доставить ролик, снять за это денег с рекламодателя, а потом не показывать его пользователю, чтобы не раздражать.
Не только гугл контролирует рекламу. Вот они и боролись с конкурентами, чтобы только гугл контролировал рекламу. Заодно чтобы в глазах пользователей хорошо выглядеть, типо мы против "неправильного" мёда.
В начале был простой HTML, и интернет был хорош. Потом решили, что нужно добавить свистоперделок. Потом поняли, что серверы не справляются с нагрузкой, и переложили часть работы на клиентов. Потом ещё. Потом поняли, что у клиентов всё тормозит, жрёт в три горла и срёт в две жопы, и начали переносить всё обратно. Глядишь, когда-нибудь вернёмся к чистому HTML. И всё снова станет хорошо
> Глядишь, когда-нибудь вернёмся к чистому HTML. И всё снова станет хорошоТы всё проспал Аноним. Уже виток сделали и назвали AMP. Хорошо не стало...
AMP это очередная попытка гугла захватить интернет и это не могло быть хорошо
AMP уже отменил сам гугл
Вы можете возвращаться прямо сейчас.
>Глядишь, когда-нибудь вернёмся к чистому HTML- идея глубже: в идеале отрисовка будет производиться на бэкенде, а в браузер будут оправляться отрисованные изображения
Трафик. Но вообще опера именно это и делает. Только там престо и он немного устарел. Отличный браузер, только им и пользуюсь всегда. Ну, на java me.
Так уже сделали, есть барузер Mighty. Он стримит сайт в клиент барузера и передаёт клики на свой сервис.
И как в таком браузере ходить по интернет-магазинам? Номера карточек тоже сервису отправлять?
давно уже веб версия libreoffice умеет отрисовыватся на канвасе или напрмер adobe photoshop тоже - без ручного написания js
но там свои нанотехнологии по типу компиляции декстоп приложения в wasm и переноса рендера через графический тулкит в браузер
Надо идти дальше чтобы искусственный интеллект перевыполнял код еще до того как пользователь к нему обратится.
А убедить пользователя, что он хотел именно того, что выдал ему ИИ - этим уже займётся товарищ майор. Тоже, разумеется, разработанный на основе ИИ.
Ага, и получим всякие спектры с мельтдаунами, только уже уровнем повыше ;)
Ну, собственно, так оно и есть. HTML5+CSS - решение, позволяющее делать красивые интерактивные сайты, не прибегая к костылям яваскрипта.
Ты мне скажи, как ты на чистом HTML+CSS создашь интерактивный календарь с выбором диапазона дат и моментальной фильтрацией рядом находящегося списка элементов по этому самому диапазону?!
Идеальный вариант - вернутся к чистому HTML. Именно по этому пути пуса и пошла.
В пределе - с клиента на сервер события, с сервера на клиент контент.
идеальный но не везденапример приложения типа гугл таблицы гугл докс и тому подобное - все на канвас перешли
flutter для web тоже рендер через канвас внедряет
Чем это принципиально отличается от Vue SSR?
Клиентский код 11 кб, вот чем.
Vue SSR - это когда фронтендеры решили что неплохо бы иногда запилить бекенд (пусть и на компонентах). в принципе прикольно - чем то отдаленно похоже так delphi компоненты - только не кидаеш на форму и не настраиваешь а пишеш рукамиа с pusa наоборот - когда бекендеры думали а не плохо бы иногда запилить фронтент на php например
и не придется становится javascriptизером и не надо руками js трогать и с мылом потом их мыть каждый раз
Следующий этап - компилировать полученный PHP код на JS и перенос его обратно на сторону клиента. Все что требуется - простенький транспортный протокол для работы с БД.
для этого уже давно придумали wasm
Суть технологии - в этом нет необходимости.
Пишем на чистом PHP без пересборок в JS.
уже есть https://gitlab.com/kornelski/babel-preset-php
Забавно - джаваскрипт гитлаба не смог мне на мобиле протокол показать.
над названием еще надо поработать.
Мы не про маркетинг. Мы про кодинг. Но Pusa - хорошее короткое имя.
Я смотрю любят программисты JavaScript велосипеды изобретать - JSF/GWT/Vaadin/ZKoss не слышали, надо обязательной свой забабахать.
У всех этих технологий есть фатальный недостаток, но однажды и у этой технологии его найдут
> Эталонная реализация Pusa написана на языке PHP
> Я смотрю любят программисты JavaScript велосипеды изобретать - JSF/GWT/Vaadin/ZKoss не слышали, надо обязательной свой забабахать.Судя по приведенным примерам программисты на Java не могут осилить JavaScript и изобретают свои велосипеды.
А можно просто отдавать html без всякого говнокода на js и будет всё быстро, тормозить будет нечему.
>А можно просто отдавать html без всякого говнокода на js и будет всё быстро, тормозить будет нечему.Это не современно и не модно.
Сейчас на васм Раст так делает
Можно. Но тебе это не понравиться
Очень нравится. Уже давно использую js - минимально. А то и совсем не использую. Всё летает, даже на слабых устройствах.
оптимально не весь хтмл заново, а дифф.
Откуда эту настойчивая потребность избавления от JS? В устойчивой неспособности на нем программировать? Зря, хороший язык.Поведение интерфейса и представление данных в любом случае пишется на фронтенде. И это не только формы. В реальной работе очень быстро окажется, что возможностей не хватает и нужно писать JS.
> Откуда эту настойчивая потребность избавления от JS?Например, сходу:
- С js добавляются тормоза.
- C js приходится качать тонну кода.
- C js менее безопасно, чем без него.
- C js - пользователь получает какую-то программу на своё устройство, которая хрен знает что делает на его устройстве. А пользователя никто даже не спрашивает.
- ???
- Тормоза.Я стараюсь минимально использовать js, а то и совсем без него. Всё летает, все довольны. Пора формировать движение за сеть без js!
Т.е. адекватное потребностям использование JS вы не допускаете даже?
Проблема ведь не в технологии.
Вот минимально использовать и есть адекватное использование. А потребности... ну у авторов кода могут быть извращённые потребности.
Если технология позволяет безнаказанно г..нокодить - проблема в ней. Си не позволяет г..нокодить безнаказанно. Даже "легкие в освоении и удобные в использовании" языки типа пхп или питона дают вполне ощутимые последствия г..нокодинга в виде нагрузки, которую сервер не тянет, и за это вполне можно получить по башке от начальства, если оно хоть мало-мальски разбирается в деле, которым руководит.
А вот жс позволяет г..нокодить почти совсем безнаказанно. Ошибок в консоли браузера юзер не видит, жор ресурсов часто проходит для юзера незамеченным, тормоза тоже редко становятся проблемой (ну, тупанул броузер на секунду), в крайнем случае юзер перезагрузит страницу, не вдаваясь в причины проблемы. Вывезти вебкодера в гости к фермеру и предложить там открыть свой шедевр - этого никто не делает. Поэтому на жс можно безнаказанно лепить любое г..но.
Гуглы перестают выдавать сайт в поиске, если он тормозит и жрет ресурсы. Вебмакаки из кожи вон лезут, чтобы ускорить загрузку страниц.
Ахаха, си не позволяет говнокодить, 70000 строк кода в геофизическом софте с тремя тысячами магических чисел
> Я стараюсь минимально использовать js, а то и совсем без него. Всё летает, все довольны.я заинтригован.
не поделитесь ли ссылкой на ваш портфолио?
(да простит меня модератор за такие запросы).
Не его, но с миниум JS (а некоторые темы и вообще без): https://gohugo.io/showcase/
Там без жс даже картинки не грузятся, хороший пример.
app.bundle.js - 133кб
app.кучабуков.js - 157кб
buttons.github.io - 19кб
> Там без жс даже картинки не грузятся, хороший пример.Хьюго - это -генератор статических сайтов, все зависит от того, кто делает, ЖС там в основном чтоб можно было динамически менять (меняешь ишодники, меняется тут же морда) ну и или еще свистелки, без которых можно спокойно обойтись.
https://www.linode.com/docs/ сделаная на хьюгев полне рабочая без ЖС
Какое у вас замечательное чувству юмора. Примеры один лучше другого )
Вы не пробовали для разнообразия самому зайти туда с отключенным яваскриптом? )))
> Какое у вас замечательное чувству юмора. Примеры один лучше другого )
> Вы не пробовали для разнообразия самому зайти туда с отключенным яваскриптом? )))А где я говорил что вообще без ЖС ?
Я говорил, - с миниумом JS (!!!)Если Вы отлючаете JS на линоде, там появляется два меню:
Docs Home > Guides > Linode Platform > Managed
И то, что ниже - это и есть публичная тема хьюго, которя хоть со скрипом, но работает без ЖС по линкам документации (только)https://letsencrypt.org/docs/ сделанный кстати тоже на hugo, - вполне тоже обходится с миниумом JS (хотя в принципе и вообще без ЖС тоже работает)
Если нужна тема для хьюго вообщe без js, то для него есть темы на базе Bulma CSS:
https://bulma.io/documentation/ (кстати рабоатет без ЖС вполне нормально)
и пример рабочeго (и даже responsive) сайта на Бульме: https://briangreunke.com/blog/css-responsive-themes/ который работает прекрасно с javascript.enabled = falseВ великому сожалению, единицы разумных сайтов, не спасут от толпы обезьян, в firefox, так называемом "свободном" брузере, вообще давно брали отлючение JS из UI :(
Забавно то, что в браузере тормозит не JS, а DOM который JSом теребят стотыщраз в секунду. И минимальное использование JS это правильная стратегия. А бывает так, что фронтендеры, чтобы вывести обычную таблицу в браузере, вместо <table> накручивают лютого монстра на React, где каждая ячейка - это отдельный компонент рендерящийся в <div>.
Как будь-то <table> не рендерится.
> Откуда эту настойчивая потребность избавления от JS? В устойчивой неспособности на нем программировать?Возможно, причина лежит в устойчивой неспособности полностью запретить распространение своего js-кода -- без такого запрета распространять код на коммерческой основе весьма затруднительно: продавать приходится только временный доступ к коду и к техподдержке.
Нет. Причина - в безопасности. Яваскрипты очень часто используются для сбора информации с компьютера и для размещение на компьютере посетителя вредоносного кода. Поэтому у людей, заботящихся о своей безопасности, как правило, исполнение яваскриптов запрещено или ограничено, и такой человек скорее покинет сайт, чем будет включать яваскрипты для него.
Плюсую.
Даже специально временно включил js для оупеннета, чтобы проголосовать плюсиком ))))
> Откуда эту настойчивая потребность избавления от JS? В устойчивой неспособности на нем
> программировать? Зря, хороший язык.Язык-то хороший. Проблема в том, что работа в инфосети превратилась (превращена) в постоянное исполнение неведомо кем сделанных приложений У СЕБЯ ДОМА. Это и HTML5 касается, насколько понимаю.
Раньше неведомо кем сделанные приложения были нативными и работали не в виртуальной машине браузера, а прямо на вашей ОС. Что-то изменилось?
Человек ностальгирует по временам, когда возле компа дышать нельзя было, чтобы он не поломался.
> Раньше неведомо кем сделанные приложения были нативными и работали не в виртуальной
> машине браузера, а прямо на вашей ОС. Что-то изменилось?В те времена у каждого приложения были фамилия, имя и отчество. ЕВПОЧЯ.
Мы хорошо знаем JS и умеем на нем писать.
Причина не в JS а в наличии необходимости координации между бэками и фронтами. Это финансово расходно.
>недоступность основного кода со стороны фронтэндаСразу на *** такие сайты.
Предпочитаешь, чтобы чужой код исполнялся в твоём браузере? Лично я бы предпочёл, чтобы код исполнялся на железе того, кто этот код писал.
не все сервера принадлежат программистам.
Не важно, пусть тем, кто заказал разработку сайта.PS Будет тормозить, следующий раз подумает, стоит ли так перегружать страницы динамическими украшательствами. А то же, когда у клиента тормозит, хозяину-то сайта не видно.
> А то же, когда у клиента тормозит, хозяину-то сайта не видноНу вообще-то для этого есть тестеры, которые тестируют работу
Ну так они его могут протестировать на i7 с 32 GiB оперативы.
Если хозяин продаёт что-то дорогое, то он может нарочно решить не тестировать на медленном железе, потому что решил, что его клиент может позволить себе быстрое.Есть и другие. Например, заказчик сделал себе в системе масштаб 150% и просит уменьшить сайт, а то всё крупное стало. То, что у посетителей станет мелко, его не волнует. Причём, он-то своим сайтом вряд ли будет пользоваться как посетитель, поэтому его вообще не должно волновать, как он видится на его странном компе.
В общем, как тестировщику сказали тестировать, так он и тестирует. Если попросят посмотреть на медленных компах, он посмотрит.
Если хозяин продаёт что-то дорогое, то он может нарочно решить не тестировать на медленном железе, потому что решил, что его клиент может позволить себе быстрое.Есть и другие. Например, заказчик сделал себе в системе масштаб 150% и просит уменьшить сайт, а то всё крупное стало. То, что у посетителей станет мелко, его не волнует. Причём, он-то своим сайтом вряд ли будет пользоваться как посетитель, поэтому его вообще не должно волновать, как он видится на его странном компе.
В общем, как тестировщику сказали тестировать, так он и тестирует. Если попросят посмотреть на медленных компах, он посмотрит.
Предпочитаю контролировать, какие данные и каким образом использует чужой код. Если код плохой, то я его модифицирую и он отдаётся браузеру вместо оригинального.
Ты что же, каждый сайт, на котором JS есть, переделываешь?
а это случайно не ты тот чувак который любил писать и бекенд и фронтент на js, говорил что все класно нравится и еще потом его в дурку забрали?
Сколько раз их учили что GPL, даже GPLv3 не делает код свободным, который исполняется на чужих серверах. Что позволяет легко форкнуть такой GPL проект и не публиковать изменений. Для этого надо использовать AGPLv3, чтобы код исполняемый на чужих серверах оставался свободным для пользователя.
Выйди с этого. Фронтенд никак не может получить перловый код с сервера :)
Ну и напрасно.
Юзеру, а их большинство глубоко без разницы открытый код или нет. Они просто пользуют сайт и все.
А вот заказчик - кто платит деньги - предпочитает код оставить себе.
ничего страшного если вы просто не попадаете в ЦА владельцев подобных сервисов
Яваскрипт придумали именно для того, чтобы разгрузить сервер и канал, здесь же - наоборот, нагрузка переносится с клиента на сервер. Это то, что касается нагрузки. Но есть и другая сторона - безопасность. Перенос исполнения кода на сторону сервера приведёт к тому, что на сервер придётся передавать информацию о клиенте, такую, как разрешение экрана и тому подобное, которую яваскрипт может обработать локально, ничего на сервер не передавая. Что же касается сокрытия бесценных авторских прав авторов скриптов, то с этим неплохо справляется и обфускация.
> Яваскрипт придумали именно для тогоЧтобы клиентские устройства тормозили. Вот его основная фича.
Чтобы серваки не тормозили. А на юзверей им нас. Рать.
Хоть кто-то не отрицает))
Но есть вот фанбои, которые на полном серьёзе думают, что не для этого.
Вот от этой самой обфускации кода, исполняемого на клиенте, проблем с безопасностью гораздо больше. Ибо обфусцированное может всё тоже, что не стоило бы на сервер передавать, таки молча передавать.
> яваскрипт может обработать локально, ничего на сервер не передаваяКак будто это может помешать отправить на сервер ВСЁ, что скрипт сможет собрать.
>Что же касается сокрытия бесценных авторских прав авторов скриптов, то с этим неплохо справляется и DMCA takedownы и судебные иски.Пофиксил.
> Яваскрипт придумали именно для того, чтобы разгрузить сервер и канал, здесь же - наоборот, нагрузка переносится с клиента на сервер. Это то, что касается нагрузки.в определенной нише это вполне имеет смысл - сервисы расчитанные на дешевые мобильные устройства, или сервисы типа google stadia и им подобные взамен увеличения интернет трафика предлагают уменьшение требований к аппаратным ресурсам
> Перенос исполнения кода на сторону сервера приведёт к тому,приведет к тому что бизнес логика хранится на сервере - будет сложнее произвести реверс инженеринг
опять же на примере google stadia - приложение не спиратиш
Мдаааа, у них с головой все в порядке ?Кричали что php/python крутящийся на сервере это типа плохо а давайте часть логике в js на клиента перетащим. Мда ....
В принципе андроиды работают быстро что ещё надо ? Тоже мое думаю : ничего . Другие же говорят в этом случае "не нужно" что c первых букв при другой раскладке звучит как yt ye;yj , а кто использует ytd ? Правильно ютуб
Не взлетит. Так-то по идее так и следовало делать.
Я думаю они наедятся этого всего от пуза судя по тому что фремиворк пузатый
У нас с головой все в порядке.
JS - место размещение компонентов MVC не страдает.При этом браузеру (клиенту) отводится его основная суть а именно ОТОБРАЖЕНИЕ.
Это наиболее правильное использование клиентской стороны в текущих условиях инета.
Не взлетит. Не модно. Должно жрать на стороне клиента.
Ну да, производители мобилок будут сильно против.
подобная идея давно уже используется - начиная от turbolinks и заканчивая blazor и рендером gnome окружения в браузере
Т.е. ты такой сидишь в своей конторке и думаешь: "О! А давайте сэкономим на зажравшихся фронтах и будем эту логику на бекэнде выполнять!" Выносишь все обработчики и состояние на бэк и вдруг понимаешь, что у тебя не одно соединение, а тысячи-миллионы и что теперь тебе нужен новый тарифный план в этих ваших облаках.
> Т.е. ты такой сидишь в своей конторке и думаешь: "О! А давайте
> сэкономим на зажравшихся фронтах и будем эту логику на бекэнде выполнять!"
> Выносишь все обработчики и состояние на бэк и вдруг понимаешь, что
> у тебя не одно соединение, а тысячи-миллионы и что теперь тебе
> нужен новый тарифный план в этих ваших облаках.А какого лешего юзверь должен тратить свои вычислительные мощности ради вашей рекламы?
Не переживай, а то переживе..
Все по-старинке останется. ФФ
а если подумать над архитектурой и UX - то может оказатся все не так уж и плохо
в осбености если это не сервис типа VK на милион пользователей, а специфическое веб приложение
Pusa прекрасно справляется со значительной нагрузкой.
В основу поддержки сессий Pusa заложена возможность поддержки множества вебсерверов (точек входа) без необходимости сессионной синхронизации.Таким образом пользователь, авторизовавшись на одном из серверов может продолжить работу на другом. Это позволяет организовывать зонтик и паралелить вебсервера в сколь угодных количествах.
Хорошая технология для каких-нибудь дашбордовЯ видел как такое работает на Phoenix LiveView, очень круто, только там вебсокет а не ajax
Все просто, это нужно для того, чтоб на мелких проектах,
PHP-макака могла запилить проект в одно рыло, без
JS-макаки
полностью согласен - ато эти js-макаки понаделают а потом уволятся, потомутчо новый фреймворк веть вышел а на нем не дают переписывать, да и старый код поддерживать скучно
Ну и велосипед
У кого ещё такое есть, если не считать блейзор?
Unpoly и Htmx
У всех:
https://github.com/dbohdan/liveviews
Спасибо.
Во блин. А я давно уже думал, что это на самом деле бред писать вэб приложения на двух языках - один для бэкэнда, а другой для фронтэнда. Раньше был смысл, когда странички считались чем-то вроде текста. Но сейчас то, блин, это уже полноценные приложения и в браузере мы видим по сути только морду. Так зачем вот эта огромная куча костылей? Все эти html, css, js и еще куча всякой другой ереси?
> бред писать вэб приложения на двух языках - один для бэкэнда, а другой для фронтэнда.Пиши на одном. NodeJS уже давно существует /s
NodeJS - пишите. Это хорошо.
Речь идет не об исключении JS а об уменьшении объема кода на клиенте.
По хорошему - сведение его в 0, если данный стандарт разовьется и будет принят браузерами.
> По хорошему - сведение его в 0, если данный стандарт разовьется и будет принят браузерами.Не будет. Стандарт - это гугл, а они развивают JS, WASM и прочие веб стандарты. Браузер - это своего рода ОС, давно уже пора это понять.
> NodeJS - пишите. Это хорошо.
> Речь идет не об исключении JS а об уменьшении объема кода на
> клиенте.
> По хорошему - сведение его в 0, если данный стандарт разовьется и
> будет принят браузерами.Либо ты платишь за ресурсы, либо пользователь. Крупные игроки на рынке деньги считать умеют и дополнительную нагрузку на бек брать не будут.
Безусловно.
При этом по имеющемуся опыту раскходы на технические ресурсы ничто по сравнению с расходами на персонал. Pusa про второе...
> Пиши на одном. NodeJS1 язык != 1 платформа
попробуй напиши один и тот же код чтобы запускался и в браузер и node.js без костылей и подпороквот deno его заменитель действительно откроет всем ворота в светлое будущее, когда будет 1 код и для браузера и для сервера без костылей в виде транспиляторов, тысячи сборoшиков и прочей ереси чернокнижников
Это странное мнение, обычно программные продукты пишутся более чем 1 человеком, и нет никакой проблемы в разных языках, да и знать несколько языков не проблема вообще. По мне так наоборот, писать на JS то что можно писать на нормальном ЯПе, спроектированном не за неделю - бред.
Выключите свет!
Как стимулировать продажи железа?
- Бесконечно раздувать овносайты.
Что только не придумают, лишь бы JS не учить
что только не пишут, чтобы оправдать знание только одного языка Javascript
Вперед в здоровое прошлое?
Этакий тонкий клиент для толстых сайтов. Конечно не zero javascript, но всё же только минимальная прослойка, а вся нагрузка на сервере. Но есть минус — это огромное количество запросов на каждый чих, на какой-нибудь blur или hover, что вполне решается просто css.А вообще стоило бы смотреть в сторону TwinSpark, HTMx. Они тоже занимают 11кБ размера (золотой стандарт я погляжу) и при этом всё декларативно. А взглянув на ужасный протокол Pusa чуть плохо не стало, пусть дорабатывают.
> Этакий тонкий клиент для толстых сайтов. Конечно не zero javascript, но всё
> же только минимальная прослойка, а вся нагрузка на сервере. Но есть
> минус — это огромное количество запросов на каждый чих, на какой-нибудь
> blur или hover, что вполне решается просто css.Верно. Это и должно решаться через CSS. Таким образом количество запросов - умеренное.
> А вообще стоило бы смотреть в сторону TwinSpark, HTMx. Они тоже занимают
> 11кБ размера (золотой стандарт я погляжу) и при этом всё декларативно.
> А взглянув на ужасный протокол Pusa чуть плохо не стало, пусть
> дорабатывают.Декларации недостаточно.
С удовольствием выслушаем инфу о недостатках. Объективную учтем.
Вот класно бы было запустить Pusa на MuditaOS
> Вот класно бы было запустить Pusa на MuditaOSЧем объясняется такое экзотичное желание?
Синергией процесса...
заявлена что можно реализовать протокол на Go - а в Go как раз есть встроенный веб сервер, теоретически можно скомпилировать через cgo под микроконтроллер, так почему бы нет?
Интересно, можно ли таким образом ддосить ресурсы, - просто эмулировать перемещение курсором по страничке?
> Интересно, можно ли таким образом ддосить ресурсы, - просто эмулировать перемещение курсором
> по страничке?ддосить ресурсы куда как проще без мышки. возить эмулируемой мышкой слишком дорого.
> Состояние фронтэнда формируется но не контролируется бэкендом, что делает разработку для Pusa схожей с кодом для видеокарты или Canvas, где результат исполнения не контролируется разработчикомКто объяснит, что здесь написано? Что значит "схожей с кодом для видеокарты Canvas, где результат исполнения не контролируется разработчиком"?
>> Состояние фронтэнда формируется но не контролируется бэкендом, что делает разработку для Pusa схожей с кодом для видеокарты или Canvas, где результат исполнения не контролируется разработчиком
> Кто объяснит, что здесь написано? Что значит "схожей с кодом для видеокарты
> Canvas, где результат исполнения не контролируется разработчиком"?Когда в видюху отправляется поток команд, проверить его исполнение у отправляющего кода нет никакой возможности. Только пользователь увидит картинку. От видеокарты максимум будет получен ответ, что команды приняты.
В новости GPLv3, а в репозитории чего-то про лицензию ничего и нет.
> В новости GPLv3, а в репозитории чего-то про лицензию ничего и нет.Исправлено.
Вы хоть понимаете что GPLv3 для серверного кода почти бесполезен? В этом случае правильнее использовать AGPLv3.
> Вы хоть понимаете что GPLv3 для серверного кода почти бесполезен? В этом
> случае правильнее использовать AGPLv3.Лицензия изменена, ОДНАКО наивно полагать, что подобные условности позволяют рулить судьбой кода.
Это проблема скорее сообщества, а не наша.
Идея в выпущена.
> Вы хоть понимаете что GPLv3 для серверного кода почти бесполезен? В этом
> случае правильнее использовать AGPLv3.Небольшое дополнение.
https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/src/la...
В верхнем правом углу сайта указана лицензия GPLv3.
Есть pjax livewire hotwire turbolinkА это чисто пэхэпэ или тащит за собой фреймворк?
> Есть pjax livewire hotwire turbolink
> А это чисто пэхэпэ или тащит за собой фреймворк?Это чистый PHP без сторонних библиотек.
JS вложен в проект. Его не много.
После оптимизации и уборки коментов полный код JS для PUSA менее 7кб. И более 7кб он едва ли будет.
эта новость пугает Javascript бандерлогов.
Почему? Каждый из них получит в свое распоряжение миллионы серверов... Теперь они станут главными...
Они сломали кнопку back в браузере.
> Они сломали кнопку back в браузере.Исправлено.
О, круто. Действительно работает теперь.
а умеет в SSR или есть ли планы по его реализации? т е сначала рендерим страницу полностью а далее через этот протокол - при этом чтоб код одинаковый был
Pusa это делает в том числе.Pusa имеет внутренний сборщик, позволяющий на бэеке полностью собрать всю страницу на основе шаблонов и их кроссвызовов (вообще без PHP на голом html). После чего страница будет возвращена.
Выбор пути организации потрохов остается на усмотрение разработчика.
видимо, кто то из пыхошколоты набрел пару лет назад на http://hrud.net
но не понял сути, и решил сделать все на пхп и для масс-веба ))
да простят меня авторы "пуса" но это было первое впечатление.
приношу извинения, если кого обидел.
Не обидели. IT не для обидчивых.Сфера применения HRUD:
Где нужно применять HRUD ? Разработка АРМ, личных кабинетов, и др. приложений с web-интерфейсом, для которых необходима поддержка сложной логики поведения или взаимодействия с клиентом, поддержка «сложного состояния клиента».
Это «statefull технология», которая выгодна при организации сложных бизнес-процессов, быстрой разработки промышленных АРМ.Сфера применения Pusa значительно шире и все перечисленное так же.
ваш оптимизм конечно похвален, но я бы сказал что вы заявляете пока еще трудноподъемные для вашей технологии вещи.сейчас будет много критики. я не столько хочу чутька сбить ваш оптимизм, сколько дать вам понять какие у вашей технологии сейчас я вижу проблемы. возможно я не прав, и вы меня переубедите, или примерами докажете, что я не прав.
допускаю, что я сейчас попросту не понимаю как вы организуете серверные скрипты, плохо понимаю, что в ваших терминах является контроллером (уж не MVC ли? но тогда где модель?...).. но если я этого не понимаю - тогда у меня вопрос: а где доки которые дают мне как архитеткору или разработчику "модель вашего приложения" ? тех 2-х рисунков что есть в текщих манах - не достаточно. примеры - можете их сделать? в описанных на рисунках терминах разложить несколько примеров простого взаимодйствия - простой, средний (см ниже лифлет) , сложный ...
В общем делайте мануалы и демки? но это спойлер - см про это в конце.Теперь про проблемы которые я вижу:
_________________
во первых. ты часть проблем, что вытекает из простоты протокола.Сейчас это, имхо, как proof-of-cоncept. Протокол не предполагает передачу проивольных данных между клиентом и сервером, генерацию событий программно, у клиента нет js-api, нет механизмов взаимодействия сервера с находящимся на клиенте js (например как вы хотите добалять на leaflet-карту новые объекты?). вы похоже не очень то предрасположены к тесной интеграции с js ? да есть метод вызова произвольного js - но там же стоит пометка "Рекомендуется минимизировать использование"?
Вопрос: как вы, например, собираетесь обрабатывать сдвига карты в leaflet - что бы запростиь у сервера объекты для новой области отображения? ведь у вас нет ни js-api в клиенте, ни механизма генерации событий программно, ни передачи дополниетльных, динамически генерируемых данных с событиями отсылаемыми на сервер.
Будете делать это _не_ через PUSA? тогда прогнозирую нежелание разработчиков пользовать клиент pusa на стороне клиента. Примерно так же как мы не хотели видеть JSF потому что с "его клиентом" было очень проблемно интегрироваться - вызвать метод какого-то бина на сервере, когда ты находишься в js-коде - это сплошные костыли.
_________________
во вторых. часть проблем - из выбранного языка реализации и механизма взаимодействия.Простите, но вы сказали что применения вашего протокола - больше чем то что описано на странице hrud - но заявлять про statefull приложение когда в php банально нет управления процессами и межпроцессного взаимодействия... это имхо странно.
Сложное корпоративное приложение - оно живет на сервере постоянно, а не пока генерятся странички. Хотите совет? понимаю, это нагло, но если хотите развивать вашу спеку далее - переходите на Java, или C#. именно там вы отхватите кучу всего, что надо добавлять в ваш протокол. заодно поймете как перестроить структуру и внутреннюю логику вашего решения тоже - если потребуется.
Далее - как говорить про сферу применения - "statefull приложения" когда у вас сервер не знает состояния клиентских узлов или хотя бы модели клиентской страницы? имхо - это как-то странно.
И пока вы сидите на php - вы не сможете организовать без костылей хранение состояния клиента на севере в памяти (хотя возможно мои знания про php устарели и вы знаете как это сделать изящно... но я вот думаю что нет таких вариантов с пхп ).
_________________
И если вы создавали Pusa как спооб избавиться от JS - и это, имхо, "не прокатит".У вас не хватит возможностей. Банально - разберитесь как реализовывать работу с Leaflet - например. Сейчас у вас не хватит быстродействия - куча ajax запросов на каждый чих который надо обрабатывать на клиенте - этот шквал может сожрать быстродействие и погребет любые попытки сделать что-то более-менее сложное. т.е. я к чему - от js вы не откажетесь, примите это, и научитесть жить с ним.
_________________
И ВАЖНО: поймите вашу нишу. сейчас вы заявляете о слишком большой области, что бы верить вам наслово - это как с новыми языками - создатели всегда начинают свои поделия пихать куда ни попадя. Вот примерно как вы озвучили "непоймикакую" широкую нишу применения.Понимаю - вам кажется что у вас в руках Бруксовская "серебрянная пуля"... но имхо, важно понять, что эту пулю надо "приземлить" как можно быстрее и найти вашу нишу. Пока не наломали дров, пока интерес публики не кончился... Но это - только имхо . стратегия развития вашего продукта - ваша стратегия.
Для сравнения: hrud создавался не из соображения отказа от js - хотя это почти и получилось. hrud создавался для целей локализации бизнес-логики на серверной стороне. Именно бизнес-логики, с оставлением логики отображения на клиенте (т.е. например вопросы тесной интеграции с js - которые у вас не решены или числятся как "жежательно минимизировать" - там - заложены на уровне архитектуры и являются обычным штатным механизмом).
Его область - это та область, где технологии построения приложений на типичных спрингово-ангулярных связках слишком тяжеловесны, медлительны в разработке и модификации, когда куча микросервисов начинает неуправляемо "разваливаться" и ею становаится трудно управлять, когда js-приложение настолько большое что даже грузится минуту, а переплетение операций такое, что у вас бизнес-логика начинает "просачиваться" на клинета через сотню циклов рефакторинга (и в итоге через F12 ты можешь начать делать операции не так как это допускаетс приложение....) - и вот именно это ниша - та самая в которой hrud более мнее способен конкурировать со "спрингво-ангуляровой попсой" - потому что позволяет эти проблемы решить и прделагает процесс разработки, который не приводит к подобным эффектам ))
потому у него и написано в области применения - "не для массовых-публичных сайтов".Вы же, как я понимаю, хотите переенсти всю логику на сервер просто потмоу что "не хочется в JS"? И предложить решение всем и везде - в массовом вебе... имхо - не выйдет. "в чем цимес?" - вам это надо будет объяснить. И чем ваш вариант "лучше перегенерации страницы как это делается например на _этом_ форуме"? (см ниже секцию про "нишу")
И проблема даже не потому что "у нас уже есть куча ангулярщиков". Заявленное в полном виде (перенос всей логики на сервер) можно будет сделать только через полный аналог rdp- или x- клиента в браузере, и как следствие - полностью перестроить логику приложения на сервере. И придумать кучу компонент под себя (напрмер карты?). А у вас еще и в добавок - нет модели страницы клиента на сервере...
+ массовый веб не поймет увеличения нагрузки на сервер при потенциально неограниченном числе клиентов. Попытки вынести на клиента бОльшую часть логики - и появление тяжелых js-клиентов (реакт-ангулярных) - вот это всё ужасное-и-противное что вы тоже наблюдаете - не от простой же это жизни появилось? Нет. а с целью как раз _разгрузить_ сервер. А вы предлагаете его как раз наоборот - нагрузить. И массовый веб вас спросит - "а зачем?!". и как я понимаю по комментам - уже спрашивает.
А корпоративный сектор "тяжелых" приложений для вас - с php - практически закрыт.
не с php соваться в "тяжелый интерпрайз". ну вот серьезно.
(*) и да предвижу вопросы - сразу скажу : вконтактик - это не "тяжелое интерпрайз приложение". это "одностраничник с _примитивной_ бизнес логикой в 3 клика".И.... вот как-то для начала так.
Надеюсь я вас не сильно "приложил" ?Если сможете выдержать - "добро пожаловать в коллектив" ))
_________________
Возможно я не прав во всем выше, и вы сейчас в ответ на всё что я рассказал - найдете кучу "элегантных" решений или придумаете что то вообще супер крутое...
Но почему бы не начать с того, что бы сделать ... демки ? Демки и примеры. Несколько кейсов которые показывают чем ваше решение облегчает разработку приложений.
Потому что вы - создатель. У вас есть идея. А я - токсичный комментатор который не понимает как использовать то что вы предлагаете.
Покажите вашу идею! воплотите! я же пока могу только гадать и вспоминать мои шишки._________________
Не знаю что предложить... - давайте скажем ... для начала
1) карту, с отображением только объектов, которые только в отображаемой области. с динамическйо подгрузкой данных с сервера через pusa;
2) выполнение на сервере какого-то длительного расчета с отображением прогресс-бара;и всё это - на технологии вашего протокола и вашего клиента.
Без много-сот-строчного js-кода и "классических ajaх-запросов" вне вашего клиента.
Всё общение с сервером - только через ваш клиент (ведь перестройка UI - в вашей идеологии - только через него и производится?(троллинг)Еще покажите как будет вести себя ваше приложение когда будут открыты 2 вкладки в одном браузере - и на ниж будут "нажиматься разные кнопки".
И уже потом можно будет разговаривать более предметно.
Предметно, и дальше - там еще есть пучок проблем на этом пути, но как первый шаг - я бы предложил вам решить описанные ваше кейсы.
справитесь?
Благодарю за длинный ответ. Отвечу кратко по существу.1. Pusa - результат работы в архитектурно сложной структуре с 2001 года.
2. Мы реализуем Pusa свои деньги, с благодарностью принимаем советы, но очередность их исполнения выбираем сами.
3. Мы осознаем, что PHP не самый шустрое средство. Он выбран из за простоты и стройности. Реализация Pusa на GO или иных средствах НЕ проблематична, если у кого либо повится таковое желание.По кейзам:
0 - leaflet - в Концепте Pusa явно указана необходимость JS при работе с mousemove. Если у вас есть реализация без mousemove - изложите и будет предложена реализация без доп скриптов. У нас ЕСТЬ реализация leaflet и минималистичный (благодаря Pusa) JS скрипт, но выложен в рамках Pusa он не будет, так как потребует публикации серверной части, которая не будет опубликована по agpl3.
1 - прошу уточнить задачу. что понимается по понятием Карта. Если выше означенный leaflet то см п 0.
2 - ожидание клиентом ответа более 1 секунды с выводом индикаторов считаю недопустимым - это плохо. при оперативной работе повесить пользователю индикатор с временем ожидания 2 минуты - очень плохо. Блокирует работу. Тяжелые результаты отправляются почтой или телеграмом содержащей ссылку на результат который отображаться в реалтайме. Индикатор загрузки более 1 секунды - ПЛОХО.
3 - прошу уточнить задачу ИЛИ откройте две вкладки браузера и кликните меню на сайте pusa.
Итого прошу уточнить постановку пунктов 1 и 3.
пока отвечу кратко, потом с вашего позволения дополню.и так. пока про leaflet :
вот смотрите : вы, по сути, предлагаете "какой-то-фреймворк". мне в частности, разным посетителям форума вообще (иначе зачем вы это публиковали?). говорите что он классный и на нем можно делать много разных штук и он крутой потому что "полшел нафиг этот js".
я поддерживаю, мне интересно... но возникает вопрос:
"а мы вот карту на базе leaflet делали для заказчика. отображали на карте расположение cctv-камер на карте города. как такое же сделать на базе какого-то-фреймворка? я не помнимаю - покажите демку? и демос траничку на сайте запилить можете? а то демок у вас с гулькин нос и они какие-то примитивные слишком".
вот и вся постановка. в дополнение - с сервера надо динамически подгружать порцию камер для отображения при сдвиге карты - для той области на которую сдвинули. т.е. просто загрузить все камеры сразу - нельзя. надо порциями, с выбором по отображаемой геообласти.
и ваша задача - по сути показать как быстро и легко сделать это на вашем фреймворке и связать с сервером через pusa.
еще наверное дополню: мне надо видеть гео-координаты отображаемой сейчас на карте области. т.е. вот я сдвинул область отображения - обновились геокоординаты.как мне такое сделатт на pusa и как, чем ваш фреймворк будет мне полен, как он облегчит мне решение такой задачи ?
1. Вы предлагаете выполнить полноценную работу. Работа = денги.
2. Постановка крайне предварительна и требует уточнения:
- кто провайдер карты (api)?
- если API провайдера подразумевает JS то, есть ли у него событие завершения драгдропа?
- представьте api для получения информации о камерах.:)
> 1. Вы предлагаете выполнить полноценную работу. Работа = денги.нет, я прошу вас сделать демонстрационный кейс, туториал,
пример того, как интегрировать pusa и js-компоненты на веб-странице.который будет красоваться у вас в туториалах.
это необходимый элемент, если вы хотите что бы вашим фреймворком хоть как то заинтересовались.сложность туториала должна быть не сильно сложнее хелловордов на https://leafletjs.com/examples.html
________________________
> 2. Постановка крайне предварительна и требует уточнения:
> - кто провайдер карты (api)?эээээ.... ну вроде ж как говрили не раз: leaflet... конкретная подложка - как в хелловордах лифлета. там кажется osm...
________________________
> - если API провайдера подразумевает JS то, есть ли у него событие
> завершения драгдропа?всё необходимое можно найти на https://leafletjs.com/examples/quick-start/
и не драгндроп, а событие moveend, вы мышкой перетаскиваете карту меняя центр точки просмотра. обработчик подключаете через
map.on('moveend', function(e) {
alert(e.latlng); // e is an event object (MouseEvent in this case)
});________________________
> - представьте api для получения информации о камерах.
это не важно. рандомно сгенерируйте 100-200 маркеров в квадрате над городом Москва, например.
держите их в памяти, и по мере поступления запросов отдавайте их координаты клиенту.
т.е. вы сами являетесь поставщиком данных для карты.
ну это же демка - не важно откуда брать данные.т.е. да, можно отображать даже не камеры, а просто маркеры - тут важно не что мы передаем,
а сам факт передачи по программно генерируемому событию, через pusa,
и обновление координат области карты на странице.примечание: для простоты область координат можно свести к прямоугольнику на геоиде от левого верхнего угла отображаемой области к правому нижнему (это ответ на вопрос касательно проекции и точности поиска объектов).
При наличии события оно может быть направлено на Back, и будет возвращен результат, который ДОЛЖЕН быть обработан так или иначе сторонним скриптом.Итого: я не вижу существенных проблем в реализации. Если у вас есть таковая потребность, вы можете сделать это самостоятельно (исходники доступны) или подождать когда мы сочтем возможным прислушаться к вашим советам.
ОСНОВНОЕ: если вы намерены использовать сторонние скрипты JS то их ПРИДЕТСЯ загрузить и сделать порт между ними и ответом Pusa. Это явно указано в концепции. ;)
>> При наличии события оно может быть направлено на Back, и будет возвращен результат,
>> который ДОЛЖЕН быть обработан так или иначе сторонним скриптом.а у вас есть примеры того как это делать? потому что ничего похожего в тех трех примерах на https://pusa.catlair.net/?section=Examples я не вижу .
>> Итого: я не вижу существенных проблем в реализации. Если у вас есть таковая потребность,
>> вы можете сделать это самостоятельно (исходники доступны) или подождать когда мы
>> сочтем возможным прислушаться к вашим советам."Неет, мужик, ты так слона не продашь"(с) ))
В общем вы только что окончательно провалили презентацию ваших наработок архитектору, который присматривался к технологии для включения её в проект. Ну как бы так)))
Нет, я не требую бегать вокруг меня и делать всё что я прошу. Меня устроил бы ответ "ну... мы постараемся на неделе выкроить время. но не обещаем.". Я ж вам денег не плачу. А вот посыл "разбирайся если тебе надо"... вы знаете - (пока) не надо. Пока все эти задачи прекрасно решаются и уже известными технологиями
А доказать мне что ваш фреймворк облегчит мне жизнь или ускорит работу людей в моей команде - вы (пока) не смогли.
Меня "напугали" ваши слова 2 поста назад "Вы предлагаете выполнить полноценную работу.".
Т.е. если "встроить карту на страницу с отображением маркеров" - на вашем фреймворке - это "полноценная работа" - то извините.Мне нужно сокращение затрат и времени, а не "полноценная работа" для создания "прототипа типовой задачи".
Будет интересно услышать о вас снова, когда/если вы доберетесь до расширенных примеров, расширите перечень кейсов в разделе examples и покажете как интегрироваться с js.А главное - сможете показать чем использование вашего фреймворка и технологии выгоднее, по сравнению с обычными web-технологиями и в каких нишах.
Удачи.
Благодарю за внимание проекту.Добавлен пример динамической загрузки контента без использования JS на основе события scroll. Аналогичным образом вы можете реализовать необходимый вам функционал для ваших задач.
Примеры - https://dev.pusa.catlair.net/?section=Examples
Гит - https://gitlab.com/catlair/pusa/-/blob/main/site/pusa/php/pu...Слона мы не продаем. Мы отдаем его даром - и пусть никто не уйдет обиженным. :)
-
Они придумали VNC
> Они придумали VNCНе совсем. Сравнение с VNC близко с тем отличием, что со стороны сервера не отстроенный контент а динамически собираемый на основании запросов. В этом и идея.
И да... все это только на браузере через REST - ничего боле у клиента.
Не могу не упомянуть свой проект "Королев" для языка Scala, который развиваю с 2016 года. https://github.com/fomkin/korolev
> Не могу не упомянуть свой проект "Королев" для языка Scala, который развиваю
> с 2016 года. https://github.com/fomkin/korolevПредлагаю обсудить в телеге голосом. Суть беседы:
- сравнение схем;
- представление похожих и различных моментов статьей;Будет заинтересованность - прошу ответить сюда: https://t.me/pusa_catlair_net.
По итогам беседы:
- заберем удачные мысли в Pusa;
- есть что и нам предложить для вас.
Погодите, GWT и подобные проекты уже похоронили
Google Web Toolkit — свободный Java-фреймворк, который позволяет веб-разработчикам создавать Ajax-приложения. Его особенность — компилятор Java -> JavaScript, позволяющий почти всю разработку клиента и сервера реализовать на основе Java и лишь на последнем этапе создать соответствующие JavaScript, HTML и CSS.Pusa НЕ создает JavaScript, НЕ выполняет перекомпиляций, НЕ тянет на клиент JS под специфику запроса, НЕ использует какой либо сторонний код JS ни в каком виде, если того не пожелает разраб.