Как стать автором
Обновить

Комментарии 20

И сколько теперь мегахешей можно получать с каждого зашедшего на сайт?
А как вы распространяете получившиеся после emscripten модули для использования другим JS-кодом? Последний раз, когда я смотрел, инструментов для C/C++ модулей практически не было. Есть ли что-то наподобие wasm-pack для C/C++, хотя бы могущее в паковку модулей и их использование в webpack?
у вас есть модуль, который вы можете использовать в своем проекте а чем он собирается не важно

Праивльно ли я понимаю, что WASM это еще одна попытка зайти в байт-код на стороне пользоватлея? Почему это должно в этот раз произойти? Напомню, что существовал Java Applets (с которым я когда-то делал приложение для рисования диаграм), а позднее был SilverLight, Macromedia Flash и на самом деле я думаю, что еще много всего вроде NPAPI и т.д. Почему на этот раз должно взлететь? Теперь W3C не будет ставить палки в колеса и помогать стандарту развиваться? А это вроде как выглядит не очень конкурентно со стороны свободного сцентра стандартизации? С другой стороны почему бы и нет... так как с каждым днем не видно сильных игроков на стороне универсальных GUI для ОС общего назначения.

в этот раз все браузеры уже реализовали поддержку WebAssembly

В этот раз в разработке нет основного недостатка (NIH) на мой взгляд. Именно по этому WASM-у и дали зеленый свет. Если моя догадка верная, то очень печально это осознавать: союз W3C и все эти альтруисты по сути просто выпинали неудобный им продукты с условного "рынка".

Вам нужно почитать причины по которым WebAssemly все таки создавался, все что вы перечислили ровно там и разобраны. Начнем с того, что код выполняется строго в песочнице.

Ну в некоторых кругах предложение подучиться звучит оскорбительно, но сделаю скидку на то что не все сегодня имеют воспиатние и культуру дисскусий. Если обьяснять лень, то пройти мимо на мой взгляд предпочтительнее чем создавать "пустые" по инстормации комментарии.

Вы утверждаете, что код работающий в Java Applet и Silverlight выполнялись не в песочнице виртуальной машины?

Нет тут ничего оскорбительного, вопрос безопасности стоял, как вы можете догадаться, на первом месте. Явааплеты как и флеш так и Silverlight не выполнялись в такой изолированной среде, потому что могут сами порождать свои процессы и иметь доступ к апи браузера да и не только браузера. WebAssembly работает только в случае вызова его js и общается с браузером он только через js. Он не может сделать ничего что не может делать js.

Явааплеты как и флеш так и Silverlight не выполнялись в такой изолированной среде, потому что могут сами порождать свои процессы и иметь доступ к апи браузера да и не только браузера. WebAssembly работает только в случае вызова его js и общается с браузером он только через js. Он не может сделать ничего что не может делать js.

Разве Java Applet может порождать процессы на пользовательском окружении без яновго на это разрешения? На сколько я помню для этого нужно запросить дополнительное разрешение у пользователя, а в этом сейчас и есть главное ограничение и достоинство WASM по вашему мнению?

Хорошо я понял Вашу позицию и видимо какую-то веру (скорее всего производственную вовлеченность) в то что одна технология была уязвима, а другая сейчас будет надежной и современной за счет использования видимо JSON и ограниченной по возможностям виртуальной JS мышины. Кстати напомню, что Node.js отлично запускает внешние процессы, так что в некоторых реализациях так же можно запускать внешние процессы.

Разве Java Applet может порождать процессы на пользовательском окружении без яновго на это разрешения?

Кажется с яваапплетами такое творилось, что разрешения было вообще не нужно.


васм не может вызывать сам свой код. Только js, который дергает его каждый раз где ему это нужно.
Хорошо я понял Вашу позицию и видимо какую-то веру (скорее всего производственную вовлеченность) в то что одна технология была уязвима, а другая сейчас будет надежной

Дело в архитектуре, в webAssembly она совершенно другая. Ничего нового по сути в браузер не добавляется, кроме среды исполнения, которая может взломать браузер ровно так же как и любой сайт, использующий js.

В долгосрочке дать васму больше полномочий к браузерному API без обращения к js.

Кстати напомню, что Node.js отлично запускает внешние процессы, так что в некоторых реализациях так же можно запускать внешние процессы.

У ноды написано дополниельное API, поэтому это нода а не браузер.
Посмотреть как нода работает в браузере можно по этой ссылке
stackblitz.com/fork/node
npm работает
Только все необходимое апи для работы ноды переписано на js. (типа обращения к сайтам)

Кажется с яваапплетами такое творилось, что разрешения было вообще не нужно.

Ну тут я не подскажу вполне вероятно, что какие-то сочетания версий и программного обеспечения могли давать возможность уязвимостей, но как я вижу в последних версиях полным полно каких-то механизмов защиты https://docs.oracle.com/en/java/javase/14/security/java-security-overview1.html#GUID-C6D250FC-F147-4284-A6BF-8384DFD39DA6

Дело в архитектуре, в webAssembly она совершенно другая. Ничего нового по сути в браузер не добавляется ...

Так какая разница виртуальную машину переиспользовать у браузера или прлепить движки от C# или JVM? Почему доверия Google больше чем разработчику Windows или Oracle? Единственный профит, который я тут вижу, так это переносимость платформы, которой не обладает по хорошему ни JVM и ни .NET. А уязвимости будут что в WASM, что в любой другой платформе это сегодня уже всем понятно, что делать без ошибок люди не могут.

в последних версиях


Емнип, поддержка java аплетов выпелена из браузеров помоему абсолютно принудительно и уже довольно давно.

Так какая разница виртуальную машину переиспользовать у браузера или прлепить движки от C# или JVM? Почему доверия Google больше чем разработчику Windows или Oracle?

васм позволяет отвязаться от языка и выполнять и c# или java в браузере, почти любую кодовую базу вашего уже написанного приложения. Автокад кажется так перенес своего монстра в браузер.

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

Уязвимости это про архитектуру. Все показывает только время. Архитектурно тут все очень безопасно.

Емнип, поддержка java аплетов выпелена из браузеров помоему абсолютно принудительно и уже довольно давно.

Да, действительно на сайте Java была новость https://www.java.com/ru/download/help/firefox_java.html о том, что NPAPI больше не соответствует профилям безопастности браузера, но запуск приложений через "Web Start" вроде работает. Приложение будет загружено и выполнено на целевой машине в JVM. Просто непонятно зачем нужен браузер как Canvas для рисования или какие-то другие преимущества?

Автокад кажется так перенес своего монстра в браузер.

Вот это выглядит как ползеная для бизнеса возможность собрать уже существующее приложение на C/C++, C#, Java и предоставить на любую платформу в виде байткода работающего в виртуальной машине, но скорее всего нужно будет писать промежуточный слой для того же GUI и сегодня полным полно уже готовых виртуальных машин JVM, .NET их не пишет разве что ленивый (кстати о ленивых, а что там для кросплатформы в macOS?). Странно только зачем использовать браузер как уже ранее говорили, что для Java есть JNLP или "Web Start" и думаю, что для C# есть что-то подобное. Чувствую, что корпорации вроде Google/Mozilla решили выйти на рынок настольных приложений обойдя все эти инновационные .NET, Cocoa, WPF, WindowsForms, GTK и прочие GUI Toolkit-ы и VM-ки предварительно выпилив из браузеров и даже из ОС потенциальных "конкурентов".

васм не может вызывать сам свой код

Не совсем понятно о чем тут речь? В языке нет eval или о чем идет речь? Нельзя создать буфер с байткодом и передать на него управление?

Архитектурно тут все очень безопасно.

Эту маркетинговую сказку рассказывает каждый производитель своего продукта, но смотрите сколько в тем же браузере было уязвимостей.

Просто непонятно зачем нужен браузер как Canvas для рисования или какие-то другие преимущества?

Общий вопрос почему веб заменяет десктопные приложения.
но скорее всего нужно будет писать промежуточный слой для того же GUI

Конечно. Хочешь в веб, надо поковыряться.

что для C# есть что-то подобное.

Ага, Блазор.
dotnet.microsoft.com/apps/aspnet/web-apps/blazor

Нельзя создать буфер с байткодом и передать на него управление?

Инициировать выполнение кода васм может только если его дёрнет js. Нельзя на васме породить какой-то новый процесс, вызвать самостоятельно какой-то метод. Кажется там байткод просто дергается через промисы. То есть сам свой байткод он не умеет вызывать без js.
Эту маркетинговую сказку рассказывает каждый производитель своего продукта, но смотрите сколько в тем же браузере было уязвимостей.


мм… ну мне нечего добавить, безопасность это эволюционный процесс, пока не долбанет, не пофиксишься. Есть еще репутация.
Вот Сафари ублюдки, они тормозят внедрение васма, они боятся потеряться рынок функционала, доступного только через приложения. С васмом можно видеопоток распознавать в браузере нейронками, кодировать видео, аудио, портировать игры. А у стора подгорает.

Общий вопрос почему веб заменяет десктопные приложения.

Экономический для компании не выгодно писать с нуля три приложения для Widnows, macOS и не дай бог ещё искать фанатиков писать приложение для Linux. Так вот и выходит, что можно взять и сделать что-то на электроне. Правда мне вот интетесно сравнивал ли затраты кто-то и действительно выходит дешевле?

Редко когда решают писать с нуля, а если есть кодовая база, то можно сделать запуск с использованием этих плюшек вроде Web Start. Хотя я уже далек от этих стеков и не знаю использует их кто-то сегодня.

Конечно. Хочешь в веб, надо поковыряться.

Это почти в каждой технологии. Думаю, что запуск через JNLP тоже будет для компании стоить денег, так как там возникнут какие-то свои требования и проблемы. Так что затраты будут при любом переходе. Бесплатный сыр только в мышеловке. Вопрос стоимости каждой "новой" технологии и ее потенциальных возможностей.

Вот Сафари ублюдки, они тормозят внедрение васма, они боятся потеряться рынок

Ну подождем и посмотрим как они прокомментирую ситуацию. Я думаю, что после того как они сделали Swift в догонку к Java, C# они теперь долго будут еще рассказывать о преимуществах своего изделия. В целом конечно WASM на мой взгляд хочет урвать рынок десктоп приложений как я понимаю и постепенно стать уравнивателем за счет своей аудитории пользователей браузеров. Движение любопытное, но почему-то вспоминаю ребят из QT, которые в свое время все это уже делали, а раньше пионером была Java с ее наш код работает везде. Просто интересно почему WASM считает, что именно у них это выйдет?

wasm ничего не считает, просто веб расширяет возможности, речь не только про одну кодовую базу но и удобство доставки обновлений.
Вариант работы с распознаванием жестов.
fingerspelling.xyz/game

Web Start — это вообще не про исполнение в браузере, это про скачивание и запуск.

Возможно это по какой-то причине для вас имеет какое-то очень важное значение (структура и компонентная модель той или иной технологии), но я тут говорю в целом о подходе. Подход скачать байт код и запустить в виртуальной машине вроде уже много раз предлагался рынку и Java, .NET, Macromedia, а позднее Adobe. В целом думаю, что это просто борьба технологических компаний, но меня в данном случае интеерсует не конкретная реализация (думаю что и через 20-30 лет будет какой-то новый пионер и так же задушит этот WebAssembly), а скорее ошибка технологических компаний и крупных игроков? Где они ошиблись создавая свои решения?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий