Пробуем делать web-frontend на Rust (WebAssembly)

    Недавно вышла новость про то, что webassembly теперь включен в firefox 52 из коробки. А потом еще и chrome 57 подтянулся (правда, там вроде бы были какие-то баги с запуском). Я решил, что обязательно надо попробовать.


    Для тех, кто не знает, что такое webassembly краткая информация: webassembly (или wasm) — это низкоуровневый язык, который понимают браузеры, и в который можно будет скомпилировать программы, написанные на популярных языках. Это гораздо более выгодно по скорости парсинга и выполнения, чем компилировать эти языки в чистый javascript или какой-нибудь asm.js.


    Wasm задумывался в основном для c/c++, но, на удивление, уже все готово, чтобы скомпилировать программу на rust. Давайте сделаем небольшое приложение и посмотрим, что получится. Все это будем компилировать на Ubuntu. Без теоретических деталей, просто "пощупаем".


    Устанавливаем Rust и emscripten SDK


    Для начала нам понадобится rustup. Это инструмент для установки как самого rust компилятора, так и других вещей из rust мира.


    curl https://sh.rustup.rs -sSf | sh

    При установке в ваш ~.profile будет прописан путь до бинарников cargo, но чтобы не перелогиниваться прямо сейчас, можно просто выполнить команду source $HOME/.cargo/env.


    Теперь нам надо добавить нужный target


    rustup install stable
    rustup default stable
    rustup target add wasm32-unknown-emscripten

    emscripten — это такой LLVM-to-javascript компилятор. Также умеет генерить и wasm. (Как известно, Rust использует llvm).


    Надо скачать и распаковать sdk для этого дела. Качаем файл emsdk-portable.tar.gz со страницы http://kripken.github.io/emscripten-site/docs/getting_started/downloads.html#sdk-downloads


    Примерно так:


    mkdir emsdk
    cd emsdk
    wget "https://s3.amazonaws.com/mozilla-games/emscripten/releases/emsdk-portable.tar.gz"
    tar -xzf emsdk-portable.tar.gz
    cd emsdk_portable
    source emsdk_env.sh

    Далее надо это дело скомпилировать. Предупреждаю, это может занять пару часов, причем с диким выжиранием процессора и памяти.


    emsdk update
    emsdk install sdk-incoming-64bit
    emsdk activate sdk-incoming-64bit

    emsdk предложит еще раз выполнить
    source ./emsdk_env.sh


    Hello, world


    Сделаем простенький хелловорлд на расте


    fn main() {
        println!("============\nHello, world\n===============");
    }

    И скомпилируем


    rustc --target=wasm32-unknown-emscripten wasmtest.rs

    Компилятор создаст файл wasmtest.wasm, а также js-обвязку для загрузки этого файла (wasmtest.js), потому что пока что нельзя просто взять и написать <script src="wasmtest.wasm">


    Теперь нам надо сделать простую html-страницу для этого дела.


    <!DOCTYPE html>
    <html lang="ru">
    <head>
        <meta charset="utf-8" />
        <title>Rust Wasm</title>
    </head>
    <body>
    <script type='text/javascript'>
        var Module = {};
        fetch('wasmtest.wasm').then(response =>
            response.arrayBuffer()
        ).then(buffer => {
            Module.wasmBinary = buffer;
            const script = document.createElement('script');
            script.src = "wasmtest.js";
            document.body.appendChild(script);
        });
    </script>
    </body>
    </html>

    Чтобы посмотреть результат, проще всего запустить http-сервер на python, он не требует никакой конфигурации


    python -m SimpleHTTPServer


    Запустив в браузере (лучше в firefox) http://localhost:8000/hello.html вы увидите в консоли надпись "Hello, world!".


    Доступ к DOM


    Консоль — это здорово, но хотелось бы что-то на странице отобразить, для этого нужны какие-то функции работы с DOM. Сначала я зарылся в мозгодробительную документацию, но потом выяснил, что всё уже написано до нас. Есть библиотека webplatform, которая предоставляет какие-то базовые вещи для работы с DOM.


    Перепишем нашу программу:


    extern crate webplatform;
    
    fn main() {
        println!("============\nHello, world\n===============");
        let document = webplatform::init();
        let body = document.element_query("body").unwrap();
        body.html_set("<h1>Привет, Хабр, я web assembly!</h1> <button>Нажми меня</button>");
        let button = document.element_query("button").unwrap();
        button.on("click", |_| webplatform::alert("Кнопка нажата!"));
    }

    Весь проект можете посмотреть на github


    Собрать его можно так:


    cargo build --target=wasm32-unknown-emscripten
    rustc --target=wasm32-unknown-emscripten src/wasmtest.rs -L target/wasm32-unknown-emscripten/debug/deps/ 

    (Я не особо знаток раста, так что если это можно сделать в одну команду cargo, подскажите плиз).


    Потом запускаем наш питон-сервер


    python -m SimpleHTTPServer

    И смотрим в firefox http://localhost:8000/hello.html. Должно получиться примерно так, как на КДПВ.


    Скомпилированные файлы и hello.html тоже лежат в репозитории, так что вы можете просто пощупать результат у себя, не заморачиваясь с компиляцией.


    Выводы и перспективы


    Понятно, что сейчас всё сырое, неудобное и с багами, но у webassembly несомненно большое будущее. Всё, что требует сложных вычислений, можно будет перенести из javascript на wasm. Появятся тяжелые программы в вебе, о которых мы сейчас и мечтать не можем. Навороченные игры? Обработка видео и звука? Кто знает.


    Куча библиотек на c, c++, rust и т.д. будет перенесена на веб в виде wasm-модулей.


    Появились энтузиасты, которые хотят ускорить reactjs засчет rust и wasm (ссылка).


    Появится закрытый проприетарный код. Если js, пропущенный через uglifyjs еще как-то можно читать, то c wasm это будет сделать гораздо сложнее.


    Как всегда, добро пожаловать в коменты. Что думаете вы?

    Поделиться публикацией
    Комментарии 144
      +2

      Ждём полноценные десктопные UI-фреймворки. Благо, они либо умеют рисоваться через OpenGL ES, либо можно на взять и отрендерить битмап из памяти.

      • НЛО прилетело и опубликовало эту надпись здесь
          +3
          А то! Загрузка файлов из папки на HDD возможна уже сейчас
          Видео моего маленького поделия


            0

            Да вон оно уже есть https://epicport.com/en/ttd

              0

              Оно же на emscripten, а не сабжевом wasm

                +3
                Ну и что? Emscripten может компилировать как в asm.js так и в wasm.

                Фишка emscripten'а в том, что сам инстанциирует нужный код и с точки зрения программиста — нету разницы, что именно под капотом. И при asm.js и при wasm вызов функции происходит совершенно одинаково.

                Еще одно преимущество — emscripten сделал реализацию системных вызовов платформы linux(syscalls). Это дает возможность прямо переносить программы, которые обращаются к файлам в web. Обращение будет происходить к виртуальной файловой системе, в emscripten есть несколько имплементаций таких — используй какая больше тебе подходит
                  0
                  Еще одно преимущество — emscripten сделал реализацию системных вызовов платформы linux(syscalls). Это дает возможность прямо переносить программы, которые обращаются к файлам в web. Обращение будет происходить к виртуальной файловой системе, в emscripten есть несколько имплементаций таких — используй какая больше тебе подходит

                  Строго говоря, не сисколов, а libcшного API к ним. Хоть оно и маппится почти один в один для простых вещей, это разные вещи.


                  Я смотрел в исходники и видел там MEMFS и IDBFS, как минимум. Думаете в glue-коде для wasm будет принципиальная разница? Наверняка те же имплементации fs будут и для wasm варианта.

                    0
                    Да, я это и имел ввиду. Те же MEMFS, IDBFS и WORKERFS можно использовать и для wasm варианта. Разницы нету никакой.

                    Из wasm кода можно делать прозрачные вызовы js функций. Благодаря этому факту, glue код для wasm'а ничем не отличается и все эти прелести можно использовать из коробки
              0
              Сегодня вы запускаете десктопные приложения через ОС :) Все равно есть посредник. Но так, хотя бы он будет кроссплатформенный. Занес приложение в закладки и вуаля, оно доступно без инсталляции на любых платформах, где есть браузер с поддержкой wasm. Сейчас мне очень не хватает нескольких виндовых приложений на маке, wasm должен решить эту проблему. Так же приложения могут легко удаляться при нехватке места, хранить можно только данные, но не гигабайтные бинарники от редко используемых приложений. Понятно, что до этого «вуаля» еще несколько лет, но хорошо, что работа идет.
                0

                А чому нет. Автоматически снимаются проблемы песочницы, кроссплатформенности и установщика.

                • НЛО прилетело и опубликовало эту надпись здесь
                  0
                  А зачем ждать?
                  https://habrahabr.ru/post/325102/
                  0
                  –6
                  Ура рекламщики потирают руки от ощущения кучи денег.
                  Наконец будет неблокируемая исполняемая реклама.
                  Появятся тяжелые программы в вебе, о которых мы сейчас и мечтать не можем
                  ага ядрёна вирусы,( загружающихся в память, во время исполнения- из за неведомого переполнения) зашифрующие диск(загрузочную область) за время нахождения на сайте при прокрутке какой нибуть 3 d картинки.
                  Появится закрытый проприетарный код.
                  Если js, пропущенный через uglifyjs еще как-то можно читать, то c wasm это будет сделать гораздо сложнее
                  . А если сайт взломают негодяи и как такой код найти и разобрать?
                    0
                    По поводу вирусов — думаю, будет как с java-апплетами в своё время — начнут подписывать, а неподписанные будут по-умолчанию у всех блокироваться.
                      +7
                      Уфологи в треде, все в летающую тарелку!

                      Вирусов не будет. Если бы была возможность они существовали бы уже сейчас. Суть в том, что нужно смотреть на то, какие API браузер предоставляет для JS окружения. То же самое API будет доступно со временем и для WebAssembly. Т.е. ничего нового не добавят

                      В 2011-м году браузеры добавили поддержку для произвольного доступа к папкам и файлам на HDD без участия юзера. Но потом это выпилили, по всей видимости из соображений безопасности.

                      Так что боятся нечего, живем!
                        0
                        Вирусов не будет.

                        Так что боятся нечего, живем!

                        Вангуете?
                        +4
                        > как такой код найти и разобрать?

                        Разработчики антивирусов смотрят в недоумении и удивлённо пожимают плечами.

                        А разработчику зачем искать код вируса? Перезалил приложение и прописал права доступа как правильно, а не как всегда :-)
                          0
                          Вирусы вряд ли, так как это по сути тот же контекст JavaScript. А вот неотключаемая реклама — легко.
                          +1
                          А вы пробовали сравнить скорость выполнения вставки куска ДОМа через wasm и обычными методами? Было бы интересно посмотреть быстродействие на реальных задачах, навроде обновления.
                            0
                            Глубоко не копал. Просто решил пощупать из любопытства.
                              +3
                              Скорее всего так же, либо чуть медленее, т.к. на самом деле библиотека webplatform генерирует js код обычный, который вставляет дом элементы. Напрямую из WebAssembly c DOM пока работать нельзя.
                                0

                                Там DOM же отдельная сущность, за пределами js. Не думаю, что что-то изменится принципиально, а вот появление рендеринга в стиле десктопных gui библиотек с отрисовкой через web-gl думаю можно ожидать в будущем.

                                  0

                                  Поисковики скажут большое спасибо таким приложениям.

                                    +2

                                    А зачем индексировать, например photoshop? Или IDE? Тут ведь речь скорее о суровых приложениях, а не сайтах.

                                      +1

                                      А зачем пилить UI на web-gl? HTML для этого гораздо лучше подходит. А вот операции с большими массивами данных лучше перенести в WASM. Получим гибкий интерфейс и быструю логику.

                                        0

                                        По большей части из-за DOM, в котором сейчас все проблемы. Иерархичность, вложенность элементов никогда не была необходимым условием существования UI. Сейчас HTML выражает одну парадигму, судя по низкой производительности DOM, не всегда применимую.

                                          0

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

                                            0

                                            Ну это из разряда научить зайца курить. Можно, но зачем. DOM довольно точно и прямоленейно выражает идеи html — тем и ценен. Возможно надо попробовать отказаться от самой html+css разметки. Как мне кажется все эти модные вещи типа flexbox это именно попытка упростить вложенность и перегруженность современного html.
                                            Например Хабравская лента комментов может быть сделана иерархично, когда каждый новый уровень вложенности достигается оберткой его в относительно текущего с фиксированным padding. А можно сделать их без вложенности с прямым вычислением смещения (похоже так и сделано).
                                            Да и сам html… В текущих условиях это выглядит странно. Предлагаю нажать ctrl+u и увидеть сколько в тексте непосредственной информации, а сколько разметочной. Особенно разбалансировано выглядит лента комментов. А теперь представте, что у нас есть возможность скомпилировать всю разметочную информацию в удобный для браузера вид? В какой-то мере современный мир к этому движется, генерируя элементы на лету из JS, но только выглядит это странно: генерацией html и вставкой в текстовом виде в dom дерево, с последущим парсом и отрисовкой

                                              +1

                                              Давайте вспомним, что HTML это история не про приложения, а про документы. Здесь важна семантика от того и богатство возможностей каждого элемента. Но скоро появятся Custom Elements, и это уже будет шаг в сторону оптимизации HTML под приложения: вы сможете отдать с сервера древовидную семантическую структуру, а отобразить одномерным списком. После этого вопрос останется в том, чтобы дать разработчикам возможность более низкоуровневых оптимизаций.

                                                0

                                                Ну так вы определитесь:


                                                А зачем пилить UI на web-gl? HTML для этого гораздо лучше подходит.

                                                Или


                                                HTML это история не про приложения, а про документы.
                                  +1
                                  У меня такое ощущение, что работа с DOM`ом останется лишь для обратной совместимости с легаси, если же говорить о серьёзном геймдеве или всяких прогах с крутой графикой, типа Maya или хотя бы если WebStorm/IDEA в вебе — то тут, скорее всего, будет юзаться только canvas в 2d/3d-режимах. А из DOM`а в лучшем случае на старте какой-то контент будет вытягиваться, а то и от этого откажутся. Не верю я, что работа с DOM`ом не станет баттлнеком в случае перехода на WASM. Так что DOM для WASM`а — это настоящее, но не думаю, что — будущее…
                                    +2
                                    Это плохо, потому что нативные интерфейсы ОС при этом будут игнорироваться. Прийдём к тому, что для того, чтобы мигать курсором, нам нужно будет выделенное ядро.
                                      +4

                                      А они и так игнорируются. Веб жеж.

                                        +6
                                        Нет. Сейчас поле ввода — это системное поле ввода (браузерное). Так же как и кнопки в формах. Я понимаю, что бутстрап и всё такое, но базовые элементы всё-таки подчиняются правилам браузера, которые в свою очередь используют правила ОС.

                                        Условно говоря, если мы совсем забиваем на браузер, то мы рисуем на канвас не только своим шрифтом, но и своим растеризатором шрифтов со своим хинтингом и алиасингом, сами мигаем курсором, сами рисуем выделение и рассчитываем сколько пикселов глиф занимает.
                                          0
                                          А это всегда плохо?
                                          Уже есть товарищи которые свои шрифты на Canvas используют и получают за счет этого неслабые преимущества по сравнению с конкурентами — OnlyOffice тот же https://habrahabr.ru/company/teamlab/blog/141434/
                                          За счет чего могут например нормально редактировать большие документы (чего Office365 / Google Docs не могут).

                                            +3
                                            А если я монитор в вертикальное положение поверну и включу субпиксельный рендеринг с вертикальным RGB? Откуда веб-приложение будет про это знать?

                                            А если я люблю slight hinting, а full hinting не выношу, то я могу это у себя в настройках системы включить. А в этом веб-приложении?
                                              0
                                              Если веб приложение рисует текст с помощью Canvas.drawText() то оно видимо может это знать, поскольку используется реализация браузера.
                                                0
                                                А это видимо стоит спросить у Marazmatik
                                                Если даже нельзя из JS получить данные — ну галочку сделают если будет так нужно.

                                                Альтернатива в данном случае — DOM-based редактор типа Google Docs который просто не способен работать корректно в некоторых случаях (один из них — большие документы).
                                                  +1
                                                  В ONLYOFFICE мы рисуем сами, не средствами браузера (Canvas.drawText). Поэтому да, не достучаться до монитора и порядка субпикселей в нем. Но да, можно сделать галку. Правда пока мы не даем использовать субпиксельный рендеринг. Пока это очень накладно. И с кэшем проблемы. Да и нужен ли он теперь со всеми планшетами/ноутами-трансформерами. Наконец-то виндоус по-нормальному наулился работать не с 96dpi мониторами — ждем хороших мониторов). Может доживем и до отрисовки без антиалиасинга.

                                                  PS. экспериментировал с wasm. Пока если его использовать — то надо использовать по-крупному — т.е. выносить сразу большой кусок кода. Иначе похоже много времени тратится на вызов функций из js, Написал на wasm (не компилил, писал сразу на нем, только в текстовом формате) функцию для работы с int64. Нам в ONLYOFFICE очень нужна такие вычисления. Так вот. пока wasm проигрывает в скорости эмулятору int64 на js. А там такой огород! (храню в двух интах и работаю с ними, верхняя/нижняя часть и так далее). Но работает. Ждем улучшений. Канвас ускорился в разы с момента появления. И тут думаю все будет отлично.
                                              –1

                                              Можно libfreetype свежий с собой таскать и не иметь проблем. А шрифты сейчас и так уже повсеместно используют не системные, а загружаемые.

                                            0
                                            Игнорирование нативных интерфейсов — это вообще не выход. Сразу же все языки, где есть хитрый ввод (китайский, японский, корейский например) перестают поддерживаться. Или нужен будет кросс-платформенный API для доступа к состоянию IME и прочих средств ввода, чего никогда не будет, я думаю.
                                              0
                                              Прийдём к тому, что для того, чтобы мигать курсором, нам нужно будет выделенное ядро.

                                              Зачем же так грубо. Не целое, а всего 30%.

                                                +1
                                                Это пока используются нативные примитивы для перерисовки и обраружения клиппинга. А если мы всё своё пишем — придётся напрягаться. Ах, да, ещё же есть движения курсора…
                                                  0

                                                  Можно взять ту же самую Skia, которой хром и так рендерит весь контент. И не надо напрягаться.

                                                  0

                                                  Ну вот тема внезапно получила неожиданное развитие :-)

                                                –1
                                                wasm не умеет dom, это работает только через внешние вызовы. игры и так в 3д рисуются, разве что частично UI бывает удобнее сделать на dom
                                                0
                                                Не думаю, что станет кардинально быстрее. Основная проблема при работе с DOM — пересчет и перерисовка дерева. Но даже если использовать wasm для этой цели, сильно быстрее пересчитывать вряд ли получится. Количество работы по пересчету всех позиций и расчету стилей останется тем же самым.
                                                  0
                                                  сейчас это даже медленнее так как из wasm просто дергаются внешние функции на js, сама же wasm ничего о дом не знает и умеет только считать int и float 32 и 64, да в линейную память писать.
                                                    +1
                                                    Я к тому, что это вряд ли вообще имеет смысл. Части кода, реализующие расчеты и отрисовку страницы после изменения, и так написаны на чем-то более низкоуровневом, чем js. Я думаю, там все сделано достаточно эффективно. Поэтому вряд ли будет профит от работы с домом из wasm.
                                                0
                                                Немного размер получаемого wasm бинарника смущает, 183кБ.
                                                  +1

                                                  Есть подозрение, что весь rust рантайм один в один скомпилирован в wasm. Думаю это пройдет со временем.

                                                    +3
                                                    у rust нету рантайма.
                                                      +3

                                                      Смотря что под рантаймом понимать.


                                                      https://www.rust-lang.org/en-US/faq.html


                                                      Does Rust have a runtime?

                                                      Not in the typical sense used by languages such as Java, but parts of the Rust standard library can be considered a “runtime”, providing a heap, backtraces, unwinding, and stack guards. There is a small amount of initialization code that runs before the user’s main function. The Rust standard library additionally links to the C standard library, which does similar runtime initialization. Rust code can be compiled without the standard library, in which case the runtime is roughly equivalent to C’s.
                                                        0
                                                        stack guards виполенены не для всех платформ, из libstd
                                                        #[cfg(all(not(all(target_os = "linux", not(target_env = "musl"))),
                                                                  not(target_os = "freebsd"),
                                                                  not(target_os = "macos"),
                                                                  not(target_os = "bitrig"),
                                                                  not(all(target_os = "netbsd", not(target_vendor = "rumprun"))),
                                                                  not(target_os = "openbsd"),
                                                                  not(target_os = "solaris")))]
                                                        #[cfg_attr(test, allow(dead_code))]
                                                        pub mod guard {
                                                            pub unsafe fn current() -> Option<usize> { None }
                                                            pub unsafe fn init() -> Option<usize> { None }
                                                        }
                                                        
                                                        

                                                        тобишь его нету для emscripten-target.
                                                        Stack unwinding можно не использовать (тобишь zero-cost), а если надо исвользовать то в си будешь юзать примерно такой же код.
                                                        heap в Rust юзается аналогично си, в языке даже никаких операторов для этого не встроено, просто в std есть парочка стандартных контейнеров шоб не лепить свой велосипед как это часто делаетя в си.
                                                          +1
                                                          в языке даже никаких операторов для этого не встроено, просто в std есть парочка стандартных контейнеров

                                                          Box это не то что бы прям обычная структура: https://www.reddit.com/r/rust/comments/5j05j6/magic_box/


                                                          Да и рано или поздно, но нормальный box-синтаксис вернут, а Box::new объявят устаревшим костылем.

                                                            +1
                                                            интересно, но опять же это compiletime, а не runtime.
                                                    +6
                                                    Автор похоже собрал без --release. Не удивительно.
                                                    0

                                                    На мой взгляд идея крутая как и asm.js для написания именно библиотек/виртуальных машин, насколько я вижу они будут работать очень быстро(относительно быстро).
                                                    Но для реализации конечного продукта системные языки типа rust и с/с++ слишком не выразительны будет сильная потеря в производительности труда. По этому, интересно поддерживает ли данный модуль сборку мусора, которая в общем то есть в Rust? Насколько я понимаю память организуется как JS массив и управляется непосредственно модулем/приложением? Если уже реализована сборка мусора будет круто перенести на данный модуль ScalaJs, ClojureScript и др. нуждающиеся в автоматическом освобождении памяти.

                                                      0
                                                      Сборка мусора в планах, но в основном для взаимодействия с JS. https://github.com/WebAssembly/design/blob/master/GC.md
                                                      Сейчас модель памяти сишная, то есть без сборки мусора, но с указателями и адресной арифметикой.
                                                        +6
                                                        В Rust сборки мусора нет. При желании, ее можно реализовать отдельной библиотекой, если вы сможете придумать, зачем.
                                                          +3

                                                          Спасибо был не до конца осведомлен, я знал что Rust утилизирует память не явного участия программиста но не знал что это выполняется отличным от GC механизмами.
                                                          Если кому-то интересно: https://www.rust-lang.org/en-US/faq.html#is-rust-garbage-collected.

                                                          0

                                                          Сборщик мусора можно и свой написать. Я уже частично портировал свой Java-JavaScript компилятор в WebAssembly: https://github.com/konsoletyper/teavm

                                                            0

                                                            Это позволит отправить JavaScript на то место, для которого он и задумывался — анимировать снежинки и связывать компоненты на странице. Языки со статической типизацией начинают доминировать после определённого объёма проекта — динамику сложно анализировать и рефакторить.

                                                              0

                                                              Согласен с вами по поводу динамики vs статики для больших проектов.
                                                              К тому же это подтолкнет к экспериментам и появлению новых все лучших подходов к разработки для web.

                                                              +7
                                                              Я бы не назвал Rust «недостаточно выразительным». Скорее наоборот — недостаточно выразительным выглядит JavaScript на фоне Rust, как только начинает писаться что-то сколько-нибудь сложное. Rust позволяет писать достаточно сложные выражения лаконично и компактно. Хотя многие применённые в нём концепции непривычны широкому кругу разработчиков и на первых порах у новичка может получаться достаточно неуклюжий и громоздкий код.
                                                                0

                                                                Ну не знаю, очень неудобно работать со спецификаторами времени жизни, читать практически так же трудно, как J. Возможно, это от непривычки, но я с растом 1.0 знакомился когда он только вышел — было тяжко понять, что вообще происходит.

                                                                  +3

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

                                                              0

                                                              Мне кажется, что для WASM должен появится новый язык транслируемый в С, а в дальнейшем компилируемый для других платформ. Т.е. для которого WASM будет первичен и избавлен от наследия, и при этом возьмет самое лучшее от современных разработок: транспиляцию вместо макросов, минималистичный синтаксис как в Go, централизованый репозиторий и т.п. Трансляция в C позволит создать ОС прямо в браузере, как пример.

                                                                +4
                                                                Любой язык, транслируемый emscripten прекрасно будет компилироваться в WAsm.
                                                                Библиотеки на разных языках будут интегрироваться на уровне WAsm.
                                                                Но WAsm — не серебряная пуля, проблемы интеграции, создававшиеся специфичным рантаймом языков останутся. Одна из сложностей крутится вокруг разных подходов к управлению памятью.

                                                                Создание при этом отдельного языка — вопрос ортогональный. Сколько угодно — лишь бы хватало энтузиазма :-)

                                                                «ОС прямо в браузере» — сомнительная затея, проистекающая видимо из непонимания целей создания WebAssembly и закладываемых в него возможностей и ограничений. ОС будет просто «тесно» в таких условиях, да и смысла — 0, чем эта ОС будет управлять, если её саму держат в песочнице?
                                                                  –1

                                                                  Про emscripten это и так понятно. Но разработчиков на C, D, Go, Rust, C# будет трудно объединить из-за идеологических разногласий, и здесь нужен аналог С для unix. Это мое мнение.


                                                                  ОС прямо в браузере – это во-первых пример. Во-вторых, снижение порога входа в разработку это не "сомнительная затея", а спусковой механизм к расцвету технологического разнообразия, пример которого мы наблюдаем сегодня благодаря появлению персональных компьютеров.

                                                                    0
                                                                    Про emscripten это и так понятно. Но разработчиков на C, D, Go, Rust, C# будет трудно объединить из-за идеологических разногласий, и здесь нужен аналог С для unix. Это мое мнение.
                                                                    Вы не понимаете, что делает emscripten. Он берет LLVM IR код и транслирует его в вид, понятный виртуальной машине JS. Соответственно, любой фронтенд, генерирующий IR код (rust, clang, mono, llst…), сможет быть использован для веба.
                                                                      0

                                                                      Я прекрасно понимаю что делает emscripten, но проблему это не решает, у каждого языка свой рантайм, вы захотите использовать одновременно модули, написанные на Go, Rust, Java если к каждому оверхед + несколько десятков мегабайт? Думаете, да? Посмотрите что сейчас происходит в том же linux, каждый язык поддерживает свой собственный зоопарк модулей зачастую выполняющий идентичные функции, потому что мало кто хочет использовать в проекте больше одной платформы. Язык это не просто форма представления, это несколько больше, это огромное количество логических примитивов, особенностей работы и философия. Наглядный пример Objective-C и Swift, я регулярно слышу от мобильных разработчиков фразы, вроде "может такой модуль есть на свифте?". Так что не стройте фантазий на тему того, что все языки заживут дружной семьей внутри WASM. WASM лишь выведет гонку языков на новый уровень.

                                                                        +3

                                                                        Многие языки просто делают обёртки вокруг системных библиотек. Сами системные библиотеки пишутся на разных языках, но предпочтение отдаётся тем, которые работают эффективней. Понятное дело, что большинство написано на C/C++, но есть примеры и библиотек на Фортране. Хотя, конечно, велосипедостроителей — тоже хватает. Но раз это устраивает соответствующие сообщества, то в чём проблема? Типовые наборы для платформ будут, как сейчас популярные библиотеки JS и веб-шрифты, грузиться с CDN и с большой вероятностью будут уже кешированы в браузере.


                                                                        Go, Rust и Java самих по себе будет сложно подружить. Но как альтернативный язык решит проблему? Почему бы всем разработчикам не перейти на тот же Rust? Но они не хотят, их по тем или иным причинам устраивают родные Go, Java и прочие. То же самое и с каждым другим языком из длинного списка.


                                                                        Ещё один язык как решит эту проблему? Будет ещё один язык, на который никто не хочет просто так переходить, тыкая своим богатым багажом наработок, накопившимся за десятилетия, в противовес молодой и малоразвитой экосистеме. Вот в чём весь вопрос.


                                                                        Поэтому вопрос конкуренции языков никуда в ближайшей перспективе не денется. И его не решит дорогостоящий проект по созданию ещё одного самого лучшего языка, на котором не будет своих нужных модулей.


                                                                        Причём даже его тотальная совместимость с тем же С и сишными библиотеками не решит проблемы языков, создававшихся, чтобы уйти от С. С++ — своя песочница, требующая написания специальной прослойки для совместимости с С. Rust — своя песочница со строгим контролем памяти, создававшаяся, чтобы избежать проблем С и С++. Обойма языков с GC — отдельная история — создававшаяся для избегания необходимости управлять памятью и проще писать код, даже серьёзно жертвуя производительностью. Какое из этих сообществ легко согласится пожертвовать своей песочницей в угоду возвращения к уровню С?

                                                                          0
                                                                          вы захотите использовать одновременно модули, написанные на Go, Rust, Java

                                                                          вов-вов, какой Java? wasm расчитан на те случаи когда производительности JS нехватает, а не для того чтобы привести зоопарк языков в браузеры.
                                                                        +1
                                                                        разработчиков на C, D, Go, Rust, C# будет трудно объединить из-за идеологических разногласий

                                                                        И введя новый язык мы заставим всех ненавидеть его одинаково из-за чего "идеалогические разногласия" пропадут? (:

                                                                          0
                                                                          заставим всех ненавидеть его одинаково

                                                                          Это вы откуда взяли?


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

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

                                                                              "Это вы откуда взяли?"


                                                                              Кто-то в восторге от "простоты" Go и терпеть не может "перегруженность" С++//D/Rust, для кого-то сборка мусора принципиальный вопрос, кому-то подавай выразительности, кто-то рад дополнительным гарантиям раста и считается дополнительную сложность адекватной ценой. Вот какой должен быть новый язык, чтобы всем угодить?

                                                                                0

                                                                                Недовольные останутся на том, что есть. Тех же кто захочет получить профит от вышеперечисленного не смутит отсутствие некоторых фич. Суть именно в том чтобы получить усредненный результат, а не тащить все и сразу. Тот же rust также появился.

                                                                                  0
                                                                                  Недовольные останутся на том, что есть.

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


                                                                                  Тот же rust также появился.

                                                                                  Раст совершенно не похож на "усреднённый результат" и привносит уникальные (по крайней мере, для около-мейнстрима) фичи.

                                                                            +2

                                                                            Здесь просто напрашивается картинка про 15-й стандарт.
                                                                            Ну, будет ещё один язык, который будет точно так же бороться за место под солнцем с C, D, Go, Rust, C# (и далее длинный список выше не упомянутых, но относительно популярных языков от Паскаля до Хаскеля). Чтобы стать по-настоящему популярным, ему потребуется выйти за пределы Wasm и начать применяться в других областях (или рано или поздно найдутся энтузиасты, которые его туда притащат.


                                                                            С другой стороны сделать качественный и непротиворечивый язык — это весьма сложная задача. И язык должен решать задачи программиста, а не задачи платформы, иначе ему ничего не светит. Дальше — задача распространения языка, обучения специалистов, создания необходимого множества библиотек (в современных языках это достаточно большое множество), создание своего менеджера пакетов, создание IDE (задача на самом деле не менее ресурсоёмкая, чем создание самого языка).
                                                                            Вы уверены, что все эти затраты — действительно стоят того, чтобы получить лишь немного лучше подходящий для конкретной ниши язык, возможности которого с лихвой перекрываются уже существующими более универсальными языками?


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


                                                                            Посмотрите на пример Rust — его уже не один год разрабатывает достаточно крупный коллектив. Разработка идёт очень открыто в тесном сотрудничестве с сообществом и это сообщество делает немалый вклад в развитие экосистемы. Но совершенно очевидно, что даже при таком участии большого количества людей сделать качественный современный язык — достаточно непростая затея. Убедить людей перейти на него, когда их в целом устраивает их текущий язык, с которым они делают бизнес и сильно зависят от него, накопив большое наследие и опыт — непростая затея.


                                                                            После этого можете оценивать шансы и необходимость ещё одного языка, а тем более его шансы стать хорошим языком.

                                                                        +1
                                                                        Зачем что-то транслировать в Си если можно транслировать или в WASM или в какой нить IR/IL?
                                                                          –1

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

                                                                            +2

                                                                            Что мешает эти сишные либы компилировать в тот же LLVM IR?

                                                                              –1

                                                                              Для начала аргументируйте в чем преимущество использования IR. Но возможность скомпилировать библиотеку с помощью gcc важна для сообщества разработчиков открытого ПО как таковая.


                                                                              При описанном мной подходе, я не вижу никаких препятствий для поддержки разных способов компиляции.

                                                                                –1

                                                                                Скомпилируйте, пожалуйста открытую библиотеку Apache Lucene с помощью GNU GCC, если это столь принципиальная проблема, чтобы любой проект был компилируем GCC. Или предложите альтернативу. Подскажу, clucene и sphinx сильно отстают по функционалу, а lucenecpp загнулся.


                                                                                А если вам не нравится LLVM IR, то используйте любое другое intermediate representation, никто не мешает иметь что-то подобное в результате работы фронта и оптимизатора gcc (за исключением самого gcc, конечно, если это ещё не вылечили). И дальше скармливать emscripten'у как бэкенду компиляции в asm.js/wasm.

                                                                                  –3

                                                                                  Это не проблема языка, то что Apache Lucene не может быть скомпилирован в gcc. Строить вавилонскую башню не вижу никакого смысла. Количество языков не должно быть слишком большим, чтобы не убить прочие плюсы, именно поэтому я и говорю о возможности трансляции в C наравне с WASM.

                                                                                    +1

                                                                                    Интересно за что минусы? Apache lucene написан на Java, если кто не в курсе.

                                                                                  +2
                                                                                  в чем преимущество использования IR

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


                                                                                  Конечно, если смотреть на С/С++, для них существуют более эффективные компиляторы (тот же GCC для примера). Но эти компиляторы не так универсальны и их архитектура не позволяет их сделать настолько же универсальными, как и LLVM. Поэтому LLVM IR — такой себе лингва франка, в развитие которого вкладываются усилия многих сообществ и корпораций.


                                                                                  Это, к слову, о едином стандарте для разных языков: LLVM — один из кирпичиков этой универсальности. И такие языки как Python, получили свою дорогу в WAsm именно благодаря ему.

                                                                            +5
                                                                            А можно будет скомпилить Servo в WASM и запускать браузер в браузере?
                                                                              0
                                                                              а почему бы и нет?)
                                                                                0
                                                                                Наверняка Servo опирается на вызовы системные функции, которые недоступны в браузере.

                                                                                Поэтому чтобы запустить Servo в браузере — придется имплементировать abstraction layer на API, доступном в браузере. Нечто подобное происходит, когда вендор портирует Android на свой девайс(делается имплементация HAL)
                                                                                  0
                                                                                  это делает не вендор, а платформодежратель, в нашем случае qualcom, mediatek и т.д.
                                                                                –4
                                                                                Не очень понятно, зачем изобретать webassembly — если это обычная байт-кодовая машина с JIT?
                                                                                Их полно на любой вкус, начиная с Питона и заканчивая Явой.

                                                                                Чтобы «зацепиться» за опять модное слово ассемблер?

                                                                                Сколько ассемблер халва не говори, во рту слаще быстрее работать не станет.
                                                                                  +6
                                                                                  Как минимум — это позволяет более эффективно исполнять математику в браузере. JS не сильно дружит с системами типов и виртуальной машине JS приходится постоянно проверять, не изменился ли тип. Если тип изменился — вызывается неоптимизированная версия и чуть позже происходит возможная перекомпиляция JS в тот же машинный код. А это потеря производительности.

                                                                                  А с wasm — типы известны еще до исполнения программы.

                                                                                  Еще один минус JS — нету нативной поддержки Int64. Все числа в JS — double, под значащую часть выделяется только 56 битов и 8 бит под мантису. Из-за этого большие int64 округляются до 2^56 и теряется точность. А wasm поддерживает int64 из коробки

                                                                                    –2
                                                                                    Если тип не изменился — то не так уж и страшна эта проверка, так что не так все и плохо с математикой в js. Плохо правда, что не всегда делается приведение операций к типу данных и при сложении int8 могут использоваться операции над int32, но это сейчас в процессе доработки.

                                                                                    Поддержка int64 и вообще чисел произвольного размера добавлена в предложения.

                                                                                    На самом деле 53 и 11.
                                                                                      +1

                                                                                      «на вид-то он хорош, да зелен — ягодки нет зрелой» © :-)


                                                                                      Были б проверки для математики "не так страшны", так бы не бились над языками и алгоритмами для исключения лишних проверок откуда только возможно. Ветвление само по себе плохо сказывается на оптимизации производительности, поскольку нужно предсказывать по какой ветви пойдёт вычисление, но ещё и сокращает эффективность кеша — больше кода, более рыхлый код, больше данных (информация о типе), соответственно меньше оседает в более производительном кеше процессора.


                                                                                      И одна к другой таких проблем у JS много, как бы ни был крут JIT, ухитряющийся иногда выжать производительность всего-лишь на порядок худшую, чем у нативного кода.

                                                                                        –2
                                                                                        Так нет там ветвлений, там проверка входных параметров на соответствие ожидаемым, она достаточно простая, если она не проходит — все деоптимизация и попытка повторной оптимизации. Потому производительных жс выглядит довольно плохо так как приходится отказываться от любого вида мономорфизма. Иногда компилятор может быть уверенным на счет типа, если значение получено из типизированного массива (это пока не всегда хорошо работает, но это исправляют) или выполняется явное приведение типов. Так что в принципе как раз математику на жс писать можно довольно производительную, но на васм производительность будет более предсказуемой. По тестом это даже не на порядок, а в несколько раз 2-7.
                                                                                          +3

                                                                                          "нет ветвлений" и "проверка" — это взаимоисключающие параграфы.

                                                                                            –2
                                                                                            Ок, одиночное ветвление — это не ветвления
                                                                                              +2

                                                                                              А кто сказал, что оно одиночное? Если мы в цикле складываем элементы массива — ок, тут простая ситуация. Но обычно не это называют "математикой".

                                                                                                –2
                                                                                                Мы говорим про проверку сложных входных параметров, а дальше можно конечно написать плохой неоптимизируемый код, но как раз математика — это обычно про числа так что можно написать так, что лишних проверок не будет.
                                                                                                  –2
                                                                                                  Собственно теперешняя реализация васм очень похоже на то, что мы писали на асм если нужно было ускорить часть подсчетов. Разница пока только в инт64, расширяемой линейной памяти и более крутом динамическом связывании через таблицы.
                                                                                                    +1
                                                                                                    более крутом динамическом связывании через таблицы

                                                                                                    Опять же, динамическое связывание — это противоположность того, что необходимо для достижения высокой производительности. Но эта тема уже выходит за пределы парадигмы языка, созданного быть динамическим, так что требовать от JS прыгнуть выше головы — нет смысла.


                                                                                                    Поэтому, собственно, и появился WAsm, — для заполнения этой лакуны, способный генерировать код близкий по производительности к нативному, в том числе благодаря возможности статически всё прописать и оптимизировать.

                                                                                                      –2
                                                                                                      от dll никуда не убежишь нельзя же все монолитом собирать. Брендон Айк сказал когда-то «Всегда ставьте на джаваскрипт» и пока его голова поднимается все выше, типизация тоже должна появится в каком-то виде, эксперименты с саундскрипт и юз стриктер уже были. Хотя про динамическое связывание было в сторону васм, это у него оно более крутое.

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

                                                                                                        +2
                                                                                                        от dll никуда не убежишь нельзя же все монолитом собирать

                                                                                                        Тут немного не то. Сами библиотеки могут подключаться динамически, но таки их интерфейс быть статическим, соответственно код остаётся статически анализируемым и оптимизируемым.


                                                                                                        Но динамическое связывание вполне может быть и в монолитном бинарнике. Всё, что ведёт к определению типа в рантайме, проверкам в рантайме — всё это бьёт по производительности и надёжности.


                                                                                                        WAsm позволяет избежать именно этого вида динамичности и достигнуть пределов возможного — полной отдачи от процессора. Но это не означает, что саму динамичность он исключает, нет — он даёт выбор, который был крайне беден в JS и появилось хоть что-то с asm.js.


                                                                                                        Эволюция самого JS — тоже достаточно радующий факт. Возможно через несколько лет мы получим стандарт достаточно продуктивного языка. Но наследие со всеми странностями, нелогичностями и проблемами — ещё долго будет тянуться. Хотя, какой-нибудь очередной strict mode и транспилеры могут решить эту проблему.

                                                                                                          –2
                                                                                                          Я и не говорил, что он динамический, я вам говорил про то, что можно к примеру 5 васм модулей между собой переключать и пересвязывать через таблицы этих модулей, по сути это будет схема работы с dll.

                                                                                                          Я никогда не спорил с тем, что динамическое определение типов ведет к лишним накладным расходам, но динамическое связывание это все-таки не о том.

                                                                                                          Так и жс позволяет избежать этого вида динамичности благодаря развитию JIT.
                                                                                                            +1

                                                                                                            Тогда, возможно, мы просто говорили о разных вещах, ок.


                                                                                                            JS не позволяет избежать динамичности в силу того, что у него просто нет соответствующих инструментов. И JIT, каким бы он ни был умным, не сможет из ничего сделать статическую проверку и оптимизацию. Речь ведь не только про конкретные типы переменных, речь про сам алгоритм.


                                                                                                            В Rust мы можем выполнить проверку варианта с перечислением через match — компилятор будет точно знать, что значение не может содержать ничего лишнего, "проверка" сведётся лишь к проверке значения дискриминанта и в соответствии с этим значением будет выбрана конкретная ветвь. Компилятор может статически проанализировать ход исполнения и убедиться, что какие-то ветви вообще не будут задействованы и просто исключить их. Компилятор может заранее вычислить все статические преобразования и убрать их из кода, заменив на вычисленные значения. Таким же способом он может вооще исключить вызовы функций, либо заинлайнив их код, либо в процессе упрощения выражений вообще сократив, как ненужные (что проблема для JS, который должен свериться с виртуальными таблицами методов у объектов). Много таких оптимизаций, которые возможны благодаря заранее и однозначно размеченному коду. Сюда же свобода от сборщика мусора — память управляется однозначно и предсказуемо, а большое количество типов не требуют отдельного выделения памяти в куче.


                                                                                                            Всё это то, чего JS не может предоставить компилятору в силу своей парадигмы динамического языка, максимально простого для пользователя. Сам же JIT — тоже требует времени на компиляцию, которая в случае компилируемых языков происходит заранее. Причём оптимизация может занимать времени в разы больше, чем сама компиляция (в случае с Rust это легко может достигать показателя "на порядок дольше") — в каком-то смысле это роскошь для JIT, хотя у него есть и свои, недоступные обычным компиляторам возможности.


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

                                                                                                              –2
                                                                                                              было бы интересно услышать опыт тех, кто этим занимался

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

                                                                                                              Всё это то, чего JS не может предоставить компилятору в силу своей парадигмы динамического языка, максимально простого для пользователя

                                                                                                              JIT делает предположения и по сути оставляет небольшое поддерево из всего множества вариантов, самое главное не разрушить его ожидания. Да JIT дорогой и время инициализации от этого растет, но не время выполнения. Скажем для игр это не так критично как для магазина одежды.
                                                                                                            –2
                                                                                                            То есть я сравнил асм и васм и сказал, что теперь там таблицы функций более крутые и динамичные, так что с ним можно работать как с длл. В асм тоже так можно было, но там проблема была во внешних функциях которые не аннотировались.
                                                                                                              +1

                                                                                                              В целом — я согласен, что WAsm достаточно близок к asm.js. Тут не о чем особо спорить: первый — развитие идеи второго и логическое его завершение. Просто не могли в конечном итоге не придти к представлению в виде байткода, поскольку это самое удобное и компактное представление, уже подвергнутое предварительной оптимизации, и не могли не сделать его максимально близким к низкоуровневой платформе.

                                                                                                      –2
                                                                                                      Это конечно сравнение мягкого с теплым, но для ориентировки подойдет wasm performance
                                                                                                  0

                                                                                                  Я, конечно, не исключаю, что оптимизатор JS может проанализировать код и убедиться, что тип не должен поменяться — в такой ситуации можно выбросить проверку и это как раз хорошо скажется на производительности. В конце концов, за счёт чего-то таки потрясающих результатов таки добиваются.

                                                                                                    –2
                                                                                                    Может если сделать аннотацию типов как например в асмжс.
                                                                                            +5
                                                                                            Assembly и Assembler — таки разные слова. Более того, это слова, достаточно широко применяемые в английском языке, а не страшно звучащие заклинания, как в русском. Странно было бы придираться к слову «сборка», если есть некий язык под названием «сборщик»?

                                                                                            WebAssembly — это больше про сам байт-код, а не про виртуальную машину с JIT. Стандарт кода, интеграция с другими API браузера, изоляция веб-приложений. Байткодовую машину тоже с нуля никто не изобретал — она уже есть в браузерах для JS. Теперь же это всё (или ещё не совсем всё) упорядочено и стандартизировано.
                                                                                            –3
                                                                                            Если посмотреть сайт вебасембли, там как раз своя стековая песочница. Написано на заглавной странице.
                                                                                            Вместе с маркетинговыми заявлениями про [задуманную] нативную производительность и компактный размер.

                                                                                            Исходники интерпретатора на OCAml тоже вполне можно посмотреть.

                                                                                            Так что все это новый велосипед, хотя можно было действительно взять V8 и ее байт код.
                                                                                              0

                                                                                              WASM это в первую очередь универсальная библиотека, которую можно встроить в любой язык Python, JS, Ruby, C. Другими словами она не привязана к браузеру и может использоваться как элемент любых приложений, в том числе и десктопных. Например уже сейчас появился проект перевода криптовалюты Ethereum на WASM, что уже многое говорит о заложенной в эту нее (библиотеку) универсальности.

                                                                                                0
                                                                                                Библиотека? Мы на одном языке говорим? Зачем смешивать языки и браузеры ???

                                                                                                Библиотека это API, но я вижу только JavaScript API

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

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

                                                                                                На самом деле это очередная драка за монополию за код в браузере — JavaApplets похоронили, Silverlight похоронили, Flash закапывают, освобождают место.
                                                                                                Потому пока что этот васмовский байт код засунули интерпретироваться в JS-машинку в браузере (хоть куда нибудь). Чтобы попытаться потом вытеснить и JS.

                                                                                                Кто сможет сожрать JS — получит много денег.
                                                                                                  +1

                                                                                                  Читайте доку (пункт 4) прежде чем писать такое.

                                                                                              +7
                                                                                              Приведу пример, для чего может быть полезен wasm
                                                                                              Сейчас мы делаем standalone веб-приложение по распознанию и анализу японского текста с изображений. Распознание производится с помощью tessaract, который через emscripten был скомпилирован в asm.js код.



                                                                                              Распознание в хроме без поддержки asm.js: 9.17 секунды
                                                                                              Распознание в фаерфоксе с поддержкой asm.js: 3.19 секунды
                                                                                              Это не считая времени на инициализацию 2.8 мегабайт js кода

                                                                                              Теоретически, при появлении wasm результат будет 1.2 секунды в любом браузере, а инициализация модуля будет быстрее (и весить он будет меньше).

                                                                                              Не нужно ничего качать и устанавливать, достаточно зайти на сайт и быстренько распознать интересующий кусок текста, и с применением того же метода можно тут же увидеть анализ текста:



                                                                                              Поэтому на данном этапе можно сказать, что wasm это не замена js, не работа с dom (сам dom к js имеет слабое отношение, поэтому ускорение js не дает ускорение dom), а дополнение к текущим возможностям, без которых было бы менее удобно.
                                                                                                +1

                                                                                                Если правильно помню, то в chromium/chrome собрались asm.js компилировать в wasm, т. е. asm.js там будет отставать от wasm'а не очень сильно. Ну и поддержка wasm появилась в актуальных chrome и firefox, что крайне радует.

                                                                                                0
                                                                                                Подскажите, пожалуйста.
                                                                                                С приходом wasm станет ли доступно управление TCP сокетом из браузера? Чтобы не использовать websocket.
                                                                                                  +3

                                                                                                  Нет. Это совершенно разные технологии.

                                                                                                  0
                                                                                                  Появились энтузиасты, которые хотят ускорить reactjs засчет rust и wasm (ссылка).

                                                                                                  Пробежался глазами по ссылке, но так и не понял как они собираются этого добиться?
                                                                                                  По идее же все опять упрется в тормознутый DOM? Не очень понимаю откуда ускорение должно взяться.
                                                                                                    +1

                                                                                                    Как один из возможных вариантов оптимизации: если использовать текстовые шаблоны, Rust может сделать работу с шаблоном очень эффективной (наполняя строковой буфер, а не создавая тучу промежуточных строк в куче). Генерация же DOM-дерева через .innerHTML, это обычно более оптимизированная операция, чем поэлементное добавление узлов с помощью JS. Не знаю, насколько это хорошо стыкуется с достаточно популярным JSX.

                                                                                                      –2
                                                                                                      code/decode между строками и буфером будет довольно дорогим, я думаю они будут там реализовывать иммьютабл деревья для виртуального дома, но пока сложно представить как это будет кодироваться числами в линейной памяти.
                                                                                                        +2
                                                                                                        code/decode между строками и буфером будет довольно дорогим

                                                                                                        Почему? Что сделает его дорогим? Строка по сути и есть буфер. В любом случае одно преобразование — это значительно дешевле, чем масса промежуточных аллокаций на каждый объект JS. Тут уже нужно закапываться в устройство React и детально изучать возможности, поскольку сложно что-то утверждать на основе догадок и предположений. Посмотрим, если у "энтузиастов" получится то, что они задумали — это будет хорошим знаком и примером, который будет стоить изучить всем. Хотя они вполне могли и ошибиться, неверно оценив задачу.

                                                                                                          –2
                                                                                                          Ну потому что вам прийдется каждый символ строки превращать в число, потом передавать в васм и там с ним работать и потом возвращать обратно и снова превращать в символ и клеить из этого набора символов большую строку — это уже куча аллокаций. Это дорого, было даже предложение добавить стринг буффер чтоб этого избежать, но пока воз и ныне там. Это проверено экспериментами — игра не стоит свеч. Вообще строки в жс медленные и в парсерах сравнение делается по кикоду, чтоб не сравнивать подстроку с другой строкой и это быстрее.

                                                                                                          Эффективнее хранить шаблон в теге шаблона и потом его клонировать и вставлять в дом. А вот дерти-чекинг виртульного дома операция вполне математическая и очень тяжелая, ее теоретически можно скинуть в васм если придумать как tries закодировать в линейную память.
                                                                                                            +2
                                                                                                            прийдется каждый символ строки превращать в число, потом передавать в васм и там с ним работать и потом возвращать обратно и снова превращать в символ и клеить из этого набора символов большую строку

                                                                                                            Не совсем понимаю суть операции. Строки в Rust — это массивы байт, которым гарантируется, что они являются корректным utf-8. Их не требуется дополнительно преобразовывать в "символы".


                                                                                                            Кроме того, сами шаблоны вполне могут работать в режиме байтовых массивов, им не требуется быть полноценной строкой.

                                                                                                              –2
                                                                                                              так жс об этом великолепии ничего не знает, как только вы захотите строку из васма достать или в васм впихнуть — быть беде. а дом он в жс так что без этого никуда.
                                                                                                                +1

                                                                                                                Да, я про само представление строк в JS не подумал, там таки UTF-16.
                                                                                                                Ну, никто не заставляет преобразовывать их в utf-8. Если у нас на входе будут корректные массивы байт с UTF-16 строками в шаблонах и значениях, то они же будут и на выходе. Хотя соответствующие примитивы для парсинга шаблонов в Rust придётся "завелосипедить".

                                                                                                                  –2
                                                                                                                  Тут даже не в том дело, нужно из строки создать массив значений и потом из массива значений склеить обратно строку. Операции элементарные, но дорогостоящие, особенно склейка. Прийдется преобразовать наборы числовых значений в символы и потом склеить их в одну строку — это обычно нивелирует всю скорость от работы с буфером. Если строковый буфер таки добавят в стандарт — тогда будет нам счастье.
                                                                                                                    0
                                                                                                                    нужно из строки создать массив значений

                                                                                                                    Строка в представлении JS — и есть массив значений. Технически какой-нибудь аналог Vec<u16> или Vec<Utf16Char>. Преобразования не требуется, (разве что чисто номинальное, чтобы получить в Rust необходимый тип), данные уже являются набором байт (как и вообще всё в памяти машины).


                                                                                                                    Операции элементарные, но дорогостоящие, особенно склейка

                                                                                                                    В том и суть, что Rust позволяет делать склейку дёшево — в едином буфере, что многократ эффективней, чем создание множества промежуточных строк, как это делается в JS. Точно так же Rust может склеивать и байты и массивы произвольных типов, "наливая" их последовательно сразу в конечный массив. В результате на выходе мы имеем уже готовую строку, которую только и остаётся передать в JS.


                                                                                                                    Именно поэтому я и предположил, что вынесение в Rust задачи шаблонизации, позволит достичь существенной экономии. Всё-таки этот язык создавался в том числе и для скорости, что достигается за счёт низкоуровневых операций, обычно недоступных в высокоуровневых языках.

                                                                                                                      –2
                                                                                                                      Вы не можете передать или вернуть строку в васм, вы можете передать или вернуть только буфер, а буфер можно забрать например из типизированного массива, а он о строках ничего не знает. Так что на стороне жс вы ничего не выиграете и никуда от этого преобразования не денетесь.
                                                                                                                        0
                                                                                                                        из типизированного массива, а он о строках ничего не знает.

                                                                                                                        Вы хотите сказать, что проблему создаст сам JS, выполняя некоторую бессмысленную работу? Тогда согласен, тут всё будет сложнее, нужно подробней изучать, как всё устроено, в том числе как получается этот типизированный массив и обртно строки из него.


                                                                                                                        Со стороны Rust подобных проблем не будет, поскольку он может прозрачно "трансмутировать" тип значений в массиве.


                                                                                                                        Но вообще, линейная трансформация строки, имхо, менее затратная операция, чем масса аллокаций в процессе обработки шаблона. Но тут уже решающее слово за бенчмарками.

                                                                                                                          –2
                                                                                                                          Да, не существует строкового буфера. Он только в предложениях на рассмотрение.

                                                                                                                          Бенчмарчили уже — все плохо. При склейке происходят множественные аллокации для создания большой строки из символов.
                                                                                                                            +1

                                                                                                                            Что ж, надеюсь под давлением насущной потребности это случится достаточно быстро.

                                                                                                                    +1

                                                                                                                    А может даже и велосипедить не придётся, всё-таки Rust создавался с мыслью о создании браузера.


                                                                                                              –3
                                                                                                              Те, кто минусуют, очевидно не могут аргументировать свою позицию по причине того, что они ТП — типичные программисты
                                                                                                            0
                                                                                                            Генерация же DOM-дерева через .innerHTML, это обычно более оптимизированная операция, чем поэлементное добавление узлов с помощью JS. Не знаю, насколько это хорошо стыкуется с достаточно популярным JSX.


                                                                                                            На начальном рендере это так, но последующие обновления дешевле делать «атомарно» через DOM api (насколько я знаю, реакт так и поступает)
                                                                                                              0

                                                                                                              Вообще-то наоборот. Вот рассказ об этом, например: https://youtu.be/TXqiq5tOWRQ?t=3604


                                                                                                              И именно поэтому React получается быстрее обычных шаблонов на том же Handlebars.

                                                                                                            +2
                                                                                                            Представил на минутку: Киберспортивные турниры проходят в mozilla firefox, chrome, edge и Yandex brauser. Как по мне будет прикольно XD
                                                                                                              –2
                                                                                                              1. Столманн негодует
                                                                                                              2. Эм… пойду учить Go наверное

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

                                                                                                              Самое читаемое