We made a server-less virtual Linux environment that runs unmodified Debian binaries in the browser. This is powered by CheerpX, a WebAssembly virtualization platform.
Здравствуйте, Baiker, Вы писали:
B>Ну так предложи! Спрашивать любой дурак может!
Ну ок, вот мои мысли.
Прежде всего мне не хватит мозгов, чтобы действительно предложить что-то прорывное. Поэтому я попробую проанализировать разные варианты и сравнить их.
Итак, в чём суть проблем.
Начну с покомпонентного рассмотрения Web.
Web по моему мнению это TCP + TLS + HTTP + HTML + CSS + JS.
TCP + TLS + HTTP имеют некоторые известные проблемы. Эти проблемы решены переходом на UDP + QUIC. Вряд ли их можно решить лучше. Поэтому тут всё оптимизировано.
HTML это просто XML-подобный язык. В целом тут придираться особо не к чему. Про всякие семантические теги сейчас рассуждать не буду, к производительности это в любом случае не относится. Единственное, на чём можно остановиться — HTML это не строгий язык, причём в стандарте описано, как нужно парсить невалидный HTML. На мой взгляд это лишнее. Будь моя воля, я бы запретил все вольности. Всякие самозакрывающиеся теги, атрибуты без кавычек и прочее. Но, полагаю, что в разрезе производительности это ни на что не влияет.
CSS это штука сложная. Однозначно вижу одну из проблем веба именно тут.
Во-первых CSS заточен на страницу и не заточен на компоненты. В то время, как в программировании компонентный подход это, как говорится, наше всё.
Во-вторых в CSS собрано слишком много функционала. Я бы предложил его разделить как минимум на две части: собственно стили (шрифты, цвета, границы, тени и тд) и layout (размеры, флоаты, flex, grid и тд).
В-третьих layout движок в CSS по моему мнению настолько сложен, что мало людей вообще способны осознанно с ним работать. Понятно, что от наследия никуда не деться. Но если про него забыть, то layout было бы правильней создать с нуля, используя опыт мобильных приложений. Там с ним всё куда проще.
JS — тут сложный вопрос. С одной стороны язык однозначно неудачный. С другой стороны современные реализации его умеют выполнять с умопомрачительной скоростью. WebAssembly тут даёт некоторую альтернативу, хотя он и не доделан на мой взгляд. Не уверен, что если бы вместо JS был, к примеру Python, веб был бы лучше.
Таким образом могу только согласиться с мнением, что в браузере уже всё есть и ничего принципиально лучшего изобрести нельзя. Но веб тем не менее плох и не похоже, чтобы он становился лучше, несмотря на весь прогресс. То бишь ответа в улучшении каких-то отдельных компонентов веба не найти.
Рассмотрим мобильные приложения. Это относительно новое явление и они решают задачи, похожие на задачи, которые решают веб-приложения. В целом считается, что у них лучше UX и я с этим соглашусь. Хотя в теории я не вижу ничего, что мешало бы делать веб-приложения такими же удобными, как мобильные приложения, на практике большинство мобильных приложений удобней большинства веб-приложений. Значит что-то в них отличается.
Во-первых мобильные приложения, как правило, скачиваются сразу целиком. То бишь у пользователя есть раздельные фазы — сначала он скачивает сто мегабайтов непонятно чего и потом уже не скачивает. В веб-приложениях скачивание ресурсов обычно так или иначе размазано. Что приводит к тому, что страницы грузятся дольше.
Во-вторых в мобильных приложениях упомянутый layout сделан гораздо проще. Это тема большая и обширная, но сам факт остаётся фактом. Помимо прочего интерфейс в мобильных приложениях обычно проектируют визуальным редактором. В вебе до сих пор интерфейс в 99% случаев пишут текстом. Хотя дельфи была 30 лет назад. Это однозначно сказывается на скорости разработки.
В-третьих мобильные приложения используют заранее скомпилированный и более оптимизированный код. Тут вебу противопоставить нечего. Даже хвалёный webassembly требует относительно долгого времени для компиляции в native вид. Я не знаю, как "установить" сайт со 100 MB кода на webassembly и скомпилировать его в x64 один раз, чтобы потом пользоваться им без задержек при запуске. На маленьких примерах это не заметно, на больших объёмах компиляция начинает занимать ощутимое время. Тут можно ожидать прогресса в браузерах, к примеру подхода, как в Java — сначала работаем интерпретатором и компилируем только "горячие" функции, причём в фоне. Но всё равно это будет не так эффективно, как с мобильными приложениями. Ну или браузеры научатся кешировать скомпилированный машинный код, наверное это не должно быть так уж сложно.
Если резюмировать, что бы я сделал по-другому:
Сам формат HTML был создан для документов, а не для приложений. То бишь лучше всего вообще забыть про него, если речь идёт про приложения. А создать параллельный стек технологий, работающий в том же браузере.
Приложение должно определяться, как группа ресурсов. При первом открытии приложения вся группа ресурсов должна скачиваться. Обновление не должно быть обязательным, у пользователя должна быть возможность использовать старую версию приложения и обновляться по желанию. К примеру я стою на светофоре и запустил навигатор. Мне нужно, чтобы он запустился моментально, а не скачивал 150 мегабайтов новой версии.
Код должен доставляться как webassembly и сразу по завершении доставки компилироваться и сохраняться в нужных кешах, при повторных запусках код должен сразу выполняться. WebAssembly должен быть доработан, к примеру должна быть поддержка GC со стороны браузера, должен быть прямой доступ к вызовам API, в целом эта работа ведётся и сейчас, просто надо на ней сфокусироваться и всё доделать.
Для интерфейса должен использоваться отдельный язык разметки. XML-подобный, но никакой семантики. Простой и минималистичный. С хорошей поддержкой компонентов.
Для стилизации должны использоваться темы. Что-то вроде CSS. В целом стилизация должна делаться внутри компонента, а тема задаёт некие входные параметры для стилей.
Для layout должен использоваться отдельный механизм. Для вдохновения можно посмотреть на готовые решения из iOS, Android, Flutter, React Native.
Есть соблазн дать приложению пустой canvas и сказать: рисуй как хочешь. А там фреймворки разберутся. Но считаю это неправильным подходом. Браузер будет работать быстрей, чем код в песочнице. А также есть такие моменты, как accessibility, которые проще обеспечивать, имея унифицированный подход к интерфейсу. Extensions тоже своё место в вебе имеют.
Также нужно продумать многопоточность. Современная программа должна её использовать более активно. В современном вебе с этим тухловато. Ну тут вопрос больше к WebAssembly, наверное. В общем должна быть возможность легко убирать код в фоновый поток и получать результаты. Также layout и DOM должны быть полностью асинхронными и использовать многопоточность по максимуму. Обработка пользовательского ввода должна вестись в отдельном потоке, у кода приложения не должно быть возможности "заморозить" или хоть как-то повлиять на интерфейс.
Также нужно продумать хороший API для анимаций, плавные анимации это очень важная часть в восприятии пользователями скорости работы приложения, а удобный API это то, что позволит делать эти анимации без лишних усилий. Ну тут, думаю, тоже особо выдумывать ничего не надо, посмотреть, как сделали другие и взять лучшее. Тут я не особо разбираюсь, честно говоря, понимаю только то, что это важно.
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
vsb>Но жаловаться любой дурак может. А вот что бы вы сделали по-другому? Чтобы при этом не терять удобство использования веба, которое есть сейчас.
Ну вот возьмем для примера MAUI, Flutter, React Native. В том же направлении надо двигаться и браузерам c Webassembly.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vsb, Вы писали:
vsb>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают.
А почему managed в вебе не взлетел? Типа JVM? Почему не смогли аналог java-апплетов до ума довести?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
vsb>>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. ·>А почему managed в вебе не взлетел? Типа JVM? Почему не смогли аналог java-апплетов до ума довести?
У Java безопасность была неудовлетворительная. Постоянно находили эксплоиты. Флеш Джобс решил в айфоне не поддерживать, наверное это был последний гвоздь, хотя там тоже с безопасностью вроде было не супер.
Здравствуйте, vsb, Вы писали:
vsb>>>Все жалуются на медленные сайты. Ну в принципе правильно жалуются, я в целом согласен. Десктопные приложения пошустрей работают. vsb>·>А почему managed в вебе не взлетел? Типа JVM? Почему не смогли аналог java-апплетов до ума довести? vsb>У Java безопасность была неудовлетворительная. Постоянно находили эксплоиты. Флеш Джобс решил в айфоне не поддерживать, наверное это был последний гвоздь, хотя там тоже с безопасностью вроде было не супер.
Понятно, что были дыры в конкретных реализациях. Непонятно почему сам подход с верифицируемым байт-кодом не взлетел. Или просто что первое выстрелило, то и прижилось?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
vsb>>·>А почему managed в вебе не взлетел? Типа JVM? Почему не смогли аналог java-апплетов до ума довести? vsb>>У Java безопасность была неудовлетворительная. Постоянно находили эксплоиты. Флеш Джобс решил в айфоне не поддерживать, наверное это был последний гвоздь, хотя там тоже с безопасностью вроде было не супер. ·>Понятно, что были дыры в конкретных реализациях. Непонятно почему сам подход с верифицируемым байт-кодом не взлетел. Или просто что первое выстрелило, то и прижилось?
Ну WebAssembly можно считать следующей попыткой по сути. А так — хз, попыток наверное не особо много было. Внутрь браузера никто не пускает. Подходы вроде апплетов, сильверлайта требуют установки плагинов, зачастую обвешаны окошками подтверждения, в общем это не тот пользовательский опыт, который бизнес хочет видеть.
Здравствуйте, ·, Вы писали:
·>Понятно, что были дыры в конкретных реализациях. Непонятно почему сам подход с верифицируемым байт-кодом не взлетел. Или просто что первое выстрелило, то и прижилось?
Неправильный подход к безопасности. java runtime api спроектировано для работы без ограничений, и в нем понатыкано проверок на права. JS пошел с другой стороны — API изначально спроектировано для работы в песочнице. Флеш по-моему на те же грабли наступил.
Здравствуйте, vaa, Вы писали:
vaa>1) сделать загрузку контента однопоточной.
Глупость. Без разницы, когда и как ты загрузишь допы, главное — чтобы браузер умел рендрить главную страницу до всяких картинок.
vaa>2) запретить делать рич контент. никаких скриптов на клиенте
Здесь абсолютно солидарен, скрипты на%ер не нужны. HTML — это гипертекст, он никогда не нуждался ни в какой динамике, это же паблишинг в чистом виде.
vaa> я бы даже css запретил
эээ! Ну ты это, выдыхай, бобёр! Не нужно впадать в крайности, CSS как раз много дал для ЛОГИЧЕСКОЙ вёрстки и реюзабельности.
Нам нужен "паблишинговый" WWW отдельно от "прикладного". Газеты, порносайты, блоги — всё спокойно верстается на HTML 1.0; Это и должен быть "мир гипертекста". А для "приложений в браузере", увы, мы опять придём к тому, что каждое недо-веб-приложение будет пытаться всё больше вылезти за пределы песочницы и "подёргать нативный API". Поэтому НАХРЕН все эти жабосрипты и вебассембли — берите C# и пишите нормальные MSIL-приложения! Они и на ведроиде смогут работать, и на линуксе, и в эппло-диктатуре.
Здравствуйте, Baiker, Вы писали:
B>Здравствуйте, gandjustas, Вы писали:
G>>Я бы сделал быстрые сайты. При текущем уровне развития веба это сделать можно. RSDN же быстро работает.
B>А в IE 3.0 без скриптов он будет работать?
Не будет. А должен? Много пользователей RSDN сидит на IE 3? Я думаю примерно ноль.
vsb>Прежде всего мне не хватит мозгов, чтобы действительно предложить что-то прорывное. Поэтому я попробую проанализировать разные варианты и сравнить их.
Ну, не прибедняйся уж так. На самом деле причина просто выпирает из веба своими бородавками: противоречие между вебом в изначальной задумке (как ГИПЕРТЕКСТ, т.е. паблишинг с переходами) и его современным применением для ИМИТАЦИИ приложений, но через убогую веб-страничку. И кстати далее ты это упомянул.
vsb>Будь моя воля, я бы запретил все вольности. Всякие самозакрывающиеся теги, атрибуты без кавычек и прочее. Но, полагаю, что в разрезе производительности это ни на что не влияет.
Ещё как влияет!! Попробуй написать движок для "вольного HTML" и для строгого XML — очевидно, что последний будет стократ надёжнее и быстрее.
vsb>CSS это штука сложная
+1, его надо сократить до уровня "цвет-шрифт-отступы" и этого будет достаточно за глаза.
vsb>В-третьих layout движок в CSS по моему мнению настолько сложен
Его там вообще не должно быть. Лэйаут — это к HTML. Внешний вид — CSS.
vsb>JS — тут сложный вопрос
Вообще не сложный. JS must die. Кто не согласен, пусть сожрёт ведро горчицы.
vsb>Таким образом могу только согласиться с мнением, что в браузере уже всё есть и ничего принципиально лучшего изобрести нельзя
Ровно наоборот — в браузере реализована такая ПОМОЙКА технологий, что даже бывалые зубры не отважатся создать браузер с нуля. А что уж творится внутри Chromium даже сами разрабы хромого не все понимают.
vsb>Рассмотрим мобильные приложения
Не хочу. Они сюда вообще никаким боком.
vsb>Сам формат HTML был создан для документов, а не для приложений. То бишь лучше всего вообще забыть про него, если речь идёт про приложения. А создать параллельный стек технологий, работающий в том же браузере.
ВОТ! Здравая мысль. Отделить обезьян-жабописак от паблишинга и вернуть Вебу былую скорость и компактность.
А для приложений — я уже писал, Silverlight был прекрасной технологией. Но она не имеет смысла В БРАУЗЕРЕ. Поэтому инсталлируем везде .NET Framework и не ипём мозга — всё канпеляем в MSIL и вообще не паримся.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Baiker, Вы писали: B>>А в IE 3.0 без скриптов он будет работать?
G>Не будет. А должен?
Должен. Но не потому, что "люди сидят в IE", а потому, что IE — это просто! Это минималистичный набор инструментов, который ЛЕГКО РЕНДРИТЬ и не закапываться в тонны JS/CSS.
Строго говоря, RSDN вообще спокойно может прожить без единой строчки JS. ЗАЧЕМ ОН ТУТ??
Плюс, если чел будет общаться через смарт, ему не нужны будут гигабайтные телефоны — на простом iPhone-2 можно запросто читать/писать.
Если посмотреть на тулбар окна редактирования сообщения, то в принципе это и есть тот набор, который должен использоваться при вёрстке сайта! Жирный, италик, картинки, списки... что вам ещё нужно?? HTML уже вам всё дал — посмотрите, сколько всего можно засунуть между <form></form>! Но нет, люди изгаляются, строчат 100-строчные CSS, лезут в каждый элемент со своими стилями... оно мне надо? Просто сделай <button type="submit"> — всё, я буду счастлив!
Не так сложен веб, как буйна фантазия разрабов. Сайт должен ориентироваться в первую очередь на простоту (влекущую малый объём и скорость) и только потом на красоту.
Здравствуйте, scf, Вы писали:
scf>·>Понятно, что были дыры в конкретных реализациях. Непонятно почему сам подход с верифицируемым байт-кодом не взлетел. Или просто что первое выстрелило, то и прижилось? scf>Неправильный подход к безопасности. java runtime api спроектировано для работы без ограничений, и в нем понатыкано проверок на права. JS пошел с другой стороны — API изначально спроектировано для работы в песочнице. Флеш по-моему на те же грабли наступил.
Ну в браузерах по итогу та же модель, например, firefox в about:config, pref/lockPref и по всему коду проверки на установленность соответствующих ключей конфига.
Аналог java.lang.SecurityManager по сути...
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
vsb>>А вот что бы вы сделали по-другому? BFE>Я бы сделал его децентролизованным, как eMule. Ничто не мешает каждому браузеру раздавать из кэша куски неизменяемых данных.
Зачем это делать браузеру? Для этого есть кеширующие прокси и cdn.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>Я бы сделал его децентролизованным, как eMule. Ничто не мешает каждому браузеру раздавать из кэша куски неизменяемых данных.
Более того, это дыра в privacy и безопасности. Можно будет видеть что у кого в кешах личного браузера.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
На самом деле причина просто выпирает из веба своими бородавками: противоречие между вебом в изначальной задумке (как ГИПЕРТЕКСТ, т.е. паблишинг с переходами) и его современным применением для ИМИТАЦИИ приложений, но через убогую веб-страничку. И кстати далее ты это упомянул.
