Comments 22
С чистым WebAssembly или с emscripten
Сам пытаюсь ответить на этот вопрос)
TodoMVC Vue.js занимает порядка 100kB

TodoMVC Yew занимает в dev версии 13Mb, в release версии 1,1Mb

Собрать TodoMVC с флагами
`--target=wasm32-unknown-unknown`
и
`--target=wasm32-unknown-emscripten`
я не смог.
У кого получится — поделитесь рецептом.
понятно, следующий
$ rustup target add --toolchain nightly wasm32-unknown-unknown
$ cargo +nightly --target=wasm32-unknown-unknown
Чтобы ещё "зашакалить" вес результирующего WASM бинарника, используют/-вали wasm-gc
, wasm-snip
, wasm-opt
из binaryen. Детальнее есть в этой статье.
Общее желание и тенденция к уменьшению WASM-бинарников наблюдается.
К тому же, WASM by design парсится прямо во время скачивания, соответственно у него нет фазы парсинга и компиляции после загрузки, как у JS.
Посмотрим на сколько хватит энтузиазма у разработчика.
Как все таки выглядит процесс разработки целиком? Можно ли ошибки находить и исправлять прямо в браузере ( как при разработке на JS ). Есть ли плагины типа FireBug что ли для того чтобы видеть что там происходит в программе? Как увидеть значения переменных?
Кроме браузера — эту программу можно отладить как то еще? В дебагере каком то запустить?
Как все таки выглядит процесс разработки целиком?
Если скомпилировалось — значит всё работает и багов нет. Если баг есть — то он в бизнес-логике, и найти его можно просто медитацией над соответствующим кодов.
Работая в студии со удобными средствами отладки я раньше и не думал, что такое возможно. Поработав с солидити полгодика, где нет никакой IDE и дебаггера (кроме неработающего remix), просто от безысходности начал ловить баги, просто просматривая исходный код. И то солидити, где у меня куча багов была связанна с отсутствием ошибок при доступе по неинициализированному значению, опечатки в переменных циклов потому что нет нормальных итераторов, и прочих, а то раст…
С хорошим типизированным языком можно жить без отладчика, особенно если нет никаких FFI в натив.
Кроме браузера — эту программу можно отладить как то еще? В дебагере каком то запустить?
Можно дебажить с полноценным таргетом, там дебаггер будет, но браузерное окружение будет эмулироваться, и если баг сильно специфичный для браузера то так его не поймать. Но, как сказано выше, скорее всего этого не произойдет. Компилируемые языки потому и имеют такие «противные» компиляторы, что builds == runs реальная цель, которую они таким образом достигают.
Очень хотелось бы какой-либо пошаговый how-to с этим фреймворком. Прям шаг за шагом. Я понимаю, что есть примеры в репе на гитхабе, если несколько статьей около Yew.
Но нет никаких блогов/постов о том как шаг-за-шагом создать что-либо более-менее сложнее hello world с использованием сего фреймворка (мне, например, очень интересно, как работать с событийной моделью).
Если кто знает такие, буду признателен, если поделитесь линком.
Если браузер старый, без поддержки WebAssembly, то потребуется emscripten. Это, грубо говоря, эмулятор WebAssembly для браузера.
<зануда> Emscripten — это не эмулятор WASM, это LLVM-бекенд для генерации Asm.JS/WASM, JS-рантайм для сгенерированного кода и, видимо, ещё пачка всякого разного (вероятно, включающая и интерпретатор). </зануда>
demo skoppe.github.io/d-wasm-todomvc-poc
Исходники куда менее вырвиглазные чем на Rust
Самое узкое место в производительности веб-приложений — это ресурсоемкие вычисления при отрисовке DOM. Насколько я понимаю, WASM вообще никаким боком тут помочь не может. Зачем нужно городить ui-огород на Rust, если взаимодействие все равно просиходит через то же DOM API что и на JS? По моему, это какое-то нецелевое и малоэффективное использование WASM, хотя, конечно, эксперимент очень интересный.
В Elm мы просто создаем новую модель и отображаем ее на экране. Предыдущая версия модели остается неизменяемой.
разве она не будет «подчищена» сборщиком мусора после рендеринга?
В том же Elm вряд ли существует проблема какого-то конкурентного доступа. Старая модель нужна только для того, чтобы понять, когда производить рендеринг.
А как же концепция time travel?
Yew — Rust&WebAssembly-фреймворк для фронтенда