С приходом WASM стоит ли ожидать массового появления canvas приложений?

Волей судьбы на прошлом месте работы пришлось поработать над одним внутреннем проектом, где большая часть работы — это фронтенд. Я не очень все это люблю, но раз уж начал делать, то решил разобраться с тем что там сейчас на эдже фронтенд технологий.

Ну вот смотри, DOM и HTML уже не модно писать самому, сейчас же используется виртуальный DOM во всяких там React'ах и генерируется автоматически. Более того CSS сам по себе тоже не модно, сейчас в тренде PostCSS, это такая штуковина, которая по твоему CSS строит ast и потом как-то процессит этот твой псевдо-css в обычный CSS с применением различных модулей.

Да, сейчас богомерзкий JavaScript может куда больше, чем раньше. Считай ты можешь реализовать гуй любой сложности использую тот же React (Redux и прочую лабуду). И вообще веб дев сейчас больше похож на классические приложения, только вот вместо ассемблера чистый JavaScript, поддерживаемый всеми браузерами, вместо процессора движок браузера. За все это мы платим невероятным оверхедом в плане памяти и, из-за абсолюто идиотской идеалогии жаваскрипта, необходимости тянуть даже за самым маленьким приложением тонну зависимостей. Зато паттерны вполне себе стандартные, модульность, ооп, классы и все такое.

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

Очень даже может быть, мне вот ситуация с emscripten не нравиться когда мне для аллокации памяти нужно дёргать js когда я пишу на С, да и вообще многое там через вызовы js приходится делать через extern js function, для себя и что бы вникать в суть буду медленно нужные мне вещи из stdio.h string.h и прочее запиливать нативно, но тут кроется жопа по моему так как получится что-то похожее на jquery, жирнота вообщем что тоже плохо когда клиент должен выкачивать мегабайтную либу. Хотя хз, может в вместе с браузерами будет поставляться libcwasm где всё будет уже готово для дёрганья.

а зачем тогда вообще нужен броузер? вот, к примеру, для go есть замечательная кроссплатформенная библиотека GUI тулкита на чистом OpenGL. она работает и под линуксом и под виндй и под андроидом (сам проверял). нахрена тогда прослойка в виде броузера? https://github.com/golang-ui/nuklear

Подожди ещё пару лет и круг замкнётся. Вернёмся к «нативным» приложениям, только теперь в виртуальной машине (aka бровзер).

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

Всё новое — хорошо забытое старое. ©

Будет вам и Motif™ и GTK с Qt в WebGUI. Надо только подождать, пока хипстеры не допрут до этого.

PS: а HTTP превратится в жалкую пародию 9P/IPC (точнее уже)

В WASM нет доступа к DOM. Вот когда появится, тогда да, заживем.

а зачем тогда вообще нужен броузер? вот, к примеру, для go есть замечательная кроссплатформенная библиотека GUI тулкита на чистом OpenGL. она работает и под линуксом и под виндй и под андроидом (сам проверял). нахрена тогда прослойка в виде броузера?

Нативное приложение нужно делать для каждой платформы. Хорошо, в Go можно сразу для каждой из поддерживаемых скомпилить прямо из консоли. Но потом всё равно придётся запиливать установщики / деинстелляторы: под Windows, каждый сорт GNU/Linux и т.д.

А после всё это как-то распространять. Как? Добавлять в каждый маркет, репу каждого дистра? Платить GOOG 20$, Apple 99$, спрашивать разрешение?

Браузер решает проблему запуска и распространения.

Даже если бы она позволяла просто не писать на go, это было бы уже достаточной причиной

Будет вам и Motif™ и GTK с Qt в WebGUI. Надо только подождать, пока хипстеры не допрут до этого.

https://developer.gnome.org/gtk3/stable/gtk-broadway.html

Well, we're doomed.

Считай ты можешь реализовать гуй любой сложности

Можешь, не значит, что это всегда подходит. Как насчет индексирования поисковиками (основного источника новых посетителей)? Будут ли поисковики индексировать такие сайты-приложения. Если у тебя сайт-приложение-почтовый клиент или CMS для внутреннего потребления - такое решение отлично подходит. А если обычный сайт (каких большинство), у которого для каждой страницы должен быть свой адрес и индексация гуглом? Насколько сайт-приложение подходит для таких случаев.

Этот вопрос решен еще со времен появления динамически подгружаемого контента. Как по-твоему сейчас индексируются такие сайты? Тут то же самое.

Контент (который нужно индексировать) и интерфейс, в котором он представлен пользователю, абсолютно разные, никак не связанные между собой вещи.

Так проходили уже, java browser plugin :)

Дык, ничто не ново под луной.

Those who cannot learn from history are doomed to repeat it. ©

замечательная кроссплатформенная библиотека GUI тулкита

И как она справится с адаптивной версткой? Да вообще с какой-нибудь версткой? На скриншотах этого нуклеура гуй уровня Delphi 1.0. Сравнивать ЭТО с современным HTML - курам на смех

Ты забыл упомянуть, что все эти гэтэкэ и кутэ никому и даром не нужны. На десктопах их место в ОС с 1% аудитории. На телефоны они никогда не придут в силу своей косности. На телефонах GUI на основе XML, которые тоже не блещут гибкостью и разнообразием возможностей

По факту имеем, что HTML сейчас самый совершенный тулкит. И в браузере будут рисовать на canvas/WebGL только в том случае, если какой-то мегамозг запилит гуй, круче HTML-я

HTML сейчас самый совершенный тулкит

Не HTML тогда уж, а DOM или даже BOM (CSSOM+DOM).

Ибо как интерфейс веб-приложения можно отрисовать и не написав ни строчки html или css.

Можно и так сказать

нахрена тогда прослойка в виде броузера?

Рантайм + средство доставки+гемморой для безопасников

Подожди - еще появятся MtM прокси которые в WASM будут свой рекламный код добавлять, потом появятся антивирусы для браузеров ......

Сравнивать ЭТО с современным HTML - курам на смех

лол. если ты не в силах оторвать [один из] инструментов и считаешь его аксиомой, то ты просто плохой программист.

Фидонет станет популярным?

стоит ли ожидать массового появления canvas приложений?

Нет, как жава апплеты и флешь не были массовыми, так и сейчас будет.

Кстати да, «строить DOM» и «рисовать на canvas» — чем не противостояние примитивов из X11 и рисования в текстуру на клиенте?

Это просто биндинги к GUI либе для игр. Нормальные приложения на ней не сваяешь.

По факту имеем, что HTML сейчас самый совершенный тулкит.

HTML - это язык разметки текста, на который навешали костылей больше, чем на C++.

С Qt и GTK+ он и рядом не стоял, ибо HIG, native look-and-feel, accessibility и прочее, о чём html и не мечтает. Про производительность веб-поделий я вообще молчу.

Весь «прогресс» веб-дизигна за последние 10 лет - это переход от Comic Sans к color:#cccccc.

Векторный ага :)

По факту имеем, что HTML сейчас самый совершенный тулкит.

фейспалмточкажпг. TK самый простой, портируемый и понятный тулкит !

Хорошо бы, если от всей этой виртуальной машины остался лишь jit-компилятор (или что там такое) wasm.

Можно было бы запилить либу для этого wasm в виде кроссплатформенного gui тулкита, опирающегося на wasm (как язык для кроссплатформы) и OpenGL/WebGL/OpenGL ES.

HTML - это язык разметки текста, на который навешали костылей больше, чем на C++.

Ага. То-то QML и XAML сделали по образу и подобию «языка разметки текста» (и не суть, что получились малоразвитые ублюдки)

С Qt и GTK+ он и рядом не стоял, ибо HIG, native look-and-feel

Мы с тобой уже как-то дискутировали на этот счет, и выяснили, что твой клинер не укладывается в современный HIG (Metro). Далее дискутировать на эту тему смысла не вижу. Нативный дизайн - понятие расплывчатое даже в рамках одной ОС

Весь «прогресс» веб-дизигна за последние 10 лет - это переход от Comic Sans к color:#cccccc.

Плохо значит разбираешься в теме, раз такое неуклюжее мнение имеешь

Я не в силах поклоняться «крутому» тулкиту навроде Nuklear или Conrod. Потомучто им не хватает минимум миллиона человека-часов чтобы стать юзабельными. Гуй это тебе не сортировку пузырьком накатать

То-то QML и XAML сделали

Хз что там в XAML, но QML ни разу не HTML.

что твой клинер не укладывается в современный HIG (Metro)

Да. Только он и не должен. Он ещё и в HIG GNOME не укладывается, потому, что на Qt. Но это не мои проблемы.

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

Плохо значит разбираешься в теме

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

но QML ни разу не HTML

Может быть. Но свиду те же яйца (а точнее, дерево), только json-подобный синтаксис вместо тэгов. И смешивание разметки с оформлением, за что в приличном обществе по головке не погладят (аналог css не завезли?)

Во-первых, это не json, а js.

Во-вторых, там css является частью разметки, ибо разметка идёт элементов интерфейса, а не текста, как в html.

«строить DOM»

- это, возможно, сильно теоретически, похоже на

примитивов из X11

а по сути, нет. Да и canvas больше на примитивы похожа...

А если обычный сайт (каких большинство), у которого для каждой страницы должен быть свой адрес и индексация гуглом?

А в чем проблема? JavaScript умеет отлично менять урл, SPA так и работает, посмотри на вконтакте и вообще что угодно популярное, гитхаб, ютуб.

лолл. давай, скажи мне, какой тулкит ты считаешь юзабельным.. Qt? - это? это то у чего миллиард зависимостей, 4 часа компиляции при том ещё, что «Qt - это отдельный язык, а не c++»? лол, если это то чему ты поклоняешься, то ты - в двойне бездарное ничтожество, а не программист! ... лол.. html.. «миллионы человеко-часов».. «миллионы человеко-часов» - таких же бездарных программистов как и ты!

какой тулкит ты считаешь юзабельным.. Qt?

Qt юзабелен только для разработчиков C++. С графическими тулкитами вообще беда. Как правило они крекпо привязаны к конкретной ОС (вин, эпл, андроид) и не переносятся на другие. А всё потому, что гуй - штука большая и сложная. Пару кнопочек то можно нарисовать и в GL. А как дело коснется деталей (hidpi, устройства ввода, диалоговые окна, лэйауты, работа с текстом итд итп) - то ты со своим nuklear лососнешь, даже если встроишь его в браузер

Я вижу только один реально переносимый гуй - к сожалению это браузер

Как правило

FLTK

ОС UNIX/Linux X11, Microsoft Windows и MacOS X

На нём тот же лаунчер для Braid написан, к примеру. Ещё есть Tk

Tk портирован на большинство реализаций Linux, Mac OS X, Unix, и Microsoft Windows. Начиная с Tcl/Tk 8 графический интерфейс имеет «родной» для ОС вид

Так что выбор есть, если искать. Другое дело что ты просто болтаешь, а не ищешь. Ведь так проще, не правда ли?

FLTK, Tk

Хах. Спасибо за такой «выбор» )

Qt? - это? это то у чего миллиард зависимостей

Список в студию.

4 часа компиляции

Ты для каждого проекта, что ли, отдельную копию Qt собираешь? Ну и у меня, по-моему, было намного быстрее, когда я делал статическую сборку Qt 4.8 для вендосборок (я там отключил всё ненужное). В линуксе вообще не парюсь и использую готовые qt*-dev из репозитариев.

при том ещё, что «Qt - это отдельный язык, а не c++»?

Это преувеличение. Нормальный C++ плюс несколько макросов плюс некоторое количество автосгенерированного кода.

Поклоняться тулкитам, конечно же, не надо. :)

Да, кстати... Хрен с ними, с поисковиками. Как решить проблему незрячих пользователей? Сейчас у них читалки, парсящие html и озвучивающие содержимое. Как это может работать с canvas?

С приходом WASM стоит ли ожидать массового появления canvas приложений?

Нет.

забили на HTTP / формы / cookies / серверные шаблоны
С приходом новых ... годных GUI либ, стоит ли ждать, что следующие на очереди - DOM, HTML, CSS

Где тут логика? Хорошо подумай прежде, чем приводить подобные аналогии.

годных GUI либ

Где ты видел годные GUI либы? Их на десктопе нет, а ты еще хочешь годную GUI либу под специфичную вещь? Самая годная GUI либа сейчас это HTML+CSS+JS и удобный фреймворк над ними. Именно поэтому так быстро набирает тема веб-приложений.

вся работа (обработка кликов, перерисовка и т.п.) средствами библиотеки ЯП

Тут дернуло меня посмотреть, что творится на офтопике, зашел на торенты, глянул темы популярного ПО - 3, 5, 6 Гб на дистриб. Думал может васяны просто понапихали всего... Нет, читаю комментарии оно и правда настолько ставится.

И эти 3, 5, 6 Гб в браузер закачивать?

Нативное приложение нужно делать для каждой платформы. Хорошо, в Go можно сразу для каждой из поддерживаемых скомпилить прямо из консоли.

А кресты так разве не умеют? Серьезно?

Но потом всё равно придётся запиливать установщики / деинстелляторы: под Windows, каждый сорт GNU/Linux и т.д.

А для веб-приложения нужно запиливать деплой на сервера и БД, а затем это еще всё админить. Балансировать нагрузку. Плюс еще куча геморроя (например, плохая совместимость между браузерами).

А после всё это как-то распространять. Как?

Для этого даже под виндами маркет придумали.

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

А их что 100500? Руки отвалятся автоматизировать этот процесс?

Платить GOOG 20$, Apple 99$, спрашивать разрешение?

Выложи на свой лендинг и торент сервер подними, какие проблемы?

Возможно стоит ожидать появление кучи игр в браузере. Как это произошло с появление флеша. Со временем на WASM-е можно будет более серьезные игры запиливать/портировать, чем это было возможно с флешем.