Как оформить веб-приложение без веба? Принципиально ново и модно?

веб-приложение без веба

Но при этом оно должно продолжать работать с сетью? Отдавать информацию по запросу, все дела?

Но при этом оно должно продолжать работать с сетью? Отдавать информацию по запросу, все дела?

Зачем? Например, локальная википедия или локальный OSM для себя любимого. Сеть вообще не нужна.

Но при этом оно должно продолжать работать с сетью? Отдавать информацию по запросу, все дела?

Алсо, зачем самому приложению работать по сети? К примеру, многопользовательность может обеспечивать сама операционная система. Подключился по ssh новый пользователь, запустил ту или иную команду - готово. Вся работа с сетью на ssh.

Еще можно вспомнить древние BBS - оно с сетью само со себе работает?

Если ты хочешь мозгового онанизма, то переезжай на SNMP.

Если ты хочешь мозгового онанизма, то переезжай на SNMP.

На нем можно создать гипотетический порносайт? Или многопользовательский чатик?

Если искать готовые протоколы, то попадалось это: https://docs.alfresco.com/content-services/6.0/develop/reference/cmis-ref/ - сам не осилил

«Отказ от веба» можно трактовать по разному. В т.ч. как отказ только от формы (формата) представления.

Теперь посыл темы стал понятнее.

1. Код пишется на wasm. Он жрёт меньше всего ресурсов.

2. Отрисовка осуществляется через WebGPU как наиболее близкий к железу интерфейс.

3. Понятно, что будет какой-то клей на JS, иначе браузеры пока не умеют, ну ладно.

4. Для связи с нужным сервером поднимается websocket, внутри уже идёт взаимодействие по какому-нибудь более-менее оптимальному протоколу.

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

Осталось только написать хорошие библиотеки для всего. Ну это уже мелочи.

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

«Отказ от веба» можно трактовать по разному.

Я бы сформулировал так: «гипотетически любой веб-сайт, без HTML/CSS/JS/JSON/HTTP»

Итого мы из веба

У меня веба еще не изобрели. У меня нету HTML. Твоих wasm/webgl/webgpu тоже пока не изобрели.

В целом для меня это пока звучит как «manpages с гипертекстом».

В целом для меня это пока звучит как «manpages с гипертекстом».

В нем нету интерактивности. Личную википедию как сделать?

Что ты понимаешь под интерактивностью, для начала? Добавления гипертекста недостаточно?

нового нескучного политического строя

За такое вроде как 7 лет отдыха и освоение новых профессий за счет государства.

Что ты понимаешь под интерактивностью, для начала? Добавления гипертекста недостаточно?

Смотря что за сервис:

Если локальная википедия - добавление новых статей

Если локальная фотогалерея - добавление новых фото, тегирование, выделение лиц, создание комментариев

Если локальный OSM - смотреть карты, рисовать новые, выгружать GPX

сделай как https://yaml.org
только со шрифтами поиграйся и тему по контрастней придумай.

Почти испытал оргазм, увидев «# Edit This Website», но тыкнул и сильно разочаровался.

Как оформить веб-приложение без веба?

Бабманя принесла котлеты, разлила их по стаканчикам. Все мы начали в предвкушении намазывать чай на сироп. А вот и конфеты, проговорила Тоня доставая раскалённые сардельки из морозильника.

написать всё на чём то скомпильнуть в васм и отдавать. Только зачем? Напиши клиент серверную пару приложений и всё.

Автор WebPlotDigitizer, помимо веб- варианта, предлагает srandalone приложение, завёрнутые в electron.

Оно же тупо картинку показыват.

написать всё на чём то скомпильнуть в васм и отдавать. Только зачем? Напиши клиент серверную пару приложений и всё.

Варианты зачем:

1. Допустим, я осознал тленность бытия, ненужность веб-технологий

2. На планете появился веб-вирус, который уничтожает веб-технологии. С первых дней были поражены все веб-браузеры - многие просто выдавали сегфолт, а часть хоть и запускалась, не могла никуда сконнектится, выдавая ошибки SSL или парсинга HTML. Человечество надеялось, что на этом все и остановится, но вирус мутировал и со временем перестали работать и приложения на Электроне. Народ массово сжигал программистов на React Native, но это никак не помогало остановить эпидемию. Мир медленно погружался в чистый десктопный софт. Использовать json/soap/xml для протоколов было страшным зашкваром, все срочно переходили на grpc, из-за чего отвалился и хипстерский софт, а олдскульный продолжал работать. Со временем люди отказались от всего того, что было когда-то вебом.

Ага, показывает картинку, добавляет поверх нее точки, распознает линии по цвету/маске выделения, насчитывает координаты точек в разных системах координат…

А электрон показывает картинку.

Ну так я и говорю «Напиши клиент серверную пару приложений и всё» на сишке. Локально будет работать только клиент, а если надо разнести то сервер будет клиенту данные отдавать, допустим умрёт и интернет, но локальные сети по UART например могут работать, ну или по морзянке.

А чем заменить HTML?

Ааа, оно распознаёт, тода ладна

Самописным гуем с самописным форматированием.

Если очень вывернуться, то можно редактируемые статьи и посредством telnet реализовать. Но стоит ли оно того?

https://www.gnu.org/software/texinfo/manual/texinfo/texinfo.html

Да хоть маркадуном, хоть LORCODE, HTML это же просто язык разметки текстового документа, можете написать хоть свой XML-подобный язык.

написать хоть свой XML-подобный язык

Опять пахнет вебом!

winforms

Можно запустить у себя на ЭВМ сервер с вики и обращаться к нему через localhost. Можно использовать оффлайновые программы для создания баз знаний, вроде TheBrain или Zim или ConnectedText, тысячи их.

Вопрос в топике так и не распарсил, возможно вам нужно копать в сторону альтернативных к WWW протоколов обмена файлами, например такие старички как:

• гипертекстовый векторный фидонет
• gopher WAIS
• ftp
• nntp BBS (wikipedia.org)
• telnet

Современной рабочей не WWW альтернативы этому не знаю. Разве что это (wikipedia.org)

Разбираешься. Смотрящий тут, небось?

кстати, ваяй в TeX, рендери в pdf.
с мультимедия будут проблемы, но это же ненужный веб.

Tcl/Tk или wxPython по вкусу.

Глобально - вспомнился Gopher.

Ну и банально клиент-сервер, которые чем угодно обмениваются по сети. Можно не чем угодно, а json, чтоб совсем модно-молодёжно. В итоге на клиенте получится недобраузер, заточенный под задачу. Я не против этого подхода, если реализовано прямыми руками оно приятнее и шустрее веба получается, но сейчас даже 1Ска в сторону веба отгребает.

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

Нельзя рассматривать wasm как замену вебу, потому что js и wasm применяются для программ (веб-приложений). Вот именно для такой задачи wasm-браузер был бы хорошим решением.

wasm можно рассматривать как замену вебу, т.к. это более низкоуровневая конструкция, хотя и в текущих реализациях по сути поверх старых стандартов, но это не обязательно должно быть так. Вполне можно сделать браузер, в котором будет только wasm и webgl, а JS и HTML будут подключаться отдельными модулями, как сейчас подключается React какой-нибудь.

И я считаю, что за этим будущее. Браузеры становятся всё сложней и в какой-то момент станет очевидно, что один проект это тянуть уже не может - такую кучу таких сложных технологий. Нужно разбивать это всё на малосвязанные компоненты и тут wasm может и вылезти.

Тем более, что wasm уже находит применение и в совсем других областях. К примеру ещё одно гипотетическое применение wasm это замена докера. Одна из проблем докера, которая в последние годы стала очевидна - для каждой платформы нужен свой образ. То бишь я принципиально не могу разрабатывать на ARM-ноутбуке софт для x86, на моём ноутбуке всегда будет выполняться другой код. Как и наоборот. wasm решает эту проблему, предлагая с одной стороны универсальный байткод, работающий одинаково на любой архитектуре, с другой стороны спроектированный под песочницу дизайн, позволяющий делать изолированные приложения без оверхеда контейнеров ОС. Как люди ушли от потоков ОС к юзерспейс-потокам, так они и от контейнеров ОС могут уйти к юзерспейс-контейнерам. Это дело не ближайших лет и не факт, что так будет, но я такой вектор просматриваю.

А по твоему посту. Всю тему читать мне лень, на досуге пролистаю. Хочу только сделать некоторые замечания:

Именно поэтому мы не имеем надёжной изоляции вкладок

Не понятно, что ты имеешь в виду под этим. Изоляция идёт на уровне доменов и этого хватает.

контроля за кэшем и сетевыми запросами

В API контроль есть. Ставь адблок и контролируй. Если ты рассчитываешь, что в интерфейсе пользователя будет крутилка для контроля кеша, такого, конечно, не будет. Пользователям это не надо.

лимитирования ресурсов

В браузерах есть лимитирование ресурсов. К примеру сафари периодически выгружает фоновые вкладки, чтобы не жрали батарею. Чем не лимитирование. Может быть не так хорошо, как могло бы, соглашусь. Я бы хотел тут некоторые крутилки. Но в целом оно работает достаточно неплохо.

изоляции самого браузера от системы

У хрома многоуровневая система защиты. Винда вообще браузер запускает на уровне гипервизора в отдельной виртуалке (ну или раньше была такая фича, до того, как они на хромиум переехали, не знаю, точно, как сейчас). С изоляцией в целом всё хорошо. В браузере она на порядок лучше, чем у любого другого приложения.

А про wasm - согласен. Веб приложения это не заменит, они обязаны открываться по щелчку на ссылку, а значит работать в браузере. Любые альтернативы тут недопустимы. Но тот же электрон заменить было бы очень неплохо. Очень уж он жирен.

Допустим, это веб-приложение — гуглекарты.

Значит надо изобрести свое, скорее cli-based, чтобы сохранить принцип «один запуск - один запрос

Конечно.

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

Ага.

Веб строится на поиске, а поиск на индексации html содержимого. Без поиска останется убогая реклама, как в телеграме. И как же индексировать приложения, если даже js исполнять дорого, а только один билд wasm запросто может весить 50мб и выжирать 200 из озу?

Выгода для контейнеров сомнительна из-за потери производительности. Это серверная технология, а сервера в основном на x86.

Не понятно, что ты имеешь в виду под этим. Изоляция идёт на уровне доменов и этого хватает.

В недавнем релизе FF сделали: теперь исполнение кода можно изолировать в отдельном процессе, чтобы из других вкладок нельзя было на него влиять. И общий кэш прихлопнули наконец.

В браузерах есть лимитирование ресурсов.

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

С изоляцией в целом всё хорошо. В браузере она на порядок лучше, чем у любого другого приложения.

Только с 2020 было несколько уязвимостей в v8, позволяющих исполнить произвольный код на устройстве. Вызвано это тем, что v8 компилирует js в нативный код, который в некоторых случаях сбегает из песочницы. Поэтому исполнение нативного кода должно быть более надёжно огорожено, чем сейчас.

Любые альтернативы тут недопустимы

Допустимы: открывать wasm-браузер по ссылке, как сейчас открываются разные приложения. Веб остаётся просто вебом с посадочными страницами, а когда нужно поведение — пользователь одним кликом открывает приложение. По желанию приложение можно установить, как сейчас сделано с помощью PWA.

Веб строится на поиске, а поиск на индексации html содержимого. Без поиска останется убогая реклама, как в телеграме. И как же индексировать приложения, если даже js исполнять дорого, а только один билд wasm запросто может весить 50мб и выжирать 200 из озу?

Индексировать веб-приложения - идея в любом случае мутная. А для информационных сайтов HTML никуда не денется. Я же не пишу, что его надо выкинуть. Хотя я бы на какой-нибудь markdown заменил, но не суть. Просто поменяется архитектура браузера. И будет возможность одной строчкой в сайте сменить движок.

Выгода для контейнеров сомнительна из-за потери производительности.

У контейнеров нет потери производительности. Контейнер это просто другой сgroup, другие namespace-ы для ресурсов. Процесс в контейнере ничем не отличается в плане производительности от процесса вне контейнера.

Это серверная технология, а сервера в основном на x86.

Уже нет, ARM шагает по планете. Уже здесь и сейчас у амазона ARM-серверы дешевле.

И будет возможность одной строчкой в сайте сменить движок

Вряд ли это упростит архитектуру. Нечто похожее было с java апплетами, не взлетело. Потом был флеш, тоже не взлетел. Сейчас третья попытка с js на стероидах и wasm сделать из браузера запускалку программ.

Проблема нынешнего wasm в том, что он приколочен к webgl и js. Чтобы располовинить браузеры, придётся оставить чистый wasm, а это означает смену стека. В итоге получится новая java, зато с мультиязычностью. Как ни крути — выходит отдельный wasm-браузер.

У контейнеров нет потери производительности

Так у контейнеров или у wasm? Wasm медленный, докер тоже. В случае с докером потерями можно пренебречь (помня лишь о пзу и озу), но они всё равно есть.

Уже нет, ARM шагает по планете

Относительно x86 их слишком мало. Когда станет много — придётся подстроится. Но вряд ли это будет новая виртуальная машина с дикими потерями производительности.

Код пишется на wasm. Он жрёт меньше всего ресурсов.

Отрисовка осуществляется через WebGPU как наиболее близкий к железу интерфейс.

Я ждал wasm из этих же соображений. Но потом подумал и решил, а нафиг собственно в этой схеме вообще wasm и привязка к web технологиям, если проще сделать нормальную новую платформу и обратную совместимость заткнуть автогенерацией «мостов» для web (т.е., своего рода бесплатным фронтендом, генерирующимся из newgen приложения)?

За такое вроде как 7 лет отдыха и освоение новых профессий за счет государства.

Смотря у кого ружжо. Завтра «гос-во» объявит тебе о новом нескучном строе и осваивать профессии поедут уже те, кто недостаточно колышется.

Веб строится на поиске, а поиск на индексации html содержимого. Без поиска останется убогая реклама, как в телеграме. И как же индексировать приложения, если даже js исполнять дорого, а только один билд wasm запросто может весить 50мб и выжирать 200 из озу?

Легко решается соглашениями. Приложения будут отдавать текстовое меню / представление поисковикам, ботам и читалкам (для незрячих). И будут весить не более {N}KB по-умолчанию с догрузкой доп. данных по ходу работы (иначе будут блокироваться клиентом, требуя мануального подтверждения загрузки, что будет негативно влиять на конверсию, мотивируя авторов решить проблему).

Выгода для контейнеров сомнительна из-за потери производительности. Это серверная технология, а сервера в основном на x86.

Речь, наверное про Fermyon, получивший 6 млн. инвестиций под это дело. Они говорят, что за счёт использования wasm вместо традиционных технологий контейнеризации/виртуализации у них заметно уменьшается простой серверов в ДЦ. Т.е., wasm код разных компаний выполняется на общем кластере, возвращает результат без резервирования фиксированной части ресурсов. Такая реинкарнация php, но не завязанная на конкретный ЯП.

У контейнеров нет потери производительности. Контейнер это просто другой сgroup, другие namespace-ы для ресурсов. Процесс в контейнере ничем не отличается в плане производительности от процесса вне контейнера.

А что говорят про использование контейнеров для исполнения недоверенного кода?

Wasm медленный

Концептуально или если мерить скорость JS интерпретатора, куда изолентой прикрутили поддержку wasm?

А что говорят про использование контейнеров для исполнения недоверенного кода?

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