Комментарии 103
НЛО прилетело и опубликовало эту надпись здесь
Да здравствует закрытый веб, без индексации страниц, выделения текста и наполненый неудаляемой рекламой
Все пункты кроме рекламы решаются технически. Посмотреть как это работает в действии можно уже сегодня к примеру тут: https://gallery.flutter.dev
Пока что флатер проигрывает в плавности нативным приложениям, но я думаю это вопрос времени
Индексацию можно вынести какими-то метаданными
А потом надо для удобства внутри canvas создать свои метатэги, описывающие стандартные блоки, отдельно сделать метаязык стилей для этих метатэгов... И вообще написать метабраузер внутри canvas... И замкнётся колесо сансары.
Вероятнее произойдёт чуть по другому — HTML/CSS/JS будет вынесено из ядра браузера и превратится в набор подключаемых модулей, живущие до тех пор, пока привычный нам веб полностью не умрёт. А браузер просто станет комбинацией из виртуальной машины и графического движка.
Одновременно будет умирать HTTP, так как нет смысла придерживаться одного варианта, когда есть возможность поверх TCP-сокетов в виртуальной машине любые протоколы наворачивать.
Если подумать в такой логике дальше, браузер скоро может и ОС начать вытеснять
Одновременно будет умирать HTTP, так как нет смысла придерживаться одного варианта, когда есть возможность поверх TCP-сокетов в виртуальной машине любые протоколы наворачивать.
Если подумать в такой логике дальше, браузер скоро может и ОС начать вытеснять
HTML/CSS/JS будет вынесено из ядра браузера… А браузер просто станет комбинацией из виртуальной машины и графического движка.
Очень понравился ваш комментарий, это действительно похоже на будущее.
И появится ХромБук 2.0
Одновременно будет умирать HTTP, так как нет смысла придерживаться одного варианта, когда есть возможность поверх TCP-сокетов в виртуальной машине любые протоколы наворачивать.
Смею не согласиться. По-моему, наоборот умирают кастомные протоколы, а новый софт строится с использованием слоя http.
для удобства внутри canvas создать свои метатэги, описывающие стандартные блоки, отдельно сделать метаязык стилей для этих метатэгов
Зачем метатэги? Просто принять стандарт представления информации для индексирования. Поисковику нужно всего лишь получить текстовое представление некого ресурса — вот это и оговорить в стандарте. Чтобы поисковик ничего не парсил а получал в удобном для него виде без возможности ошибочной трактовки.
Колесо замкнется, когда кому-то в метабраузере снова понадобится метаканвас...
Да, и этот пример показывает именно то, что говорилось комментарием выше: выделение не работает, страница игнорирует настройки прокрутки браузера и google не может нормально найти текст на ней. Про плавность вы и сами сказали.
Так ради этого и разрабатывается ))
Java Swing? :) Где с точки зрения ОС одно AWT окно в котором все рисуется
Flex? Где все контролы по-моему рисовались в одном flash фрейме…
Можно еще сделать библиотеку material html контролов и рисовать в канвас…
Flex? Где все контролы по-моему рисовались в одном flash фрейме…
Можно еще сделать библиотеку material html контролов и рисовать в канвас…
НЛО прилетело и опубликовало эту надпись здесь
Но с самого начала шла тихая, но никогда не прекращающаяся война между двумя точками зрения на веб, между теми, кто воспринимал его как хранилище структурированных документов, и теми, кто видел его платформой, обеспечивающей функционирование контейнеров для приложений.
Я безусловно являюсь сторонником веба как хранилища структурированных документов, и дальнейшей семантизации веба с перспективой превращения его в открытую базу знаний человечества и основу для будущих баз знаний искусственного интеллекта. А приложения в моем понимании должны быть классическими оффлайн-приложениями, хранящими данные на диске пользователя и дающие пользователю полный контроль над данными. В частности, так работали оффлайновые почтовые клиенты и прочие подобные программы.
Но увы — победу (по крайней мере на данном этапе) одержали сторонники веб-приложений. Теперь весь контент находится не у пользователя, а где-то там, на серверах корпораций. Большинство пользователей не сохраняет понравившуюся им информацию — а лайкает, репостит и т.п. — в результате информация остается под полным контролем веб-ресурса и может быть удалена в любой момент.
Да, canvas это еще один огромный шаг в сторону, противоположную семантическому вебу. Даже сайты с текстом вполне могут рендериться попиксельно, не давая пользователю сохранить текст, а разрешая только смотреть — т.е. интернет превратится в банальный телезомбоящик. Тут может показаться, что Гугл сам от этого пострадает — как он будет индексировать интернет? Но в этой мрачной антиутопии возможно всё — например, сайты, чтобы попасть в выдачу, будут предоставлять Гуглу и ограниченному числу других поисковиков специальные «текстовые» версии, закрытые для остального мира паролями, которые будут передаваться поисковикам через специальную регистрацию веб-ресурсов на самих поисковиках. А остальным — жрите картинки…
Тут может показаться, что Гугл сам от этого пострадает — как он будет индексировать интернет?Можно распознавать текст с страницы-картинки и потом его индексировать, но ресурсов это конечно потребует намного больше.
Так концепция "вы ничем не владеете, и вы счастливы" реализуется по разным направлениям, как бы не хотелось верить в обратное.
Тут может показаться, что Гугл сам от этого пострадаетКак раз на этот случай, для подобного есть AMP, и предполагается, что это одна из причин, по которой гугл хочет скрыть доменное имя.
Да уж, печально все это. Изначальную идею HTML как универсального мультиплатформенного веб-языка уже полностью извратили и похоже готовяться сделать финальное фаталити.
В современных сайтах объем жабаскрипт-мусора уже превышает объем графики, а для рендеринга этого безобразия нужны гигагерцы и гигабайты, а ведь раньше веб был на даже девайсах с объемом памяти, измеряемой в килобайтах. При этом функционал за редким исключением практически не поменялся.
И вот что мешало развивать HTML, добавляя новые теги для нужных фич, которые бы рендерились нативно браузером, вместо этого засилия js?
В современных сайтах объем жабаскрипт-мусора уже превышает объем графики, а для рендеринга этого безобразия нужны гигагерцы и гигабайты, а ведь раньше веб был на даже девайсах с объемом памяти, измеряемой в килобайтах. При этом функционал за редким исключением практически не поменялся.
И вот что мешало развивать HTML, добавляя новые теги для нужных фич, которые бы рендерились нативно браузером, вместо этого засилия js?
И вот что мешало развивать HTML, добавляя новые теги для нужных фич, которые бы рендерились нативно браузером, вместо этого засилия js?Во-первых, не всё можно сделать с помощью тегов. Во-вторых, на оптимизацию нужны деньги и она может легко не окупиться.
При этом функционал за редким исключением практически не поменялся.
Это, мягко говоря, совсем не так.
Думал, про Google Docs шутка. Открыл таблицы, нашел в элементах canvas, удалил canvas, посмотрел, вернул — да, все так. Неожиданно
Возможно, для текстового процессора это оправданный шаг. Им же нужна точная верстка на всех устройствах.
change to Canvas rendering will “improve performance and improve consistency in how content appears across different platforms.”
https://thenewstack.io/google-docs-switches-to-canvas-rendering-sidelining-the-dom/
canvas — редкостно тормознутая штука. Вот пример, допустим вы делаете эмулятор древнего DOS-терминала. Просто окошко с текстом, 80x25 символов, 16 цветов самого текста, 16 цветов фона. В качестве теста производительности — простое заполнение этого терминала рандомными символами с рандомным цветом.
Это, блин, на 386 процессоре работало без проблем в начале 90-х!
Но вот добиться, чтобы при рендере на канвас этот код выдавал хотя бы 50 FPS на современном восьмиядерном десктопе и 20 FPS на мобильных устройствах (тоже с восемью ядрами) — задача нетривиальная, а на тех мобильных устройствах, которые WebGL2 не поддерживают, и вовсе неразрешимая.
Это, блин, на 386 процессоре работало без проблем в начале 90-х!
Но вот добиться, чтобы при рендере на канвас этот код выдавал хотя бы 50 FPS на современном восьмиядерном десктопе и 20 FPS на мобильных устройствах (тоже с восемью ядрами) — задача нетривиальная, а на тех мобильных устройствах, которые WebGL2 не поддерживают, и вовсе неразрешимая.
Во времена процессора i386 всем этим занимался видеоконтроллер. Он просто отображал содержимое оперативной памяти, начиная с адреса, хранящегося в определенном регистре. Если был установлен текстовый видеорежим, то каждый байт интерпретировался как символ, а следующий за ним (ЕМНИП) содержал информацию о цвете символа и его фона (16+16). Там процессору делать было вообще нечего, кроме как время от времени записывать в память байты.
Делал что то подобное, не должно это так тормозить. Может тормозит не вывод а генерация?
Вот наиболее быстрый пример:
jsfiddle.net/vknm2dwq
но даже он не даёт достаточного FPS. При том, что FillText здесь рендерит сразу полными строками, а не по символу, и у canvas куча параметров выставлена, чтобы скорость повысить.
Без использования WebGL сделать ещё быстрее по-видимому невозможно, кроме как снижением размера канваса (с последующим «растягиванием» на весь экран чисто за счёт style.width). Так, если в примере выставить SYM_WIDTH=8 и SYM_HEIGHT=16 (что даст нам ширину канваса в 640 пикселей), то FPS будет достаточным, но качество изображения сильно упадёт.
jsfiddle.net/vknm2dwq
но даже он не даёт достаточного FPS. При том, что FillText здесь рендерит сразу полными строками, а не по символу, и у canvas куча параметров выставлена, чтобы скорость повысить.
Без использования WebGL сделать ещё быстрее по-видимому невозможно, кроме как снижением размера канваса (с последующим «растягиванием» на весь экран чисто за счёт style.width). Так, если в примере выставить SYM_WIDTH=8 и SYM_HEIGHT=16 (что даст нам ширину канваса в 640 пикселей), то FPS будет достаточным, но качество изображения сильно упадёт.
как и говорил, проблема не в отрисовке а в генерации jsfiddle.net/xbe9kgmj
дело в том что некоторые ф-ии в js медленные. даже вызов лишней функции в цикле это огромные потери времени. а вы на каждый пиксель вызываете кучу функций, миллионы вызовов в итоге.
+ опасайтесь использовать разные медленные функции типа random и др.
в вашем примере я заменил генерацию рандомного цвета, на выбор из массива. выводимый текст также захардкожен, а не генерится на каждый кадр. в итоге у меня фпс вырос с 40 до 58-60. вывод не менял. если еще оптимизировать то делал чисто 60.
в следующий раз когда фпс сядет — комментируйте часть кода обновления фрейма пока не восстановится.
дело в том что некоторые ф-ии в js медленные. даже вызов лишней функции в цикле это огромные потери времени. а вы на каждый пиксель вызываете кучу функций, миллионы вызовов в итоге.
+ опасайтесь использовать разные медленные функции типа random и др.
в вашем примере я заменил генерацию рандомного цвета, на выбор из массива. выводимый текст также захардкожен, а не генерится на каждый кадр. в итоге у меня фпс вырос с 40 до 58-60. вывод не менял. если еще оптимизировать то делал чисто 60.
в следующий раз когда фпс сядет — комментируйте часть кода обновления фрейма пока не восстановится.
посомтрел еще раз код. на счёт миллионов я конечно преувеличил. но все равно итераций много и дело однозначно в них. и поменьше рандома.
stackblitz.com/edit/canvas-dos-render?file=index.ts
Рендеринг 8мс + GPU 10мс, около 50 FPS на ноутбуке.
Кернинг шрифта много занимает.
Рендеринг 8мс + GPU 10мс, около 50 FPS на ноутбуке.
Кернинг шрифта много занимает.
А зачем обязательно WebGL 2?
Чтобы иметь возможность отрендерить всё, включая текст, одним шейдером. Иначе придётся в несколько проходов делать.
вот с генерацией текста WebGL наоборот может все замедлить, потому что текст часто обновляется, а обновление текстур стоит дорого
поэтому, к примеру, живые (векторные) тексты в Phaser 3 обновляются с заметными тормозами (особенно видно на больших списках). (речь идет об Phaser.GameObjects.Text)
Лечение — пререндер символов или использование растровых шрифтов, тут WebGL дает максимальные преимущества.
Выше есть примеры текстов в цикле, там текст живой и обновляется. Даже без WebGL это можно чудовищно ускорить, если заранее буферизовать все символы.
pS: «живой» — то есть не является статичной картинкой и у него меняются свойства, он создается заново, что требует перерисовки.
поэтому, к примеру, живые (векторные) тексты в Phaser 3 обновляются с заметными тормозами (особенно видно на больших списках). (речь идет об Phaser.GameObjects.Text)
Лечение — пререндер символов или использование растровых шрифтов, тут WebGL дает максимальные преимущества.
Выше есть примеры текстов в цикле, там текст живой и обновляется. Даже без WebGL это можно чудовищно ускорить, если заранее буферизовать все символы.
pS: «живой» — то есть не является статичной картинкой и у него меняются свойства, он создается заново, что требует перерисовки.
В Quake 3 Arena можно отлично поиграть, без каких-либо лагов в мультиплеере.
WebGL1 для этого хватит, а оно поддерживается на 99% мобилок. За исключением очень старых, таких, на которые и нативного приложения уже давно не найдешь. На моем телефоне 60000 спрайтов канвас рендерит в 60 fps. Хватит чтобы покрыть экран текстом в 30 слоев.
Это, блин, на 386 процессоре работало без проблем в начале 90-х!
Давайте будем честны: в те времена не было ни полноценного RGBA, ни векторных TrueType шрифтов (точнее, они только-только появились в Mac 7 и Windows 3.1), ни субпиксельного сглаживания, ни субпиксельного же кернинга. В текстовых режимах графики символы были строго двухцветные, а их изображения были статичны и вшиты в видеокарту. Итоговое изображение монопольно захватывало весь экран, а не находилось в пределах отдельного окошка, опционально будучи перекрытым другими окошками, возможно даже полупрозрачными и с красивым размытием, которое нужно высчитывать в реальном времени при каждой перерисовке.
Если стоит задача эмулировать текстовый режим графики, то использовать все эти новомодные штучки в канвасе, вероятно, не стоит, так как они лишь добавят накладных расходов. В частности, лучше сразу же выкинуть fillText и measureText, так как они очень тяжёлые по сути своей. И попутно вырубить композитный менеджер окон, это тоже заметно повышает фпс.
Меня тут упороло на лютые извращения, но зато получились ровные 60 фпс на телефоне и 300 фпс на десктопном хроме https://jsfiddle.net/oc3520zL/
Если же вы хотите рисовать векторный текст, то стоит иметь в виду, что даже за банальным measureText прячется множество нетривиальных вычислений, которых во времена DOS в принципе не было (и в итоге длина строки в пикселях даже не является целым числом), пиксели могут быть дробными (это влияет на сглаживание), а fillText из-за всей этой фигни вынужден каждый раз заново заниматься растеризацией и всеми связанными с ним вычислениями. Оптимизировать такое — занятие не самое простое.
А разве такой же эмулятор терминала на HTML/CSS работал бы лучше, чем на canvas?
У меня как раз и выдает 50 FPS на старом двухъядерном десктопе. В чем проблема-то...
А зачем собственно веб тогда нужен? На десктопах канвас был практически с рождения.
А зачем собственно веб тогда нужен? На десктопах канвас был практически с рождения.
Годный вопрос. Мне вначале 00-х не понятно было зачем нужно встраивать видео в браузер, если его можно просто скачать и нормально смотреть.
Причины вижу такие:
1. Так уж повелось, что десктопные проги нужно устанавливать, сохранять на диск, а браузерные приложения в установке не нуждаются и использует ОЗУ.
2. Вопрос безопасности десктопных прог (песочница) пытались решить — но не шмогли. А с сайтами более-менее получилось.
3. Все-таки важна концепция URL-адресов, это простая идея, но очень многое меняет. Переизобрести ее сложно. Адресная строка в браузере — это неотъемлемый атрибут.
Буду благодарен если кто дополнит.
Адресная строка в браузере — это неотъемлемый атрибут.
Настолько неотъемлемый, что браузеры стали скрывать все, что идёт после первого слэша?
Раньше было habr.com/ru/company/ruvds/blog/560736
Теперь стало habr.com. Хочешь увидеть полный адрес страницы? Нажми на него…
Теперь стало habr.com. Хочешь увидеть полный адрес страницы? Нажми на него…
И все же адрес можно скопировать, поделиться им, перейти по ссылке одним кликом. Адрес глобален — он актуален на любом компьютере мира.
у меня в фаерфоксе на линуксе показывается весь адрес. Правда, habr.com белым, а остальное — сереньким. Но видно отчётливо.
Так уж повелось, что десктопные проги нужно устанавливать, сохранять на диск, а браузерные приложения в установке не нуждаются и использует ОЗУ.
Место на диске на пару порядков дешевле чем RAM. Браузер все равно много чего кэширует. Ничто не мешает делать тонкий клиент, который всё добро из веба подтащит.
Время играет роль. Установка программы — это целый процесс, нужно нажимать на кнопки, читать лицензионное соглашение, наблюдать за прогресс-баром. А сайт — просто кликнуть по ссылке.
Может быть в идеальном мире все иначе, но у нас так.
Может быть в идеальном мире все иначе, но у нас так.
А сайт — просто кликнуть по ссылке.
Так то оно так, да не совсем. Для мелких приложений — да. Для тяжелых (тот же Quake Live например) — всё равно нужны гигабайты данных, только уже время тратится на скачивание вместо установки.
Установка программы — это целый процесс
А удаление — еще больший процесс. В вебе с этим проще.
Самое главное забыли, возможность запустить видео в один клик (YouTube).
Плюс это расширяет возможности по созданию приложений.
Как вы относитесь к веб-приложениям, интерфейс которых основан на <canvas>?
У меня нет на это цензурных комментариев
Canvas с самого начала позиционировался, как замена флешу. Он им и останется. В Google-Docs довольно много функций, которые раньше бы посоветовали реализовать на флеше. Плюс неважна индексация поисковыми системами, а также сложность разработки не влияет на третьих лиц. Раньше на флеше тоже сайты целиком делали, и где они сейчас? :) А простые сайты 20-летней давности на HTML4.1 до сих пор живут. Webassembly тоже несколько лет назад пророчили, что он изменит веб и все будут писать на нем. Идея что canvas поглотит DOM — это фантазии системных программистов, которые смотрят на веб, и сразу видят, насколько он «несовершенный». Но веб живет своей жизнью и его основополагающим принципам пока что ничего не угрожает.
Угрожает. В мире осталось 2.5 актуальных браузера, а ведь раньше где и каких только браузеров небыло. Жабаскрипты практически поглотили веб — уже есть куча сайтов, которые без js выглядят как белый прямоугольник. Да, еше много сайтов на старых движках, которые просто нормально работают, но и они могут превратиться в жабомонстров после очередного обновления.
Ну а рисование в канвас вместо вывода текста — просто финальный этап этого процесса.
Ну а рисование в канвас вместо вывода текста — просто финальный этап этого процесса.
НЛО прилетело и опубликовало эту надпись здесь
Всё развивается по спирали, были Java апплеты, теперь будет canvas и WebAssembly.
Думал давно уже про эту штуку. Сразу понял, что идею можно развивать, но топорное решение «рендерим всё на canvas» не сработает, потому, что на деле придётся просто новый html+css создавать, только ещё и внутри canvas… без девтулов и прочих удобств, поверх старого html. В итоге будет тот-же html, только внешне отличающийся, с кучей уязвимостей, багов и недоработок ближайшие 100500 лет
Да и ресурсов будет высасывать прилично. У меня на старом ноуте простой крутящийся куб (three.js + canvas) почти роняет вкладку. Потом вроде работает нормально, но медленнее того-же куба на CSS.
Но исследования — это хорошо. Авось, что и найдут.
Да и ресурсов будет высасывать прилично. У меня на старом ноуте простой крутящийся куб (three.js + canvas) почти роняет вкладку. Потом вроде работает нормально, но медленнее того-же куба на CSS.
Но исследования — это хорошо. Авось, что и найдут.
на деле придётся просто новый html+css создавать
Зачем? Все что нужно — это определить стандарт представления информации для поисковиков. В остальном сайты будут похожи на мобильные приложения — вполне юзабельно.
Да и ресурсов будет высасывать прилично
Так это и нужно хозяевам IT — чтобы мы покупали новое железо. Наши интересы никто не представляет — у нас нет союза пользователей.
Возмущаться в курилках мы можем сколько угодно — но все равно придется идти в магазин и раскошелиться на новое железо.
Если массово не ходить и не раскошеливаться, то «хозяева IT» получат кукиш. Не ходите сами и не советуйте другим и, возможно, ситуация измениться.
Если массово
Вот почему-то мы не можем массово. Объединиться не можем — сколько народу столько и мнений.
Я уже так делаю и всем вокруг рассказываю. Иногда, конечно, встречаю непонимание, ну да мне не привыкать. И вы так делайте и другим расскажите. Концепция простая, её можно в три предложения изложить. Объединяться для этого не обязательно. Нет, лучше конечно объединиться, но тогда сразу нужен бюджет, пожертвования, директор, лоббисты и всё такое прочее. Если вы не подвижник, то тут делать нечего. А вот делать самому и рассказывать всем подряд, это каждому по плечу.
Зачем? Все что нужно — это определить стандарт представления информации для поисковиков. В остальном сайты будут похожи на мобильные приложения — вполне юзабельно.
Так основная проблема не поисковиках. Основная проблема в разработчиках.
Точнее, в удобстве разработки. Как вы собираетесь рендерить, например, кнопки?
Будете вручную их прорисовывать? Знаете-ли, рисование на канвасе довольно низкоуровневое.
Уверен, что 99% разработчиков манало вручную весь сайт рисовать.
А как генерить пользовательские события? Вручную переписывать то, что уже есть и работает хорошо?
Да и простой, привычный нам, разработчикам, инпут, такой на вид примитивный, на самом деле не такой уж примитивный, если создавать «с нуля».
Если автоматизировать, то прийдеться придумать шаблонный язык разметки.
А что такое HTML? HTML — Это язык гипертектовой разметки.
А чтобы не перегружать HTML, но дать возможность кастомизации был придуман CSS.
Получается, что круг замыкается и рендеринг на канвасе пришёл к тому-же, что HTML. Только без «опыта», баганый и глючный.
Без девтулов, гайдов и документации.
Кстати, теперь этот новый «HTML» рендерит не браузер на нативном языке, нет, теперь его рендерит JS.
А как известно, JS не особо шустрый. Он растёт в этом плане хорошо, но ещё не догоняет нативные ЯП.
В итоге этот подход, в топорном представлении, у разбитого корыта со всех сторон.
Я лично не стал бы работать в таких свинских условиях.
А любая технология, как известно, умирает очень быстро, если нет сообщества, пользователей.
С одной стороны я был бы только рад, если бы можно было бы вот так разом выбросить нахрен весь стек HTML-JS-CSS-вебпаки-транспиляторы-реакты, просто выбрать в любимой IDE build target=«web», и получить веб-приложение на c/rust/go/python (нужное подчеркнуть).
Типа "Qt for web", только работающее :)
Но, бляха-муха, как только появится способ без головняка рисовать всё на canvas, так сразу же каждый завалящий сайт непременно захочет стать «приложением» и далее получаем упомянутый выше «закрытый веб, без индексации страниц, выделения текста и наполненый неудаляемой рекламой». Grim Deal.
Типа "Qt for web", только работающее :)
Но, бляха-муха, как только появится способ без головняка рисовать всё на canvas, так сразу же каждый завалящий сайт непременно захочет стать «приложением» и далее получаем упомянутый выше «закрытый веб, без индексации страниц, выделения текста и наполненый неудаляемой рекламой». Grim Deal.
далее получаем упомянутый выше «закрытый веб, без индексации страниц
Для решения этой проблемы нужно принять стандарт представления информации для индексирования. Что нужно поисковику? Для каждого ресурса (страницы) — информацию для добавления в индекс. Даже лучше — ничего парсить не нужно, поисковик получает в готовом виде.
Конечно, в таком случае возможен клоакинг — но он и сейчас возможен.
выделения текста
Это тоже можно решить на самом деле.
наполненый неудаляемой рекламой
А это право автора сайта. Можно просить деньги за отключение рекламы. Или вы можете сделать свой аналогичный сайт без рекламы.
НЛО прилетело и опубликовало эту надпись здесь
Ну юзают же люди приложения для Android/iOS и никто не плачет. Причем юзают и на больших экранах.
Если вместо сайтов будет что-то похожее на эти приложения — никто плакать не будет.
Если вместо сайтов будет что-то похожее на эти приложения — никто плакать не будет.
Да и слава богу, пускай в приложениях кнопки будут кнопками, вкладки — вкладками, а текстовые поля — полями, и всё это консистентно в рамках всей ОС, с одинаковыми оступами, шрифтами, тенями, хинтингом, сглаживанием, значками, анимациями, да ещё и с возможностью настройки тем и количества свистения-пердения (если не system-wide, то хотя бы на уровне отдельного GUI-тулкита).
Заодно это немного поубавило бы желание все сайты переделывать в приложения, потому что одно дело, когда клиент почты/электронные таблицы/графический редактор выглядит как Excel, а другое — сайт с котиками (которому и нафиг не нужно быть приложением) выглядит как Excel — так не станут делать ибо пользователи вряд ли оценят.
Заодно это немного поубавило бы желание все сайты переделывать в приложения, потому что одно дело, когда клиент почты/электронные таблицы/графический редактор выглядит как Excel, а другое — сайт с котиками (которому и нафиг не нужно быть приложением) выглядит как Excel — так не станут делать ибо пользователи вряд ли оценят.
Qt for WebAssembly уже вполне рабочее решение. И можно обычное desktop qt приложение превратить в приложение, работающее в браузере. Не всегда достаточно просто перекомпилировать, могут потребоваться доработки. Но все решаемо. А вот надо ли так делать — тут однозначного ответа нет.
Интересно, как мистер Тим Бернерс-Ли к этому относится, он пушал семнтический веб, новое будущее это прогресс для него или драма…
Теперь пока все текстуры не прогрузятся, страницу не увидишь...
То есть Google, производитель известного веб-браузера,
не смогли сделать Google Docs на веб-технологиях, даже со всеми своими Chrome-specific нестандартными расширениями?
Очередная каста велосипедистов?
Можно всё сделать, но если есть рабочие решения, быстрые решения, проверенные решения, зачем делать многое и заново?
Есть такое золотое правило, техническая сложность решения никуда не денется, как её не переделывай и не рассовывай, поэтому как они не аргументируй, они всё-равно сделают велосипед, если уйдут на canvas.
Вобщем, имхо, это решит лишь конкретные узкие задачи, но это не замена текущему вебу.
Господи, ну кто ж мешает делать нативные приложения? Добавьте какую-нибудь платформу для унификации, и все.
Даешьгипертекстовый векторный текстовый веб. Где ты можешь сохранить ссылку на произвольную страницу и скопировать текст страницы.
Даешь
Если вы заглянете на страницу, работа которой основана на WebAssembly, то окажется, что на ней выполняется предварительно скомпилированный код, уровень которого лишь немногим выше уровня ассемблера. И такой код, определённо, если сравнить его даже с очень сильно минифицированным образцом JS-кода, гораздо сложнее прочесть человеку.Кроме минификации с целью уменьшения размера, есть ещё обфускация, а с учётом лёгкости рефлексии, js даёт огромные возможности по запутыванию кода, включая непечатные символы, юинкод в идетификаторах, управление порядком строки и так далее.
Прочитал статью, прочитал комменты. на самом деле, мне и страшно, и интересно на это посмотреть, благо, в компании, где я работаю, используется стек Microsoft, и Google Docs пока не критичны. Я тот самый пользователь ассистивных технологий, попросту говоря, слепой. Мы, пользователи программ экранного доступа, воспринимаем только текст. Текст, текст и ничего кроме текста. Отрисованные буковки и пиксели не катят, их нельзя прочитать и перевести в речь или Брайль. Есть OCR, но это ужасно медленно и, главное, ужасно ненадёжно по качеству (а ещё практически нереально сохранить семантическое форматирование в виде заголовков, списков, таблиц и прочего, с чем мы сейчас в DOM можем быстро и эффективно взаимодействовать). В соответствующем мейлинг-листе Google идёт буча, но результат пока не ясен. С одной стороны, вряд ли такая крупная корпорация позволит себе такой мегапровал по доступности, а с другой — кто знает.
«Непрозрачные» веб-приложения, которые беспокоят пуристов, это — мелочь в сравнении с тем, что обещает нам WebAssembly. Речь идёт о выводе производительности веб-приложений, работающих в браузерной «песочнице», практически на уровень нативных приложений.
WebAssembly для этого много ещё не умеет.
Чтобы запустить истинный параллельный поток, нужно создать Wasm.Memory с параметром shared True, но сейчас требуется обязательно указание максимального размера памяти, то есть, заранее обозначен потолок роста.
Настоящий процессор, когда складывает 2 миллиарда с 2 миллиардами, отмечает в EFLAGS переполнение, и мы сразу идём бросать исключение. В WebAssembly EFLAGS теряется. А как жить-то, как жить без EFLAGS? Приходится изгаляться так:
AdaMagic/wasm/rtl.wasm/standard.h
/****************/
/* Unary negation and absolute value overflow only for the most-negative
number. */
#define s_32_neg_v(result, x) /* result = -x; */ \
if (((result) = -(x)) == S_FIRST) rts_overflow()
#define s_32_abs_v(result, x) /* result = abs(x); */ \
do { \
const int32 _xcopy = (x); \
if (_xcopy == S_FIRST) rts_overflow(); \
(result) = abs(_xcopy); \
} while (0)
/****************/
/* Signed addition and subtraction are implemented in terms of the
unsigned operations. Overflow is determined by comparing
the sign bits of the operands and result, which is done
using bit-wise xor. We first calculate the result (lower 32 bits)
and then check whether it overflowed. */
/* Addition overflows iff x and y have the same sign,
and the result has a different sign (from x and y). */
#define s_32_plus_v(result, x, y) /* result = x + y; */ \
do { \
const int32 _xcopy = (x); \
const int32 _ycopy = (y); \
const int32 _same_sign = ~_xcopy ^ _ycopy; \
/* The sign bit of _same_sign is set iff x and y have \
the same sign. */ \
(result) = _xcopy + _ycopy; \
if ((_same_sign & ((result) ^ _xcopy)) < 0) rts_overflow(); \
/* The sign bit of "((result) ^ _xcopy)" is set iff result and x have \
different signs. Overflow if that and _same_sign both have \
sign bits set. */ \
} while (0)
/****************/
/* Subtraction overflows iff x and y have different signs,
and the result and x have different signs. */
#define s_32_minus_v(result, x, y) /* result = x - y; */ \
do { \
const int32 _xcopy = (x); \
const int32 _ycopy = (y); \
const int32 _diff_sign = _xcopy ^ _ycopy; \
/* The sign bit of _diff_sign is set iff x and y have \
different signs. */ \
(result) = _xcopy - _ycopy; \
if ((_diff_sign & ((result) ^ _xcopy)) < 0) rts_overflow(); \
/* The sign bit of "((result) ^ _xcopy)" is set iff result and x have \
different signs. Overflow if that and _same_sign both have \
sign bits set. */ \
} while (0)
/****************/
/* For multiplication, we treat the various cases for y separately. We
check for overflow by checking whether x is in the right range. If one
operand is known at compile time, then the compiler should make that one
y, so the C compiler can hope to eliminate all but one range check, and
perform the divides at compile time. We need to take care to avoid
dividing by zero, and to avoid dividing the most-negative number by
minus one. */
#define s_32_times_v(result, x, y) /* result = x * y; */ \
do { \
const int32 _xcopy = (x); \
const int32 _ycopy = (y); \
\
if (_ycopy > 0) { \
rts_range_check(_xcopy, S_FIRST/_ycopy, S_LAST/_ycopy); \
} else if (_ycopy < -1) { \
rts_range_check(_xcopy, S_LAST/_ycopy, S_FIRST/_ycopy); \
} else if (_ycopy != 0) { \
/* The "-1" special case */ \
if (_xcopy == S_FIRST) rts_overflow(); \
} \
(result) = _xcopy * _ycopy; \
} while (0)
/****************/
/* Division can only overflow when dividing the most negative number by
-1. */
#define s_32_div_v(result, x, y) /* result = x / y; */ \
do { \
int32 _xcopy = (x); \
int32 _ycopy = (y); \
if (_xcopy == S_FIRST && _ycopy == -1) rts_overflow(); \
(result) = _xcopy/_ycopy; \
} while (0)
/****************/
Компилятор вынужден проштамповывать таким кодом каждую арифметическую операцию, иначе теряется фирменная адская безопасность.
Ах, да, если обнаружена лажа, нужно бросить исключение. Но в Wasm нет исключений. Родных. Можно зайти в JS, чтоб JS бросил исключение, тогда оно сдерёт весь стек Wasm и вылетит с другой стороны в вызывающий JS. И не сработают финализаторы! Ну такое.
Если мы хотим писать как на настоящем процессоре, нас такая лажа не устроит, мы хотим ещё и ловить эти исключения, и обрабатывать. И всякие ошибки роста памяти, обычно сдирающие стек Wasm, хотим ловить. И тут начинаются танцы на батуте (Trampolined Style) по типу Continuation Passing C. Так вот ты какой, «практически натив»!
Что ещё может натив? Может библиотеку загрузить динамически и в синхронном стиле. Существующие трансляторы Wasm это поддерживают довольно плохо. Ну вот что нужно сделать в обычном Wasm, чтоб произвести такую загрузку? Библиотека динамически загружаемая предоставляет какие-то, допустим, COM-подобные объекты. Если там не COM, а glib, погоды не меняет. Для косвенных вызовов в Wasm используются массивы функций с идентичной сигнатурой. Для каждой сигнатуры отдельный массив. Нужно массивы дополнить тем, что предоставляет библиотека. Вызывающих нужно связать с дополненными версиями всех массивов, чтоб они могли косвенно вызывать методы объектов, созданных новой библиотекой. Чтоб сама библиотека могла косвенно вызывать свои методы, ей нужно произвести релокацию: рассказать библиотеке, по каким смещениям в дополненных массивах начинаются добавленные ею методы, а потом в блобе сегмента данных пропатчить таблицы виртуальных методов.
Под Windows-то уже ASLR отработал, и несмотря на его работу, и достаточно рандомно получилось, и релоцированный слепок закешировался на диске. Ах да, диск. А зачем на диск? А мы же прямо с диска можем mmap сделать! У нас в нативе есть вирутальная память. А на WebAssembly фиг. У нас каждый байт Wasm.Memory стоит как настоящий. В нативе может применяться оптимистичное выделение памяти, почти моментальное, а потом по требованию выделяются настоящие страницы. В нативе библиотеки нередко прямо с диска шлёпаются релоцированные. Под стек место выделяется оптимистично. Почему стеком Wasm крайне сложно пользоваться, написано выше, но если им не пользоваться, то пользуемся сегментированным стеком в Wasm.Memory, где за каждый байт надо честно платить.
Это всё очень далеко от натива.
Многие компиляторы, которые я видел, поэтому генерят отнюдь не набор библиотек. Отнюдь! Вот берём мы, допустим, сайт типа ВК и видим, что он сделан на JS, и что JS там грузятся по требованию: для музыки, для альбомов, для вики грузится только когда понадобилось. Библиотеки кешируются и обновляются независимо. Нам втирают, что Wasm вроде как то же самое, но быстрее. Но когда мы берём многие реальные Wasm-трансляторы, они ведут себя совсем не так. Мы хотели такие же отдельные кешируемые независимо обновляемые библиотеки, а получили большой целиком обновляемый блоб, и из-за того, что обновляется он целиком, он ещё и обновляется часто. Минус кеш.
Статью, пожалуйста статью!
Недоступен EFLAGS — а в обычном C или Java, без использования ассемблера/интринсиков, они же точно так же недоступны (в .NET вроде что-то есть). Кто "мы" исключения бросает?
Так почитаешь ваш пост — так и писать только на ассемблере.
Всякие языки со сборкой мусора относятся к нативу или нет? Там и упомянутый вами mmap смысла мало имеет.
Кто «мы» исключения бросает?
Да обычные Delphi, Ada, Модулы, Обероны, и на чём ещё люди пишут.
Всякие языки со сборкой мусора относятся к нативу или нет? Там и упомянутый вами mmap
Сборка мусора ортогональна загрузке по mmap. Например, AOT ngen.exe делает бинарники, подходящие к проецированию в память, уже с инструкциями в машинных кодах. У Оберонов практически все реализации как раз создают машинный код. Самая известная, Compoment Pascal, скорее, исключение, чем правило. Да и к ней вроде бы приделали уже возможность подключать скомпилированные в машинные коды расширения.
а в обычном C или Java, без использования ассемблера/интринсиков
__builtin_sadd_overflow и другие интринсики расползаются по компиляторам, а на случай трудных платформ можно скопипастить реализацию из спойлера
Ах, да, если обнаружена лажа, нужно бросить исключение. Но в Wasm нет исключений. Родных. Можно зайти в JS, чтоб JS бросил исключение, тогда оно сдерёт весь стек Wasm и вылетит с другой стороны в вызывающий JS. И не сработают финализаторы! Ну такое.Полагаю, так и должно быть. Исключения реализуются средствами самого языка, то есть исключения будут доступны за счёт прилинкованной части рантайма. Всё же в одних языках исключения перехватываемы, а в других исключений нет, и они там нужны для высвобождения ресурсов, а обычные ошибки обрабатываются за счёт кодов возврата.
Тем временем прошло 2 года и ничего не изменилось в сторону канваса.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Будущее веба: станет ли рендеринг в <canvas> заменой DOM?