Запустил эту хрень на рабочей машине
Получил "Your browser does not support WebGL 2. Please try with Firefox 52 or newer"
При том что это как раз и был FF 52 x64
Запустил на домашней.
Через 2 минуты крэшанулся FF.
Здравствуйте, rm822, Вы писали:
R>Запустил эту хрень на рабочей машине R>Получил "Your browser does not support WebGL 2. Please try with Firefox 52 or newer" R>При том что это как раз и был FF 52 x64
WebAssembly is enabled in Firefox 52+, although disabled in the Firefox 52 Extended Support Release (ESR.)
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, rm822, Вы писали:
R>Запустил эту хрень на рабочей машине R>Получил "Your browser does not support WebGL 2. Please try with Firefox 52 or newer" R>При том что это как раз и был FF 52 x64
R>Запустил на домашней. R>Через 2 минуты крэшанулся FF.
У меня всё работает отлично — спокойно пинаю там рыбок и бабочек. ))) А у тебя с видеодрайверами всё нормально на компьютере, современные игры идут без проблем?
Туфта. Писать на этом еще долго не будут, потому что половина клиентов со старыми браузерами. Плюс нет API к браузерному DOM.
А твой пример фееричен по размеру, ты б предупредил, вдруг у кого трафик.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Ну что господа C++'ки, начинаем ваять сайтики?
А что — господа C++'ки до этого спали и в JS никогда-никогда не вляпывались или emscripten это не их поделка? Хм... а если подумать... господа яваскриптеры и не додумались бы до такого. Это вы прилумали?! Каакие молодцы у нас прямо примерные господа! Гордимся! Но лучшее что вы сможете сделать — сидеть в сторонке пооодальше со своими извращенными идеями как выдолбать мозг пременной x через y, да так — что бы компилятор ни-ни-ни об этом не догадался. Ибо вы писали всю жизнь и продолжаете писать пошлятину неугодную богу ибо даже он такой херни бы не нёс. Даже если бы писал на C++.
В общем — по делу — и без вас умников дебилоидных хватает везде. От того что вы изнасилуете очередную VM — быстрее не станет. Вы мля за записями в DOM следите что-бы небыло лишних — того глядишь и половина сайтов научится не перерисовывать себя полность при появлении подсказок.
Про паталогию в google sheets — я уже писал. Клик на любую ячейку приводит к... перерисовке листа. А почему? А потому что html наслуют в мозг. А когда насилуют — свой отключают напроч. Увы.
Так и ты со своим сообщением — говоришь — пацаны — давай поблещем своей безграмотностью, а то что С++ники бывшие и настоящие со стажем одни из самых грамотных людей и сами придумали вебассембли для таких как ты...
Вот назови три причины почему они должны наваять вебасм, а не обычный жс?
Ops>Туфта. Писать на этом еще долго не будут, потому что половина клиентов со старыми браузерами. Плюс нет API к браузерному DOM.
Про DOM API ты серьёщно? Нахер оно нужно без него? Загружать декодер любимого видео, но всё равно встроенный лучше?!
Здравствуйте, Ops, Вы писали:
Ops>Туфта. Писать на этом еще долго не будут, потому что половина клиентов со старыми браузерами. Плюс нет API к браузерному DOM.
1. Браузеры сейчас в основном на автоапдейте сидят. Так что думаю через годик wasm (эх, будет теперь постоянно путаться с нашим старым добрым WASM) будет доступен на подавляющем числе браузеров.
2. Не особо представляю зачем тебе может понадобиться доступ к DOM, но если что, он априори доступен (через jS).
3. Ещё до выхода wasm приложения на C++ во всю портировались в браузер с помощью emscripten (смотри например тут https://github.com/kripken/emscripten/wiki/Porting-Examples-and-Demos). Просто там работала компиляция не в wasm, а в js — менее эффективные приложения выходили, но для определённых целей годилось и такое. Так что в принципе технология наработанная и сейчас она просто получит многократное увеличение эффективности (позволяющее портировать уже не только quake3, но и например последний Doom). Т.е. хотя раньше emscripten и притворялся практически обычным C++ компилятором, но разница всё же была принципиальная (быстродействие, затратах памяти и т.п.). А теперь реально не будет разницы между компиляцией C++ кода под какую-то ОС или "под браузер". )
Здравствуйте, alex_public, Вы писали:
_>1. Браузеры сейчас в основном на автоапдейте сидят. Так что думаю через годик wasm (эх, будет теперь постоянно путаться с нашим старым добрым WASM) будет доступен на подавляющем числе браузеров.
+1. Но хотел уточнить, что Chrome, STS + принципиальная зашитая в хром тайм-бомба на 3 недели — делает из года — месяца 1.5. Т.е. их следующих можорный релиз. STS тупо хардкодится — ембеддеры патчат. Счастливые — не догадываются. Те ещё ублюдки с точки зрения написания либ.
Здравствуйте, alex_public, Вы писали:
_>2. Не особо представляю зачем тебе может понадобиться доступ к DOM, но если что, он априори доступен (через jS).
А я вот не понимаю. Нахера мне либа от фейсбука в 300-500Кб для писания в дом. JSX? Тапочки разорвались от смеха. Но — т.е. юквери в вебасм не будет? На кой черт тогда вебасм нцюужен? 3д тарахтелки при всём желании просто сосут у C++-based эжинов или у гибридов на Юнити. Эм. Вебовый юнити... Ну как увижу хотя бы Pillars of Eternity в вебе — тогда да (это что технологтчески подъемно на ваших супер видюхах). А тот же новый тормент — и так едва шевелится на встроенном видео. А демки аля квак 2-3.0 — это то что шевелится пять лет как на мобилах.
Здравствуйте, alex_public, Вы писали:
_>1. Браузеры сейчас в основном на автоапдейте сидят. Так что думаю через годик wasm (эх, будет теперь постоянно путаться с нашим старым добрым WASM) будет доступен на подавляющем числе браузеров.
А ты загляни в соседнюю тему. Тут даже в IT куча народу принципиальные противники обновлений, часто по религиозным причинам.
Или зайди на caniuse, много узнаешь о поддержке у пользователей фич, которые были реализованы еще 5 лет назад, а сейчас полностью поддерживаются всеми современными версиями мейнстримовых браузеров.
А еще можешь попробовать запустить ту демку из стартового сообщения на мобиле с 512 памяти — таких тоже много, и выбросят их все отнюдь не скоро.
_>2. Не особо представляю зачем тебе может понадобиться доступ к DOM, но если что, он априори доступен (через jS).
Вот как раз хотелось бы заменить JS нормальным языком. А апплеты можно было бы и на жабе писать, даром что ее банить везде начали.
_>3. Ещё до выхода wasm приложения на C++ во всю портировались в браузер с помощью emscripten (смотри например тут https://github.com/kripken/emscripten/wiki/Porting-Examples-and-Demos). Просто там работала компиляция не в wasm, а в js — менее эффективные приложения выходили, но для определённых целей годилось и такое. Так что в принципе технология наработанная и сейчас она просто получит многократное увеличение эффективности (позволяющее портировать уже не только quake3, но и например последний Doom). Т.е. хотя раньше emscripten и притворялся практически обычным C++ компилятором, но разница всё же была принципиальная (быстродействие, затратах памяти и т.п.). А теперь реально не будет разницы между компиляцией C++ кода под какую-то ОС или "под браузер". )
Что-то мне кажется, это будут те же апплеты, просто в новом виде. У браузерных приложений есть огромный недостаток — им нужен браузер. Зато с тем, что браузеры должны делать, эта чуда-юда работать не умеет.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>А ты загляни в соседнюю тему. Тут даже в IT куча народу принципиальные противники обновлений, часто по религиозным причинам. Ops>Или зайди на caniuse, много узнаешь о поддержке у пользователей фич, которые были реализованы еще 5 лет назад, а сейчас полностью поддерживаются всеми современными версиями мейнстримовых браузеров. Ops>А еще можешь попробовать запустить ту демку из стартового сообщения на мобиле с 512 памяти — таких тоже много, и выбросят их все отнюдь не скоро.
Браузер априори в выгодном положении — у него есть доступ в интернет. Если соединение "бесплатное" — то значит и обновиться можно. Я ещё раз повторяю, если очень грубо то хром или любое уважающее себя приложение — будет требовать апдейта. Это требование — натуральная тайм-бомба. Всё. Апдейты нужны в первую очередь не сколько ради исправлений браузера, а сколько ради обновления сертификатов и прочей мутоты. В случае с хромом — нас всех незаметно насилуют воблаго — т.к. получаем мы не только обновления сертификатов жёстко встроенных в бинарник — но и обновления самого браузера.
Не скажу, что это идеальная схема. Совсем нет. Скажу что эта схема позволяет в какой-то степени не думать о браузере. А моё предыдущее сообщение было о том же самом — то технически — они ембеддеров посылают на юх практически всегда, потому что у них всегда есть две дежурных отговорки:
1. by design
2. by security
И, лишь избранные кого они считают достойными — с ними нормально общаются (с тем же финальным рельзутатом в основном).
Но, поскольку мы всё таки в КСВ — я считаю важным обратить внимание на инженерный момент. А с точки зрения юзера — я считаю команда хрома делает правильно. Собственно — достаточно системную дату укрутить назад в укурок и никакой гугл не загрузиться.
Здравствуйте, fddima, Вы писали:
F> Про DOM API ты серьёщно? Нахер оно нужно без него? Загружать декодер любимого видео, но всё равно встроенный лучше?!
Ну они чего-то там обещают, но у них это с низким приоритетом, а пока прослойка между браузером и вебасмом — JS. Т.е. на страничке у тебя крутятся скрипты, которые этот вебасм дергают, а по результатам правят DOM, если надо. ИМХО, довольно монструозно и геморройно, для многих применений проще на этот вебасм вообще забить.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Ну они чего-то там обещают, но у них это с низким приоритетом, а пока прослойка между браузером и вебасмом — JS. Т.е. на страничке у тебя крутятся скрипты, которые этот вебасм дергают, а по результатам правят DOM, если надо. ИМХО, довольно монструозно и геморройно, для многих применений проще на этот вебасм вообще забить.
Жесть. Я честно слово туда не вникаю — не очень нужно. Но это очень странно — ведь поддержкой webasm заняты именно движки JS. И кто как ни они могут лучше всех совершать вызовы по работе с DOM.
Ну посмотрим. Мож одумаются. В принципе оно и щас юзерам пофигу — что JS грузить, что webasm.
Здравствуйте, sin_cos, Вы писали:
_>теперь наступит путаница: wasm c nasm, fasm, masm, tasm и вообще с ассемблером который assembly.
Не наступит. Ваши wasm/nasm это очень узко или маргиналов. masm/tasm — скорее история. В конце концов — webasm отличить от предыдущих можно. А wasm-ом опять же их может называть очень узкий круг людей.
Мне лично assembly нравится гораздо больше чем module — последний и так уже нагружен смыслами что хватит. Давайте webasm назовём чисто и красиво — солнышко!
Теперь можно картинки на сайтах делать сразу в WebP, а для тех браузеров, которые его не хотят поддерживать, конвертировать прямо в браузере в .png с помощью быстрого WebAssembly приложения по событию onerror для <img>.
Здравствуйте, Ops, Вы писали:
_>>1. Браузеры сейчас в основном на автоапдейте сидят. Так что думаю через годик wasm (эх, будет теперь постоянно путаться с нашим старым добрым WASM) будет доступен на подавляющем числе браузеров. Ops>А ты загляни в соседнюю тему. Тут даже в IT куча народу принципиальные противники обновлений, часто по религиозным причинам. Ops>Или зайди на caniuse, много узнаешь о поддержке у пользователей фич, которые были реализованы еще 5 лет назад, а сейчас полностью поддерживаются всеми современными версиями мейнстримовых браузеров. Ops>А еще можешь попробовать запустить ту демку из стартового сообщения на мобиле с 512 памяти — таких тоже много, и выбросят их все отнюдь не скоро.
Так демка то тяжёлая не потому что webasm, а потому что сам мир там рисуется красивый. ) Собственно если взять любой другой веб-инструмент для попытки прорисовки такого мира, то ситуация будет ещё намного хуже. ))) Так что тут всё нормально. И сейчас на десктопах вполне себе полно игр, которые не пойдут на слабом железе. А так же полно игр (требующих обязательно DX11), которые не пойдут на какой-нибудь старой ОС. Но этот факт же не мешает выпуску каждый год топовых игр, собирающих миллионы, не так ли? )
_>>2. Не особо представляю зачем тебе может понадобиться доступ к DOM, но если что, он априори доступен (через jS). Ops>Вот как раз хотелось бы заменить JS нормальным языком. А апплеты можно было бы и на жабе писать, даром что ее банить везде начали.
Правильно, заменяем JS нормальным языком (пока в наличие C++, но скоро наверняка подтянутся и остальные), а DOM заменяем нормальным OpenGL рендерером.
_>>3. Ещё до выхода wasm приложения на C++ во всю портировались в браузер с помощью emscripten (смотри например тут https://github.com/kripken/emscripten/wiki/Porting-Examples-and-Demos). Просто там работала компиляция не в wasm, а в js — менее эффективные приложения выходили, но для определённых целей годилось и такое. Так что в принципе технология наработанная и сейчас она просто получит многократное увеличение эффективности (позволяющее портировать уже не только quake3, но и например последний Doom). Т.е. хотя раньше emscripten и притворялся практически обычным C++ компилятором, но разница всё же была принципиальная (быстродействие, затратах памяти и т.п.). А теперь реально не будет разницы между компиляцией C++ кода под какую-то ОС или "под браузер". ) Ops>Что-то мне кажется, это будут те же апплеты, просто в новом виде. У браузерных приложений есть огромный недостаток — им нужен браузер. Зато с тем, что браузеры должны делать, эта чуда-юда работать не умеет.
В общем то да, типа апплетов. Но с несколькими поправками:
— быстродействие должно быть ближе к C++ (ну приблизительно как у проектов на LLVM), а не к жабкe
— язык разработки любой, а не только жабка
— изначально доступ к GPU
— y апплетов помнится были какие-то мутные дела с правами и т.п., а в данном случае будет уже стабильная и проверенная песочница от JS
— данное решение является результатом договорённости основных игроков в данной индустрии, а не проталкиваемым одним игроком решением (от которого кривятся остальные).
В общем на мой взгляд апплеты с таким набором свойств взлетят обязательно. )
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, sin_cos, Вы писали:
_>>теперь наступит путаница: wasm c nasm, fasm, masm, tasm и вообще с ассемблером который assembly. F> Ваши wasm/nasm это очень узко или маргиналов.
нет. более того, на ассемблере можно писать под webasm.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ops, Вы писали:
Ops>>Туфта. Писать на этом еще долго не будут, потому что половина клиентов со старыми браузерами. Плюс нет API к браузерному DOM.
а вообще, как это работает, если по-простому? как плагин? я не понял. то есть, эту webassembly нужно подгружать через соотвествующий тэг, как флэш в html коде?
или все идет к тому, что скоро html кода на клиенте не будет вообще и клиенту будет передаваться только бинарная штука? то есть, никто не сможет потом уже посмотреть html сайта у себя в браузере. то есть, будет как десктоп приложения.
_>А у тебя с видеодрайверами всё нормально на компьютере, современные игры идут без проблем?
Последний раз играл года полтора назад. Лара крофт не жаловалась
Здравствуйте, rm822, Вы писали:
R>Запустил эту хрень на рабочей машине R>Получил "Your browser does not support WebGL 2. Please try with Firefox 52 or newer" R>При том что это как раз и был FF 52 x64
R>Запустил на домашней. R>Через 2 минуты крэшанулся FF.
Это ж и была идея, показать всю мощь си-плюс-плюс!!!!1111одинодин
Здравствуйте, sin_cos, Вы писали:
_>а вообще, как это работает, если по-простому? как плагин? я не понял. то есть, эту webassembly нужно подгружать через соотвествующий тэг, как флэш в html коде?
Нет, скорее это похоже на подгружаемые в процессе js файлы. Только формат у них будет бинарный. )
_>или все идет к тому, что скоро html кода на клиенте не будет вообще и клиенту будет передаваться только бинарная штука? то есть, никто не сможет потом уже посмотреть html сайта у себя в браузере. то есть, будет как десктоп приложения.
Да, в случае применения wasm будет именно так. Только применять эту технологию для простеньких страничек естественно никто не будет — она нужна для интенсивных вычислений, крутой графики и т.п. )
Здравствуйте, alex_public, Вы писали:
_>Что-то не очень понял твою основную мысль) Может сформулируешь поточнее? )
Забей. Лень. Я хорошо вчера вбросил и получил массу полезной информации в ответ.
Посмотрим как webasm будет в резали. Работы вокруг замены JS/asmjs давно велись — очень хорошо, что наконец-то это сдвинулось с мёртвой точки.
Здравствуйте, alex_public, Вы писали:
_>Так демка то тяжёлая не потому что webasm, а потому что сам мир там рисуется красивый. ) Собственно если взять любой другой веб-инструмент для попытки прорисовки такого мира, то ситуация будет ещё намного хуже. ))) Так что тут всё нормально. И сейчас на десктопах вполне себе полно игр, которые не пойдут на слабом железе. А так же полно игр (требующих обязательно DX11), которые не пойдут на какой-нибудь старой ОС. Но этот факт же не мешает выпуску каждый год топовых игр, собирающих миллионы, не так ли? )
Казалось бы, нахрена тем играм нужен браузер?
_>Правильно, заменяем JS нормальным языком (пока в наличие C++, но скоро наверняка подтянутся и остальные), а DOM заменяем нормальным OpenGL рендерером.
OpenGL нафиг не нужен в явном виде для большинства применений. Сегодня большинство клиентских веб-приложений — это все тот же старый html, обвешанный скриптами, и в этой области вебасм предлагает только ректальное решение, с тем же JS.
Рисовать свой стандартный интерфейс руками? Зачем, когда уже есть готовый? Ах, новомодная фигня с ним работать не умеет...
Какая же это замена?
_>В общем то да, типа апплетов. Но с несколькими поправками: _>- быстродействие должно быть ближе к C++ (ну приблизительно как у проектов на LLVM), а не к жабкe
Веб-пейсатели это одолеют, не сомневайся. _>- язык разработки любой, а не только жабка
Возможно. _>- изначально доступ к GPU
Нужный для ограниченного числа применений. _>- y апплетов помнится были какие-то мутные дела с правами и т.п., а в данном случае будет уже стабильная и проверенная песочница от JS
Это можно было и с ними решить, волевым решением поломав совместимость для новых версий. _>- данное решение является результатом договорённости основных игроков в данной индустрии, а не проталкиваемым одним игроком решением (от которого кривятся остальные).
Так и апплеты по факту практически везде работали. _>В общем на мой взгляд апплеты с таким набором свойств взлетят обязательно. )
Взлетят, куда денутся. В такой же узкой нише. А ведь надежды были, что действительно удастся уйти от JS.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ikemefula, Вы писали:
R>>Запустил на домашней. R>>Через 2 минуты крэшанулся FF.
I>Это ж и была идея, показать всю мощь си-плюс-плюс!!!!1111одинодин
Буквально вчера яростно крешился C# софт 2011 года розлива. Видите-ли, в ProgramData не смог папку за запись открыть, из-под non-elevated аккаунта. Конечно же, надо упасть. МОЩЬ!
Здравствуйте, alex_public, Вы писали:
_>Хы, ну попробуй сделать с помощью этого пример из моего первого сообщения. )))
А нафига мне в клиента плеваться кодом который надо будет еще исполнять? Я могу всё это быстренько и на сервере нарулить. Понапридумают реактов, блин а потом сайты тормозят не по детски.
Здравствуйте, Sheridan, Вы писали:
_>>Хы, ну попробуй сделать с помощью этого пример из моего первого сообщения. )))
S>А нафига мне в клиента плеваться кодом который надо будет еще исполнять? Я могу всё это быстренько и на сервере нарулить. Понапридумают реактов, блин а потом сайты тормозят не по детски.
Сайты тормозят бывает даже без реактов, более того, часто сайты тормозят вообще без единой строчки скрипта.
Прошел по ссылке, скачалось больше 100Мб непонятно чего, как скачалось — браузер крашнулся. Все в стиле С++, хорошо хоть не с Access Violation вылетел.
Здравствуйте, alex_public, Вы писали:
_>https://geektimes.ru/post/286718/ — позитивная новость!
_>Ну что господа C++'ки, начинаем ваять сайтики?
CGI ещё в 93-ем придумали и сишники смогли ваять сайты из консольных приложений, это веб-программисты зачем-то теперь, в 2017, хотят программы в браузере запускать.
Здравствуйте, alex_public, Вы писали:
_>В Хроме поддержка webasm должна появиться начиная с версии 57.
57 канарейка:
Your browser does not support WebAssembly. Please try with Firefox 52 or newer.
Current user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2965.0 Safari/537.36
А после рефреша вообще прикольно:
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
_>>Так демка то тяжёлая не потому что webasm, а потому что сам мир там рисуется красивый. ) Собственно если взять любой другой веб-инструмент для попытки прорисовки такого мира, то ситуация будет ещё намного хуже. ))) Так что тут всё нормально. И сейчас на десктопах вполне себе полно игр, которые не пойдут на слабом железе. А так же полно игр (требующих обязательно DX11), которые не пойдут на какой-нибудь старой ОС. Но этот факт же не мешает выпуску каждый год топовых игр, собирающих миллионы, не так ли? ) Ops>Казалось бы, нахрена тем играм нужен браузер?
Вообще то игры — это только пример того, что вполне нормально для тяжёлых приложений иметь определённые ограничения на запуск и при этом быть успешными. А так это касается не только игр, но и любого тяжёлого ПО (вот например такое http://formit360.autodesk.com сразу же станет на порядок эффективнее от прихода wasm).
_>>Правильно, заменяем JS нормальным языком (пока в наличие C++, но скоро наверняка подтянутся и остальные), а DOM заменяем нормальным OpenGL рендерером. Ops>OpenGL нафиг не нужен в явном виде для большинства применений. Сегодня большинство клиентских веб-приложений — это все тот же старый html, обвешанный скриптами, и в этой области вебасм предлагает только ректальное решение, с тем же JS. Ops>Рисовать свой стандартный интерфейс руками? Зачем, когда уже есть готовый? Ах, новомодная фигня с ним работать не умеет... Ops>Какая же это замена?
Так GUI построенный на базе HTML во-первых достаточно убогий (посмотри на список доступных контролов в современных GUI библиотеках и в HTML), а во-вторых рендеринг через DOM весьма тормозной. Различные JS библиотеки (типа ExtJS) пытаются решать эти проблемы разработкой своих контролов и различными оптимизациями DOM, но всё это не эффективно на практике. Если же у тебя есть C++ приложение и предоставленная OpenGL поверхность, то ты просто берёшь одну из готовых мощных GUI библиотек и автоматически получаешь быстрый и профессиональный GUI. Естественно это актуально только для всяческих сложных сайтов (по сути веб приложений), а не для обычных "каталогов текста с картинками". )
Здравствуйте, Sheridan, Вы писали:
_>>Хы, ну попробуй сделать с помощью этого пример из моего первого сообщения. ))) S>А нафига мне в клиента плеваться кодом который надо будет еще исполнять? Я могу всё это быстренько и на сервере нарулить. Понапридумают реактов, блин а потом сайты тормозят не по детски.
Ты скажи честно, ты сайт то, показанный в первом сообщение, открывал или нет? ))) А то похоже ты даже не представляешь о чём идёт речь... )))
Здравствуйте, Klikujiskaaan, Вы писали:
_>>https://geektimes.ru/post/286718/ — позитивная новость! _>>Ну что господа C++'ки, начинаем ваять сайтики? https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html — этот вроде не плохо вышел. ) K>Прошел по ссылке, скачалось больше 100Мб непонятно чего, как скачалось — браузер крашнулся. Все в стиле С++, хорошо хоть не с Access Violation вылетел.
Там должно быть больше 200 мегабайт)
Вот мне интересно, а как вы все этого добиваетесь? Я лично не помню уже когда у меня последний раз падал браузер, а в этой теме вижу уже не первое сообщение такого рода. Вы там все пользуетесь бета версиями или набиваете браузер какими-то сомнительными плагинами или что? )
Здравствуйте, Ops, Вы писали:
_>>В Хроме поддержка webasm должна появиться начиная с версии 57. Ops>57 канарейка: Ops>
Ops>Your browser does not support WebAssembly. Please try with Firefox 52 or newer.
Ops>Current user agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2965.0 Safari/537.36
Здравствуйте, alex_public, Вы писали:
_>Так версия 57 Хрома же ещё не вышла. Т.е. ты пользуешься бетой? )
Я ж написал — канарейка
А пользуюсь FF, в нем сработало.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
_>>Так версия 57 Хрома же ещё не вышла. Т.е. ты пользуешься бетой? ) Ops>Я ж написал — канарейка
А, сорри, просто я Хромом не пользуюсь и поэтому не в курсе его внутренних имён)))
Вообще всё это конечно же ещё достаточно не отлажено, но думаю что уже даже через полгодика это можно будет рассматривать как достаточно стабильный инструмент. Естественно для специфического применения в тяжёлых случаях, а не как замена JS на всех сайтах. )))
Здравствуйте, alex_public, Вы писали:
_>А, сорри, просто я Хромом не пользуюсь и поэтому не в курсе его внутренних имён)))
Обычно в таких версиях уже все фичи есть, но могут быть баги. А первая ошибка говорит, что оно вообще в 57 работать не хочет. Хотя, может ее надо там отдельно включать, не вникал.
_>Вообще всё это конечно же ещё достаточно не отлажено, но думаю что уже даже через полгодика это можно будет рассматривать как достаточно стабильный инструмент. Естественно для специфического применения в тяжёлых случаях, а не как замена JS на всех сайтах. )))
Вооот! Только подается вебасм как "замена JS", а оказывается, заменяет очень частично, и для большинства случаев очень неудобно.
Сдается мне, в "расстановке приоритетов" те самые "крупные игроки" не последнюю роль сыграли — а то вдруг рынок их JS-движка усохнет?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Подождите, подождите!
Меня ведь господа жабаскриптеры убеждали, что JScript быстрый, что на него Линукс портировали, кто-то там даже фотошоп для браузера выпустил, что вот-вот новый Crysis под браузер выпустят....
А тут на тебе, такое счастье привалило.
Неужели врали?
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, Философ, Вы писали:
Ф>Подождите, подождите! Ф>Меня ведь господа жабаскриптеры убеждали, что JScript быстрый, что на него Линукс портировали, кто-то там даже фотошоп для браузера выпустил, что вот-вот новый Crysis под браузер выпустят.... Ф>А тут на тебе, такое счастье привалило. Ф>Неужели врали?
Не поверишь, редакторы кода на нем пишут.
Здравствуйте, rFLY, Вы писали:
FLY>Здравствуйте, Философ, Вы писали:
Ф>>Подождите, подождите! Ф>>Меня ведь господа жабаскриптеры убеждали, что JScript быстрый, что на него Линукс портировали, кто-то там даже фотошоп для браузера выпустил, что вот-вот новый Crysis под браузер выпустят.... Ф>>А тут на тебе, такое счастье привалило. Ф>>Неужели врали? FLY>Не поверишь, редакторы кода на нем пишут.
Редакторы кода даже на ассемблере в 82 году писали под 8086 — нифига не показатель. Даже окошки кое-кто на qbasic'е писал для 80386.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, alex_public, Вы писали:
_>Если же у тебя есть C++ приложение и предоставленная OpenGL поверхность, то ты просто берёшь одну из готовых мощных GUI библиотек и автоматически получаешь быстрый и профессиональный GUI. Естественно это актуально только для всяческих сложных сайтов (по сути веб приложений), а не для обычных "каталогов текста с картинками". )
OpenGL — не mark-up. Ты что хочешь остаться без хипстеров-дизайнеров и заняться формошлепством?
Единственное что может сойти за mark-up платформу поверх OpenGL и что теоретически можно запустить на wasm — QML (ну может еще scitter). При этом в нем нет из коробки кучи полезного функционала доступного в любом браузере, например глобального поискa линков/текста, печати, масштабирования пользователем, сохранение картинок и т.д. Более того в нем опять таки используется этот гребанный JS.
Если тебе не нравится HTML/CSS то можно адвокатировать его эволюции (WPF и т.д.), но откат к подходу 80-х это путь в никуда.
Здравствуйте, Философ, Вы писали:
Ф>Редакторы кода даже на ассемблере в 82 году писали под 8086 — нифига не показатель. Даже окошки кое-кто на qbasic'е писал для 80386.
Ложное сравнение. Правильное из 82-го года это Emacs, написанный на "правильном" JS — Lisp-e.
Здравствуйте, novitk, Вы писали:
_>>Если же у тебя есть C++ приложение и предоставленная OpenGL поверхность, то ты просто берёшь одну из готовых мощных GUI библиотек и автоматически получаешь быстрый и профессиональный GUI. Естественно это актуально только для всяческих сложных сайтов (по сути веб приложений), а не для обычных "каталогов текста с картинками". ) N>OpenGL — не mark-up. Ты что хочешь остаться без хипстеров-дизайнеров и заняться формошлепством? N>Единственное что может сойти за mark-up платформу поверх OpenGL и что теоретически можно запустить на wasm — QML (ну может еще scitter). При этом в нем нет из коробки кучи полезного функционала доступного в любом браузере, например глобального поискa линков/текста, печати, масштабирования пользователем, сохранение картинок и т.д. Более того в нем опять таки используется этот гребанный JS. N>Если тебе не нравится HTML/CSS то можно адвокатировать его эволюции (WPF и т.д.), но откат к подходу 80-х это путь в никуда.
Так а чем по твоему может помочь html или wpf при создание сайта типа примера из первого сообщения или какого-нибудь там Аutodesk FormIt? ) Поиск текста/линков там точно не нужен. )))
Здравствуйте, turbocode, Вы писали:
_>>Ну что господа C++'ки, начинаем ваять сайтики? T>То есть можно будет стримить видео из ютуба не через HTML5(Flash), а через WebAsm?
По идее без проблем. Правда для ютуба это не особо надо (что им там, дополнительную кнопочку в плеер прилепить что ли?). А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. )
Здравствуйте, IID, Вы писали:
IID>Здравствуйте, Ikemefula, Вы писали:
R>>>Запустил на домашней. R>>>Через 2 минуты крэшанулся FF.
I>>Это ж и была идея, показать всю мощь си-плюс-плюс!!!!1111одинодин
IID>Буквально вчера яростно крешился C# софт 2011 года розлива. Видите-ли, в ProgramData не смог папку за запись открыть, из-под non-elevated аккаунта. Конечно же, надо упасть. МОЩЬ!
Буквально неделю назад не крэшился thunderbird, примерно той же давности. Вместо этого он начинал настолько яростно жрать память, что винда пыталась спрятаться в свопе целиком. МОЩЬ C++, аднако.
Здравствуйте, alex_public, Вы писали:
_>Так а чем по твоему может помочь html или wpf при создание сайта типа примера из первого сообщения или какого-нибудь там Аutodesk FormIt? ) Поиск текста/линков там точно не нужен. )))
Да и сайт из примера не нужен, наткнись я на него случайно — закрыл бы еще до конца загрузки, как чаще всего делаю с подобными сайтами на более старых технологиях. А FormIt, как я понял, можно скачать десктопный и не морочиться с вебом.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. )
Вскроют. Это в принципе нежизнеспособная концепция, когда клиент должен показывать пользователю расшифрованный контент, найти способ добраться для него лишь вопрос джонеуловимости.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Sheridan, Вы писали:
_>>>Хы, ну попробуй сделать с помощью этого пример из моего первого сообщения. ))) S>>А нафига мне в клиента плеваться кодом который надо будет еще исполнять? Я могу всё это быстренько и на сервере нарулить. Понапридумают реактов, блин а потом сайты тормозят не по детски.
_>Ты скажи честно, ты сайт то, показанный в первом сообщение, открывал или нет? ))) А то похоже ты даже не представляешь о чём идёт речь... )))
По ссылке ничего такого не пишут, наоборот. А вот сами авторы вебасма обещают DOM, только непонятно когда, давно уже обещают. Еще где-то писали, что эта задача для них не очень приоритетная, а так ведь можно очень надолго затянуть или вообще забить.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Вообще то игры — это только пример того, что вполне нормально для тяжёлых приложений иметь определённые ограничения на запуск и при этом быть успешными. А так это касается не только игр, но и любого тяжёлого ПО (вот например такое http://formit360.autodesk.com сразу же станет на порядок эффективнее от прихода wasm).
За счет чего станет эффективнее на порядки? WebGL и так нейтивный. HLSL закидываются в него точно так же.
Вызовы нейтивной подсистемы из JS в подобных приложениях происходят со скоростью кликанья мышки, JS должен справляться.
_>Так GUI построенный на базе HTML во-первых достаточно убогий (посмотри на список доступных контролов в современных GUI библиотеках и в HTML), а во-вторых рендеринг через DOM весьма тормозной. Различные JS библиотеки (типа ExtJS) пытаются решать эти проблемы разработкой своих контролов и различными оптимизациями DOM, но всё это не эффективно на практике. Если же у тебя есть C++ приложение и предоставленная OpenGL поверхность, то ты просто берёшь одну из готовых мощных GUI библиотек и автоматически получаешь быстрый и профессиональный GUI. Естественно это актуально только для всяческих сложных сайтов (по сути веб приложений), а не для обычных "каталогов текста с картинками". )
Интресно, какой получится размер подобной загружаемой библиотеки GUI? ))
пишут, что что-то будет. Ops>По ссылке ничего такого не пишут, наоборот. А вот сами авторы вебасма обещают DOM, только непонятно когда, давно уже обещают. Еще где-то писали, что эта задача для них не очень приоритетная, а так ведь можно очень надолго затянуть или вообще забить.
Так там туда же ссылка и стоит. Что-то будет точно — а вот с какими ограничениями — уже будет видно по факту. Что они подразумевают под opaque reference types — мне вот не очень понятно... если через протаскиваение persistent GC handles — то опять надо будет обязательно все ссылки зануливать, что катастрофой в общем-то тоже не будет. Утечки просто будут и крики <мой браузер> опять сожрал всю память.
Здравствуйте, Ops, Вы писали:
_>>А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. ) Ops>Вскроют. Это в принципе нежизнеспособная концепция, когда клиент должен показывать пользователю расшифрованный контент, найти способ добраться для него лишь вопрос джонеуловимости.
Формально — конечно. Вопрос в сложности) И wasm по своей природе (можно же загружать "новый" плеер хоть на каждый новый фильм) существенно её увеличивает — возможно тогда проще какой-нибудь HDCP Stripper использовать, чем ломать такую штуку. )))
Здравствуйте, fddima, Вы писали:
F> Так там туда же ссылка и стоит.
Думал, ты про пост, ссылки дальше не смотрел. F>Что-то будет точно — а вот с какими ограничениями — уже будет видно по факту.
Когда будет-то? Они не торопятся, и явно писали, что задача не из первых. А ведь для многих это ключевой момент. F>Что они подразумевают под opaque reference types — мне вот не очень понятно... если через протаскиваение persistent GC handles — то опять надо будет обязательно все ссылки зануливать, что катастрофой в общем-то тоже не будет. Утечки просто будут и крики <мой браузер> опять сожрал всю память.
Кстати, у них FAQ интересное, "вебасм — это не замена JS, а дополнение", так что если что-то и прикрутят, это совсем не обязательно будет полноценным API, вполне может оказаться неудобным костылем.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, alex_public, Вы писали:
_>Формально — конечно. Вопрос в сложности) И wasm по своей природе (можно же загружать "новый" плеер хоть на каждый новый фильм) существенно её увеличивает — возможно тогда проще какой-нибудь HDCP Stripper использовать, чем ломать такую штуку. )))
Нет, вопрос в повсеместном использовании и в реализации. Сколько не защищай, на соседнем сайте нет никакой защиты, так что твой поток, если он не полностью уникальный, никто и ломать не будет, а контент все равно утечет. Говорю же, вопрос в джонеуловимости. Ну и какой смысл тогда вкладываться в защиту этого Джо?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vdimas, Вы писали:
_>>Вообще то игры — это только пример того, что вполне нормально для тяжёлых приложений иметь определённые ограничения на запуск и при этом быть успешными. А так это касается не только игр, но и любого тяжёлого ПО (вот например такое http://formit360.autodesk.com сразу же станет на порядок эффективнее от прихода wasm). V>За счет чего станет эффективнее на порядки? WebGL и так нейтивный. HLSL закидываются в него точно так же. V>Вызовы нейтивной подсистемы из JS в подобных приложениях происходят со скоростью кликанья мышки, JS должен справляться.
Ну так на шейдерах то только прорисовка. А надо ещё просчитывать сам мир, взаимодействия объектов и т.п. )
_>>Так GUI построенный на базе HTML во-первых достаточно убогий (посмотри на список доступных контролов в современных GUI библиотеках и в HTML), а во-вторых рендеринг через DOM весьма тормозной. Различные JS библиотеки (типа ExtJS) пытаются решать эти проблемы разработкой своих контролов и различными оптимизациями DOM, но всё это не эффективно на практике. Если же у тебя есть C++ приложение и предоставленная OpenGL поверхность, то ты просто берёшь одну из готовых мощных GUI библиотек и автоматически получаешь быстрый и профессиональный GUI. Естественно это актуально только для всяческих сложных сайтов (по сути веб приложений), а не для обычных "каталогов текста с картинками". ) V>Интресно, какой получится размер подобной загружаемой библиотеки GUI? ))
А можешь сам посмотреть например тут http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos — это примеры Qt приложений, скомпилированных под браузер (причём не в wasm, а в js). Самое забавное, что даже при компиляции в js этот интерфейс выглядит более отзывчивым, чем многие GUI на современных сайтах (сделанные с помощью JS GUI библиотек). А вот что это всё превратится с приходом wasm...
Здравствуйте, alex_public, Вы писали:
_>Ну так на шейдерах то только прорисовка. А надо ещё просчитывать сам мир, взаимодействия объектов и т.п. )
Ну если только физика, т.е. если мир слишком "активный"...
А так-то, даже если сцена сложная, но изменяется редко или часто изменяются только параметры сцены или небольшая группа объектов при уже загруженных ресурсах (изменение освещения, назначения разных уже предзагруженных текстур в зависимости от удалённости объектов), то заметного буста быстродействия не будет, ес-но.
_>А вот что это всё превратится с приходом wasm...
Посмотрим.
Браузер — это инфраструктура доставки исполняемого/интерпретируемого кода на сторону клиента. Не только доставки, но и кеширования.
Если с кешированием общих (для разных сайтов) библиотек разберутся, то может и взлетит...
Главный вопрос — когда?
Мы с тобой обсуждали несколько месяцев назад относительно того, что на прямо сейчас происходит натуральное "безвременье" в браузерных технологиях. Старые плагинные технологии уже преданы анафеме, но полноценной замены еще нет.
Здравствуйте, alex_public, Вы писали:
_>По идее без проблем. Правда для ютуба это не особо надо (что им там, дополнительную кнопочку в плеер прилепить что ли?). А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. )
"без проблем"... Я бы не был так оптимистичен.
WebAsm в принципе не может более того что может JavaScript который может рисовать только путем манипуляции DOM и методами <canvas>. <canvas> требует bitmap по спецификации, а это CPU rasterization.
А на самом деле всё еще хуже, в WebAsm, насколько я знаю, нет еще механизма обращения к DOM методам. Т.е. рисовать он не может, только что-то считать.
Ну и к тому же memory safety никто не отменял. Т.е. весь memory доступ должен быть обернут в вызовы каких-то функций. Т.е. это вот
while(p < end) ++p = 0;
будет достаточно далеко от выхлопа native C compiler.
На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM.
Здравствуйте, vdimas, Вы писали:
_>>А вот что это всё превратится с приходом wasm... V>Посмотрим. V>Браузер — это инфраструктура доставки исполняемого/интерпретируемого кода на сторону клиента. Не только доставки, но и кеширования. V>Если с кешированием общих (для разных сайтов) библиотек разберутся, то может и взлетит... V>Главный вопрос — когда? V>Мы с тобой обсуждали несколько месяцев назад относительно того, что на прямо сейчас происходит натуральное "безвременье" в браузерных технологиях. Старые плагинные технологии уже преданы анафеме, но полноценной замены еще нет. V>Чёрти что, как по мне. Мир сошел с ума...
Ну так ты же сам пишешь, что в принципе JS с WebGL уже сам может почти всё. Единственно, что ему может не хватать, это производительности в некоторых случаях (например если мы хотим написать свой плеер видео, которому соответственно придётся декодировать h.264/h.265) и доступа к функциям ОС (например для общения со всякими железками). Первую проблему очевидно решает как раз wasm. А вторую в какой-то степени решает Native messaging API, позволяющий данному JS скрипту общаться с внешним нативным приложением, естественно имеющим доступ ко всему OS API (однако установить это приложение как плагин браузера не выйдет — нужная нормальная инсталляция).
Здравствуйте, c-smile, Вы писали:
_>>По идее без проблем. Правда для ютуба это не особо надо (что им там, дополнительную кнопочку в плеер прилепить что ли?). А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. ) CS>"без проблем"... Я бы не был так оптимистичен. CS>WebAsm в принципе не может более того что может JavaScript который может рисовать только путем манипуляции DOM и методами <canvas>. <canvas> требует bitmap по спецификации, а это CPU rasterization.
Ты забываешь про WebGL. )))
CS>А на самом деле всё еще хуже, в WebAsm, насколько я знаю, нет еще механизма обращения к DOM методам. Т.е. рисовать он не может, только что-то считать.
Мы можем спокойно написать приложение на OpenGL, откомпилировать его emscripten и запустить в браузере. Причём это работало ещё и до wasm (с компиляцией в js), просто было не так эффективно по быстродействию. Хотя для определённых целей (включая сложные Qt интерфейсы, вроде таких http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos) даже такого хватало. А теперь будет ещё намного быстрее.
CS>На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM.
Байткод бывает разный. Бывает JVM, а бывает LLVM. )
Здравствуйте, alex_public, Вы писали:
_>Ну так ты же сам пишешь, что в принципе JS с WebGL уже сам может почти всё.
WebGL не может ничего.
Это как голый AutoCAD без плагинов, где можно рисовать только плоскости, базовые фигуры и т.д.
Далеко ты таким макаром не уедешь, ес-но.
Это не то же самое, что работать с полным набором плагинов для архитектурного проектирования, к примеру.
Т.е. нужно будет портировать кучу либ на wasm.
А потом как-то разбираться с их версионированием и кешированием.
Потому что размер таких полноценных либ сегодня — десятки метров.
_>Единственно, что ему может не хватать, это производительности в некоторых случаях (например если мы хотим написать свой плеер видео, которому соответственно придётся декодировать h.264/h.265) и доступа к функциям ОС (например для общения со всякими железками).
Чего в JS не хватает — это нормального языка программирования и хорошо структурированных библиотек к нему. ))
Код клиентских приложений может быть (и должен быть) довольно-таки сложен.
Я пару раз пытался читать обзоры того, что сейчас пользуют из либ для JS — голова идёт кругом.
Там происходит идеальнейший в природе Хаос.
Я же писал уже, что Сервелат еще жив в корпоративе по банальной причине — клиента можно писать на вменяемом C# с кучей хорошо стыкующихся друг с другом либ к нему.
А тут экосистему языков и библиотек к ним поверх wasm еще только предстоит создать.
Т.е. необходимо будет портировать и переосмыслить структуру гигантских пластов исходников.
Т.е., если в середине 90-х "из ничего" за 2-3 года появилось "всё", то сейчас всё изменилось, инерционность веба дикая.
Как и прежде, я вангую еще лет 5 минимум на "созревание" этой технологии.
При том, что ей уже пошёл 6-й год от первой демонстрации "вживую"...
_>Первую проблему очевидно решает как раз wasm. А вторую в какой-то степени решает Native messaging API, позволяющий данному JS скрипту общаться с внешним нативным приложением, естественно имеющим доступ ко всему OS API (однако установить это приложение как плагин браузера не выйдет — нужная нормальная инсталляция).
И обратиться из кода страницы к такому приложению выйдет только в том случае, если оно получено из надёжного источника. Например, в WIN 8 и выше можно запустить по специальной браузерной ссылке установленное приложение. Это ссылка на страничку этого приложения в Магазине. Если приложение уже стоит — оно запустится. Если еще не стоит — откроется Магазин и предложит установить.
Осталось придумать, как ровно таким же образом из надёжных источников получать библиотеки для wasm.
Потом предкомпиллять их (АОТ) при инсталляции.
А потом посмотреть на всё это с высоты птичьего полёта и сделать вот так ...
Будет та же плагинная система, вид сбоку. ))
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, c-smile, Вы писали:
_>>>По идее без проблем. Правда для ютуба это не особо надо (что им там, дополнительную кнопочку в плеер прилепить что ли?). А вот например всяким кинотеатрам и т.п. сервисам возможно будет очень интересно наладить персональные зашифрованные каналы доставки контента. ) CS>>"без проблем"... Я бы не был так оптимистичен. CS>>WebAsm в принципе не может более того что может JavaScript который может рисовать только путем манипуляции DOM и методами <canvas>. <canvas> требует bitmap по спецификации, а это CPU rasterization.
_>Ты забываешь про WebGL. )))
WebGL это тоже canvas
gl = canvas.getContext('webgl')
CS>>А на самом деле всё еще хуже, в WebAsm, насколько я знаю, нет еще механизма обращения к DOM методам. Т.е. рисовать он не может, только что-то считать.
_>Мы можем спокойно написать приложение на OpenGL, откомпилировать его emscripten и запустить в браузере. Причём это работало ещё и до wasm (с компиляцией в js), просто было не так эффективно по быстродействию. Хотя для определённых целей (включая сложные Qt интерфейсы, вроде таких http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos) даже такого хватало. А теперь будет ещё намного быстрее.
Только если WebAsm'у позволено обращаться напрямую к методам DOM. Пока — нет.
CS>>На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM.
_>Байткод бывает разный. Бывает JVM, а бывает LLVM. )
JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.
Здравствуйте, vdimas, Вы писали:
V>Чёрт-те что, как по мне. Мир сошел с ума...
Это не мир сошел с ума, это ты на него смотришь через амбразуру старых задач. Все эти окошки с кучей кнопочек, пимпочек и фитюлечек уже мало кому интересны. Типичный пользователь сейчас увидел твое приложение 5 минут назад, а еще через 5 про него забудет. И смотрит этот пользователь на него через смартфон, планшет или киоск производства мастера Лю из китайского аналога Усть-Зажопинска. Т.е. в качестве устройства ввода там никаких клавиатур, мышей и тачпадов, только собственный палец, елозящий по подглюкивающему тач-скрину. И рассчитывать на то, что там будет что то более менее стандартное, окромя браузера тоже не приходится.
Здравствуйте, vdimas, Вы писали:
_>>Ну так ты же сам пишешь, что в принципе JS с WebGL уже сам может почти всё. V>WebGL не может ничего. V>Это как голый AutoCAD без плагинов, где можно рисовать только плоскости, базовые фигуры и т.д. V>Далеко ты таким макаром не уедешь, ес-но. V>Это не то же самое, что работать с полным набором плагинов для архитектурного проектирования, к примеру. V>Т.е. нужно будет портировать кучу либ на wasm. V>А потом как-то разбираться с их версионированием и кешированием. V>Потому что размер таких полноценных либ сегодня — десятки метров.
В принципе если библиотека использует только стандартную библиотеку C++ в сочетание с какой-то разновидностью OpenGL/OpenAL, то всё "портирование" сведётся к просто перекомпиляции под emscripten. Т.е. очень многие движки заведутся "с ходу". )
Скажем для портирования SDL (которая теперь кстати входит в стандартное API emscripten https://github.com/kripken/emscripten/tree/master/system/include) им наверное (я сам не смотрел детали) пришлось добавить на уровне js-кода только простейшие вещи (поддержку получения событий от мышки с клавой и всякие мелочи типа установки заголовка окна, перехода в полноэкранный режим и т.п.). А теперь любое приложение, работающее на базе SDL (а таких не мало) будет собираться под браузер простой перекомпиляцией. Причём это всё было ещё до wasm, просто под js. А wasm всего лишь добавит к этой уже существующей инфраструктуре быстродействие близкое к нативному.
_>>Единственно, что ему может не хватать, это производительности в некоторых случаях (например если мы хотим написать свой плеер видео, которому соответственно придётся декодировать h.264/h.265) и доступа к функциям ОС (например для общения со всякими железками). V>Чего в JS не хватает — это нормального языка программирования и хорошо структурированных библиотек к нему. )) V>Код клиентских приложений может быть (и должен быть) довольно-таки сложен. V>Я пару раз пытался читать обзоры того, что сейчас пользуют из либ для JS — голова идёт кругом. V>Там происходит идеальнейший в природе Хаос.
Ну так сейчас вот уже C/C++ добавились. Обещается в ближайшее время Rust. Может потом и всякие Java/C# подтянутся (хотя не очень понятно зачем они нужны для wasm, т.к. их код обычно не намного более быстродействующий, чем JS)...
V>Т.е., если в середине 90-х "из ничего" за 2-3 года появилось "всё", то сейчас всё изменилось, инерционность веба дикая. V>Как и прежде, я вангую еще лет 5 минимум на "созревание" этой технологии. V>При том, что ей уже пошёл 6-й год от первой демонстрации "вживую"...
Нуу использовать то на практике думаю можно будет уже прямо в этом году. А вот повсеместное распространение она не факт что и через 5 лет получит, просто потому что она реально не везде нужна. )))
_>>Первую проблему очевидно решает как раз wasm. А вторую в какой-то степени решает Native messaging API, позволяющий данному JS скрипту общаться с внешним нативным приложением, естественно имеющим доступ ко всему OS API (однако установить это приложение как плагин браузера не выйдет — нужная нормальная инсталляция). V>И обратиться из кода страницы к такому приложению выйдет только в том случае, если оно получено из надёжного источника. Например, в WIN 8 и выше можно запустить по специальной браузерной ссылке установленное приложение. Это ссылка на страничку этого приложения в Магазине. Если приложение уже стоит — оно запустится. Если еще не стоит — откроется Магазин и предложит установить. V>Осталось придумать, как ровно таким же образом из надёжных источников получать библиотеки для wasm. V>Потом предкомпиллять их (АОТ) при инсталляции. V>А потом посмотреть на всё это с высоты птичьего полёта и сделать вот так ... V>Будет та же плагинная система, вид сбоку. ))
Так для wasm как раз не требуется надёжного источника, т.к. его исполнение ограничено песочницей браузера. ) В этом и есть главный смысл. )
Здравствуйте, c-smile, Вы писали:
_>>Ты забываешь про WebGL. ))) CS>WebGL это тоже canvas CS>
CS>gl = canvas.getContext('webgl')
CS>
Конечно, только рисуют в него совсем по другому. )
_>>Мы можем спокойно написать приложение на OpenGL, откомпилировать его emscripten и запустить в браузере. Причём это работало ещё и до wasm (с компиляцией в js), просто было не так эффективно по быстродействию. Хотя для определённых целей (включая сложные Qt интерфейсы, вроде таких http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos) даже такого хватало. А теперь будет ещё намного быстрее. CS>Только если WebAsm'у позволено обращаться напрямую к методам DOM. Пока — нет.
Зачем ему DOM, если ему доступен OpenGL в предоставленную canvas? ))) Ну точнее пока DOM ещё используется в какой-то степени снаружи (через js), для перехвата сообщений от мышки/клавы и пересылки их в wasm приложение. Но надеюсь это они доработают, придумав какой-то аналог API для обработки "оконных сообщений". А вот DOM для вывода информации в таких приложениях точно не нужен. )
CS>>>На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM. _>>Байткод бывает разный. Бывает JVM, а бывает LLVM. ) CS>JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.
В быстродействие (ради которого wasm и придумали) разница очень принципиальная. ))) Что касается ограничений, то я ещё не смотрел детальную реализацию wasm, так что ничего сказать не могу. Но думаю что там всё реализовано достаточно эффективно, иначе бы просто во всём этом не было бы смысла. )))
Здравствуйте, c-smile, Вы писали:
CS>>>На самом деле WebAsm нужно расценивать как byte codes, а всю инфраструктуру как нечто очень похожее на среду JavaVM. _>>Байткод бывает разный. Бывает JVM, а бывает LLVM. ) CS>JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.
Кстати, решил тут немного поискать информацию по данному вопросу и оказалось что все детали элементарно находятся под рукой. Просто надо было заметить, что все эти низкоуровневые нюансы реализованы в отдельном проекте. Вот он https://github.com/WebAssembly/binaryen. Кстати, даже ещё не смотря во внутренности, по первой странице можно увидеть важную информацию: на данный момент доступны два варианта компиляции wasm. Из некого js (например сгенерированного emscripten) и из llvm кода (причём там даже при компиляции в llvm появилась возможность указывать архитектуру wasm32). Так вот последнее думаю будет крайне эффективным. )
Здравствуйте, alex_public, Вы писали:
CS>>JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing.
_>Кстати, решил тут немного поискать информацию по данному вопросу и оказалось что все детали элементарно находятся под рукой. Просто надо было заметить, что все эти низкоуровневые нюансы реализованы в отдельном проекте. Вот он https://github.com/WebAssembly/binaryen. Кстати, даже ещё не смотря во внутренности, по первой странице можно увидеть важную информацию: на данный момент доступны два варианта компиляции wasm. Из некого js (например сгенерированного emscripten) и из llvm кода (причём там даже при компиляции в llvm появилась возможность указывать архитектуру wasm32). Так вот последнее думаю будет крайне эффективным. )
Причем здесь это ? LLVM это bytecode generator. Кто исполняет это bytecode?
Представь себе что WebAsm может читать/писать произвольные адреса внутри browser. Любой "залетевший дятел" сразу начнет писать "стыривалки" паролей, да вообще что угодно.
Неправильно ведь, да? Т.е. нужно sandbox'ить это дело. Защита памяти только на уровне процесса в текущих архитектурах. Т.е. все защиты будут делаться программно.
Ну и всё такое...
На самом деле WebAsm он не для C/C++. А для всяких там TypeScript и прочего. Т.е. WebAsm это фактически расширенный JavaScript bytecode.
Просто отцов-основателей достали стоны про то какое г. этот ваш JS. Ну вот и делается WebAsm для "хочите front end на Haskell писать- нате вам".
Работать это если и будет быстрее чем JS то не намного. Просто из-за специфики JS в котором нет int32, int64 и пр. базовых вещей.
Здравствуйте, c-smile, Вы писали:
CS>>>JVM или LLVM — разницы в данном контексте нет. Эти байткоды напрямую к памяти обращаться не могут — sandboxing. _>>Кстати, решил тут немного поискать информацию по данному вопросу и оказалось что все детали элементарно находятся под рукой. Просто надо было заметить, что все эти низкоуровневые нюансы реализованы в отдельном проекте. Вот он https://github.com/WebAssembly/binaryen. Кстати, даже ещё не смотря во внутренности, по первой странице можно увидеть важную информацию: на данный момент доступны два варианта компиляции wasm. Из некого js (например сгенерированного emscripten) и из llvm кода (причём там даже при компиляции в llvm появилась возможность указывать архитектуру wasm32). Так вот последнее думаю будет крайне эффективным. ) CS>Причем здесь это ? LLVM это bytecode generator. Кто исполняет это bytecode?
LLVM тут вот https://github.com/WebAssembly/binaryen/wiki/Compiling-to-WebAssembly-with-Binaryen причём. Да, это не имеет отношения к вопросу безопасности памяти (про это ниже), но имеет отношения к оптимизации и производительности кода.
CS>Представь себе что WebAsm может читать/писать произвольные адреса внутри browser. Любой "залетевший дятел" сразу начнет писать "стыривалки" паролей, да вообще что угодно. CS>Неправильно ведь, да? Т.е. нужно sandbox'ить это дело. Защита памяти только на уровне процесса в текущих архитектурах. Т.е. все защиты будут делаться программно. CS>Ну и всё такое...
Хы, смешно, ты вот действительно думаешь, что описанное тобой — это какая-то проблема? С учётом того, что у нас приходят не машинные коды, а AST, которое надо ещё оттранслировать в машинные коды (и как раз тут можно встроить любую защиту)?
Память в wasm устроена очень просто: http://webassembly.org/docs/semantics/#linear-memory. Т.е. внутри своего куска памяти ты можешь развлекаться любыми "нативными" способами, как тебе угодно. Нужна только гарантия, что ты не вылезешь за пределы этого куска (т.е. что величина указателя меньше значения current_memory данного модуля). Реализация этого момента в документации оставлена на усмотрение "встраивателя" (т.е. в данном случае авторов браузера). Но понятно, что это элементарно делается при трансляции wasm инструкций load и store в машинные коды.
CS>На самом деле WebAsm он не для C/C++. А для всяких там TypeScript и прочего. Т.е. WebAsm это фактически расширенный JavaScript bytecode. CS>Просто отцов-основателей достали стоны про то какое г. этот ваш JS. Ну вот и делается WebAsm для "хочите front end на Haskell писать- нате вам".
О, какие интересные открытия у нас тут на форуме встречаются. ))) Только вот есть небольшая неувязка — на самом сайте wasm указано прямо противоположное: http://webassembly.org/docs/high-level-goals/.
CS>Работать это если и будет быстрее чем JS то не намного. Просто из-за специфики JS в котором нет int32, int64 и пр. базовых вещей.
Ну запишем это твоё предположение. И после проведения первых же тестов вернёмся к нему. Ну просто чтобы не тратить время на лишние споры, а сразу фактами решить вопрос. ) Хотя лично я уже сейчас вижу, что ты абсолютно не прав. )))
P.S. Почитал тут эту http://webassembly.org/docs/use-cases/ их страничку. Про раздел Inside the browser я приблизительно так и представлял целевую нишу данной технологии. А вот их раздел Outside the browser довольно любопытен — как-то я не думал про подобное применение. Хотя с точки зрения эффективности голый LLVM должен быть лучше, но там нет никакой безопасности. Так что возможно оно действительно не только в вебе пригодится.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это не мир сошел с ума, это ты на него смотришь через амбразуру старых задач.
А они никуда не делись, эти "старые задачи".
Тот факт, что добавились новые, не означает потерю старых.
Просто теперь конторы должны оплачивать разработку копий клиентского софта для Андроида, iOS и виндов + трахаться с поддержкой актуальности такого софта уникально для каждой платформы (внутренняя прога служб такси, система оформления заказов для оптовой конторы и т.д. до бесконечности).
Суть веба когда-то была в том, чтобы всего этого не делать.
Сейчас корпоративный сектор, считай, грубо кинут гуглом и мозиллой.
Здравствуйте, alex_public, Вы писали:
_>Так для wasm как раз не требуется надёжного источника, т.к. его исполнение ограничено песочницей браузера. ) В этом и есть главный смысл. )
На новый круг решил зайти? ))
Такая же песочница была и в Java-апплетах, и во Флеше и в Сервелате.
Причем, этим песочницам много лет, много было поймано и отлажено багов.
Гуглу только еще предстоит пройти тяжелый путь созревания технологии.
Поэтому, в сухом остатке у нас есть только один главный смыл — Гугл решил всех бортануть нафик, поэтому проталкивает своё поделие wasm и бинарную машинку к нему, тоже своего производства, ес-но.
А как мы вообще докатились до такой жизни, почему этого Гугла кто-то там вообще слушает? ))
А, ну да, он же когда-то захватил почти половину пользователей браузеров.
На десктопе.
И поставил свою операционку на половину мобильных девайсов.
Скажем так.
Когда много лет назад я увидел рекламу Гугла про их новый браузер, у меня был сильный негатив по этому поводу.
Собсно, всё было понятно — это чудо потянуло свои немытые ручки туда, где его никогда не было.
И, разумеется, потянуло ручки не с целью сделать всем приятно, а ровно наоборот — подгадить всем, кому получится.
По-сути, надо было начинать разваливать Гугл в судебном порядке уже тогда, как MS за 5-6 лет до этого.
Потому что теперь мы имеем ту самую нечестную конкуренцию через манипуляцию понятием "современные стандарты".
Здравствуйте, vdimas, Вы писали:
НС>>Это не мир сошел с ума, это ты на него смотришь через амбразуру старых задач. V>А они никуда не делись, эти "старые задачи".
Да не делись конечно. Только другие задачи стали важнее и фокус ушел на них.
V>Просто теперь конторы должны оплачивать разработку копий клиентского софта для Андроида, iOS и виндов + трахаться с поддержкой актуальности такого софта уникально для каждой платформы (внутренняя прога служб такси, система оформления заказов для оптовой конторы и т.д. до бесконечности).
У качественного мобильного софта тоже акценты сместились. Если приложение для вызова такси или онлайн-банкинга построено по принципу десктопного софта, оно тут же идет в мусор.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>У качественного мобильного софта тоже акценты сместились. Если приложение для вызова такси или онлайн-банкинга построено по принципу десктопного софта, оно тут же идет в мусор.
А это здесь причем?
Богатая функциональность не обязательно означает дестопный GUI.
Здравствуйте, vdimas, Вы писали:
_>>Так для wasm как раз не требуется надёжного источника, т.к. его исполнение ограничено песочницей браузера. ) В этом и есть главный смысл. ) V>Такая же песочница была и в Java-апплетах, и во Флеше и в Сервелате. V>Причем, этим песочницам много лет, много было поймано и отлажено багов. V>Гуглу только еще предстоит пройти тяжелый путь созревания технологии.
Всё верно (кроме разве что упоминания Гугла). Только вот у перечисленных трёх технологий были прямо одинаковые недостатки:
1. Зависимость от одного языка/платформы.
2. Зависимость от одной компании, управляющей развитием данной технологии.
В wasm у нас эти неприятности решены от рождения: технология мультиязычная и развивается консорциумом ведущих игроков в данной области (Mozilla, Google, Microsoft, Apple).
V>Поэтому, в сухом остатке у нас есть только один главный смыл — Гугл решил всех бортануть нафик, поэтому проталкивает своё поделие wasm и бинарную машинку к нему, тоже своего производства, ес-но.
Что за бинарная машинка для wasm и почему она производства Гугла? )
Третий раз изобрели Джаву. Зачем?
Чем не годились первые две?
И джавовский и дотнетовский байткоды тоже строятся на стек-машинах.
Чем они плохи?
Ну ладно, дотнет — сильно ориентирован на майкрософт и не используется во фронтенде.
Джава таки давно используется...
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
Я бы сказал, что это скорее ближе к безопасному LLVM)
ДФ>Чем они плохи? ДФ>Ну ладно, дотнет — сильно ориентирован на майкрософт и не используется во фронтенде. ДФ>Джава таки давно используется...
Здравствуйте, alex_public, Вы писали:
_>Всё верно (кроме разве что упоминания Гугла). Только вот у перечисленных трёх технологий были прямо одинаковые недостатки: _>1. Зависимость от одного языка/платформы.
Давай называть вещи своими именами.
Не было возможности задействовать тонны легаси кода на С/С++ в вебе. ))
_>2. Зависимость от одной компании, управляющей развитием данной технологии.
Это как раз не принципиально.
Мои претензии тут того плана, что некая новая технология должна естественным путём выигрывать конкуренцию, а не по той единственной причине, что все остальные оказались под искусственным запретом.
_>В wasm у нас эти неприятности решены от рождения: технология мультиязычная и развивается консорциумом ведущих игроков в данной области (Mozilla, Google, Microsoft, Apple).
Немного не так. Гугл+Мозилла выступили с некоей инициативой, поставив других членов W3C перед фактом: участвовать в доработке стандартов этих инициатив или совсем остаться не у дел. Когда-то за гораздо менее наглые выходки насильно в судебном порядке развалили MS.
Просто тут так странно получается, что якобы свободные разработчики ПО (какими себя усердно называют мозилловцы) по-сути остаются безнаказанными независимо от любых своих выкрутасов. Очень удобно, чо.
Но я никогда не верил, что программисты из Мозиллы работают даром, ес-но.
Кто-то им платит ЗП. С какой целью?
Тут получается та самая разновидность благопристойной (якобы благопристойной) ширмы для грубого передела рынка Сети:
Организация Mozilla огласила финансовые результаты за 2012 год. К сожалению, диверсифицировать источники дохода организации не удается. Совсем наоборот: в очередной раз увеличилась финансовая зависимость от компании Google, которая в прошлом году обеспечила 90% всех доходов Mozilla. Годом ранее этот показатель составлял 85%.
На сегодня Мозилла — это филиал Гугла.
Прикормленные с рук крестьяне.
Финита ля комедия.
Вернее, комедию ломают перед нами и держат за идиотов.
В одиночку, без Мозиллы, только лишь через свой Хром, Гугл не смог бы "запретить" популярные еще вот недавно веб-технологии, ес-но.
V>>Поэтому, в сухом остатке у нас есть только один главный смыл — Гугл решил всех бортануть нафик, поэтому проталкивает своё поделие wasm и бинарную машинку к нему, тоже своего производства, ес-но. _>Что за бинарная машинка для wasm и почему она производства Гугла? )
The web is not controlled by any single vendor, so every change must be a joint effort. Fortunately, the teams behind WebAssembly know this. At Mozilla, a group of hardcore developers tried to provide an answer in the form of asm.js: a subset of JavaScript meant to serve as a compiler target. On the other side, Google worked on Native Client (NaCl) and Portable Native Client (PNaCl), a binary format for the web based on LLVM.
Выделенное — это самая большая современная ложь.
Примерно как мантры про демократию на Западе. ))
Ну и изначальная ориентировка на LLVM — оно не принципиально ни разу, ес-но. Т.е. это НЕ важно, каков будет конечный стандарт байт-кода этой виртуальной машинки, бо не за тонкости будущего стандарта идёт битва, а за право контролировать процесс разработки стандартов и технологий. за право навязывать свои правила игры.
Как это всё смотрится со стороны, думаю, объяснять не надо.
Пахнет это всё отвратительно.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Дрободан Фрилич, Вы писали:
_>>>https://geektimes.ru/post/286718/ — позитивная новость! _>>>Ну что господа C++'ки, начинаем ваять сайтики? https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html — этот вроде не плохо вышел. ) ДФ>>Третий раз изобрели Джаву. Зачем? ДФ>>Чем не годились первые две? ДФ>>И джавовский и дотнетовский байткоды тоже строятся на стек-машинах.
_>Я бы сказал, что это скорее ближе к безопасному LLVM)
А какая разница? И то и то требует JIT — компиляцию в target машину.
Единственная принципиальная разница в том что Java bytecodes имеют ввиду GC. Что есть большой плюс в контексте browser based UI — ownership graph в event driven системах крайне сложный.
На самом деле JavaVM, это не побоюсь этого слова, архитектурно идеальное решение для работы именно внутри browser. Там всё заточено именно для этого use case. Да и создавалась она именно для этого изначально. Server side Java usage это не от хорошей жизни.
Если бы там была конструкция типа VARIANT то мы бы сейчас вместо JavaScript наблюдали бы толпу разных скриптовых языков транслируемых в .class файлы работающих в browser.
ДФ>>Чем они плохи? ДФ>>Ну ладно, дотнет — сильно ориентирован на майкрософт и не используется во фронтенде. ДФ>>Джава таки давно используется...
_>Оно будет побыстрее и без вендор лока. )
"Оно будет побыстрее"... если и будет то совсем незначительно. JIT c managed прослойками в обоих случаях.
Здравствуйте, vdimas, Вы писали:
_>>Всё верно (кроме разве что упоминания Гугла). Только вот у перечисленных трёх технологий были прямо одинаковые недостатки: _>>1. Зависимость от одного языка/платформы. V>Давай называть вещи своими именами. V>Не было возможности задействовать тонны легаси кода на С/С++ в вебе. ))
Не только легаси. Вот смотри, допустим разработает сейчас кто-то новый супер крутой кодек видео (думаю понятно на каком языке это будет происходить ), позволяющий существенно уменьшать время загрузки видео по сети. Представляешь сколько лет потребуется для его проталкивание в реализацию всех современных браузеров? А с помощью wasm создатели кодека смогут просто продать (ну выложить бесплатно, это уж их дело) нужную библиотечку любому желающему сайту и оно без проблем заработает сразу у всех пользователей.
_>>2. Зависимость от одной компании, управляющей развитием данной технологии. V>Это как раз не принципиально. V>Мои претензии тут того плана, что некая новая технология должна естественным путём выигрывать конкуренцию, а не по той единственной причине, что все остальные оказались под искусственным запретом.
Общетеоретически я тут с тобой конечно же согласен. Но в данном конкретном случае я всё же предлагаю оценить трезво предоставленный "неконкурентный" продукт — пока он по всем параметрам выглядит интереснее "заблоченных" конкурентов. )
V>>>Поэтому, в сухом остатке у нас есть только один главный смыл — Гугл решил всех бортануть нафик, поэтому проталкивает своё поделие wasm и бинарную машинку к нему, тоже своего производства, ес-но. _>>Что за бинарная машинка для wasm и почему она производства Гугла? ) V>Я уже упоминал в прошлом обсуждении, откуда у всего этого растут ноги: V>https://en.wikipedia.org/wiki/Google_Native_Client V>https://auth0.com/blog/7-things-you-should-know-about-web-assembly/ V>
V>The web is not controlled by any single vendor, so every change must be a joint effort. Fortunately, the teams behind WebAssembly know this. At Mozilla, a group of hardcore developers tried to provide an answer in the form of asm.js: a subset of JavaScript meant to serve as a compiler target. On the other side, Google worked on Native Client (NaCl) and Portable Native Client (PNaCl), a binary format for the web based on LLVM.
Ну как бы всё верно. LLVM очень хорош по эффективности, но в прямом виде небезопасен. Asm.js очевидно полностью безопасный, но не такой эффективный. А сейчас мы видим в wasm оптимальную смесь — эффективное и безопасное решение. Причём в инструментарий wasm входят как раз компиляторы llvm->wasm и asm.js->wasm.
V>Выделенное — это самая большая современная ложь. V>Примерно как мантры про демократию на Западе. )) V>Ну и изначальная ориентировка на LLVM — оно не принципиально ни разу, ес-но. Т.е. это НЕ важно, каков будет конечный стандарт байт-кода этой виртуальной машинки, бо не за тонкости будущего стандарта идёт битва, а за право контролировать процесс разработки стандартов и технологий. за право навязывать свои правила игры. V>Как это всё смотрится со стороны, думаю, объяснять не надо. V>Пахнет это всё отвратительно.
Нуу "политику" мне обсуждать уже лень... ) Скажу только что все материалы и инструменты для wasm изначально выложены в открытый доступ (здесь https://github.com/WebAssembly) и лицензии там везде Apache. Так что на данный момент меня всё устраивает. Пусть даже это и результат хитрых подковёрных игр. )))
Здравствуйте, c-smile, Вы писали:
_>>Я бы сказал, что это скорее ближе к безопасному LLVM) CS>А какая разница? И то и то требует JIT — компиляцию в target машину. CS>Единственная принципиальная разница в том что Java bytecodes имеют ввиду GC. Что есть большой плюс в контексте browser based UI — ownership graph в event driven системах крайне сложный.
Так же ещё например такие радости как рантайм рефлексию, боксинг и т.п. )
CS>На самом деле JavaVM, это не побоюсь этого слова, архитектурно идеальное решение для работы именно внутри browser. Там всё заточено именно для этого use case. Да и создавалась она именно для этого изначально. Server side Java usage это не от хорошей жизни. CS>Если бы там была конструкция типа VARIANT то мы бы сейчас вместо JavaScript наблюдали бы толпу разных скриптовых языков транслируемых в .class файлы работающих в browser.
Ну как бы JS сейчас не сильно медленнее Java. ) Смысл Java был бы разве что в статической типизации, актуальной для сложных проектов. Но сейчас же ещё TypeScript появился...
_>>Оно будет побыстрее и без вендор лока. ) CS>"Оно будет побыстрее"... если и будет то совсем незначительно. JIT c managed прослойками в обоих случаях.
Ну вот посмотрим, когда пойдут тесты. Точнее их в принципе уже сейчас можно без проблем проводить, но у меня нет времени этим заниматься. Надеюсь кто-нибудь проведёт и опубликует в ближайшее время. Ну или я сам потом.)
Здравствуйте, alex_public, Вы писали:
V>>Мои претензии тут того плана, что некая новая технология должна естественным путём выигрывать конкуренцию, а не по той единственной причине, что все остальные оказались под искусственным запретом. _>Общетеоретически я тут с тобой конечно же согласен. Но в данном конкретном случае я всё же предлагаю оценить трезво предоставленный "неконкурентный" продукт — пока он по всем параметрам выглядит интереснее "заблоченных" конкурентов. )
Тем более странно заведомо пытаться подключать новую технологию к аппарату исскуственного жизнеобеспечения.
Еще более стрёмно, когда это происходит по инициативе всего одной компании, которая усердно делает вид, что это инициатива нескольких независимых компаний, где "независимые" по-факту кормятся из того же корыта.
_>Ну как бы всё верно. LLVM очень хорош по эффективности, но в прямом виде небезопасен. Asm.js очевидно полностью безопасный, но не такой эффективный. А сейчас мы видим в wasm оптимальную смесь — эффективное и безопасное решение. Причём в инструментарий wasm входят как раз компиляторы llvm->wasm и asm.js->wasm.
Еще раз, конечный формат бинарного байт-кода не принципиален ни разу.
Я не сомневаюсь, что во втором десятилетии 21-го века нарисуют необходимую схему с учётом специфики веба.
Тут другая интрига нарисовывается:
Собсно, сейчас функциональность "песочниц" встроена прямо в современные OS — в Win 8 и выше, в iOS.
Т.е., имеет ли смысл в браузере делать еще одну собственную "песочницу", если сам браузер работает из под песочницы?
Вернее, сразу из под кучи песочниц, т.к. имеет возможность запускать по песочнице на страницу прямо ср-вами ОС — ведь приложению-браузеру доступно только "песочное" ограниченное АПИ ОС.
Просто тут еще одно такое странное совпадение, что именно на гугловом Андроиде эта "песочница" не полнофункциональная. Т.е., большинство программ работают поверх некоей их VM, где песочница вроде как есть на сугубо прикладном уровне для байт-кодных приложух, но для нейтивных вопрос в Андроиде всё еще открыт.
Т.е., пока что выглядит так, что они ниасилили песочницу на уровне ОС (линуха), поэтому делают её на уровне браузера.
Ну и заодно решили превратить этот недостаток в достоинство через давление на W3C, пользуясь своим монопольным положением на рынке браузеров. ))
_>Скажу только что все материалы и инструменты для wasm изначально выложены в открытый доступ (здесь https://github.com/WebAssembly) и лицензии там везде Apache. Так что на данный момент меня всё устраивает. Пусть даже это и результат хитрых подковёрных игр.
Я не против, пусть выкладывают что угодно куда угодно.
Я против того, чтобы некие выложенные сырые вещи (или даже не сырые — не принципиально) использовались как оправдание для зачистки конкурентов.
Здравствуйте, fddima, Вы писали:
F>Так там туда же ссылка и стоит. Что-то будет точно
Пока что даже GC не планируется для вебасма.
Сказано так: GC может быть выполнен в виде скомпиллированной в webasm VM.
То бишь, возьми реализацию VM джавы или дотнета, портируй её на webasm, вот и будет тебе GC.
Правда, к GC JS браузера он не будет иметь никакого отношения.
F>а вот с какими ограничениями — уже будет видно по факту. Что они подразумевают под opaque reference types — мне вот не очень понятно...
Некий тип без объявления "тела". Такой тип можно получать и передавать по ссылке.
Это похоже на одну из идей, как можно сделать вызовы из нейтивной (по архитектуре) webasm в управляемую JS-среду.
Например, как-то так:
Тут одно плохо — они в эту сторону не то, что делать что-то еще не начали, тут даже еще серьезного обсуждения нет.
Т.е., все эти вещи если и появятся — то очень не скоро и скорее всего сам JS будет уже не актуален на тот момент.
F>если через протаскиваение persistent GC handles — то опять надо будет обязательно все ссылки зануливать, что катастрофой в общем-то тоже не будет. Утечки просто будут и крики <мой браузер> опять сожрал всю память.
Не-е-е-е. Ты не понял. "Плоская память" VM WebAsm и память JS-машинки вообще никак не пересекаются по GC.
Я рядом давал ссылки, они рассуждают так, что для GC объектов (если GC когда-нить и будет частью webasm) будет выделена совсем отдельная куча. Более того, если почитать вот эту ссылку внимательно: https://github.com/WebAssembly/design/blob/master/GC.md
то выглядит так, что они уже и сами поняли, что в случае GC у них получится Java/Дотнет, вид сбоку, ы-ы-ы.
Я как раз всё понял и правильно.
Отсутствие внятного интеропа с сервисами браузера (читай с тем же DOM) — пока-что сильно ограничивает применимость технологии в массах. Если и когда сделают интероп — надо будет смотреть по факту, какой механизм для этого привлекут. Остальное шелуха.
Здравствуйте, vdimas, Вы писали:
V>Пока что даже GC не планируется для вебасма. V>Сказано так: GC может быть выполнен в виде скомпиллированной в webasm VM.
Пусть его (GC) и напишут тогда уже, особенно как модуль. Заодно посмотрим сколько раз понадобится хакнуть мир, что бы это заработало.
Здравствуйте, fddima, Вы писали:
F>Пусть его (GC) и напишут тогда уже, особенно как модуль. Заодно посмотрим сколько раз понадобится хакнуть мир, что бы это заработало.
Ну, они пока считают, что на первом этапе достаточно вызовов со страницы в WebAsm, а не наоборот.
В принципе, GUI-события происходят редко, их не сложно туда зароутить.
Самому WebAsm предоставляется канвас для рисования и он там делает что хочешь. ))
https://s3.amazonaws.com/mozilla-games/ZenGarden/EpicZenGarden.html — этот вроде не плохо вышел. )
Скоро браузер будет операционной системой даже и на десктопах. Будут делать антивирусы для браузера.
да блин..
...
