Comments 125
Наконец-то LISP захватит мир! ;-)
Обновил Firefox до 52, но zen garden ругается, что требуется 52-я версия :(
Есть ощущения что линуховой версии это не касается.
Посмотрите в about:support строчку «Визуализатор WebGL2», должно быть написано «Google Inc. — ANGLE», иначе какие-нибудь ошибки, решение которых стоит поискать. Убедитесь, что эта опция включена: Настройки -> Дополнительные -> По возможности использовать аппаратное ускорение.
Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.
Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.
Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.что!?
это с какого фига веб приложение вообще зависит от способа сохранения приватных данных локально?
Это из-за IndexedDB (MDN) — API для хранения данных/файлов, который работает в приватном режиме только в десктопном Chrome. Похоже, для этого необходимо хранение данных в ОЗУ и кто-то пытается реализовать это в Firefox: Bug 781982.
Тоже не работает.
У меня тоже не работало сначала, но вот это помогло:
откройте about:config, параметер javascript.options.wasm должен быть true.
откройте about:config, параметер javascript.options.wasm должен быть true.
У меня линуксовая версия Firefox 64 bit, в zen garden всё скачалось и скомпилировалось, поставило три галки и потом написало:
QuotaExceededError
TypeError: eventHandler.target is null
QuotaExceededError
TypeError: eventHandler.target is null
Видимо где-то лимит на использование памяти прописан маленький.
У меня тоже сначала вообще не заработало (тоже как и у SLY_G писало что старая версия браузера, хотя стоит 52 и пишет что доступных обновлений нет).
Вручную включил выставив javascript.options.wasm = true
Тогда стало загружаться, но на этапе компиляции (кстати хоть тут нормальная многопоточность — все 4 ядра работали) закончилось ошибкой
Хотя в диспетчере задач смотрел — на пике браузер 1.5 Гб памяти использовал, т.е. это не общая нехватка, а где-то еще лимиты прописаны.
У меня тоже сначала вообще не заработало (тоже как и у SLY_G писало что старая версия браузера, хотя стоит 52 и пишет что доступных обновлений нет).
Вручную включил выставив javascript.options.wasm = true
Тогда стало загружаться, но на этапе компиляции (кстати хоть тут нормальная многопоточность — все 4 ядра работали) закончилось ошибкой
WebAssembly instantiation failed:
out of memory
Хотя в диспетчере задач смотрел — на пике браузер 1.5 Гб памяти использовал, т.е. это не общая нехватка, а где-то еще лимиты прописаны.
Чем-то напоминает Silverlight, который из себя представлял библиотеку, которая выполнялась в браузере как обычное приложение и предоставляла для js кода доступ к своим переменным и т.п.
Почему представлял? Он до сих пор жив, игрушки на нём работают, например. В современной лисе его нет, но это же его не убило сразу
На минуточку, его доустанавливать надо было). И, если память не врет, не было возможности его использовать в Linux без бубна. С бубном получалось, но не у всех.
Вся проблема с silverlight состояла в том, что это не была часть существующего web'а. Это плагин, прямой конкурент флеша. Автор не сделал его под meego, maemo, tizen, foobaros, windows phone, ios, android, linux, windows, symbian, etc — всё, нет кросс-платформенности. А в браузере оно будет всюду. На всех платформах, которые могут показать браузер.
А открытый стандарт подразумевает, что это может сделать кто хочет, а не конкретный вендор, который «не хочет».
А открытый стандарт подразумевает, что это может сделать кто хочет, а не конкретный вендор, который «не хочет».
Наконец-то, свою долю популярности получат всякие хромОСы и другие.
UFO just landed and posted this here
В отличие от других подходов типа Flash, которые требуют установки плагина в браузере..
А технологию Flash нельзя как-то встроить в браузер?
Всё резиновое, AS3 полноценный язык, игры 3D, анимация, видео, отображается везде одинаково и т.д.
А технологию Flash нельзя как-то встроить в браузер?
Нельзя, ибо собственность одной корпорации, а не открытый стандарт.
Adobe хотят, но условия выставленные лисой и гуглом их не устраивают
UFO just landed and posted this here
Но Adobe Flash это пока отдельное нативное приложение как ни крути.
А веб-разработчики хотят полностью контролировать что происходит у них на странице.
Так же эта технология тащит за собой кучу проблем: Браузер не может контролировать чужой процесс. Многие баннеры сделанные на скорую руку, с утечками памяти. Cookies у flash свои. Новые дыры исправляются не синхронно, то есть браузер уже знает что есть важная дыра в безопасности, а Adobe еще только исправляет ее. Что в таком случае делать браузеру?
Вот если бы этот формат сделали открытым, можно было бы полноценно внедрить Adobe Flash в браузер, чтоб прямо из JS можно было обращаться к функциям Flash. А разработчики браузера сами бы имели возможность оперативно закрывать баги, до выхода официальных исправлений.
Сегодняшнее положение Adobe Flash скорее выглядит как «Не себе, не людям». Возможно Adobe еще верит в Apollo, где технологию Flash можно будет применять для создания Desktop приложений, но этот проект скорее мертв, чем жив.
А веб-разработчики хотят полностью контролировать что происходит у них на странице.
Так же эта технология тащит за собой кучу проблем: Браузер не может контролировать чужой процесс. Многие баннеры сделанные на скорую руку, с утечками памяти. Cookies у flash свои. Новые дыры исправляются не синхронно, то есть браузер уже знает что есть важная дыра в безопасности, а Adobe еще только исправляет ее. Что в таком случае делать браузеру?
Вот если бы этот формат сделали открытым, можно было бы полноценно внедрить Adobe Flash в браузер, чтоб прямо из JS можно было обращаться к функциям Flash. А разработчики браузера сами бы имели возможность оперативно закрывать баги, до выхода официальных исправлений.
Сегодняшнее положение Adobe Flash скорее выглядит как «Не себе, не людям». Возможно Adobe еще верит в Apollo, где технологию Flash можно будет применять для создания Desktop приложений, но этот проект скорее мертв, чем жив.
Спасибо за подробное пояснение.
Мне тоже хотелось бы чтобы это был открытый формат и надеюсь так и произойдет.
Мне тоже хотелось бы чтобы это был открытый формат и надеюсь так и произойдет.
В Хром же вроде он давно внедрен. Отдельного процесса для флеша не запускается. А обновляется он вместе с браузером, а не как отдельное приложение/плагин как в FireFox или I.E.
UFO just landed and posted this here
Почему вы так решили? И отдельный процесс у него есть (причем хром создает еще один, что бы весь браузер не упал в случае ошибки). И установлен он как плагин.
А вот и доказательства.
Хм, похоже был не прав. Значит он просто поставляется и обновляется вместе с браузером вместо того, чтобы использовать установленный в системе как делает FireFox или старая опера. Но по сути такой же плагин.
При обновлении флеша с get.adobe.com флеш для FireFox и других браузеров обновляется (и хранится он в одной из папок винды), а для Хрома нет — в хроме при проверке другая версия и загружаемая из другой папки. Зато хром сам его обновляет отдельно от установленного в системе.
При обновлении флеша с get.adobe.com флеш для FireFox и других браузеров обновляется (и хранится он в одной из папок винды), а для Хрома нет — в хроме при проверке другая версия и загружаемая из другой папки. Зато хром сам его обновляет отдельно от установленного в системе.
Я не очень понимаю зачем и кому оно надо?
САПР в браузере? Перемалывать в браузере числа? Но ведь он не для этого делался. Браузер ж скорее тонкий клиент, все вычисления к серверу. Если нужно мгновенное включение, без установки, то почему бы не сделать отдельно экзешник портабельной версии, который по тому же http будет получать ресурсы? К тому же и пошустрее будут из нативного кода то, а не промежуточного. Даже для вебщиков вроде не должно быть проблем, сейчас же активно js под десктоп развивается.
Ну а игрушки в браузере — простые итак работают, сложным не место в браузере(да и простым в принципе тоже).
«Переиспользование нативного кода»? Да ведь его итак придется дорабатывать нехило+и раньше работало на asm.js, причем говорят пошустрее.
Зачем развивать новую технологию, заполнять браузер лишними мегабайтами еще одной ерунды, которая делает из хлеба троллейбус, да потом еще и поддерживать? Разве что гуглу хромбуки попиарить и ФФ с хромом за собой пользователей застолбить, ведь сторонним браузерам все тяжелее будет гнаться за монополистами.
САПР в браузере? Перемалывать в браузере числа? Но ведь он не для этого делался. Браузер ж скорее тонкий клиент, все вычисления к серверу. Если нужно мгновенное включение, без установки, то почему бы не сделать отдельно экзешник портабельной версии, который по тому же http будет получать ресурсы? К тому же и пошустрее будут из нативного кода то, а не промежуточного. Даже для вебщиков вроде не должно быть проблем, сейчас же активно js под десктоп развивается.
Ну а игрушки в браузере — простые итак работают, сложным не место в браузере(да и простым в принципе тоже).
«Переиспользование нативного кода»? Да ведь его итак придется дорабатывать нехило+и раньше работало на asm.js, причем говорят пошустрее.
Зачем развивать новую технологию, заполнять браузер лишними мегабайтами еще одной ерунды, которая делает из хлеба троллейбус, да потом еще и поддерживать? Разве что гуглу хромбуки попиарить и ФФ с хромом за собой пользователей застолбить, ведь сторонним браузерам все тяжелее будет гнаться за монополистами.
Браузер ж скорее тонкий клиент, все вычисления к серверу.
Хомячков много, серверов мало, если перенести часть вычислений на клиента, это разгрузит сервер и позволит делать больше интересных вещей.
Чему место в браузере а чему нет решает индустрия и экономика, а не разглагольствования о волшебном правильном мире. Задача разработчиков браузеров, серверов и стандартов — удовлетворять требованиям индустрии и предлагать новые пути развития в экономике, чем технология WebAssembly, возможно, и станет (предыдущие как java или flash закрыты и зависимы от компаний, поэтому их судьба была лишь долгими страданиями).
А чем вам не нравится САПР в браузере? Или, к примеру, фотошоп?
Тот же Adobe можно со временем перегнать свои творения в веб, что будет 100% защитой от крякания
Да и админам проще будет сервер с тем же САПРом поднять
А а кто может и кто не может пользоваться — настраивать в политиках, а не ставить каждому на комп
Даже удалённая установка — это время
Тот же Adobe можно со временем перегнать свои творения в веб, что будет 100% защитой от крякания
Да и админам проще будет сервер с тем же САПРом поднять
А а кто может и кто не может пользоваться — настраивать в политиках, а не ставить каждому на комп
Даже удалённая установка — это время
Как минимум, зависимостью от наличия Интернета и его качества. Программы такого уровня весят поболее страниц на пару сотен килобайт, а кто то до сих пор сидит на медленных каналах, типа adsl. Да и, я думаю, не особо удобно работать в одной вкладке, когда каждый пиксель пространства на счету, полноэкранный режим не вариант потому, что параллельно мне может быть нужно еще несколько программ или тот же браузер.
Наличие интернета (или локальной сети в случае использования в организации со своим сервантом и админом) обычно и так необходимо для общения с сервером лицензий
Ну а качество связи — нативный код думаю поменьше будет чем голый js, даже минимизированный
К тому же можно придумать варианты кэширования сборок
Правда, этим должны заняться не пользователи, а разработчики
И, думаю, лучше будет, если разработчики браузеров добавят фичи кэширования с настройками (например, запрет на автоматическое обновление кэша)
Ну а качество связи — нативный код думаю поменьше будет чем голый js, даже минимизированный
К тому же можно придумать варианты кэширования сборок
Правда, этим должны заняться не пользователи, а разработчики
И, думаю, лучше будет, если разработчики браузеров добавят фичи кэширования с настройками (например, запрет на автоматическое обновление кэша)
UFO just landed and posted this here
Ещё один шаг к браузеру-ОС
Вот! Чего бы не использовать уже существующую JVM, какую-нибудь.
Хоть в браузере, хоть вне его. Уже давно есть и изобретать ничего не надо.
UFO just landed and posted this here
А уже же есть всякие Ява-апплеты. Что с ними не так?
Есть же ещё кэширование приложения. Сейчас делаю небольшой сервис, он прекрасно работает, когда отключают интернет. Нужно получить данные с сервера?! Пару килобайт json'а осилит даже медленный интернет.
Зато все работает на всех платформах, и не нужно ставить отдельное приложение, в котором ты будешь работать от силы пару минут в неделю.
Зато все работает на всех платформах, и не нужно ставить отдельное приложение, в котором ты будешь работать от силы пару минут в неделю.
Нравится оно или нет, но реальность такова, что современный браузер — уже не тонкий клиент, а исполняющая среда. Одни приложения в браузер выгружают безмозглую оболочку, другие выгружают вполне тяжёлый клиентский интерфейс и какую-то бизнес-логику.
Почему не нативные приложения? Потому что нужна универсальность. Пользователям нужно, чтобы «зайти по ссылке с любого устройства и работало», владельцам приложений нужно, чтобы не разрабатывать отдельное приложение под каждую платформу и чтобы пользователи были довольны.
И вот сейчас всё это реализовано на некоем кошмарном уровне, который до сих пор по удобству, функциональности и производительности (как для пользователей, так и для разработчиков) не дотягивает до уровня десктопных клиент-серверных приложений VB/Delphi середины 1990-х. Т.е., минуточку, того, что было достигнуто четверть века назад. Целую эпоху в мерках ИТ. На оборудовании, на порядки уступающем по производительности современным наручным часам. Пора с этим что-то делать :)
Почему не нативные приложения? Потому что нужна универсальность. Пользователям нужно, чтобы «зайти по ссылке с любого устройства и работало», владельцам приложений нужно, чтобы не разрабатывать отдельное приложение под каждую платформу и чтобы пользователи были довольны.
И вот сейчас всё это реализовано на некоем кошмарном уровне, который до сих пор по удобству, функциональности и производительности (как для пользователей, так и для разработчиков) не дотягивает до уровня десктопных клиент-серверных приложений VB/Delphi середины 1990-х. Т.е., минуточку, того, что было достигнуто четверть века назад. Целую эпоху в мерках ИТ. На оборудовании, на порядки уступающем по производительности современным наручным часам. Пора с этим что-то делать :)
UFO just landed and posted this here
А зачем вам нужна строительная САПР в браузере? Тот же Компас вполне работает себе на зоопарке компов.
Если это все правда, то весь зоопарк файрволов и антивирусов начнет строчно учиться залезать прямо в браузеры, чтобы всю эту радость внутри браузера контролировать. В результате получится все то же самое, если не хуже.
UFO just landed and posted this here
Ой, а то в браузерах дыр мало. А чем более развитая среда исполнения, тем удобнее эти дыры из неё эксплуатировать.
Расскажите это касперскому, который Free.
Он уже встраивает свой сертификат в https трафик. Правда при этом установщик забыл добавить сертификат, которым это всё подписано, в доверенные корневые сертификаты.
Второй довод — в вики на оф сайте:
Как включить расширение Kaspersky Protection в браузерах Internet Explorer, Google Chrome, Mozilla Firefox
Он уже встраивает свой сертификат в https трафик. Правда при этом установщик забыл добавить сертификат, которым это всё подписано, в доверенные корневые сертификаты.
Второй довод — в вики на оф сайте:
Как включить расширение Kaspersky Protection в браузерах Internet Explorer, Google Chrome, Mozilla Firefox
Снятие головной боли с установщиками, обновлениями, песочницами и переносимостью. Теперь это проблемы браузера.
WebAssembly это наверное хорошо, но работать надо в другую сторону:
(проверку буфера обмена мы делаем и если там пусто, пункты меню неактивны. а вот с пустой формы вырезается и копируется вполне отлично)
(проверку буфера обмена мы делаем и если там пусто, пункты меню неактивны. а вот с пустой формы вырезается и копируется вполне отлично)
А теперь на нем пусть напишут флеш ) 100500 флеш-мувиков не должны кануть в лету! )
Flash Умер, да здравствует Flash!
Шел 2017 год а многопоточность всё ещё в плане.
Сделали же ещё в прошлом релизе, работает если руками включить и с ограниченным количеством плагинов
Firefox 48: многопроцессность (и как её включить)
browser.tabs.remote.autostart — true
browser.tabs.remote.force-enable — true
browser.tabs.remote.autostart — true
browser.tabs.remote.force-enable — true
Очень интересно, как из WebAssembly происходит доступ к выводу графики
UFO just landed and posted this here
Отрисовать битмап какой-нибудь Skia и отправить байтмассивом в JS. А тот уже на канвасе нарисует.
> как из WebAssembly происходит доступ к выводу графики
Еще документов через D3
Еще документов через D3
Никак, из webasm нету доступа ни к webgl, ни к webgl2. Там даже sin cos нет. Чтобы вызвать метод webgl надо вываливается в JS. Также нельзя там использовать ни WebGlTexture, ни WebGlProgram. Таким объектам надо присваивать индексы и хранить в JsArray. тянутся
Начало конца эпохи JS?
Они убили Java! Сволочи!
А потом оно начнет в вэб-САПРе и фотошопе рекламу показывать на пол-экрана, потому что надо отбивать новую технологию.
После этого усталые парни с красными глазами в одинаковых корпоративных детских футболках нам объявят, что старые оси и слабое железо больше не поддерживаются новым супер-стандартом и всем надо сходить в магазин и купить новое, если в интернет хотим выходить.
И окончательно покончат с пиратским ПО — ведь они только ради этого всю эту затею пилят.
После этого усталые парни с красными глазами в одинаковых корпоративных детских футболках нам объявят, что старые оси и слабое железо больше не поддерживаются новым супер-стандартом и всем надо сходить в магазин и купить новое, если в интернет хотим выходить.
И окончательно покончат с пиратским ПО — ведь они только ради этого всю эту затею пилят.
Как я понимаю WebAssembly для веба что-то вроде NDK для Android, верно?
С каждым днем разработчики пытаются сделать из браузера полноценную ОС. Если ассембли взлетит то это будет прорыв на уровне AJAX
Это всё хорошо, но с 52-й версии Firefox требует PulseAudio. А поддержку ALSA можно получить только собрав самому, указав
ac_add_options --enable-alsa
Похоже, что от WebAssembly выигрывают только любители C++, т.к. пока нет никаких признаков того, чтоб в него компилировалось что-то другое — Python или Java, к примеру.
Мигель публично пообещал Mono портировать. Типа, после внесённых для поддержки нового эппловского байткода правок, это тривиальная задача.
У меня одного последняя версия огненной лисы тормозит безбожно и память жрет как не в себя?
У меня сама лиса работает шустро, но вот именно эта демка из статьи работает с ужасно низким фреймрейтом (на глаз около 10fps) на вполне себе неплохой конфигурации.
Память жрет как обычно, но тормозит жутко :(
Тормозит невыносимо, вкладки подвисают на несколько секунд, а то и минут
Это еще раньше началось с 49 по наклонной.
32 битная версия уже на 5-7 тяжелых вкладках умудряется в 2 Гб лимит упереться и либо полностью повеситься либо в лучшем случае тащиться как удав по стекловате до перезапуска.
На некоторых сайтах просто вешается, хотя 47я и более ранние версии этот же сайт отображают без проблем.
64 битная еще более менее нормально работает — жрет много по сравнению с более ранними, но хоть подобных критических косяков нет
Сидел на стабильной 47й версии, но тут разрабы начали руки выкручивать вынуждая обновляться — одни из нужных плагинов после очередного обновления в 47й версии полностью перестал работать, потом криворукие веб-админы SoundCloud в скриптах какую-то совместимость поломали, что 47я больше не может музыку воспроизводить, хотя раньше без проблем работала. Еще на паре сайтов косяки вылезать стали, которых раньше не было (видимо тоже у админа что-то «улучшить» и обновить руки слишком сильно чесались)
32 битная версия уже на 5-7 тяжелых вкладках умудряется в 2 Гб лимит упереться и либо полностью повеситься либо в лучшем случае тащиться как удав по стекловате до перезапуска.
На некоторых сайтах просто вешается, хотя 47я и более ранние версии этот же сайт отображают без проблем.
64 битная еще более менее нормально работает — жрет много по сравнению с более ранними, но хоть подобных критических косяков нет
Сидел на стабильной 47й версии, но тут разрабы начали руки выкручивать вынуждая обновляться — одни из нужных плагинов после очередного обновления в 47й версии полностью перестал работать, потом криворукие веб-админы SoundCloud в скриптах какую-то совместимость поломали, что 47я больше не может музыку воспроизводить, хотя раньше без проблем работала. Еще на паре сайтов косяки вылезать стали, которых раньше не было (видимо тоже у админа что-то «улучшить» и обновить руки слишком сильно чесались)
Решил освоить webassembly, полез в гугл, и знаете что? Будто вернулся во время ФИДО, модемов и всего этого самого. «Dark Ages», как говорит Страуструп. Более-менее вменяемая информация нашлась на MDN, но один из его CDN похоже лежит и некоторые ресурсы не грузятся. Почему так?
Потому что wasm это лишь дальнейшее развитие идеи asm.js. Всё что работало для asm.js будет, на данный момент, работать для wasm
Поэтому ничего более сложного, чем уже есть на официальном сайте не требуется http://webassembly.org/getting-started/developers-guide/
Поэтому ничего более сложного, чем уже есть на официальном сайте не требуется http://webassembly.org/getting-started/developers-guide/
Все-таки webassembly — это платформо-независимый язык, так что на вычислительных задачах с настоящим нативным кодом, использующим все преимущества конкретной архитектуры, ему трудно будет тягаться.
Теперь майнить биткоины, создавать ботнеты и брутфорсить пароли на компьютерах клиентов станет еще проще!
Даешь проприетарщину в клиентский код браузеров!
Даешь проприетарщину в клиентский код браузеров!
Что они сделали с рендером шрифтов в этой версии??? (Windows) Всё мутное. Что с Direct2D, что без, что вместе с MacType. Есть какие-нибудь настройки как вернуть всё обратно?
Ура, наконец то! Теперь игры на Юнити и Unreal Engine можно будет просто конвертить в веб. Без плагинов!
Для тех кто в танке, тут основные плюсы такие,
* Не нужно компилировать — нужно только проверить wasm код в 25 раз быстрее запуск чем JS
* Ты точно знаешь с какой скоростью это будет работать
* меньший размер
Ждем теперь многопоточность и нативные вызовы GPU
Кстати теперь есть возможно писать в вебе код на С# — так как юнити конвертирует его в C++, а потом в wasm
Для тех кто в танке, тут основные плюсы такие,
* Не нужно компилировать — нужно только проверить wasm код в 25 раз быстрее запуск чем JS
* Ты точно знаешь с какой скоростью это будет работать
* меньший размер
Ждем теперь многопоточность и нативные вызовы GPU
Кстати теперь есть возможно писать в вебе код на С# — так как юнити конвертирует его в C++, а потом в wasm
UFO just landed and posted this here
> Не нужно компилировать
Нужно, wasm — это AST.
> Ты точно знаешь с какой скоростью это будет работать
Не знаешь — у всех устройства разные.
Нужно, wasm — это AST.
> Ты точно знаешь с какой скоростью это будет работать
Не знаешь — у всех устройства разные.
> Нужно, wasm — это AST.
его не нужно компилировать как JS. Там идет просто проверка и перегон в машинный код. Как я уже сказал, разница в 25 раз. Те если запустить большой проект — к примеру игру. То она секунд 10 просто переваривает JS а потом еще около минуты — его оптимизирует — на сколько я понимаю делает JIT.
wasm этого лешен, сами С++ компиляторы будут оптимизировать код — задача браузеров валидировать и исполнять.
> Не знаешь — у всех устройства разные.
То что время выполнения зависит от железа — ну это понятно.
Реч ведь о том, что JS может работать по разному на одинаковых машинах — в зависимости от того, где компилятор оптимизировал код, а где нет. Не говоря уже об разных компиляторах. У wasm такой проблемы нету, в разных браузерах, он будет работать всегда одинаково.
его не нужно компилировать как JS. Там идет просто проверка и перегон в машинный код. Как я уже сказал, разница в 25 раз. Те если запустить большой проект — к примеру игру. То она секунд 10 просто переваривает JS а потом еще около минуты — его оптимизирует — на сколько я понимаю делает JIT.
wasm этого лешен, сами С++ компиляторы будут оптимизировать код — задача браузеров валидировать и исполнять.
> Не знаешь — у всех устройства разные.
То что время выполнения зависит от железа — ну это понятно.
Реч ведь о том, что JS может работать по разному на одинаковых машинах — в зависимости от того, где компилятор оптимизировал код, а где нет. Не говоря уже об разных компиляторах. У wasm такой проблемы нету, в разных браузерах, он будет работать всегда одинаково.
UFO just landed and posted this here
его не нужно компилировать как JS. Там идет просто проверка и перегон в машинный код. Как я уже сказал, разница в 25 раз. Те если запустить большой проект — к примеру игру. То она секунд 10 просто переваривает JS а потом еще около минуты — его оптимизирует — на сколько я понимаю делает JIT.
wasm этого лешен, сами С++ компиляторы будут оптимизировать код — задача браузеров валидировать и исполнять.
Да ну, вот же выше демка с садом — wasm делает все тоже самое. Сначала прежде чем запуститься долго комплит загружая все ядра процессора при этом.
Юнити давно умеет компилить в asm.js. Что, впрочем, не особо и помогает.
Sign up to leave a comment.
Вышел Firefox 52 c поддержкой WebAssembly