Недавно вышла новость про то, что 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-emscriptenemscripten — это такой 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-64bitemsdk предложит еще раз выполнить
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 это будет сделать гораздо сложнее.
Как всегда, добро пожаловать в коменты. Что думаете вы?
kekekeks
Ждём полноценные десктопные UI-фреймворки. Благо, они либо умеют рисоваться через OpenGL ES, либо можно на взять и отрендерить битмап из памяти.
NLO
НЛО прилетело и опубликовало эту надпись здесь
Deamon87
А то! Загрузка файлов из папки на HDD возможна уже сейчас
poxvuibr
Да вон оно уже есть https://epicport.com/en/ttd
grossws
Оно же на emscripten, а не сабжевом wasm
Deamon87
Ну и что? Emscripten может компилировать как в asm.js так и в wasm.
Фишка emscripten'а в том, что сам инстанциирует нужный код и с точки зрения программиста — нету разницы, что именно под капотом. И при asm.js и при wasm вызов функции происходит совершенно одинаково.
Еще одно преимущество — emscripten сделал реализацию системных вызовов платформы linux(syscalls). Это дает возможность прямо переносить программы, которые обращаются к файлам в web. Обращение будет происходить к виртуальной файловой системе, в emscripten есть несколько имплементаций таких — используй какая больше тебе подходит
grossws
Строго говоря, не сисколов, а
libcшного API к ним. Хоть оно и маппится почти один в один для простых вещей, это разные вещи.Я смотрел в исходники и видел там
MEMFSиIDBFS, как минимум. Думаете в glue-коде для wasm будет принципиальная разница? Наверняка те же имплементации fs будут и для wasm варианта.Deamon87
Да, я это и имел ввиду. Те же MEMFS, IDBFS и WORKERFS можно использовать и для wasm варианта. Разницы нету никакой.
Из wasm кода можно делать прозрачные вызовы js функций. Благодаря этому факту, glue код для wasm'а ничем не отличается и все эти прелести можно использовать из коробки
Iqorek
Сегодня вы запускаете десктопные приложения через ОС :) Все равно есть посредник. Но так, хотя бы он будет кроссплатформенный. Занес приложение в закладки и вуаля, оно доступно без инсталляции на любых платформах, где есть браузер с поддержкой wasm. Сейчас мне очень не хватает нескольких виндовых приложений на маке, wasm должен решить эту проблему. Так же приложения могут легко удаляться при нехватке места, хранить можно только данные, но не гигабайтные бинарники от редко используемых приложений. Понятно, что до этого «вуаля» еще несколько лет, но хорошо, что работа идет.
kekekeks
А чому нет. Автоматически снимаются проблемы песочницы, кроссплатформенности и установщика.
ggrnd0
> Автоматически снимаются проблемы песочницы
Как бы не так. В чем можно быть уверенным: наконец-то появятся полноценно-кроссплатформенные вирусы.
До сих пор с falsh/javafx их было порядочно. А что произойдет когда webasm действительно окажется в каждом браузере?
> Автоматически кроссплатформенности
не уверен, MS уже не раз отличились: java++, JScript — даже поддержка unicode не то что бы не полная, но местами не соответствует спецификациям (не уверен как сейчас).
А c++11/14 они вроде бы даже и не собираются поддерживать полностью (опять не уверен, как оно изменилось — кто-то наверняка сможет прокомментировать).
Apple тоже иногда имеет собственное мнение.
Конечно, когда нибудь мы получим свои 99.999% кросплатформенности, но оговорки останутся всегда.
Хотя бы за счет разной скорости и порядка реализации новых фич.
А ведь еще и поддержки webasm в IE9/10 нет, кто знает когда они уйдут из мира корпоративной разработки?
ЕС недавно только выдвинул претензии о сборе персональных данных win10.
Пока они решат что делать, пока MS исполнит…
Про *Embrace, Extend, and Extinguish* еще не забыли?
Я думаю, MS от своей политики не отказалась. В любом случае запилят свою версию webasm…
Надеюсь хотя бы это будет полное надмножество.
> Автоматически снимаются проблемы установщика.
А вот и не снимутся.
Просто установка/настройка будет происходить при первом запуске.
А о решении проблемы с деинсталяцией и мечтать не стоит…
А проблемы обновления по мне куда серьезней…
Erelecano
А зачем ждать?
https://habrahabr.ru/post/325102/
farcaller
http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos демкам уже несколько лет же
Contriver
Ура рекламщики потирают руки от ощущения кучи денег.
ага ядрёна вирусы,( загружающихся в память, во время исполнения- из за неведомого переполнения) зашифрующие диск(загрузочную область) за время нахождения на сайте при прокрутке какой нибуть 3 d картинки.Наконец будет неблокируемая исполняемая реклама.
Появится закрытый проприетарный код. . А если сайт взломают негодяи и как такой код найти и разобрать?
CestLaVie
По поводу вирусов — думаю, будет как с java-апплетами в своё время — начнут подписывать, а неподписанные будут по-умолчанию у всех блокироваться.
Deamon87
Уфологи в треде, все в летающую тарелку!
Вирусов не будет. Если бы была возможность они существовали бы уже сейчас. Суть в том, что нужно смотреть на то, какие API браузер предоставляет для JS окружения. То же самое API будет доступно со временем и для WebAssembly. Т.е. ничего нового не добавят
В 2011-м году браузеры добавили поддержку для произвольного доступа к папкам и файлам на HDD без участия юзера. Но потом это выпилили, по всей видимости из соображений безопасности.
Так что боятся нечего, живем!
KoToSveen
Вангуете?
BlessMaster
> как такой код найти и разобрать?
Разработчики антивирусов смотрят в недоумении и удивлённо пожимают плечами.
А разработчику зачем искать код вируса? Перезалил приложение и прописал права доступа как правильно, а не как всегда :-)
orcy
Вирусы вряд ли, так как это по сути тот же контекст JavaScript. А вот неотключаемая реклама — легко.
ShamanR
А вы пробовали сравнить скорость выполнения вставки куска ДОМа через wasm и обычными методами? Было бы интересно посмотреть быстродействие на реальных задачах, навроде обновления.
varanio
Глубоко не копал. Просто решил пощупать из любопытства.
kibitzer
Скорее всего так же, либо чуть медленее, т.к. на самом деле библиотека webplatform генерирует js код обычный, который вставляет дом элементы. Напрямую из WebAssembly c DOM пока работать нельзя.
acmnu
Там DOM же отдельная сущность, за пределами js. Не думаю, что что-то изменится принципиально, а вот появление рендеринга в стиле десктопных gui библиотек с отрисовкой через web-gl думаю можно ожидать в будущем.
Gorthauer87
Поисковики скажут большое спасибо таким приложениям.
acmnu
А зачем индексировать, например photoshop? Или IDE? Тут ведь речь скорее о суровых приложениях, а не сайтах.
rumkin
А зачем пилить UI на web-gl? HTML для этого гораздо лучше подходит. А вот операции с большими массивами данных лучше перенести в WASM. Получим гибкий интерфейс и быструю логику.
acmnu
По большей части из-за DOM, в котором сейчас все проблемы. Иерархичность, вложенность элементов никогда не была необходимым условием существования UI. Сейчас HTML выражает одну парадигму, судя по низкой производительности DOM, не всегда применимую.
rumkin
Мне кажется что в след за WASM появится какой-нибудь вариант типизированного DOM, который будет более предсказуем и менее затратен по памяти. Мобильные платформы в это очень нуждаются, а значит это привлечет интерес крупных вендоров.
acmnu
Ну это из разряда научить зайца курить. Можно, но зачем. DOM довольно точно и прямоленейно выражает идеи html — тем и ценен. Возможно надо попробовать отказаться от самой html+css разметки. Как мне кажется все эти модные вещи типа flexbox это именно попытка упростить вложенность и перегруженность современного html.
Например Хабравская лента комментов может быть сделана иерархично, когда каждый новый уровень вложенности достигается оберткой его в относительно текущего с фиксированным padding. А можно сделать их без вложенности с прямым вычислением смещения (похоже так и сделано).
Да и сам html… В текущих условиях это выглядит странно. Предлагаю нажать ctrl+u и увидеть сколько в тексте непосредственной информации, а сколько разметочной. Особенно разбалансировано выглядит лента комментов. А теперь представте, что у нас есть возможность скомпилировать всю разметочную информацию в удобный для браузера вид? В какой-то мере современный мир к этому движется, генерируя элементы на лету из JS, но только выглядит это странно: генерацией html и вставкой в текстовом виде в dom дерево, с последущим парсом и отрисовкой
rumkin
Давайте вспомним, что HTML это история не про приложения, а про документы. Здесь важна семантика от того и богатство возможностей каждого элемента. Но скоро появятся Custom Elements, и это уже будет шаг в сторону оптимизации HTML под приложения: вы сможете отдать с сервера древовидную семантическую структуру, а отобразить одномерным списком. После этого вопрос останется в том, чтобы дать разработчикам возможность более низкоуровневых оптимизаций.
acmnu
Ну так вы определитесь:
Или
CestLaVie
У меня такое ощущение, что работа с DOM`ом останется лишь для обратной совместимости с легаси, если же говорить о серьёзном геймдеве или всяких прогах с крутой графикой, типа Maya или хотя бы если WebStorm/IDEA в вебе — то тут, скорее всего, будет юзаться только canvas в 2d/3d-режимах. А из DOM`а в лучшем случае на старте какой-то контент будет вытягиваться, а то и от этого откажутся. Не верю я, что работа с DOM`ом не станет баттлнеком в случае перехода на WASM. Так что DOM для WASM`а — это настоящее, но не думаю, что — будущее…
amarao
Это плохо, потому что нативные интерфейсы ОС при этом будут игнорироваться. Прийдём к тому, что для того, чтобы мигать курсором, нам нужно будет выделенное ядро.
kekekeks
А они и так игнорируются. Веб жеж.
amarao
Нет. Сейчас поле ввода — это системное поле ввода (браузерное). Так же как и кнопки в формах. Я понимаю, что бутстрап и всё такое, но базовые элементы всё-таки подчиняются правилам браузера, которые в свою очередь используют правила ОС.
Условно говоря, если мы совсем забиваем на браузер, то мы рисуем на канвас не только своим шрифтом, но и своим растеризатором шрифтов со своим хинтингом и алиасингом, сами мигаем курсором, сами рисуем выделение и рассчитываем сколько пикселов глиф занимает.
vikarti
А это всегда плохо?
Уже есть товарищи которые свои шрифты на Canvas используют и получают за счет этого неслабые преимущества по сравнению с конкурентами — OnlyOffice тот же https://habrahabr.ru/company/teamlab/blog/141434/
За счет чего могут например нормально редактировать большие документы (чего Office365 / Google Docs не могут).
amarao
А если я монитор в вертикальное положение поверну и включу субпиксельный рендеринг с вертикальным RGB? Откуда веб-приложение будет про это знать?
А если я люблю slight hinting, а full hinting не выношу, то я могу это у себя в настройках системы включить. А в этом веб-приложении?
orcy
Если веб приложение рисует текст с помощью Canvas.drawText() то оно видимо может это знать, поскольку используется реализация браузера.
kekekeks
Можно libfreetype свежий с собой таскать и не иметь проблем. А шрифты сейчас и так уже повсеместно используют не системные, а загружаемые.
eiennohito
Игнорирование нативных интерфейсов — это вообще не выход. Сразу же все языки, где есть хитрый ввод (китайский, японский, корейский например) перестают поддерживаться. Или нужен будет кросс-платформенный API для доступа к состоянию IME и прочих средств ввода, чего никогда не будет, я думаю.
grossws
Зачем же так грубо. Не целое, а всего 30%.
amarao
Это пока используются нативные примитивы для перерисовки и обраружения клиппинга. А если мы всё своё пишем — придётся напрягаться. Ах, да, ещё же есть движения курсора…
kekekeks
Можно взять ту же самую Skia, которой хром и так рендерит весь контент. И не надо напрягаться.
BlessMaster
Ну вот тема внезапно получила неожиданное развитие :-)
Large
wasm не умеет dom, это работает только через внешние вызовы. игры и так в 3д рисуются, разве что частично UI бывает удобнее сделать на dom
radyno
Не думаю, что станет кардинально быстрее. Основная проблема при работе с DOM — пересчет и перерисовка дерева. Но даже если использовать wasm для этой цели, сильно быстрее пересчитывать вряд ли получится. Количество работы по пересчету всех позиций и расчету стилей останется тем же самым.
Large
сейчас это даже медленнее так как из wasm просто дергаются внешние функции на js, сама же wasm ничего о дом не знает и умеет только считать int и float 32 и 64, да в линейную память писать.
radyno
Я к тому, что это вряд ли вообще имеет смысл. Части кода, реализующие расчеты и отрисовку страницы после изменения, и так написаны на чем-то более низкоуровневом, чем js. Я думаю, там все сделано достаточно эффективно. Поэтому вряд ли будет профит от работы с домом из wasm.
kibitzer
Немного размер получаемого wasm бинарника смущает, 183кБ.
acmnu
Есть подозрение, что весь rust рантайм один в один скомпилирован в wasm. Думаю это пройдет со временем.
Dethrone
у rust нету рантайма.
acmnu
Смотря что под рантаймом понимать.
https://www.rust-lang.org/en-US/faq.html
Halt
Автор похоже собрал без --release. Не удивительно.
AlexTheLost
На мой взгляд идея крутая как и asm.js для написания именно библиотек/виртуальных машин, насколько я вижу они будут работать очень быстро(относительно быстро).
Но для реализации конечного продукта системные языки типа rust и с/с++ слишком не выразительны будет сильная потеря в производительности труда. По этому, интересно поддерживает ли данный модуль сборку мусора, которая в общем то есть в Rust? Насколько я понимаю память организуется как JS массив и управляется непосредственно модулем/приложением? Если уже реализована сборка мусора будет круто перенести на данный модуль ScalaJs, ClojureScript и др. нуждающиеся в автоматическом освобождении памяти.
bfDeveloper
Сборка мусора в планах, но в основном для взаимодействия с JS. https://github.com/WebAssembly/design/blob/master/GC.md
Сейчас модель памяти сишная, то есть без сборки мусора, но с указателями и адресной арифметикой.
Halt
В Rust сборки мусора нет. При желании, ее можно реализовать отдельной библиотекой, если вы сможете придумать, зачем.
AlexTheLost
Спасибо был не до конца осведомлен, я знал что Rust утилизирует память не явного участия программиста но не знал что это выполняется отличным от GC механизмами.
Если кому-то интересно: https://www.rust-lang.org/en-US/faq.html#is-rust-garbage-collected.
konsoletyper
Сборщик мусора можно и свой написать. Я уже частично портировал свой Java-JavaScript компилятор в WebAssembly: https://github.com/konsoletyper/teavm
TargetSan
Это позволит отправить JavaScript на то место, для которого он и задумывался — анимировать снежинки и связывать компоненты на странице. Языки со статической типизацией начинают доминировать после определённого объёма проекта — динамику сложно анализировать и рефакторить.
AlexTheLost
Согласен с вами по поводу динамики vs статики для больших проектов.
К тому же это подтолкнет к экспериментам и появлению новых все лучших подходов к разработки для web.
BlessMaster
Я бы не назвал Rust «недостаточно выразительным». Скорее наоборот — недостаточно выразительным выглядит JavaScript на фоне Rust, как только начинает писаться что-то сколько-нибудь сложное. Rust позволяет писать достаточно сложные выражения лаконично и компактно. Хотя многие применённые в нём концепции непривычны широкому кругу разработчиков и на первых порах у новичка может получаться достаточно неуклюжий и громоздкий код.
PsyHaSTe
Ну не знаю, очень неудобно работать со спецификаторами времени жизни, читать практически так же трудно, как J. Возможно, это от непривычки, но я с растом 1.0 знакомился когда он только вышел — было тяжко понять, что вообще происходит.
BlessMaster
А их никто не заставляет прописывать на каждый чих — в большинстве случаев они вполне подходят умолчательные и указываются только там, где ситуация нестандартна. Да и из практики скажу — не так уж они сложно читаются — просто ещё один вид параметров, достаточно легко отличимый от других и на ход выполнения программы не влияющий.
rumkin
Мне кажется, что для WASM должен появится новый язык транслируемый в С, а в дальнейшем компилируемый для других платформ. Т.е. для которого WASM будет первичен и избавлен от наследия, и при этом возьмет самое лучшее от современных разработок: транспиляцию вместо макросов, минималистичный синтаксис как в Go, централизованый репозиторий и т.п. Трансляция в C позволит создать ОС прямо в браузере, как пример.
BlessMaster
Любой язык, транслируемый emscripten прекрасно будет компилироваться в WAsm.
Библиотеки на разных языках будут интегрироваться на уровне WAsm.
Но WAsm — не серебряная пуля, проблемы интеграции, создававшиеся специфичным рантаймом языков останутся. Одна из сложностей крутится вокруг разных подходов к управлению памятью.
Создание при этом отдельного языка — вопрос ортогональный. Сколько угодно — лишь бы хватало энтузиазма :-)
«ОС прямо в браузере» — сомнительная затея, проистекающая видимо из непонимания целей создания WebAssembly и закладываемых в него возможностей и ограничений. ОС будет просто «тесно» в таких условиях, да и смысла — 0, чем эта ОС будет управлять, если её саму держат в песочнице?
rumkin
Про emscripten это и так понятно. Но разработчиков на C, D, Go, Rust, C# будет трудно объединить из-за идеологических разногласий, и здесь нужен аналог С для unix. Это мое мнение.
ОС прямо в браузере – это во-первых пример. Во-вторых, снижение порога входа в разработку это не "сомнительная затея", а спусковой механизм к расцвету технологического разнообразия, пример которого мы наблюдаем сегодня благодаря появлению персональных компьютеров.
Halt
rumkin
Я прекрасно понимаю что делает emscripten, но проблему это не решает, у каждого языка свой рантайм, вы захотите использовать одновременно модули, написанные на Go, Rust, Java если к каждому оверхед + несколько десятков мегабайт? Думаете, да? Посмотрите что сейчас происходит в том же linux, каждый язык поддерживает свой собственный зоопарк модулей зачастую выполняющий идентичные функции, потому что мало кто хочет использовать в проекте больше одной платформы. Язык это не просто форма представления, это несколько больше, это огромное количество логических примитивов, особенностей работы и философия. Наглядный пример Objective-C и Swift, я регулярно слышу от мобильных разработчиков фразы, вроде "может такой модуль есть на свифте?". Так что не стройте фантазий на тему того, что все языки заживут дружной семьей внутри WASM. WASM лишь выведет гонку языков на новый уровень.
BlessMaster
Многие языки просто делают обёртки вокруг системных библиотек. Сами системные библиотеки пишутся на разных языках, но предпочтение отдаётся тем, которые работают эффективней. Понятное дело, что большинство написано на C/C++, но есть примеры и библиотек на Фортране. Хотя, конечно, велосипедостроителей — тоже хватает. Но раз это устраивает соответствующие сообщества, то в чём проблема? Типовые наборы для платформ будут, как сейчас популярные библиотеки JS и веб-шрифты, грузиться с CDN и с большой вероятностью будут уже кешированы в браузере.
Go, Rust и Java самих по себе будет сложно подружить. Но как альтернативный язык решит проблему? Почему бы всем разработчикам не перейти на тот же Rust? Но они не хотят, их по тем или иным причинам устраивают родные Go, Java и прочие. То же самое и с каждым другим языком из длинного списка.
Ещё один язык как решит эту проблему? Будет ещё один язык, на который никто не хочет просто так переходить, тыкая своим богатым багажом наработок, накопившимся за десятилетия, в противовес молодой и малоразвитой экосистеме. Вот в чём весь вопрос.
Поэтому вопрос конкуренции языков никуда в ближайшей перспективе не денется. И его не решит дорогостоящий проект по созданию ещё одного самого лучшего языка, на котором не будет своих нужных модулей.
Причём даже его тотальная совместимость с тем же С и сишными библиотеками не решит проблемы языков, создававшихся, чтобы уйти от С. С++ — своя песочница, требующая написания специальной прослойки для совместимости с С. Rust — своя песочница со строгим контролем памяти, создававшаяся, чтобы избежать проблем С и С++. Обойма языков с GC — отдельная история — создававшаяся для избегания необходимости управлять памятью и проще писать код, даже серьёзно жертвуя производительностью. Какое из этих сообществ легко согласится пожертвовать своей песочницей в угоду возвращения к уровню С?
DarkEld3r
И введя новый язык мы заставим всех ненавидеть его одинаково из-за чего "идеалогические разногласия" пропадут? (:
rumkin
Это вы откуда взяли?
Вы не понимаете, что убедить людей использующих go отказаться от него в пользу C#, равно как и обратное, представляется невозможным. А вот предложить и тем и другим альтернативу, которая будет эффективно решать поставленные задачи, вполне возможно.
ozkriff
http://xkcd.ru/927
DarkEld3r
"Это вы откуда взяли?"
Кто-то в восторге от "простоты" Go и терпеть не может "перегруженность" С++//D/Rust, для кого-то сборка мусора принципиальный вопрос, кому-то подавай выразительности, кто-то рад дополнительным гарантиям раста и считается дополнительную сложность адекватной ценой. Вот какой должен быть новый язык, чтобы всем угодить?
rumkin
Недовольные останутся на том, что есть. Тех же кто захочет получить профит от вышеперечисленного не смутит отсутствие некоторых фич. Суть именно в том чтобы получить усредненный результат, а не тащить все и сразу. Тот же rust также появился.
DarkEld3r
Ну так я о том и говорю, что фрагментация только увеличится. Если, конечно, новый язык не будут навязывать, усложняя жизнь остальным.
Раст совершенно не похож на "усреднённый результат" и привносит уникальные (по крайней мере, для около-мейнстрима) фичи.
BlessMaster
Здесь просто напрашивается картинка про 15-й стандарт.
Ну, будет ещё один язык, который будет точно так же бороться за место под солнцем с C, D, Go, Rust, C# (и далее длинный список выше не упомянутых, но относительно популярных языков от Паскаля до Хаскеля). Чтобы стать по-настоящему популярным, ему потребуется выйти за пределы Wasm и начать применяться в других областях (или рано или поздно найдутся энтузиасты, которые его туда притащат.
С другой стороны сделать качественный и непротиворечивый язык — это весьма сложная задача. И язык должен решать задачи программиста, а не задачи платформы, иначе ему ничего не светит. Дальше — задача распространения языка, обучения специалистов, создания необходимого множества библиотек (в современных языках это достаточно большое множество), создание своего менеджера пакетов, создание IDE (задача на самом деле не менее ресурсоёмкая, чем создание самого языка).
Вы уверены, что все эти затраты — действительно стоят того, чтобы получить лишь немного лучше подходящий для конкретной ниши язык, возможности которого с лихвой перекрываются уже существующими более универсальными языками?
Нет, я не против того, чтобы появился ещё один язык, который будет на голову выше своих конкурентов и станет языком будущего, затмив другие решения. Но я точно знаю, что это не простая инженерная задача, и в современных реалиях под силу лишь солидному и хорошо финансируемому коллективу, без очевидных гарантий успеха.
Посмотрите на пример Rust — его уже не один год разрабатывает достаточно крупный коллектив. Разработка идёт очень открыто в тесном сотрудничестве с сообществом и это сообщество делает немалый вклад в развитие экосистемы. Но совершенно очевидно, что даже при таком участии большого количества людей сделать качественный современный язык — достаточно непростая затея. Убедить людей перейти на него, когда их в целом устраивает их текущий язык, с которым они делают бизнес и сильно зависят от него, накопив большое наследие и опыт — непростая затея.
После этого можете оценивать шансы и необходимость ещё одного языка, а тем более его шансы стать хорошим языком.
beduin01
Зачем что-то транслировать в Си если можно транслировать или в WASM или в какой нить IR/IL?
rumkin
Странный вопрос, затем чтобы можно было подключать сишные либы, пока своя кодовая база не наполнится.
grossws
Что мешает эти сишные либы компилировать в тот же LLVM IR?
rumkin
Для начала аргументируйте в чем преимущество использования IR. Но возможность скомпилировать библиотеку с помощью gcc важна для сообщества разработчиков открытого ПО как таковая.
При описанном мной подходе, я не вижу никаких препятствий для поддержки разных способов компиляции.
grossws
Скомпилируйте, пожалуйста открытую библиотеку Apache Lucene с помощью GNU GCC, если это столь принципиальная проблема, чтобы любой проект был компилируем GCC. Или предложите альтернативу. Подскажу, clucene и sphinx сильно отстают по функционалу, а lucenecpp загнулся.
А если вам не нравится LLVM IR, то используйте любое другое intermediate representation, никто не мешает иметь что-то подобное в результате работы фронта и оптимизатора gcc (за исключением самого gcc, конечно, если это ещё не вылечили). И дальше скармливать emscripten'у как бэкенду компиляции в asm.js/wasm.
rumkin
Это не проблема языка, то что Apache Lucene не может быть скомпилирован в gcc. Строить вавилонскую башню не вижу никакого смысла. Количество языков не должно быть слишком большим, чтобы не убить прочие плюсы, именно поэтому я и говорю о возможности трансляции в C наравне с WASM.
rumkin
Интересно за что минусы? Apache lucene написан на Java, если кто не в курсе.
BlessMaster
LLVM создавался как универсальный компилятор и в настоящее время имеет бэкенды для большого числа языков. Это своеобразный инструмент, позволяющий избегать велосипедостроения в достаточно сложной области — создании оптимизирующего компилятора под разные платформы.
Конечно, если смотреть на С/С++, для них существуют более эффективные компиляторы (тот же GCC для примера). Но эти компиляторы не так универсальны и их архитектура не позволяет их сделать настолько же универсальными, как и LLVM. Поэтому LLVM IR — такой себе лингва франка, в развитие которого вкладываются усилия многих сообществ и корпораций.
Это, к слову, о едином стандарте для разных языков: LLVM — один из кирпичиков этой универсальности. И такие языки как Python, получили свою дорогу в WAsm именно благодаря ему.
vlad20012
А можно будет скомпилить Servo в WASM и запускать браузер в браузере?
worldxaker
а почему бы и нет?)
Deamon87
Наверняка Servo опирается на вызовы системные функции, которые недоступны в браузере.
Поэтому чтобы запустить Servo в браузере — придется имплементировать abstraction layer на API, доступном в браузере. Нечто подобное происходит, когда вендор портирует Android на свой девайс(делается имплементация HAL)
worldxaker
это делает не вендор, а платформодежратель, в нашем случае qualcom, mediatek и т.д.
Siemargl
Не очень понятно, зачем изобретать webassembly — если это обычная байт-кодовая машина с JIT?
Их полно на любой вкус, начиная с Питона и заканчивая Явой.
Чтобы «зацепиться» за опять модное слово ассемблер?
Сколько ассемблер
халване говори,во рту слащебыстрее работать не станет.Deamon87
Как минимум — это позволяет более эффективно исполнять математику в браузере. JS не сильно дружит с системами типов и виртуальной машине JS приходится постоянно проверять, не изменился ли тип. Если тип изменился — вызывается неоптимизированная версия и чуть позже происходит возможная перекомпиляция JS в тот же машинный код. А это потеря производительности.
А с wasm — типы известны еще до исполнения программы.
Еще один минус JS — нету нативной поддержки Int64. Все числа в JS — double, под значащую часть выделяется только 56 битов и 8 бит под мантису. Из-за этого большие int64 округляются до 2^56 и теряется точность. А wasm поддерживает int64 из коробки
Large
Если тип не изменился — то не так уж и страшна эта проверка, так что не так все и плохо с математикой в js. Плохо правда, что не всегда делается приведение операций к типу данных и при сложении int8 могут использоваться операции над int32, но это сейчас в процессе доработки.
Поддержка int64 и вообще чисел произвольного размера добавлена в предложения.
На самом деле 53 и 11.
BlessMaster
«на вид-то он хорош, да зелен — ягодки нет зрелой» © :-)
Были б проверки для математики "не так страшны", так бы не бились над языками и алгоритмами для исключения лишних проверок откуда только возможно. Ветвление само по себе плохо сказывается на оптимизации производительности, поскольку нужно предсказывать по какой ветви пойдёт вычисление, но ещё и сокращает эффективность кеша — больше кода, более рыхлый код, больше данных (информация о типе), соответственно меньше оседает в более производительном кеше процессора.
И одна к другой таких проблем у JS много, как бы ни был крут JIT, ухитряющийся иногда выжать производительность всего-лишь на порядок худшую, чем у нативного кода.
Large
Так нет там ветвлений, там проверка входных параметров на соответствие ожидаемым, она достаточно простая, если она не проходит — все деоптимизация и попытка повторной оптимизации. Потому производительных жс выглядит довольно плохо так как приходится отказываться от любого вида мономорфизма. Иногда компилятор может быть уверенным на счет типа, если значение получено из типизированного массива (это пока не всегда хорошо работает, но это исправляют) или выполняется явное приведение типов. Так что в принципе как раз математику на жс писать можно довольно производительную, но на васм производительность будет более предсказуемой. По тестом это даже не на порядок, а в несколько раз 2-7.
BlessMaster
"нет ветвлений" и "проверка" — это взаимоисключающие параграфы.
Large
Ок, одиночное ветвление — это не ветвления
BlessMaster
А кто сказал, что оно одиночное? Если мы в цикле складываем элементы массива — ок, тут простая ситуация. Но обычно не это называют "математикой".
Large
Мы говорим про проверку сложных входных параметров, а дальше можно конечно написать плохой неоптимизируемый код, но как раз математика — это обычно про числа так что можно написать так, что лишних проверок не будет.
Large
Собственно теперешняя реализация васм очень похоже на то, что мы писали на асм если нужно было ускорить часть подсчетов. Разница пока только в инт64, расширяемой линейной памяти и более крутом динамическом связывании через таблицы.
BlessMaster
Опять же, динамическое связывание — это противоположность того, что необходимо для достижения высокой производительности. Но эта тема уже выходит за пределы парадигмы языка, созданного быть динамическим, так что требовать от JS прыгнуть выше головы — нет смысла.
Поэтому, собственно, и появился WAsm, — для заполнения этой лакуны, способный генерировать код близкий по производительности к нативному, в том числе благодаря возможности статически всё прописать и оптимизировать.
Large
от dll никуда не убежишь нельзя же все монолитом собирать. Брендон Айк сказал когда-то «Всегда ставьте на джаваскрипт» и пока его голова поднимается все выше, типизация тоже должна появится в каком-то виде, эксперименты с саундскрипт и юз стриктер уже были. Хотя про динамическое связывание было в сторону васм, это у него оно более крутое.
Васм появился скорее потому, что сам жс более многословный и его нужно было ужать во что-то более компактное. Асм был хорош, но очень уж толст и его приходилось долго грузить и парсить, а с типизацией там в принципе все было ок (хотя и не идеально, некоторые проверки оставались)
BlessMaster
Тут немного не то. Сами библиотеки могут подключаться динамически, но таки их интерфейс быть статическим, соответственно код остаётся статически анализируемым и оптимизируемым.
Но динамическое связывание вполне может быть и в монолитном бинарнике. Всё, что ведёт к определению типа в рантайме, проверкам в рантайме — всё это бьёт по производительности и надёжности.
WAsm позволяет избежать именно этого вида динамичности и достигнуть пределов возможного — полной отдачи от процессора. Но это не означает, что саму динамичность он исключает, нет — он даёт выбор, который был крайне беден в JS и появилось хоть что-то с asm.js.
Эволюция самого JS — тоже достаточно радующий факт. Возможно через несколько лет мы получим стандарт достаточно продуктивного языка. Но наследие со всеми странностями, нелогичностями и проблемами — ещё долго будет тянуться. Хотя, какой-нибудь очередной
strict modeи транспилеры могут решить эту проблему.Large
Я и не говорил, что он динамический, я вам говорил про то, что можно к примеру 5 васм модулей между собой переключать и пересвязывать через таблицы этих модулей, по сути это будет схема работы с dll.
Я никогда не спорил с тем, что динамическое определение типов ведет к лишним накладным расходам, но динамическое связывание это все-таки не о том.
Так и жс позволяет избежать этого вида динамичности благодаря развитию JIT.
BlessMaster
Тогда, возможно, мы просто говорили о разных вещах, ок.
JS не позволяет избежать динамичности в силу того, что у него просто нет соответствующих инструментов. И JIT, каким бы он ни был умным, не сможет из ничего сделать статическую проверку и оптимизацию. Речь ведь не только про конкретные типы переменных, речь про сам алгоритм.
В Rust мы можем выполнить проверку варианта с перечислением через
match— компилятор будет точно знать, что значение не может содержать ничего лишнего, "проверка" сведётся лишь к проверке значения дискриминанта и в соответствии с этим значением будет выбрана конкретная ветвь. Компилятор может статически проанализировать ход исполнения и убедиться, что какие-то ветви вообще не будут задействованы и просто исключить их. Компилятор может заранее вычислить все статические преобразования и убрать их из кода, заменив на вычисленные значения. Таким же способом он может вооще исключить вызовы функций, либо заинлайнив их код, либо в процессе упрощения выражений вообще сократив, как ненужные (что проблема для JS, который должен свериться с виртуальными таблицами методов у объектов). Много таких оптимизаций, которые возможны благодаря заранее и однозначно размеченному коду. Сюда же свобода от сборщика мусора — память управляется однозначно и предсказуемо, а большое количество типов не требуют отдельного выделения памяти в куче.Всё это то, чего JS не может предоставить компилятору в силу своей парадигмы динамического языка, максимально простого для пользователя. Сам же JIT — тоже требует времени на компиляцию, которая в случае компилируемых языков происходит заранее. Причём оптимизация может занимать времени в разы больше, чем сама компиляция (в случае с Rust это легко может достигать показателя "на порядок дольше") — в каком-то смысле это роскошь для JIT, хотя у него есть и свои, недоступные обычным компиляторам возможности.
Asm.js я здесь не рассматриваю, поскольку не знаю случаев, чтобы он напрямую использовался в разработке, а не как цель компиляции из других языков. Возможно, где-то, в особых случаях такое происходит, но это всё-таки скорее исключения, чем норма, и было бы интересно услышать опыт тех, кто этим занимался.
Large
Это боль =) Если серьезно, то немного математики туда впихнуть бывает очень удобно, кода получается меньше чем если компилить из с. Но если проект большой, то не вариант. Но в принципе оптимизации асм работают и не в асм режиме, так что можно для математических функций просто сделать аннотацию типов, работать с типизированными массивами вместо обычных и в целом это будет уже как гора с плеч для компилятора.
JIT делает предположения и по сути оставляет небольшое поддерево из всего множества вариантов, самое главное не разрушить его ожидания. Да JIT дорогой и время инициализации от этого растет, но не время выполнения. Скажем для игр это не так критично как для магазина одежды.
Large
То есть я сравнил асм и васм и сказал, что теперь там таблицы функций более крутые и динамичные, так что с ним можно работать как с длл. В асм тоже так можно было, но там проблема была во внешних функциях которые не аннотировались.
BlessMaster
В целом — я согласен, что WAsm достаточно близок к asm.js. Тут не о чем особо спорить: первый — развитие идеи второго и логическое его завершение. Просто не могли в конечном итоге не придти к представлению в виде байткода, поскольку это самое удобное и компактное представление, уже подвергнутое предварительной оптимизации, и не могли не сделать его максимально близким к низкоуровневой платформе.
Large
Это конечно сравнение мягкого с теплым, но для ориентировки подойдет wasm performance
BlessMaster
Я, конечно, не исключаю, что оптимизатор JS может проанализировать код и убедиться, что тип не должен поменяться — в такой ситуации можно выбросить проверку и это как раз хорошо скажется на производительности. В конце концов, за счёт чего-то таки потрясающих результатов таки добиваются.
Large
Может если сделать аннотацию типов как например в асмжс.
BlessMaster
Assembly и Assembler — таки разные слова. Более того, это слова, достаточно широко применяемые в английском языке, а не страшно звучащие заклинания, как в русском. Странно было бы придираться к слову «сборка», если есть некий язык под названием «сборщик»?
WebAssembly — это больше про сам байт-код, а не про виртуальную машину с JIT. Стандарт кода, интеграция с другими API браузера, изоляция веб-приложений. Байткодовую машину тоже с нуля никто не изобретал — она уже есть в браузерах для JS. Теперь же это всё (или ещё не совсем всё) упорядочено и стандартизировано.
Siemargl
Если посмотреть сайт вебасембли, там как раз своя стековая песочница. Написано на заглавной странице.
Вместе с маркетинговыми заявлениями про [задуманную] нативную производительность и компактный размер.
Исходники интерпретатора на OCAml тоже вполне можно посмотреть.
Так что все это новый велосипед, хотя можно было действительно взять V8 и ее байт код.
rumkin
WASM это в первую очередь универсальная библиотека, которую можно встроить в любой язык Python, JS, Ruby, C. Другими словами она не привязана к браузеру и может использоваться как элемент любых приложений, в том числе и десктопных. Например уже сейчас появился проект перевода криптовалюты Ethereum на WASM, что уже многое говорит о заложенной в эту нее (библиотеку) универсальности.
Siemargl
Библиотека? Мы на одном языке говорим? Зачем смешивать языки и браузеры ???
Библиотека это API, но я вижу только JavaScript API
С другой стороны, любой JIT может встроиться в адекватный по ABI язык/софтинку.
Но только в области скриптинга, боюсь, места давно заняты. Даже внедряемый режим TinyC — с компиляцией в нативный код уделает простой интерпретатор байт кода в десятки раз.
На самом деле это очередная драка за монополию за код в браузере — JavaApplets похоронили, Silverlight похоронили, Flash закапывают, освобождают место.
Потому пока что этот васмовский байт код засунули интерпретироваться в JS-машинку в браузере (хоть куда нибудь). Чтобы попытаться потом вытеснить и JS.
Кто сможет сожрать JS — получит много денег.
rumkin
Читайте доку (пункт 4) прежде чем писать такое.
Maiami
Приведу пример, для чего может быть полезен 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), а дополнение к текущим возможностям, без которых было бы менее удобно.
grossws
Если правильно помню, то в chromium/chrome собрались asm.js компилировать в wasm, т. е. asm.js там будет отставать от wasm'а не очень сильно. Ну и поддержка wasm появилась в актуальных chrome и firefox, что крайне радует.
Fuckoff95
Подскажите, пожалуйста.
С приходом wasm станет ли доступно управление TCP сокетом из браузера? Чтобы не использовать websocket.
rumkin
Нет. Это совершенно разные технологии.
YemSalat
Пробежался глазами по ссылке, но так и не понял как они собираются этого добиться?
По идее же все опять упрется в тормознутый DOM? Не очень понимаю откуда ускорение должно взяться.
BlessMaster
Как один из возможных вариантов оптимизации: если использовать текстовые шаблоны, Rust может сделать работу с шаблоном очень эффективной (наполняя строковой буфер, а не создавая тучу промежуточных строк в куче). Генерация же DOM-дерева через
.innerHTML, это обычно более оптимизированная операция, чем поэлементное добавление узлов с помощью JS. Не знаю, насколько это хорошо стыкуется с достаточно популярным JSX.Large
code/decode между строками и буфером будет довольно дорогим, я думаю они будут там реализовывать иммьютабл деревья для виртуального дома, но пока сложно представить как это будет кодироваться числами в линейной памяти.
BlessMaster
Почему? Что сделает его дорогим? Строка по сути и есть буфер. В любом случае одно преобразование — это значительно дешевле, чем масса промежуточных аллокаций на каждый объект JS. Тут уже нужно закапываться в устройство
Reactи детально изучать возможности, поскольку сложно что-то утверждать на основе догадок и предположений. Посмотрим, если у "энтузиастов" получится то, что они задумали — это будет хорошим знаком и примером, который будет стоить изучить всем. Хотя они вполне могли и ошибиться, неверно оценив задачу.Large
Ну потому что вам прийдется каждый символ строки превращать в число, потом передавать в васм и там с ним работать и потом возвращать обратно и снова превращать в символ и клеить из этого набора символов большую строку — это уже куча аллокаций. Это дорого, было даже предложение добавить стринг буффер чтоб этого избежать, но пока воз и ныне там. Это проверено экспериментами — игра не стоит свеч. Вообще строки в жс медленные и в парсерах сравнение делается по кикоду, чтоб не сравнивать подстроку с другой строкой и это быстрее.
Эффективнее хранить шаблон в теге шаблона и потом его клонировать и вставлять в дом. А вот дерти-чекинг виртульного дома операция вполне математическая и очень тяжелая, ее теоретически можно скинуть в васм если придумать как tries закодировать в линейную память.
BlessMaster
Не совсем понимаю суть операции. Строки в Rust — это массивы байт, которым гарантируется, что они являются корректным utf-8. Их не требуется дополнительно преобразовывать в "символы".
Кроме того, сами шаблоны вполне могут работать в режиме байтовых массивов, им не требуется быть полноценной строкой.
Large
так жс об этом великолепии ничего не знает, как только вы захотите строку из васма достать или в васм впихнуть — быть беде. а дом он в жс так что без этого никуда.
BlessMaster
Да, я про само представление строк в JS не подумал, там таки UTF-16.
Ну, никто не заставляет преобразовывать их в utf-8. Если у нас на входе будут корректные массивы байт с UTF-16 строками в шаблонах и значениях, то они же будут и на выходе. Хотя соответствующие примитивы для парсинга шаблонов в Rust придётся "завелосипедить".
Large
Тут даже не в том дело, нужно из строки создать массив значений и потом из массива значений склеить обратно строку. Операции элементарные, но дорогостоящие, особенно склейка. Прийдется преобразовать наборы числовых значений в символы и потом склеить их в одну строку — это обычно нивелирует всю скорость от работы с буфером. Если строковый буфер таки добавят в стандарт — тогда будет нам счастье.
BlessMaster
Строка в представлении JS — и есть массив значений. Технически какой-нибудь аналог
Vec<u16>илиVec<Utf16Char>. Преобразования не требуется, (разве что чисто номинальное, чтобы получить в Rust необходимый тип), данные уже являются набором байт (как и вообще всё в памяти машины).В том и суть, что Rust позволяет делать склейку дёшево — в едином буфере, что многократ эффективней, чем создание множества промежуточных строк, как это делается в JS. Точно так же Rust может склеивать и байты и массивы произвольных типов, "наливая" их последовательно сразу в конечный массив. В результате на выходе мы имеем уже готовую строку, которую только и остаётся передать в JS.
Именно поэтому я и предположил, что вынесение в Rust задачи шаблонизации, позволит достичь существенной экономии. Всё-таки этот язык создавался в том числе и для скорости, что достигается за счёт низкоуровневых операций, обычно недоступных в высокоуровневых языках.
Large
Вы не можете передать или вернуть строку в васм, вы можете передать или вернуть только буфер, а буфер можно забрать например из типизированного массива, а он о строках ничего не знает. Так что на стороне жс вы ничего не выиграете и никуда от этого преобразования не денетесь.
BlessMaster
Вы хотите сказать, что проблему создаст сам JS, выполняя некоторую бессмысленную работу? Тогда согласен, тут всё будет сложнее, нужно подробней изучать, как всё устроено, в том числе как получается этот типизированный массив и обртно строки из него.
Со стороны Rust подобных проблем не будет, поскольку он может прозрачно "трансмутировать" тип значений в массиве.
Но вообще, линейная трансформация строки, имхо, менее затратная операция, чем масса аллокаций в процессе обработки шаблона. Но тут уже решающее слово за бенчмарками.
Large
Да, не существует строкового буфера. Он только в предложениях на рассмотрение.
Бенчмарчили уже — все плохо. При склейке происходят множественные аллокации для создания большой строки из символов.
BlessMaster
Что ж, надеюсь под давлением насущной потребности это случится достаточно быстро.
BlessMaster
А может даже и велосипедить не придётся, всё-таки Rust создавался с мыслью о создании браузера.
Large
Те, кто минусуют, очевидно не могут аргументировать свою позицию по причине того, что они ТП — типичные программисты
YemSalat
На начальном рендере это так, но последующие обновления дешевле делать «атомарно» через DOM api (насколько я знаю, реакт так и поступает)
justboris
Вообще-то наоборот. Вот рассказ об этом, например: https://youtu.be/TXqiq5tOWRQ?t=3604
И именно поэтому React получается быстрее обычных шаблонов на том же Handlebars.
Swiftarrow7
Представил на минутку: Киберспортивные турниры проходят в mozilla firefox, chrome, edge и Yandex brauser. Как по мне будет прикольно XD
Zenus
1. Столманн негодует
2. Эм… пойду учить Go наверное