LINUX.ORG.RU

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

 , , , ,


0

2

Когда JS в браузерах научился делать что-то большее, чем падающие снежинки, многие забили на HTTP / формы / cookies / серверные шаблоны. JSON API и клиентское приложение (требующее включённый JS) сейчас - нормальная ситуация.

С приходом новых ЯП в браузер (с помощью WASM), а как следствие, годных GUI либ, стоит ли ждать, что следующие на очереди - DOM, HTML, CSS? Т.е. нормой станет приложение в HTML5 элементе canvas на всё окно, а вся работа (обработка кликов, перерисовка и т.п.) средствами библиотеки ЯП.

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

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

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

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

plotnikovanton
()

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

Dron ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

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

beastie ★★★★★
()
Ответ на: комментарий от beastie

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

entefeed ☆☆☆
()
Ответ на: комментарий от entefeed

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

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

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

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)

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

istepan
()
Ответ на: комментарий от anonymous

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

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

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

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

Schmuck
() автор топика
Ответ на: комментарий от anonymous

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

Softwayer ★★
()
Ответ на: комментарий от plotnikovanton

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от beastie

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

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

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

robot12 ★★★★★
()
Ответ на: комментарий от beastie

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

robot12 ★★★★★
()
Ответ на: комментарий от makoven

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

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

anonymous
()

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

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

goingUp ★★★★★
()
Ответ на: комментарий от beastie

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

intelfx ★★★★★
()
Ответ на: комментарий от anonymous

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от makoven

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

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

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

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от makoven

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

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

robot12 ★★★★★
()
Ответ на: комментарий от beastie

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

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

Deleted
()
Ответ на: комментарий от RazrFalcon

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

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

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

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

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

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

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

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

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

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

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

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

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

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

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

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

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

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от intelfx

«строить DOM»

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

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

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

Shadow ★★★★★
()
Ответ на: комментарий от anonymous

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

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

plotnikovanton
()
Ответ на: комментарий от makoven

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

Как правило

FLTK

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

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

hobbit ★★★★★
()
Ответ на: комментарий от anonymous

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

Schmuck
() автор топика

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

Нет.

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

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

годных GUI либ

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

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

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

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

foror ★★★★★
()
Ответ на: комментарий от Schmuck

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

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

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

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

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

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

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

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

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

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

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)

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

foror ★★★★★
()
Последнее исправление: foror (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.