Радикальная альтернатива браузеру

не работает без жабы

Значит надо было сделать так, чтоб Java была частью браузера.

Ой, это же WebAssembly

А сейчас как?

а сейчас так, но это дорого: браузер тяжелый. Вот скажи, можно было ЛОРом пользоваться на пне 4 скажем? А сегодня? ЛОР изменился? (ну, не принципиально) На первой малинке можно спосидеть на лоре не выжидая по 10 сек на каждый чих? А как первая малинка по вычислительной мощности по сравнению с четвертым пнем?

Я к чему: задача не измнилась (обмен текстовыми сообщеними на форуме), компы подрасли кратно, прожорливость браузеров подросла десятикратно

Дык любое сетевое соединение - это запрос-ответ.

да, но до вебсокетов браузер не умел слушать и без запроса получать уведомление о событии

А как тогда всю вот эту красоту рисовать?

ну как игры интерфейс рисуют? дать карт-бланш на отрисовку в окно, без необходимости встраивать все это в некоторый документ (современная веб страница, это дано приложение, а не документ)

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

Ну хорошо, допустим запилили, угадай как назовут твою сверхбыструю всю такую новую виртуалку, для неовеба? (:

На первой малинке можно спосидеть на лоре не выжидая по 10 сек на каждый чих?

Эх, https://ru.bmstu.wiki/Usenet

js проще закопать, чем исправить. А (x)html - норм, поживёт

всё равно жава у всех сейчас.

Конечно норм, пока на нём не начинают гуй пытаться делать.

Ну может 1 из 100, но ruvds и miran вечно лабуду публикуют, хотя бывают и хуже с кликбейтами и машинным переводом...

То что перечислено можно реализовать отдельными библиотеками

Ты задостанешься реализовывать это отдельными библиотеками.

Допустим, у тебя есть этот недофреймбуфер, на котором ты можешь рисовать. Где ты берёшь шрифты? Юзер вводит на каком-нибудь японском языке и жмёт пробел, чтобы получить https://media.prod.mdn.mozit.cloud/attachments/2014/10/01/8709/b654fa2f20fd3b3e837be88176ef343a/candidatewindow.png вот такой дропдаун с вариантами «что он вообще хотел ввести в текстбокс», ты же в курсе, что ради этого тебе нужно дофига интегрироваться с ОС (ты же не собираешься это велосипедить?) Опять же, читалки с экрана: ты тупо предполагаешь, что все юзеры зрячие. vimium-юзеры тоже отпадают. Всякие ОС-интегрированные вещи (тапни тремя пальцами любую ссылку в safari) отпадают. Зато ты изобрёл ещё один флеш!

И да, xkcd://standards.

тупо как на десктопе, набор точек

Тупо на десктопе уже чёрт знает сколько лет никто не рисует набором точек.

Стандартизованный файл виртуальной машины, это чемто похоже на байткод например Java, но изолированный многократно лучше

Ты же в курсе, что байткод вебассембли по мощности и возможностям аналогичен машинным кодам процессора? То есть если очередной программист решит делать свой сайтик на джаве, то в вебассембли запакуется бинарник джавы со всем рантаймом, куча обёрток для апи этой платформы и сам джавовский байткод фреймворка, библиотек и этого самого сайтика со своими ресурсами, картиночками и рекламными говнобаннерами. А другой сайтик будет написан на дотнете, там будет качаться свой рантайм. Третий будет на куте, ещё один жирный бинарь будешь грузить. Современные жсные бандлы раем покажутся.

Вот бы полгодика отпуска, чтобы со всей новомодной дичью поиграться, а. Годноты всё больше появляется, а времени всё меньше.

Наличие рисовалки нужность гипертекста не отменяет.

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

Запретим исполнение чёрного ящика @ выстроим чёрную вселенную

Если сайт невозможно прочитать просто по его исходному коду, такой сайт существовать не должен. Впрочем, сейчас просто выпустят приложение под Android/iOS, ведь обычная веб-страница - это так трудно.

ведь обычная веб-страница - это так трудно

Обычная страница сейчас сильнее может грузить телефон, чем приложение. Это одна из причин клепания приложений

Ты же в курсе, что байткод вебассембли по мощности и возможностям аналогичен машинным кодам процессора? То есть если очередной программист решит делать свой сайтик на джаве, то в вебассембли запакуется бинарник джавы со всем рантаймом, куча обёрток для апи этой платформы и сам джавовский байткод фреймворка, библиотек и этого самого сайтика со своими ресурсами, картиночками и рекламными говнобаннерами. А другой сайтик будет написан на дотнете, там будет качаться свой рантайм. Третий будет на куте, ещё один жирный бинарь будешь грузить. Современные жсные бандлы раем покажутся.

Есть python, есть pypy, для всех языков будут нормальные трансляторы для WebAssembly

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

сейчас просто выпустят приложение под Android/iOS, ведь обычная веб-страница - это так трудно.

Приложения нужны потому, что они собирают больше данных о юзере, чтобы продать рекламщикам. Сайтам с этим сложнее да и адблочить их проще.

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

И каждый сайт будет Best Viewed With Ultimate Module Pack +, ага.

Для сравнения многословности спецификаций W3C разработчик приводит размер других спецификаций и текстов:
POSIX (формат HTML): 2 017 056
USB 3.2 (PDF): 872 395
UEFI (PDF): 659 580

Что симптоматично, при беглом просмотре статьи, мне сперва показалось, что это новые безумные спецификации WebUSB, WebUEFI в браузере. Ну знаете, в духе времени.
И даже не сильно удивился.

Т.е. тебе нужен флеш? Но он же показал свою несостоятельность,

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

А так да, зонд оказался слишком толстым со всеми вытекающими последствиями.

Что симптоматично, при беглом просмотре статьи, мне сперва показалось, что это новые безумные спецификации WebUSB, WebUEFI в браузере. Ну знаете, в духе времени.

Из браузера давно пытаются делать операционную систему.

Идея гипертекста умерла в момент когда появился js.

Все захотели полноценные приложения, виртуализация позволяет их ограничить

А другой сайтик будет написан на дотнете, там будет качаться свой рантайм.

.net 5 сможет компилироваться в wasm (и не только в wasm) нативно

впрочем, и текущий .net core 3 требует рантайм лишь в пару мегабайт, которые подтянутся и закэшируются с CDN

Но не HTML и прочее, а тупо как на десктопе, набор точек.

Не катит, векторный характер веба - это фича.

для всех языков будут нормальные трансляторы для WebAssembly

уверен, что не будут

впрочем, и текущий .net core 3 требует рантайм лишь в пару мегабайт, которые подтянутся и закэшируются с CDN

эти пару мегабайт уникальны для каждого конкретного сайта, не так ли? Вдобавок, «сейчас» многие вещи просто тянутся через переходники на js к существующим браузерным API.

эти пару мегабайт уникальны для каждого конкретного сайта, не так ли?

с какой стати? runtime и библиотеки общие для всех, уникальный код будет отдельно стоящей dll и в состоянии сжатого байткода много не займёт

runtime и библиотеки общие для всех

mscorlib тоже стрипается по неиспользуемому коду. В Linker.xml явно прописывается, какие классы не должен трогать оптимизатор, чтобы ничего не поломать: This file specifies which parts of the BCL or Blazor packages must not be stripped by the IL Linker even if they aren’t referenced by user code.

Ну, в принципе уже есть Java, которая в своё время имела java applets. Можно бы поидее сварганить без особых трудов что-то вроде единого магазина Java приложений для всех платформ. И даже на разных языках можно будет писать, под jvm сейчас много всего. Однако едва ли это будет намного лучше браузера. То что приложения будут лучше интегрированы в среду это да.

Другой же пусть заключается не в создании вм и всяких там хреней вроде виртуального канваса, а в дальнейшей эволюции тулкитов и языков так, чтобы можно было написать скажем на С+GTK, на C++ + Qt, на php + Qt, на той же java или чём угодно и потом упаковать это дело в пакеты для разных платформ и опубликовать в каком-то едином магазине или репозитории для последующей установке где угодно.

Screen PostScript успешно закопан в яму ещё на заре интернетов..

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

Ты хочешь Google Play\Apple Store\Windows Store

Все это уже есть, и это не веб.

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

WebAssembly быстро пилят, уже идут разговоры дать ему доступ к сети

Как только это произойдет большая часть браузерного движка станет не нужной

Давай с тобой заключим пари, что и через пять лет, никто массово не будет пилить сайты на wasm, а гипертекстовая структура документов, в том числе концепция SPA основанная на DOM так и останется единственной технологией, которая используется повсеместно.

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

Заключаем?

Ну и еще, у меня такой вопрос, просто ради люботыпства. Смотри, Web API, которые реализует тот самый браузерный движок, включает по меньшей мере следующие компоненты

• Ambient Light Events
• Accessibility
• Background Tasks
• Battery API
• Beacon
• Bluetooth API
• Broadcast Channel API
• CSS Counter Styles
• CSS Font Loading API
• CSSOM
• Canvas API
• Channel Messaging API
• Console API
• Credential Management API
• DOM
• Encoding API
• Encrypted Media Extensions
• Fetch API
• File System API
• Frame Timing API
• Fullscreen API
• Gamepad API
• Geolocation API
• HTML Drag and Drop API
• High Resolution Time
• History API
• Image Capture API
• IndexedDB
• Intersection Observer API
• Internatialization API
• Keyboard
• Long Tasks API
• Media Capabilities API
• Media Capture and Streams
• Media Session API
• Media Source Extensions
• MediaStream Recording
• Navigation Timing
• Network Information API
• Page Visibility API
• Payment Request API
• Performance API
• Performance Timeline API
• Permissions API
• Pointer Events
• Pointer Lock API
• Proximity Events
• Push API
• Resize Observer API
• Resource Timing API
• Server Sent Events
• Service Workers API
• Storage
• Storage Access API
• Streams
• Touch Events
• URL API
• Vibration API
• Web Animations
• Web Audio API
• Web Authentication API
• Web Crypto API
• Web Notifications
• Web Storage API
• Web Workers API
• WebGL
• WebRTC
• WebVR API
• WebVTT
• WebXR Device API
• Websockets API

Я, так понимаю, ты хочешь принципиально выбросить DOM и, как следствие CSSOM, и тем самым выбросив все уже, что связано с интернациолизацией, доступностью (слабовядящие\глухие), обработкой событий от устройств ввода (клавиатура, мышь, тах, геймпад) и, что самое классное, машинной обработкой (привет невырезаемая реклама, прощайте поисковики) - и тем самым, предложить все это реализовывать каждому сайту самому (наверное, используя собственные библиотеки для всего) заново, и считай, каждому тащить свое. Окей. Допустим. Из остального, что еще мы выбрасываем, и что у нас там ненужно, или «нужно, чтобы каждый тащил свою реализацию на клиент, когда ему нужно»? Какая функциональность у нас в браузерах лишняя, по-вашему, помимо способности парсить html\css\js, строить объектное дерево элементов и рендерить его.

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

Ты предлагаешь из браузера сделать пиксельный рендерер.
Ок, по каким правилам и стандартам он будет работать и взаимодействовать с пользователем?
Как в таком случае будут взаимодействовать твои фронтенд и бакенд?
Снова всё гонять на сервер и обратно при каждом чихе?

Например WebAssembly и некое видеопространство на котором можно рисовать.

Потому что так уже можно делать. А «пихать» - это тяга лоровцев к минимализму, когда им спится спокойнее что они юз-флагом в генте что-то отключили. То что туда «запихали» лежит мертвым грузом если его нету на странице и в браузерах оно уже есть и не мешает. Тут единственный аргумент - дорого новые браузеры делать. Но если задача сделать быструю страницу - то WebAssembly уже быстрее работает даже с DOM манипуляциями, не говоря уже о рисовании. Все к тому идет. При этом API останутся, потому что они делают многие важные вещи в сфере взаимодействия с ОС, которые нельзя имплементировать иначе, изнутри в WebAssembly. Нельзя с нуля в WebAssembly имплементировать геолокацию - это должна предоставлять среда

Ну и еще, у меня такой вопрос, просто ради люботыпства. Смотри, Web API, которые реализует тот самый браузерный движок, включает по меньшей мере следующие компоненты

Кажется я уже писал, delphi возвращается, для виртуальной машины будет сборка с нужными модулями с функциями данных апи.

Если сейчас браузер содержит ВСЁ что можно, то в ВМ будет попадать ТО что нужно

Доступ к псевдожелезу будет управляться так же как и сейчас разрешениями для браузера-виртуальной машины в котором крутится webassembly приложение

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

Ещё веб можно распечатать. Хоть на А4, хоть на чековой ленте.

А с фреймбуфером управляемым WASM что делать? Это возвращение к best viewed on 1024×768, только на этот раз без какой-либо надежды на более новый браузер.

Так я же говорю, ты хочешь не веб, а app store. Это уже есть, пользуйся.

Ок, по каким правилам и стандартам он будет работать и взаимодействовать с пользователем? Как в таком случае будут взаимодействовать твои фронтенд и бакенд?

Мда, софт умер, его убило веб мышление :)

Фронтенд и бекенд и это то самое клиент-серверное приложение, стандарты протоколов и прочего не обязательны, можно свой протокол сделать.

Браузер выполняет скорее функцию гарантии безопасности, чем выполнения приложения, и городить для этого мега движок не обязательно

Можно между ВМ и сервером поставить расширяемый модуль обмена. Туда добавлять нужные протоколы

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

А с фреймбуфером управляемым WASM что делать?

Дизайн всё, функционал ничто ?

Если Wasm приложению нужно оно даст такой функционал, а так, зачем ? Если нужно распечатать сайт есть скриншот, если перевести в текст - OCR

Так я же говорю, ты хочешь не веб, а app store. Это уже есть, пользуйся.

Апстор привязан к платформе Гугла или Apple. WebAssembly как http не привязан ни к чему

Извини, как давно ты занимаешься веб-разработкой? И занимаешься ли ты ей вообще? Если нет, то программированием в какой сфере и как давно?

js проще закопать, чем исправить. А (x)html - норм, поживёт

Скорее наоборот. Браузер тормозит в основном из-за HTML и CSS в которых тонны legacy и которые не рассчитаны на быструю работу. Вместо них нужен какой-нибудь QML. Попробуйте помасштабировать окно с простой веб страницей и нативное приложение и почувствуйте разницу.

JavaScript работает достаточно быстро, он один из самых производительных скриптовых языков.

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

Браузер тормозит в основном из-за HTML и CSS в которых тонны legacy и которые не рассчитаны на быструю работу

Кстати, не хватает упрощенного протокола HTML, тупо кнопку без дизайна нарисовать и поля для формы

Под масштаьированием окна ты имеешь ввиду изменение размера окна или таки масштаб?

Изменение размеров окна.

<button>кнопка без дизайна</button>

Куда проще?

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