3D-рендеринг демки Zen Garden в браузере Firefox 52 c поддержкой WebAssembly
Mozilla выпустила Firefox 52, последнюю версию браузера с поддержкой операционной системы Windows XP. Сделан ряд важных изменений: упрощено подключение к хотспотам, где нужно сначала залогиниться в браузере, появились предупреждения об опасности, если страница запрашивает пароль по небезопасносму соединению (не HTTPS), исчезла поддержка плагинов NPAPI (кроме Flash, а в билде ESR останется полная поддержка), закрыто 28 уязвимостей.
Но ничто это не сравнится с главным и фундаментальным нововведением — поддержкой низкоуровневого языка программирования WebAssembly (wasm) типа ассемблера, который называют одной из самых значительных инноваций веб-платформы за последнее десятилетие. Это то, чего не хватало JavaScript.
WebAssembly
Разработчики объясняют, почему возникла необходимость в создании WebAssembly. Дело в том, что JavaScript был изначально задуман как легковесный язык для простеньких скриптов. Никто не предполагал, во что он разрастётся и как его начнут применять. Его придумали для новичков в программировании — для несложных вещей типа написать форму на веб-странице.
С тех пор многое изменилось. Современные веб-приложения — это сложные компьютерные программы с клиентским и серверным кодом, большая часть которого написана на JavaScript. Несмотря на прогресс в развитии самого JavaScript и все попытки разработчиков создать эффективные движки для быстрого выполнения JavaScript, ничего не вышло, это просто физически невозможно. У JavaScript есть неотъемлемые ограничения. Браузер просто не может выполнять этот код хотя бы примерно так быстро, как нативный код в операционной системе.
Mozilla первой созрела до разработки своеобразной виртуальной машины в браузере, где можно запускать низкоуровневый код — и несколько лет назад в качестве демонстрации выпустила asm.js (Google экспериментировала с Native Client API). Подъязык asm.js проявил себя настолько хорошо, что стало ясно: нужно объединять усилия со всеми крупнейшими компаниями-разработчиками для совместного проекта, который двинет веб вперёд.
Низкоуровневый язык WebAssembly может работать в связке с JavaScript и позволит веб-приложениям выполняться с гораздо большей производительностью — почти как нативные приложения в операционной системе.
Теперь в браузере можно запускать с высокой производительностью 3D-игры, системы автоматизированного проектирования (САПР), видеоредакторы, графические редакторы, научные визуализации, ресурсоёмкие вычисления, кодировать видео — что угодно.
Со временем многие существующие веб-приложения — почта, социальные сети, текстовые редакторы — и JavaScript-фреймворки с большой вероятностью начнут использовать WebAssembly, что существенно увеличит скорость загрузки и сильно увеличит их производительность во время работы.
В отличие от других подходов типа Flash, которые требуют установки плагина в браузере, чтобы выполнять приложения на скорости, сравнимой с нативными приложениями, WebAssembly полностью вписывается в стандартную веб-платформу. Это открытый и совместимый стандарт, интегрированный в браузеры. Значит, разработчики могут интегрировать библиотеки WebAssembly для CPU-интенсивных вычислений (компрессия, определение лиц, физика) прямо в существующие веб-приложения, где используется JavaScript.
WebAssembly — открытый стандарт, разработанный Mozilla, Google, Microsoft и Apple. Как можно заметить, эта группа представляет разработчиков четырёх наиболее распространённых браузеров, так что можно рассчитывать на становление wasm как всеобщего стандарта. Google обещает реализовать поддержку WebAssembly в следующей версии Chrome (57), Microsoft уже работает над реализацией в Edge.
Низкоуровневый язык станет своеобразным дополнением к JavaScript и в конце концов должен работать везде, где работает JS: во всех браузерах и во всех средах выполнения вроде Node.js.
Кто выиграет от использования WebAssembly? Речь идёт не только о написании новых приложений на wasm. Через компиляторы вроде Emscripten целые игры и уже готовые нативные приложения можно портировать для веба. Портируемый код C/C++ с помощью этого компилятора будет исполняться в браузере почти на той же скорости, что и нативное приложение. Кроме C/C++, для языка программирования Rust тоже реализована предварительная поддержка WebAssembly.
Для примера, можно поиграть в демку Zen Garden (требуется браузер Firefox 52, в данный момент поддерживается только десктопная версия).
Функции JavaScript будут вызывать функции WebAssembly и наоборот. То есть можно в рамках одной программы можно писать на высокоуровневом языке JavaScript и временами переходить на C/C++/Rust по мере необходимости.
Разработчики начнут распространять и повторно использовать низкоуровневые модули WebAssembly без необходимости разбираться в их устройстве, как они сейчас используют минифицированные библиотеки JavaScript.
Mozilla констатирует, что по уровню повторного использования кода и программной архитектуры стена между нативными и веб-приложениями начинает разрушаться, и это только начало. Инструменты разработчика, дебаггеры и компиляторы продолжат развиваться, также как совместимость, производительность и функциональность WebAssembly. Например, сейчас в плане Mozilla — реализовать поддержку многопоточности и параллелизма SIMD.
«В каком-то смысле WebAssembly меняет то, что значит веб-разработчиком, — пишет Дэвид Брайант (David Bryant), руководитель разработки платформ в Mozilla, — как меняет и фундаментальные свойства веба».
В самом деле, сейчас программы на C/C++ стало возможным портировать для выполнения в браузере, а в ближайшем будущем то же самое можно будет сделать для языков, на которых пишут мобильные приложения — Java, Swift, C#. Все они станут совместимыми со стандартной веб-платформой. Получается, что в каком-то смысле все программисты в итоге станут веб-разработчиками.
Комментарии (123)
SLY_G
08.03.2017 22:58+2Обновил Firefox до 52, но zen garden ругается, что требуется 52-я версия :(
Lertmind
09.03.2017 05:23Посмотрите в about:support строчку «Визуализатор WebGL2», должно быть написано «Google Inc. — ANGLE», иначе какие-нибудь ошибки, решение которых стоит поискать. Убедитесь, что эта опция включена: Настройки -> Дополнительные -> По возможности использовать аппаратное ускорение.
Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.rPman
09.03.2017 19:19+2Кстати, ошибка InvalidStateError — попытка запустить в приватном просмотре, нужен обычный.
что!?
это с какого фига веб приложение вообще зависит от способа сохранения приватных данных локально?Lertmind
10.03.2017 05:33+1Это из-за IndexedDB (MDN) — API для хранения данных/файлов, который работает в приватном режиме только в десктопном Chrome. Похоже, для этого необходимо хранение данных в ОЗУ и кто-то пытается реализовать это в Firefox: Bug 781982.
exfizik
10.03.2017 00:55У меня тоже не работало сначала, но вот это помогло:
откройте about:config, параметер javascript.options.wasm должен быть true.
stAndrew
12.03.2017 05:48У меня линуксовая версия Firefox 64 bit, в zen garden всё скачалось и скомпилировалось, поставило три галки и потом написало:
QuotaExceededError
TypeError: eventHandler.target is nullMad__Max
15.03.2017 23:06Видимо где-то лимит на использование памяти прописан маленький.
У меня тоже сначала вообще не заработало (тоже как и у SLY_G писало что старая версия браузера, хотя стоит 52 и пишет что доступных обновлений нет).
Вручную включил выставив javascript.options.wasm = true
Тогда стало загружаться, но на этапе компиляции (кстати хоть тут нормальная многопоточность — все 4 ядра работали) закончилось ошибкой
WebAssembly instantiation failed:
out of memory
Хотя в диспетчере задач смотрел — на пике браузер 1.5 Гб памяти использовал, т.е. это не общая нехватка, а где-то еще лимиты прописаны.
Focushift
08.03.2017 23:14Чем-то напоминает Silverlight, который из себя представлял библиотеку, которая выполнялась в браузере как обычное приложение и предоставляла для js кода доступ к своим переменным и т.п.
Denai
09.03.2017 02:37Почему представлял? Он до сих пор жив, игрушки на нём работают, например. В современной лисе его нет, но это же его не убило сразу
Areso
09.03.2017 05:59+2На минуточку, его доустанавливать надо было). И, если память не врет, не было возможности его использовать в Linux без бубна. С бубном получалось, но не у всех.
amarao
09.03.2017 12:36+5Вся проблема с silverlight состояла в том, что это не была часть существующего web'а. Это плагин, прямой конкурент флеша. Автор не сделал его под meego, maemo, tizen, foobaros, windows phone, ios, android, linux, windows, symbian, etc — всё, нет кросс-платформенности. А в браузере оно будет всюду. На всех платформах, которые могут показать браузер.
А открытый стандарт подразумевает, что это может сделать кто хочет, а не конкретный вендор, который «не хочет».
ideological
09.03.2017 01:31В отличие от других подходов типа Flash, которые требуют установки плагина в браузере..
А технологию Flash нельзя как-то встроить в браузер?
Всё резиновое, AS3 полноценный язык, игры 3D, анимация, видео, отображается везде одинаково и т.д.
Eklykti
09.03.2017 01:58+4А технологию Flash нельзя как-то встроить в браузер?
Нельзя, ибо собственность одной корпорации, а не открытый стандарт.
wlbm_onizuka
09.03.2017 10:13Я думаю сама корпорация очень хотела-бы, чтобы встроили. Только владельцы браузеров не хотя. И правильно делают
stychos
15.03.2017 23:29в хроме же так и сделано
ideological
16.03.2017 00:19Ага и это прекрасно.
По мне так технология Flash очень крутая, круче чем WebAssembly в разы. Очень жаль что Adobe не может договориться со всеми платформами или отпустить технологию в open source.stychos
16.03.2017 00:29+1Я совсем не разбираюсь во флеше, но так понимаю что отличие wasm в том, что он — стандарт, который могут/будут реализовывать все кто захочет, и на чём захочет, ну а флеш — это уже готовый инструмент, что налагает существенные ограничения.
brzsmg
17.03.2017 09:33+1Но Adobe Flash это пока отдельное нативное приложение как ни крути.
А веб-разработчики хотят полностью контролировать что происходит у них на странице.
Так же эта технология тащит за собой кучу проблем: Браузер не может контролировать чужой процесс. Многие баннеры сделанные на скорую руку, с утечками памяти. Cookies у flash свои. Новые дыры исправляются не синхронно, то есть браузер уже знает что есть важная дыра в безопасности, а Adobe еще только исправляет ее. Что в таком случае делать браузеру?
Вот если бы этот формат сделали открытым, можно было бы полноценно внедрить Adobe Flash в браузер, чтоб прямо из JS можно было обращаться к функциям Flash. А разработчики браузера сами бы имели возможность оперативно закрывать баги, до выхода официальных исправлений.
Сегодняшнее положение Adobe Flash скорее выглядит как «Не себе, не людям». Возможно Adobe еще верит в Apollo, где технологию Flash можно будет применять для создания Desktop приложений, но этот проект скорее мертв, чем жив.ideological
17.03.2017 10:35Спасибо за подробное пояснение.
Мне тоже хотелось бы чтобы это был открытый формат и надеюсь так и произойдет.
keydon2
09.03.2017 01:57Я не очень понимаю зачем и кому оно надо?
САПР в браузере? Перемалывать в браузере числа? Но ведь он не для этого делался. Браузер ж скорее тонкий клиент, все вычисления к серверу. Если нужно мгновенное включение, без установки, то почему бы не сделать отдельно экзешник портабельной версии, который по тому же http будет получать ресурсы? К тому же и пошустрее будут из нативного кода то, а не промежуточного. Даже для вебщиков вроде не должно быть проблем, сейчас же активно js под десктоп развивается.
Ну а игрушки в браузере — простые итак работают, сложным не место в браузере(да и простым в принципе тоже).
«Переиспользование нативного кода»? Да ведь его итак придется дорабатывать нехило+и раньше работало на asm.js, причем говорят пошустрее.
Зачем развивать новую технологию, заполнять браузер лишними мегабайтами еще одной ерунды, которая делает из хлеба троллейбус, да потом еще и поддерживать? Разве что гуглу хромбуки попиарить и ФФ с хромом за собой пользователей застолбить, ведь сторонним браузерам все тяжелее будет гнаться за монополистами.Eklykti
09.03.2017 02:01+2Браузер ж скорее тонкий клиент, все вычисления к серверу.
Хомячков много, серверов мало, если перенести часть вычислений на клиента, это разгрузит сервер и позволит делать больше интересных вещей.
alltiptop
09.03.2017 02:47+8Чему место в браузере а чему нет решает индустрия и экономика, а не разглагольствования о волшебном правильном мире. Задача разработчиков браузеров, серверов и стандартов — удовлетворять требованиям индустрии и предлагать новые пути развития в экономике, чем технология WebAssembly, возможно, и станет (предыдущие как java или flash закрыты и зависимы от компаний, поэтому их судьба была лишь долгими страданиями).
General_Failure
09.03.2017 05:25+2А чем вам не нравится САПР в браузере? Или, к примеру, фотошоп?
Тот же Adobe можно со временем перегнать свои творения в веб, что будет 100% защитой от крякания
Да и админам проще будет сервер с тем же САПРом поднять
А а кто может и кто не может пользоваться — настраивать в политиках, а не ставить каждому на комп
Даже удалённая установка — это время
Bonio
09.03.2017 06:48+1Как минимум, зависимостью от наличия Интернета и его качества. Программы такого уровня весят поболее страниц на пару сотен килобайт, а кто то до сих пор сидит на медленных каналах, типа adsl. Да и, я думаю, не особо удобно работать в одной вкладке, когда каждый пиксель пространства на счету, полноэкранный режим не вариант потому, что параллельно мне может быть нужно еще несколько программ или тот же браузер.
General_Failure
09.03.2017 11:19Наличие интернета (или локальной сети в случае использования в организации со своим сервантом и админом) обычно и так необходимо для общения с сервером лицензий
Ну а качество связи — нативный код думаю поменьше будет чем голый js, даже минимизированный
К тому же можно придумать варианты кэширования сборок
Правда, этим должны заняться не пользователи, а разработчики
И, думаю, лучше будет, если разработчики браузеров добавят фичи кэширования с настройками (например, запрет на автоматическое обновление кэша)staticlab
09.03.2017 11:48+1Вряд ли wasm-бинарники будут меньше системных бинарников по объёму. Кроме того, в wasm не предусмотрено механизма разделяемых библиотек, т.е., другими словами, все приложения будут компилироваться статически. Далее, если поставлять всё приложение единой сборкой, то при обновлении придётся перекачивать много данных. Придётся как-то дробить на модули.
Опять же, серьёзные приложения типа фотошопов-кадов определённо будут весить много, и кеша браузера на всё не хватит. Это тоже будет кушать трафик как пользователя, так и разработчика.
Наконец, ресурсоёмкие приложения (тот же фотошоп) вынуждены создавать в системе свои файлы подкачки, иначе им не хватит памяти.
Кажется, что здесь может помочь некоторый новый API, позволяющий сайтам создавать на компьютере свои защищённые файловые хранилища. Ещё один шаг к браузеру-ОС :)
Lsh
09.03.2017 12:44Ещё один шаг к браузеру-ОС
Вот! Чего бы не использовать уже существующую JVM, какую-нибудь.
Хоть в браузере, хоть вне его. Уже давно есть и изобретать ничего не надо.staticlab
09.03.2017 13:01Так как раз всякие джависты и дотнетчики кричат: "Не хотим писать на JS! Закапывайте его! Даёшь WebAssembly, чтобы мы могли компилять свои джавы для браузера!"
Lsh
09.03.2017 13:03А уже же есть всякие Ява-апплеты. Что с ними не так?
staticlab
09.03.2017 13:05+1Апплеты, помнится, люто тормозили и глючили при загрузке.
Lsh
09.03.2017 13:10Так и эта штука, я думаю, так сможет. =)
Можно было бы JVM с браузером таскать, например.
Все пишут, что этот wasm новая и крутая технология, но не покидает ощущение, что всё это уже было и было успешно закопано.
kAIST
09.03.2017 18:18+1Есть же ещё кэширование приложения. Сейчас делаю небольшой сервис, он прекрасно работает, когда отключают интернет. Нужно получить данные с сервера?! Пару килобайт json'а осилит даже медленный интернет.
Зато все работает на всех платформах, и не нужно ставить отдельное приложение, в котором ты будешь работать от силы пару минут в неделю.
DrPass
09.03.2017 05:53+6Нравится оно или нет, но реальность такова, что современный браузер — уже не тонкий клиент, а исполняющая среда. Одни приложения в браузер выгружают безмозглую оболочку, другие выгружают вполне тяжёлый клиентский интерфейс и какую-то бизнес-логику.
Почему не нативные приложения? Потому что нужна универсальность. Пользователям нужно, чтобы «зайти по ссылке с любого устройства и работало», владельцам приложений нужно, чтобы не разрабатывать отдельное приложение под каждую платформу и чтобы пользователи были довольны.
И вот сейчас всё это реализовано на некоем кошмарном уровне, который до сих пор по удобству, функциональности и производительности (как для пользователей, так и для разработчиков) не дотягивает до уровня десктопных клиент-серверных приложений VB/Delphi середины 1990-х. Т.е., минуточку, того, что было достигнуто четверть века назад. Целую эпоху в мерках ИТ. На оборудовании, на порядки уступающем по производительности современным наручным часам. Пора с этим что-то делать :)staticlab
09.03.2017 09:53Что же мешало сделать всё это раньше на обычном JS и канвасе, завоевав рынок первым?
DarthKotik
09.03.2017 11:25Производительность
staticlab
09.03.2017 11:27Для обычных интерфейсов канвасу и так хватает производительности. Просто разработчикам это не нужно.
Delics
09.03.2017 07:42+3Я не очень понимаю зачем и кому оно надо? САПР в браузере?
Если написанное в статье — правда*, то это нужно мне.
Чтобы написать для браузера свою специфичную строительную САПР. Причина — на локальных компьютерах сейчас просто зоопарк всяких файрволов, антивирусов, глюченных ОС (разных типов).
Решение перенести это всё в универсальный браузер (с установкой которого уже сами пользователи должны возиться) — логичное решение, которое давно витало в воздухе.
Не хватало только мощностей обработки данных в javascript.
* я пока ещё не разбирался, но надеюсь, что всё правда и что Chrome тоже такое поддерживает
anttoshka
09.03.2017 09:31А зачем вам нужна строительная САПР в браузере? Тот же Компас вполне работает себе на зоопарке компов.
Delics
09.03.2017 09:34+1Вы не поняли — я разработчик и собираюсь перенести в браузер свою разработку.
У меня, конечно, не AutoCAD и даже не Компас, но кое-какие пользователи имеются.
inkelyad
09.03.2017 10:54+2Если это все правда, то весь зоопарк файрволов и антивирусов начнет строчно учиться залезать прямо в браузеры, чтобы всю эту радость внутри браузера контролировать. В результате получится все то же самое, если не хуже.
Delics
09.03.2017 11:19Откуда такие выводы?
В браузере же изначально защищенная среда, в которой не удастся повредить чужие файлы.
Перенос программ в браузер никак не повлияет на безопасность данных на компьютере. Скорее наоборот, её повысит.
Т.к. сейчас всё регулируется сомнительными платными сертификатами, которые может купить любой.
А будет так, что как ни пытайся, а вне своей области памяти и данных — не вылезешь.
remzalp
10.03.2017 07:48Расскажите это касперскому, который Free.
Он уже встраивает свой сертификат в https трафик. Правда при этом установщик забыл добавить сертификат, которым это всё подписано, в доверенные корневые сертификаты.
Второй довод — в вики на оф сайте:
Как включить расширение Kaspersky Protection в браузерах Internet Explorer, Google Chrome, Mozilla Firefox
kekekeks
09.03.2017 12:26Снятие головной боли с установщиками, обновлениями, песочницами и переносимостью. Теперь это проблемы браузера.
ub9obe
09.03.2017 06:20-8WebAssembly это наверное хорошо, но работать надо в другую сторону:
(проверку буфера обмена мы делаем и если там пусто, пункты меню неактивны. а вот с пустой формы вырезается и копируется вполне отлично)
joker2k1
09.03.2017 10:12+3А теперь на нем пусть напишут флеш ) 100500 флеш-мувиков не должны кануть в лету! )
Jamdaze
09.03.2017 10:20+3Шел 2017 год а многопоточность всё ещё в плане.
sapper
09.03.2017 12:44+2Сделали же ещё в прошлом релизе, работает если руками включить и с ограниченным количеством плагинов
Jamdaze
09.03.2017 19:01Там была многопроцессность. Если я правильно помню, то там идея в том чтобы каждую вкладку обрабатывать в отдельном процессе. От этого ограничение в 1 поток на рендер 1 вкладки не пропадёт. Для наглядного сравнение запустите html5 игру в лисе и в хроме, посмотрите на загрузку цпу и на фпс в игре.
LESHIY_ODESSA
14.03.2017 23:03Firefox 48: многопроцессность (и как её включить)
browser.tabs.remote.autostart — true
browser.tabs.remote.force-enable — true
rise
09.03.2017 10:54+2Очень интересно, как из WebAssembly происходит доступ к выводу графики
staticlab
09.03.2017 11:32Судя по тому, что сейчас у WebAssembly ограниченный интерфейс взаимодействия с браузером, то пока что только через JS.
kekekeks
09.03.2017 12:27Отрисовать битмап какой-нибудь Skia и отправить байтмассивом в JS. А тот уже на канвасе нарисует.
Shishka
09.03.2017 13:12> как из WebAssembly происходит доступ к выводу графики
Еще документов через D3
pkirill
10.03.2017 00:56Никак, из webasm нету доступа ни к webgl, ни к webgl2. Там даже sin cos нет. Чтобы вызвать метод webgl надо вываливается в JS. Также нельзя там использовать ни WebGlTexture, ни WebGlProgram. Таким объектам надо присваивать индексы и хранить в JsArray. тянутся
Denkenmacht
09.03.2017 12:57+2А потом оно начнет в вэб-САПРе и фотошопе рекламу показывать на пол-экрана, потому что надо отбивать новую технологию.
После этого усталые парни с красными глазами в одинаковых корпоративных детских футболках нам объявят, что старые оси и слабое железо больше не поддерживаются новым супер-стандартом и всем надо сходить в магазин и купить новое, если в интернет хотим выходить.
И окончательно покончат с пиратским ПО — ведь они только ради этого всю эту затею пилят.Delics
09.03.2017 14:18+1Поэтому, пока не поздно, надо поддерживать хороших людей, делающих бесплатное или очень дешевое ПО.
А не говорить, допустим (я не про вас, но такое поведение часто встречается)
— у вас некрасивые кнопки в интерфейсе, я лучше Photoshop с торрентов бесплатно скачаю.
Потому как результат, действительно, немного предсказуем.
6opoDuJIo
09.03.2017 14:32Я не понимаю, что помешает скачать этот web-assembly, крякнуть и захостить локально на каком-нибудь IIS?
Denkenmacht
09.03.2017 14:35Проверка лицензий онлайн. Локально вы в нем скорее всего мало что запустите.
6opoDuJIo
12.03.2017 14:10Подобные механизмы когда-то мешали взламывать ПО?
Скачают, сломают, и будут хостить локально.
staticlab
09.03.2017 14:41Зависит от объёма серверной логики. Это может быть просто аутентификация и хранилище, а может и какая-то обработка. Условно, 3D-редактор может отправить сцену на рендер на ферме разработчика, а Фотошоп — попросить сервер сшить панораму.
bouncycastle
09.03.2017 14:24Как я понимаю WebAssembly для веба что-то вроде NDK для Android, верно?
staticlab
09.03.2017 14:32Да, типа того. Но на текущий момент, фактически, через wasm можно сделать только числодробительные функции. Никакие API браузера и HTML-элементы из wasm сейчас недоступны.
pkirill
10.03.2017 01:07Все верно. WebGL, WebAudio, Video, Network в WebAsm не доступны. Можно только складывать и умножать и писать в массив.
pkirill
10.03.2017 01:05Нет не верно. Например из NDK можно вызвать функции OpenGL напрямую, а из webAsm нельзя вызывать. В webasm можно вызвать метод на JavaScript (вывалиться назад из Webasm в JS), а уже из JS вызывать webGl.
kroketmonster
09.03.2017 14:31С каждым днем разработчики пытаются сделать из браузера полноценную ОС. Если ассембли взлетит то это будет прорыв на уровне AJAX
porn
09.03.2017 15:28Это всё хорошо, но с 52-й версии Firefox требует PulseAudio. А поддержку ALSA можно получить только собрав самому, указав
ac_add_options --enable-alsa
Alexey2005
09.03.2017 17:27Похоже, что от WebAssembly выигрывают только любители C++, т.к. пока нет никаких признаков того, чтоб в него компилировалось что-то другое — Python или Java, к примеру.
kekekeks
10.03.2017 01:14+2Мигель публично пообещал Mono портировать. Типа, после внесённых для поддержки нового эппловского байткода правок, это тривиальная задача.
DeadKnight
09.03.2017 19:29У меня одного последняя версия огненной лисы тормозит безбожно и память жрет как не в себя?
FibYar
09.03.2017 20:15У меня сама лиса работает шустро, но вот именно эта демка из статьи работает с ужасно низким фреймрейтом (на глаз около 10fps) на вполне себе неплохой конфигурации.
Mad__Max
15.03.2017 23:02Это еще раньше началось с 49 по наклонной.
32 битная версия уже на 5-7 тяжелых вкладках умудряется в 2 Гб лимит упереться и либо полностью повеситься либо в лучшем случае тащиться как удав по стекловате до перезапуска.
На некоторых сайтах просто вешается, хотя 47я и более ранние версии этот же сайт отображают без проблем.
64 битная еще более менее нормально работает — жрет много по сравнению с более ранними, но хоть подобных критических косяков нет
Сидел на стабильной 47й версии, но тут разрабы начали руки выкручивать вынуждая обновляться — одни из нужных плагинов после очередного обновления в 47й версии полностью перестал работать, потом криворукие веб-админы SoundCloud в скриптах какую-то совместимость поломали, что 47я больше не может музыку воспроизводить, хотя раньше без проблем работала. Еще на паре сайтов косяки вылезать стали, которых раньше не было (видимо тоже у админа что-то «улучшить» и обновить руки слишком сильно чесались)
tandzan
09.03.2017 20:30Решил освоить webassembly, полез в гугл, и знаете что? Будто вернулся во время ФИДО, модемов и всего этого самого. «Dark Ages», как говорит Страуструп. Более-менее вменяемая информация нашлась на MDN, но один из его CDN похоже лежит и некоторые ресурсы не грузятся. Почему так?
Maiami
10.03.2017 01:48+1Потому что wasm это лишь дальнейшее развитие идеи asm.js. Всё что работало для asm.js будет, на данный момент, работать для wasm
Поэтому ничего более сложного, чем уже есть на официальном сайте не требуется http://webassembly.org/getting-started/developers-guide/
nikolaynag
09.03.2017 22:50Все-таки webassembly — это платформо-независимый язык, так что на вычислительных задачах с настоящим нативным кодом, использующим все преимущества конкретной архитектуры, ему трудно будет тягаться.
Foror
10.03.2017 06:32Там JIT работает, так что еще вопрос, когда продукт массовый, а не компилируется под конкретный процессор.
herr_kaizer
10.03.2017 09:14Теперь майнить биткоины, создавать ботнеты и брутфорсить пароли на компьютерах клиентов станет еще проще!
Даешь проприетарщину в клиентский код браузеров!
Beholder
10.03.2017 10:59Что они сделали с рендером шрифтов в этой версии??? (Windows) Всё мутное. Что с Direct2D, что без, что вместе с MacType. Есть какие-нибудь настройки как вернуть всё обратно?
Beholder
10.03.2017 11:21Решение:
gfx.canvas.azure.backends = direct2d1.1,cairo gfx.content.azure.backends = direct2d1.1,cairo
(отключить там skia)
Ну и "аппаратное ускорение" отключать, само собой.
FDsagizi
10.03.2017 15:28+1Ура, наконец то! Теперь игры на Юнити и Unreal Engine можно будет просто конвертить в веб. Без плагинов!
Для тех кто в танке, тут основные плюсы такие,
* Не нужно компилировать — нужно только проверить wasm код в 25 раз быстрее запуск чем JS
* Ты точно знаешь с какой скоростью это будет работать
* меньший размер
Ждем теперь многопоточность и нативные вызовы GPU
Кстати теперь есть возможно писать в вебе код на С# — так как юнити конвертирует его в C++, а потом в wasm
vintage
10.03.2017 16:14> Не нужно компилировать
Нужно, wasm — это AST.
> Ты точно знаешь с какой скоростью это будет работать
Не знаешь — у всех устройства разные.FDsagizi
12.03.2017 11:39+1> Нужно, wasm — это AST.
его не нужно компилировать как JS. Там идет просто проверка и перегон в машинный код. Как я уже сказал, разница в 25 раз. Те если запустить большой проект — к примеру игру. То она секунд 10 просто переваривает JS а потом еще около минуты — его оптимизирует — на сколько я понимаю делает JIT.
wasm этого лешен, сами С++ компиляторы будут оптимизировать код — задача браузеров валидировать и исполнять.
> Не знаешь — у всех устройства разные.
То что время выполнения зависит от железа — ну это понятно.
Реч ведь о том, что JS может работать по разному на одинаковых машинах — в зависимости от того, где компилятор оптимизировал код, а где нет. Не говоря уже об разных компиляторах. У wasm такой проблемы нету, в разных браузерах, он будет работать всегда одинаково.staticlab
12.03.2017 12:33Строго говоря, у wasm тоже JIT. Его бинарный код не будет интерпретироваться. И это не нативный машинный код. Так что компиляция на стороне клиента всё-таки будет.Разумеется, это не должно занять много времени.
Mad__Max
15.03.2017 23:11его не нужно компилировать как JS. Там идет просто проверка и перегон в машинный код. Как я уже сказал, разница в 25 раз. Те если запустить большой проект — к примеру игру. То она секунд 10 просто переваривает JS а потом еще около минуты — его оптимизирует — на сколько я понимаю делает JIT.
wasm этого лешен, сами С++ компиляторы будут оптимизировать код — задача браузеров валидировать и исполнять.
Да ну, вот же выше демка с садом — wasm делает все тоже самое. Сначала прежде чем запуститься долго комплит загружая все ядра процессора при этом.
vintage
Наконец-то LISP захватит мир! ;-)