Комментарии 58
Интересно, получится ли современные js движки и рендеры html просто превратить в обычные библиотеки с wasm кодом для совместимости с существующим кодом, а новые веб приложения делать каким угодно образом?
НЛО прилетело и опубликовало эту надпись здесь
Пожалуйста покажите исходный код Hello World которое можно было-бы запустить в браузере.Так же смогу ли я из С++ приложения манипулировать DOM — т.е. не значит ли это что скоро всякие Ангулары и JQuery уйдут прошлое и появится новое поколение более простых и удобных фреймворков.
Плюс такой вопрос — есть ли шансы, что скоро вместо HTML можно будет QML использовать?
Плюс такой вопрос — есть ли шансы, что скоро вместо HTML можно будет QML использовать?
1. Это переводная статья, и переводчики никому ничего не должны показывать :-)
2. Да, сможете делать в том числе и это, при должной поддержке разработчиками компиляторов. WebAssembly разрабатывается именно как целевая платформа для компиляции, т.е. разработчики LLVM или backend GCC должны будут поддерживать WebAssembly как еще одну платформу.
3. Вы какой именно QML имели в виду..?
2. Да, сможете делать в том числе и это, при должной поддержке разработчиками компиляторов. WebAssembly разрабатывается именно как целевая платформа для компиляции, т.е. разработчики LLVM или backend GCC должны будут поддерживать WebAssembly как еще одну платформу.
3. Вы какой именно QML имели в виду..?
urho3d.github.io/HTML5-samples.html (чтобы мышь захватывалась примеры нужно развернуть на весь экран)
Исходный код: github.com/urho3d/Urho3D
Исходный код: github.com/urho3d/Urho3D
Пожалуйста покажите исходный код Hello World
Самый обычный Hello World, ничего лишнего. Только браузера подходящего пока нет :)
Flash умер, да здравствует кусок бинарного говна Flash!
И до вэба проклятые ироды добрались.
И до вэба проклятые ироды добрались.
Не-не, флеш был закрытый, внешний по отношению к браузеру и неконтролируемый. А WebAssembly — бегает внутри браузера (быстро), безопасный, работает с тем же HTML5, а не строит свои велосипеды.
Дело совершенно не в том, закрытый или открытый по отношению к браузеру. А в том, что эта хрень будет закрыта по отношению к пользователю.
Попробуйте-ка из бинаря рекламу вырезать, например.
Попробуйте-ка из бинаря рекламу вырезать, например.
С чего бы это? Она будет строить DOM-дерево, которое можно проинспектировать или изменить инструментами разработчика в браузере. Более того, разработчики браузеров вполне могут дать и возможность отладки WebAssembly (точки останова, трейсы, пошаговое выполнение). Что им мешает? Формат же полностью открыт и именно браузер его выполняет.
Ассемблер и бинарный формат инструкций процессора тоже ни для кого не секрет. Однако попробуйте пореверсить какой-нибудь более менее большой проект.
Всё делается ради того, чтобы закрыть свой код от посторонних глаз. А аргументы могут быть самые разные: скорость, безопасность и так далее.
Всё делается ради того, чтобы закрыть свой код от посторонних глаз. А аргументы могут быть самые разные: скорость, безопасность и так далее.
Ну мне кажется популярные вещи (типа jQuery и Angular) сразу выпустят бинарники своих либ с исходниками и файлами символов, что сделает отладку тривиальной. Что касается остальных — хм… я даже не знаю, а какой-такой хитрый закрытый код может бежать в браузере, учитывая что всё, что он может — менять UI на страничке правками DOM-дерева?
А вам лично чем это поможет, что вы так за эту технологию обрадовались? Скорость, как правильно пишут ниже, не особо изменится. Затык в другом месте. Отладка пусть чуть-чуть, но станет геморнее (надо добывать дебаг символы теперь). Где профит-то?
Серьёзно? А скажите мне, как соотносится с DOM набор пикселей внутри canvas? Или видео/звук из media?
И это всё не упоминая о привычке разработчиков считать своё приложение уникальным и единственным, и претендовать на 100% ресурсов пользователя. После чего рушить браузер при 50 открытых вкладках.
И это всё не упоминая о привычке разработчиков считать своё приложение уникальным и единственным, и претендовать на 100% ресурсов пользователя. После чего рушить браузер при 50 открытых вкладках.
ничего не мешает повесить браузер/вкладку из javascript while (true) {} и вперед, в чем проблема?
для webAssebly сразу делаю восстанавливалку кода из бинарного формата
для webAssebly сразу делаю восстанавливалку кода из бинарного формата
Как я и говорил — у WebAssembley будут те же права и возможности, что и у javaScript, просто работать он будет быстрее. Как в JS вы можете работать с DOM или рисовать по canvas — так и там сможете, просто отрисовка какой-нибудь HD-сцены из пары текстур уже сможет работать на 50 fps, а не на 10 fps.
Я не вижу принципиальной разницы между WebAssembly и минифицированным JS. Оба закрыты на одном уровне, из обоих одинаково сложно вырезать рекламу. И вырезать её всё равно будут не из них, а из построенного ими DOM.
Смотрите на два шага вперед. Сначала вам сделают бинарный JS. Потом скажут: а нафига эта свистопляска с DOM? Пусть браузер тупо исполняет код и рисует в экран. Жаба-аплеты помните? То, что не удалось тогда Sun, потому что у них не было своего браузера, сейчас на ваших глазах сделает Google сотоварищи. Только следите за руками.
Свистопляска с DOM нужна пока, чтобы кормить миллионы дизайнеров и верстальщиков :) А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее. А вот провалидировать ввод регэксиком, сделать HTTP-запрос, распарсить JSON, как-то данные эффективно в памяти разложить и быстро искать — на С++ будет реактивно и приятно.
А в чем тогда преимущество по скорости? Ведь в браузере уже давным давно тормозит не JS, а DOM. Какая разница чем вы будете манипулировать DOM (хоть Ассемблером), ведь он сам является узким местом.
НЛО прилетело и опубликовало эту надпись здесь
Декларируемая цель — да. А так: посмотрите, во что превратился ACPI из декларируемой цели сделать управление питанием простым и легким. Понимаю, что это далеко от вэб-разботки и гораздо ниже уровнем, но аналогия, как мне кажется, очень хорошая и показательная.
Кроме того, ответ на вопрос предыдущего оратора в чем преимущество по скорости так и не дан. А если не скорость, то ради чего это всё?
Кроме того, ответ на вопрос предыдущего оратора в чем преимущество по скорости так и не дан. А если не скорость, то ради чего это всё?
Ну представьте какую-нибудь игрушку в браузере. У неё некоторая часть нагрузки — это физический движок, который до этого надо было писать на Javascript и он тормозил, к примеру, для рассчета какого-нибудь там взрыва\дыма\блика\дождя. Теперь код рассчёта физики будет можно написать на С++, ну а отрисовывать как раньше — по канвасу (который тоже уже через DirectX рисуется с ускорением). Прикиньте — какое-нибудь там GTA в браузере будет работать, ну потому что нет никаких больше причин, почему бы оно не работало.
Вы либо путаете тёплое с мягким, либо путаетесь в показаниях.
Если речь идет о неком бинарном intermediate language, чем мне представляется WebAssembly из того, что я прочитал, то там должно быть всё равно на чём писать. Вы будуте ограничены наименьшим из возможностей языка и возможностей WebAssembly. Таким образом, никаких преимуществ кроме вкусовщины вы не получите.
Если речь идет о неком бинарном intermediate language, чем мне представляется WebAssembly из того, что я прочитал, то там должно быть всё равно на чём писать. Вы будуте ограничены наименьшим из возможностей языка и возможностей WebAssembly. Таким образом, никаких преимуществ кроме вкусовщины вы не получите.
Там и есть всё-равно на чём писать, просто писать будут на С\С++ :) Преимущества получаются от того, что это будет бинарный код, уже собранный под нужную архитектуру проца. И не надо тратить время на парсинг и интерпретацию javascript. Плюс можно делать такие прикольные штуки как реалтайм обработка видео, таймеры с точностью до сотен наносекунд, какой-нибудь массивчик на миллиард элементов в словаре и т.д. — попробуйте это на javascript написать.
Я ничего не понимаю. С какого рожна вэб-разрабы вдруг возьмуться за C++? А главное зачем, если то же самое можно написать на знакомом им JS, скомпилировать и вперде?
Нет абсолютно никакого спроса на разработку вэб-логики на C++. Если оставаться в рамках вэб-логики.
Нет абсолютно никакого спроса на разработку вэб-логики на C++. Если оставаться в рамках вэб-логики.
Так они и будут писать на «знакомом JS» — в смысле всякие «обычные» сайты. Просто те библиотеки, которые они сейчас используют (jQuery, Angular) будут переписаны на WebAssembly и начнут работать в разы больше. Но интерфейс у них останется тот же. Плюс добавляется возможность написать и «необычный сайт» — игрушку типа флешевой, презентацию, веб-редактор видео и т.д. — массивная логика больше не будет тормозить из-за неэффективности Javascript.
Прочитал ваш измененный камент. Скажите, а вы сами разработчик? Как у вас в одном абзаце уживаются слова: «Там и есть всё-равно на чём писать» и «попробуйте это на javascript написать»?
«Там и есть всё-равно на чём писать»
Код можно будет написать на любом языке, для которого будет создан компилятор в WebAssembly. Первым появится компилятор для С\С++ (потому что LLVM его уже пилят), но потом, возможно, будут и другие.
попробуйте это на javascript написать
Имелось в виду «попробуйте это написать сейчас на javascript, выполняющемся в браузере без WebAssembly» — работать будет очень медленно.
Код можно будет написать на любом языке, для которого будет создан компилятор в WebAssembly. Первым появится компилятор для С\С++ (потому что LLVM его уже пилят), но потом, возможно, будут и другие.Вообще как я понял emscripten занимается не компиляцией C/C++ в JS. Он занимается трансляцией LLVM биткода в JS, соответственно в WebAssembly можно скомпилировать любой язык, поддерживаемый LLVM. Уже можно. Но в статье почему‐то говорится только о C/C++.
Если я прав, то, соответственно, писать компиляторы в WebAssembly практически не будут. Будут в первую очередь писать компиляторы в LLVM биткод.
Такой длинный спор и в качестве профита — пример в виде переписанного jQuery / Angular. Ну перепишут (ли? — прямо таки огромным «ли?») и будет работать на миллисекунду в секунду быстрее, но тормозить же все равно будет отрисовка. В большинстве случаев проблема в неэффективном использовании операций работы с DOM, что вызывают лишние перерисовки, перерасчеты размеров, положения элементов на странице и т.п., а не скорость работы с JS. Вот работа с аудио, видео, игродев и прочее — вот здесь профит может быть куда ощутимее.
А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее.
Дооо! Видимо от того, как быстро, гибко и красиво можно наструячить под HTML+CSS к каждому первому большому сайту теперь есть свой апп под iOS и Android. Следующий ход: сделать апп под браузер. Следующий ход избавится от отдельных аппов под мобильные платформы, превратив вэб в сплошные закрытые аппы.
А в широком смысле слова — вы на С++ не нарисуете интерфейс настолько быстро и красиво, как на HTML+CSS. Ну, вернее, может и красивее нарисуете, но точно не быстрее.Почему быстрее не получится, расскажите?
Потому, что многие штуки из HTML+CSS просто не реализованы пока достаточно хорошо даже в мощных UI-фреймворках типа Qt и их придётся писать руками. А даже если реализованы — вы программистов на таком уровне знающих QML и всякие кутешные стили не найдёте даже 1% от количества дизайнеров и верстальщиков, знающих HTML+CSS.
Потому, что многие штуки из HTML+CSS просто не реализованы пока достаточно хорошо даже в мощных UI-фреймворках типа Qt и их придётся писать руками.Какие штуки? Можно хоть пару примеров?
А даже если реализованы — вы программистов на таком уровне знающих QML и всякие кутешные стили не найдёте даже 1% от количества дизайнеров и верстальщиков, знающих HTML+CSS.Там для качественной верстки порог вхождения на порядок ниже, так что вопрос с количеством решится очень быстро, тем более что логика в QML и так пишется на JS.
Потом скажут: а нафига эта свистопляска с DOM? Пусть браузер тупо исполняет код и рисует в экран.И это будет просто шикарно, это я вам как QML разработчик говорю. Нельзя вырезать рекламу? Ну из мобильных приложений тоже нельзя, живем же как-то.
Шикарно? Ну сиюминутную выгоду в том, что вы, я и ещё 100 тысяч девелоперов внезапно станут востребованными на рынке вэб-разработки, получим. Но как быть с тем, что 7 млдр. людей (в том числе и мы с вами) получат очередной анальный зонд?
Мне кажется, вы неправильно трактуете термин «зонд». Еще раз: проблема только в том, что рекламу нельзя вырезать, верно?
Нет, реклама — это только самое первое и самое безобидное, что приходит на ум. В перспективе вы получите андроид или айос. Да, будет умерено безопасный браузер. Да, будут приложения с разными правами и браузер будет контролировать, чтобы они эти права не превышали. Но будет юзер, который будет собственноручно и слепо выдавать права приложениям, не имея в сущности возможности проверить на сколько добросовестно приложение этими правами пользуется. И только не надо в этом месте рассказывать про юзера, который сам себе злобный буратино, потому что у него не будет другой альтернативы.
Какие права? Как была песочница в браузере, так и останется.
Это то, что вам сейчас обещают. Так было в своё время с ACPI, когда всем сунули открытую спецификацию и сказали: нафига ОС знать много подробностей об управлении питанием? Давайте сделаем AML, который будет хранится в BIOS, а в ОС будет интерпретатором этого кода.
Что имеем теперь? Теперь в каждом PC процессор иногда входит в System Management Mode. Ни ОС, ни кто-либо другой не может ни предсказать, когда это случается, ни посмотреть что за код исполняется в этот момент, потому что этот код закрыт даже от ОС (даже в бинарном виде). Потом к этому добавили UEFI и Management Engine, который также связан с этой фигней. Его работа является одним из самым больших секретов корпорации Intel (у AMD свой не менее секретный аналог). Даже разработчики BIOS'ов получают от Intel кусок бинарного говна, который они обязаны включить в свой BIOS и всё. Никаких сведений.
А всё начиналось так безобидно.
Что имеем теперь? Теперь в каждом PC процессор иногда входит в System Management Mode. Ни ОС, ни кто-либо другой не может ни предсказать, когда это случается, ни посмотреть что за код исполняется в этот момент, потому что этот код закрыт даже от ОС (даже в бинарном виде). Потом к этому добавили UEFI и Management Engine, который также связан с этой фигней. Его работа является одним из самым больших секретов корпорации Intel (у AMD свой не менее секретный аналог). Даже разработчики BIOS'ов получают от Intel кусок бинарного говна, который они обязаны включить в свой BIOS и всё. Никаких сведений.
А всё начиналось так безобидно.
Приложения, работающие на WebAssembly будут иметь те же права, которые сейчас имеет javascript в браузере. И так же, как javascript, их выполнение можно будет отключить. Ничего с этой точки зрения не поменяется.
Это конечно все круто и быстро. У меня только один вопрос на сколько это будет безопасно?
Давайте так я пишу на C++ под браузер, у меня есть указатель на адрес в памяти и я могу в теории, обратится к любому участку памяти текущего процесса, я бы не считал это особо безопасным. Можно таких дел натворить.
Давайте так я пишу на C++ под браузер, у меня есть указатель на адрес в памяти и я могу в теории, обратится к любому участку памяти текущего процесса, я бы не считал это особо безопасным. Можно таких дел натворить.
Вы и сейчас можете писать на C++ под браузер и переводить это через emscripten в asm.js. Это безопасно?
WebAssembly исполняется в виртуальной машине. Он будет ровно настолько безопасным, насколько безопасной будет виртуальная машина: т.е. никаких отличий от текущего статуса с JavaScript, за исключением новизны и, как следствие, наличия пока не обнаруженных ошибок. От используемого языка безопасность не зависит совершенно; хотя на C++ вы будете иметь все шансы обратиться куда‐то не туда, это «куда‐то» может вести только в память машины.
И, кстати, про безопасность написано прямо в README WebAssembly:
WebAssembly исполняется в виртуальной машине. Он будет ровно настолько безопасным, насколько безопасной будет виртуальная машина: т.е. никаких отличий от текущего статуса с JavaScript, за исключением новизны и, как следствие, наличия пока не обнаруженных ошибок. От используемого языка безопасность не зависит совершенно; хотя на C++ вы будете иметь все шансы обратиться куда‐то не туда, это «куда‐то» может вести только в память машины.
И, кстати, про безопасность написано прямо в README WebAssembly:
WebAssembly is safe: WebAssembly describes a memory-safe, sandboxed execution environment that may even be implemented inside existing JavaScript virtual machines. When embedded in the web, WebAssembly will enforce the same-origin and permissions security policies of the browser.
Спасибо за объяснение.
Код компилируется более предсказуемо с точки зрения безопасности из js нежели из c++. И всяких дыр там будет хватать, ладно пока в действии не увидишь, не узнаем, но будущие туманно.
Код компилируется более предсказуемо с точки зрения безопасности из js нежели из c++. И всяких дыр там будет хватать, ладно пока в действии не увидишь, не узнаем, но будущие туманно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Компилируем С\С++ код в WebAssembly