Комментарии 67
Google, Microsoft, Mozilla и несколько других людей
Карл Маркс и Фридрих Энгельс — это не четыре разных человека, а Слава КПСС — вообще не человек…
Хватит «вы» с большой буквы писать. Особенно с учётом того, что это вообще не к отдельному человеку обращение.
Бинарный asm.js?
Не совсем.
Вот тут объясняют почему создается новый стандарт:
https://github.com/WebAssembly/design/blob/master/FAQ.md#why-create-a-new-standard-when-there-is-already-asmjs
Если вкратце
1. wasm позволяет использовать бенефиты которые нельзя добиться от asm.js. А именно обойти AOT-компиляцию, и отсутствие asm.js оптимизаций.
2. Меньший размер бандла приложения(об этом кстати было в статье).
Аксель Раушмайер сегодня написал что wasm это посути способ доставки бинарного asm.js но ссылок на это я больше нигде не нашел.
Надо следить за развитием стандарта, и там уже будет предельно понятно как asm и wasm друг с другом будут взаимодейтсовать(и будут ли?).
Вот тут объясняют почему создается новый стандарт:
https://github.com/WebAssembly/design/blob/master/FAQ.md#why-create-a-new-standard-when-there-is-already-asmjs
Если вкратце
1. wasm позволяет использовать бенефиты которые нельзя добиться от asm.js. А именно обойти AOT-компиляцию, и отсутствие asm.js оптимизаций.
2. Меньший размер бандла приложения(об этом кстати было в статье).
Аксель Раушмайер сегодня написал что wasm это посути способ доставки бинарного asm.js но ссылок на это я больше нигде не нашел.
Надо следить за развитием стандарта, и там уже будет предельно понятно как asm и wasm друг с другом будут взаимодейтсовать(и будут ли?).
Очень интересно. Не подскажете где можно глянуть подробнее как это работает? Как я понял, это код, который исполняется самим браузером в каком-то низкоуровневом режиме? Или это именно бинарник, стартующий в параллельном с браузером процессе и браузер в нём считает тяжёлые части кода?
Вот наивные, они ещё не поняли, что JavaScript управляет этим миром.
А по делу, есть Roadmap? В сети не нашёл, может упустил что-то.
А по делу, есть Roadmap? В сети не нашёл, может упустил что-то.
Это что-то типа более портабельного, чем в llvm, байткода?
Батюшки… и 20 лет не прошло как додумались…
Моё, например, мнение состоит в том, что WA бесполезен by design.
Узкое место любого веб-приложения — скорость рендеринга. Да, конечно, в силу ограничений языка (некомпилируемый, слабо типизированный) код на JS будет проигрывать коду на asm-е в производительности, да только нет такой задачи в вебе. Никто не занимается тяжёлыми вычислениями на клиенте, кроме майнеров биткойнов да различных проектов полезного использования простаивающих ресурсов.
Любое приближенное к реальности приложение столкнётся в первую очередь с проблемой отображения большого количества данных (читай, дом-элементов) и скорости реакции браузера на действия пользователей. WA в этом поможет примерно никак, потому что тормозит в этом месте не js-код, а сам браузер, обрабатывающий «тяжёлые» страницы.
Узкое место любого веб-приложения — скорость рендеринга. Да, конечно, в силу ограничений языка (некомпилируемый, слабо типизированный) код на JS будет проигрывать коду на asm-е в производительности, да только нет такой задачи в вебе. Никто не занимается тяжёлыми вычислениями на клиенте, кроме майнеров биткойнов да различных проектов полезного использования простаивающих ресурсов.
Любое приближенное к реальности приложение столкнётся в первую очередь с проблемой отображения большого количества данных (читай, дом-элементов) и скорости реакции браузера на действия пользователей. WA в этом поможет примерно никак, потому что тормозит в этом месте не js-код, а сам браузер, обрабатывающий «тяжёлые» страницы.
Упреждая вопросы. На десктопе, где пишут на компилируемых статически типизированных языках, эта проблема не решена никак. Если попытаться сделать форму с таким же количеством визуальных компонент, как на обычной веб-странице, она тормозить будет гораздо круче исходной веб-страницы.
Всё это можно оптимизировать, да и из WA можно будет наверняка рендерить напрямую на какой-нибудь egl surface причем предварительно построив граф сцены и сделав так, чтобы долго считающиеся/рендерящиеся данные появлялись на экране по мере готовности, не блокируя основной тред отрисовки.
В общем, я думаю, что в прямых руках можно сделать так, чтобы веб страничка наконец-то работала и отображалась плавно, а не рывками, как сегодня.
В общем, я думаю, что в прямых руках можно сделать так, чтобы веб страничка наконец-то работала и отображалась плавно, а не рывками, как сегодня.
> Всё это можно оптимизировать, да и из WA можно будет наверняка рендерить напрямую на какой-нибудь egl surface причем предварительно построив граф сцены и сделав так, чтобы долго считающиеся/рендерящиеся данные появлялись на экране по мере готовности, не блокируя основной тред отрисовки.
В общем, я думаю, что в прямых руках можно сделать так, чтобы веб страничка наконец-то работала и отображалась плавно, а не рывками, как сегодня.
Так можно. Но что мешает браузеру это сделать прямо сейчас? Процесс рендеринга в JS не протащен никак от слова совсем, рендеринг полностью на совести браузера. Просто, ха-ха, рендеринг UI — дофига тяжёлая задача, которая в термины графических интерфейсов ложится примерно никак. Собственно, настольные приложения, работающие напрямую с видеокартой (читай, игры) обладают совершенно примитивным и недоразвитым UI, даже rich text в игрушке не встретить.
В общем, я думаю, что в прямых руках можно сделать так, чтобы веб страничка наконец-то работала и отображалась плавно, а не рывками, как сегодня.
Так можно. Но что мешает браузеру это сделать прямо сейчас? Процесс рендеринга в JS не протащен никак от слова совсем, рендеринг полностью на совести браузера. Просто, ха-ха, рендеринг UI — дофига тяжёлая задача, которая в термины графических интерфейсов ложится примерно никак. Собственно, настольные приложения, работающие напрямую с видеокартой (читай, игры) обладают совершенно примитивным и недоразвитым UI, даже rich text в игрушке не встретить.
А сложный UI в играх особенно то и не нужен. Но вообще забавно получается, что видеокарта может спокойно обрабатывать миллионы полигонов по 50 раз в секунду, но быть абсолютно бесполезной при рендеринге какого-нибудь сложноразмеченного текста.
Может в языках разметки проблема?
Может в языках разметки проблема?
Нет, проблема в том, что сложная разметка не параллелится. Положение и вид каждого глифа зависит от окружающих его глифов и миллиона сторонних причин, в отличие от видеоигр, где сцену можно описать простым и конечным набором примитивов.
Распараллелить можно что угодно, главное иметь желание. В данном случае глифы распределяются между n потоками, сначала рассчитываются габариты, как только все потоки отработали, мы знаем размеры каждого примитива, и дальше можно делать что угодно параллельно. А если все будет делаться с использованием неблокирующих структур данных, так вообще сказка.
Никто не занимается тяжёлыми вычислениями на клиентеНу, дык, видимо, теперь будут.
Ну, так как раз и хотят заниматься тяжелыми приложениями в браузере – в одной из статей говорится даже о риалтайм-приложениях, типа процессоров звуковых эффектов, обработка видео и т.д. С другой стороны, тот же Servo мозиловцы и делают с оглядкой на текущий медленный DOM, который изначально не был рассчитан на то, чтоб его модифицировали. Так что движение к быстрым веб-приложениям идет со всех сторон. Плюс, думаю, очень многих не устраивает медленная скорость обновления стандартов ES (включая доставку в браузеры) и у JS слишком много родовых травм, которые теперь надо оставлять для обратной совместимости.
> Ну, так как раз и хотят заниматься тяжелыми приложениями в браузере – в одной из статей говорится даже о риалтайм-приложениях, типа процессоров звуковых эффектов, обработка видео и т.д.
Процессоры звуковых эффектов давно есть (см. WebAudio, который, опять же, все вычисления скрывает внутри себя, на JS только интерфейсы к созданию фильтров). Обработка видео может быть, но это исчезающий кейс в онлайне.
Веб-приложение — оно, прежде всего, клиент-серверное. И главная проблема в вебе вотпрямщас — огромное количество скрытой под платформой магии типа reflow-repaint, garbage collector-а и прочей головной боли разработчика. Ахиллесова пята веб-платформы — тормоза и отзывчивость UI, вот что нужно ускорять-то. Любое сложное вычисление, если уж сильно хочется, можно на сервер отослать. Или насоздавать воркеров, чтобы компенсировать слабость интерпретируемого языка занятием пары дополнительных ядер.
> у JS слишком много родовых травм, которые теперь надо оставлять для обратной совместимости.
А поподробнее можно с этого места? Какие такие у JS родовые травмы?
Процессоры звуковых эффектов давно есть (см. WebAudio, который, опять же, все вычисления скрывает внутри себя, на JS только интерфейсы к созданию фильтров). Обработка видео может быть, но это исчезающий кейс в онлайне.
Веб-приложение — оно, прежде всего, клиент-серверное. И главная проблема в вебе вотпрямщас — огромное количество скрытой под платформой магии типа reflow-repaint, garbage collector-а и прочей головной боли разработчика. Ахиллесова пята веб-платформы — тормоза и отзывчивость UI, вот что нужно ускорять-то. Любое сложное вычисление, если уж сильно хочется, можно на сервер отослать. Или насоздавать воркеров, чтобы компенсировать слабость интерпретируемого языка занятием пары дополнительных ядер.
> у JS слишком много родовых травм, которые теперь надо оставлять для обратной совместимости.
А поподробнее можно с этого места? Какие такие у JS родовые травмы?
Ну и насчёт Серво. Основной его интент — это распараллелить всё что можно: парсинг HTML, применение CSS, вообще всё. Иными словами, Серво не оптимизирует исполнение JS просто потому, что Servo — layout engine, а в качестве JS-движка там внутри SpiderMonkey, и менять его они даже и не собираются (по крайней мере, год назад так говорили).
Итого, Серво демонстрирует ровно обратную мысль к тому, что вы пишете: нет смысла ускорять JS-движок, нужно ускорять браузер.
Итого, Серво демонстрирует ровно обратную мысль к тому, что вы пишете: нет смысла ускорять JS-движок, нужно ускорять браузер.
А я и не говорил, что Servo оптимизирует JS, перечитайте, пожалуйста, мой предыдущий комментарий. Про клиент-серверное приложение это конечно хорошо, только на дворе второе десятилетие 21 века и многим приложениям сервер нужен лишь в качестве хранилища, что уже и сейчас можно делать не только с сервером. Вы как-то не понимаете, что браузер стал сам по себе платформой, и сервер ему может и не нужен вовсе — ну, максимум загрузить код вам в бразуер. По поводу травм — да легко — int64.
> Никто не занимается тяжёлыми вычислениями на клиенте, кроме майнеров биткойнов да различных проектов полезного использования простаивающих ресурсов.
Игры на WebGL. Тут вам и тяжелые вычисления, и быстрый рендеринг. Самое очевидное предназначение, как по мне.
Игры на WebGL. Тут вам и тяжелые вычисления, и быстрый рендеринг. Самое очевидное предназначение, как по мне.
Ну так игры на WebGL и так на WebGL! То бишь шейдеры пишутся на C-подобном языке. Чего там можно ускорить на уровне замены JS другим языком?
WebGL и шейдеры это всего лишь рендеринг. При чем тут выполнение непосредственно кода? CPU в современных занимает не менее половины всего времени на кадр. И это на высокопроизводительных языках типа С++.
Один банальный пример — физика, которая по сути куча числодробительного матана, где нужно выжать *всё* из производительности, и, например, написанные вручную ассемблерные SIMD-вставки там не просто так, а уже необходимость. В итоге, на декстопах ни один современный игровой движок не поддерживает процессоры, которые не умеют SSE2. В то время как кодогенерация JS по большей части сейчас плетется где-то на уровне поддержки Intel 486DX. Без возможности использовать SIMD даже вручную (SIMD.js можно уже не учитывать).
Один банальный пример — физика, которая по сути куча числодробительного матана, где нужно выжать *всё* из производительности, и, например, написанные вручную ассемблерные SIMD-вставки там не просто так, а уже необходимость. В итоге, на декстопах ни один современный игровой движок не поддерживает процессоры, которые не умеют SSE2. В то время как кодогенерация JS по большей части сейчас плетется где-то на уровне поддержки Intel 486DX. Без возможности использовать SIMD даже вручную (SIMD.js можно уже не учитывать).
Господи, Хабр, да что с тобой? Когда думать стало немодным?
«Матан» исполняется так: программно задаётся набор объектов и их характеристики, тяжёлые расчёты выполняет спец. библиотека, опираясь на GPU или спец. комманды CPU. Абсолютно наплевать на каком языке задаются параметры — важно, на чём написан сам расчёт. И WebGL демонстрирует то же самое — абсолютно наплевать, на каком языке написана команда «загрузить текстуру в память» — важно, как имплементирована сама загрузка.
И веб-платформа в этом месте логична и проста: JS — управляющий язык. На нём пишутся скриптовые команды, что делать (манипуляция DOM-элементами, WebGL-шейдерами, применение криптографических алгоритмов, etc). А выполнение этих команд — на совести браузера, читай — C++ кода. Если приложение упирается в производительность JS — создаём новое API, в котором типовые задачи реализованы на C++, а в JS просто дырки до управляющих интерфейсов. Так сделано WebAudio, Web Animations, WebCrypto и хренова гора прочих новых спецификаций.
«Матан» исполняется так: программно задаётся набор объектов и их характеристики, тяжёлые расчёты выполняет спец. библиотека, опираясь на GPU или спец. комманды CPU. Абсолютно наплевать на каком языке задаются параметры — важно, на чём написан сам расчёт. И WebGL демонстрирует то же самое — абсолютно наплевать, на каком языке написана команда «загрузить текстуру в память» — важно, как имплементирована сама загрузка.
И веб-платформа в этом месте логична и проста: JS — управляющий язык. На нём пишутся скриптовые команды, что делать (манипуляция DOM-элементами, WebGL-шейдерами, применение криптографических алгоритмов, etc). А выполнение этих команд — на совести браузера, читай — C++ кода. Если приложение упирается в производительность JS — создаём новое API, в котором типовые задачи реализованы на C++, а в JS просто дырки до управляющих интерфейсов. Так сделано WebAudio, Web Animations, WebCrypto и хренова гора прочих новых спецификаций.
Понятия не имею, откуда вы взяли идею о использовании JS как управляющего языка. Нет. Я говорю именно про использование JS (или WebAssembly, в данном случае) для произведения самих расчетов. Да-да, вот берем и вычисляем физический матан силами JS-кода. Об этом же и в статье речь идет.
Вы же не станете предлагать все-все библиотеки на свете встраивать в браузер (чтобы они были в нативном коде) и делать к ним JS-интерфейс?
Вы же не станете предлагать все-все библиотеки на свете встраивать в браузер (чтобы они были в нативном коде) и делать к ним JS-интерфейс?
> Понятия не имею, откуда вы взяли идею о использовании JS как управляющего языка.
Да это как бы не я взял. Веб-платформа в этом направлении и развивается уже довольно долго.
> Вы же не станете предлагать все-все библиотеки мира встраивать в браузер (чтобы они были в нативном коде) и делать к ним JS-интерфейс?
Нет, не предлагаю.
Я только пишу, что WebAssembly типовых проблем веба не порешает. Никак.
Иметь возможность в браузере самому писать алгоритмы, в принципе, полезна. Но практически даром никому не нужна.
Да это как бы не я взял. Веб-платформа в этом направлении и развивается уже довольно долго.
> Вы же не станете предлагать все-все библиотеки мира встраивать в браузер (чтобы они были в нативном коде) и делать к ним JS-интерфейс?
Нет, не предлагаю.
Я только пишу, что WebAssembly типовых проблем веба не порешает. Никак.
Иметь возможность в браузере самому писать алгоритмы, в принципе, полезна. Но практически даром никому не нужна.
Поосторожнее с обобщениями. Вы видели, как работают растеризаторы томограмм в браузере? Там нужно показывать миллионы пикселей на каждом кадре, и выполнять сечения разными плоскостями в реальном времени. В играх есть много сложной математики, специфичной для каждой конкретной игры, которая должна вычисляться на клиенте. Уже сейчас множество приложений, которые до сих пор были возможны только на десктопе, переезжают в браузер. И это только начало.
Да, до этого JS действительно был не более чем управляющим языком. Но может, как раз потому, что его производительности заведомо не хватало для чего-то большего?..
Есть реальная задача — сделать производительную реалистичную 3D-физику в браузере. Какие сейчас есть способы это сделать? Верно, сейчас — никаких. Решит ли WebAssembly эту проблему? Да, решит. Я не знаю, как можно утверждать, что это не решает задачу.
«Типовая проблема» — довольно размытое понятие. Да, я совершенно согласен, что 99% веб-страниц WASM не поможет аж никак, и для них более актуально было бы ускорение, скажем, layout-движка. Но тем 1% страниц, которым WASM нужен — он действительно нужен.
Есть реальная задача — сделать производительную реалистичную 3D-физику в браузере. Какие сейчас есть способы это сделать? Верно, сейчас — никаких. Решит ли WebAssembly эту проблему? Да, решит. Я не знаю, как можно утверждать, что это не решает задачу.
«Типовая проблема» — довольно размытое понятие. Да, я совершенно согласен, что 99% веб-страниц WASM не поможет аж никак, и для них более актуально было бы ускорение, скажем, layout-движка. Но тем 1% страниц, которым WASM нужен — он действительно нужен.
>Иметь возможность в браузере самому писать алгоритмы, в принципе, полезна. Но практически даром никому не нужна.
Мне нужна. Кому платить?
Мне нужна. Кому платить?
Но практически даром никому не нужна.
Ха. Еще как нужна.
То фурье надо вычислить, то гравитацию посчитать для дофигалиона точек. JS-платформа легка для дистрибьюции в отличие от c++.
А вместо всего этого приходится городить кучу запросов-ответов на сервер, которые не смогут выполнить то что от них требуется в случае с играми — слишком долго.
Вы описываете каноническое применение скриптового языка. JS с этой задачей отлично справляется. Проблема с доставкой вашей реализации на C++ в браузеры пользователей.
Ждать, когда ваш юзкейс будет реализован в стандартных плагинах и доступен в большинстве установленных браузеров, можно очень долго. Заставлять пользователя устанавливать плагины, которые несут в себе ваш кастомный C++-код, это терять их большую долю. asm.js, как и wasm — это способ безопасно исполнять кастомный код в браузере, при этом с нулевым вовлечением пользователя.
Ждать, когда ваш юзкейс будет реализован в стандартных плагинах и доступен в большинстве установленных браузеров, можно очень долго. Заставлять пользователя устанавливать плагины, которые несут в себе ваш кастомный C++-код, это терять их большую долю. asm.js, как и wasm — это способ безопасно исполнять кастомный код в браузере, при этом с нулевым вовлечением пользователя.
И я совершенно с вами согласен!
Я только пытаюсь донести простую мысль, что типовые проблемы веб-разработки НЕ РЕШАТСЯ с помощью WebAssembly. Нетиповые задачи, как майнинг биткойнов — может быть. Ускорение работы и отзывчивости веб-страниц — нет. Нужно оптимизировать нижележащие алгоритмы и/или давать более полное управление из JS.
Я только пытаюсь донести простую мысль, что типовые проблемы веб-разработки НЕ РЕШАТСЯ с помощью WebAssembly. Нетиповые задачи, как майнинг биткойнов — может быть. Ускорение работы и отзывчивости веб-страниц — нет. Нужно оптимизировать нижележащие алгоритмы и/или давать более полное управление из JS.
*современных играх
JS — это такой Matlab для веба.
Никому почему-то не приходит в голову писать, что Matlab — плохой, негодный язык. Он же скриптовый! Со слабой типизацией! Некомпилируемый!
Да наплевать. Каждая строчка на Матлабе развернётся в миллион инструкций на asm-е, обрабатывающих гигабайты данных. Накладные расходы на сам язык Матлаб — ничтожны на этом фоне.
Никому почему-то не приходит в голову писать, что Matlab — плохой, негодный язык. Он же скриптовый! Со слабой типизацией! Некомпилируемый!
Да наплевать. Каждая строчка на Матлабе развернётся в миллион инструкций на asm-е, обрабатывающих гигабайты данных. Накладные расходы на сам язык Матлаб — ничтожны на этом фоне.
> Накладные расходы на сам язык Матлаб — ничтожны на этом фоне.
Ровно тогда, когда матлабовский скрипт не использует ничего, кроме встроенных функций, которые зачастую действительно реализованы в нативном коде. Как только же вам нужно сделать что-то нетривиальное руками — проще застрелиться, ибо производительность будет в сотни раз меньше, чем у аналогичного кода на С. Матлаб — прекрасная штука, но мне действительно приходилось несколько раз выносить тяжелые куски матлабовского скрипта в нативный код, ибо иначе ожидание становилось просто невыносимым.
Аналогичная проблема и с JS. Вот только в вебе *нет* никакой возможности вынести часть кода в нативную библиотеку. Увы.
Ровно тогда, когда матлабовский скрипт не использует ничего, кроме встроенных функций, которые зачастую действительно реализованы в нативном коде. Как только же вам нужно сделать что-то нетривиальное руками — проще застрелиться, ибо производительность будет в сотни раз меньше, чем у аналогичного кода на С. Матлаб — прекрасная штука, но мне действительно приходилось несколько раз выносить тяжелые куски матлабовского скрипта в нативный код, ибо иначе ожидание становилось просто невыносимым.
Аналогичная проблема и с JS. Вот только в вебе *нет* никакой возможности вынести часть кода в нативную библиотеку. Увы.
НЛО прилетело и опубликовало эту надпись здесь
Узкое место любого веб-приложения — скорость рендеринга.
Ws не решает проблемы рендеринга, он позволяет выполнять код быстро, когда это необходимо — например, в игре.
Любое приближенное к реальности приложение столкнётся в первую очередь с проблемой отображения большого количества данных
Любое? Мм, нет, например на странице вполне может быть всего один элемент с отображением видео, а вот у него уже на wasm-е написанные кишки.
Мне кажется, вы не совсем правильно понимаете смысла этого стандарта, он в первую очередь создается для того, чтобы в браузере работало то, что сейчас не работает (или работает плохо). А не для того, чтобы страницы быстрее работали.
Вам не кажется, что web все больше напоминает:
wget google.com | /bin/sh в песочнице
или на приложения для androind || iOS?
Почему сразу не пойти по этому пути?
wget google.com | /bin/sh в песочнице
или на приложения для androind || iOS?
Почему сразу не пойти по этому пути?
Улучшение для браузеров: Браузеры будут понимать бинарный формат ...
Ахахахаха!!! Т.е. мяу…
Держу пари, что даже те из Вас, которым посчастливилось работать с ДОС, не знают, что можно использовать “debug” для отладки ассемблера и диссасемблеризации (обратный инжиринг) существующего кодф
Пари ты проиграл ;)
Очень интересно наблюдать за развития информационных технологий… История таки развивается по спирали, на каждом витке дополняясь чем-то качественно новым.
Сначала были текстовые консольные интерфейсы.
Затем появились графические интерфейсы. Сначала — как вспомогательный режим, который нужно было запустить чтобы посмотреть картинку… после чего они поменялись местами, и теперь консоли — текстовые «окошки» в графическом окружении…
Затем браузеры. Сначала — просто одна из программ графического интерфейса. Со временем они становятся все более значимыми, и постепенно берут на себя функциональность рабочего стола как такового… И вот уже приложения, игры и даже трехмерная графика существует в браузерах, приложения пишутся на html и javascript (хотя еще недавно html — всего лишь язык разметки документов, а javascript — лишь средство создания надоедливых баннеров), появляются целые операционные системы, целиком основанные на браузере и javascript…
Вторая тенденция — виртуализация. В стародавние времена программисты работали напрямую с железом. Затем стали появляться драйверы устройств, API операционной системы, и только единственное устройство — процессор — оставалось доступно для программ напрямую. Но и здесь — Java, .NET, попытки абстрагироваться и от процессора тоже. Собственно, стоило ожидать что с Javascript произойдет что-то подобное, раз этот язык становится новым Си на новом витке развития технологий. Логично, что с помощью WebAssembly перешли от прямой интерпретации текста к виртуальному коду. Придет время — перейдут и к пре-компиляции в машинный код, как Гугл с Dalvik -> ART.
Сначала были текстовые консольные интерфейсы.
Затем появились графические интерфейсы. Сначала — как вспомогательный режим, который нужно было запустить чтобы посмотреть картинку… после чего они поменялись местами, и теперь консоли — текстовые «окошки» в графическом окружении…
Затем браузеры. Сначала — просто одна из программ графического интерфейса. Со временем они становятся все более значимыми, и постепенно берут на себя функциональность рабочего стола как такового… И вот уже приложения, игры и даже трехмерная графика существует в браузерах, приложения пишутся на html и javascript (хотя еще недавно html — всего лишь язык разметки документов, а javascript — лишь средство создания надоедливых баннеров), появляются целые операционные системы, целиком основанные на браузере и javascript…
Вторая тенденция — виртуализация. В стародавние времена программисты работали напрямую с железом. Затем стали появляться драйверы устройств, API операционной системы, и только единственное устройство — процессор — оставалось доступно для программ напрямую. Но и здесь — Java, .NET, попытки абстрагироваться и от процессора тоже. Собственно, стоило ожидать что с Javascript произойдет что-то подобное, раз этот язык становится новым Си на новом витке развития технологий. Логично, что с помощью WebAssembly перешли от прямой интерпретации текста к виртуальному коду. Придет время — перейдут и к пре-компиляции в машинный код, как Гугл с Dalvik -> ART.
Мечтаю о временах, когда можно будет заниматься веб-разработкой совсем без JavaScript
WebAssembly выглядит хорошим шагом в этом направлении
WebAssembly выглядит хорошим шагом в этом направлении
Ну ничего себе!? Они придумали ABC из Флеша!
Для тех, кто не в курсе:
Весь программный код у Flash — это ABC (ActionScript Byte Code) блоки, выполняющиеся в виртуальной машине. Она написана на С++.
Вы можете ругать Flash или же оставаться его поклонником, но разными способами и названиями разные компании пытаются повторить то же самое, но на JavaScript и ищут для этого свой формат.
Для тех, кто не в курсе:
Весь программный код у Flash — это ABC (ActionScript Byte Code) блоки, выполняющиеся в виртуальной машине. Она написана на С++.
Вы можете ругать Flash или же оставаться его поклонником, но разными способами и названиями разные компании пытаются повторить то же самое, но на JavaScript и ищут для этого свой формат.
хм. wasm.ru получает второе дыхание?
Держу пари, что даже те из Вас, которым посчастливилось работать с ДОС, не знают, что можно использовать “debug” для отладки ассемблера и диссасемблеризации (обратный инжиринг) существующего кода.
Ты проиграл.
Всё, конечно, интересно, но рассказать о новом языке (или его подвиде) без примеров — это сильно.
Хотя бы то, что есть.
Я бы хотел показать примеры, но их пока не особо много
Хотя бы то, что есть.
В статье совсем правильная вводная. Это не совсем новый язык, никто не будет писать на wasm
wasm это в первую очередь бинарный формат который должен заменить asm.js, с нормальной работой с памятью и т.д. Вы пишите код на любой языке который поддерживает LLVM, компилируете код в wasm и получившийся модуль подключаете как любой другой скрипт
По этому примеры не несут никакого особого смысла, всё что работало для asm.js, будет работать и для wasm
У wasm есть человеко читаемое представление, но и там смотреть особо не на что:
wasm это в первую очередь бинарный формат который должен заменить asm.js, с нормальной работой с памятью и т.д. Вы пишите код на любой языке который поддерживает LLVM, компилируете код в wasm и получившийся модуль подключаете как любой другой скрипт
По этому примеры не несут никакого особого смысла, всё что работало для asm.js, будет работать и для wasm
У wasm есть человеко читаемое представление, но и там смотреть особо не на что:
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WebAssembly: начало новой эры