Pull to refresh

Comments 22

в WebAssembly или в чистом расте?
$ du -h target/wasm32-unknown-unknown/release/todomvc.wasm
408K target/wasm32-unknown-unknown/release/todomvc.wasm

--release и после wasm-gc
Я бы сказал верный вопрос:
С чистым WebAssembly или с emscripten

Сам пытаюсь ответить на этот вопрос)

TodoMVC Vue.js занимает порядка 100kB
image

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

Собрать TodoMVC с флагами
`--target=wasm32-unknown-unknown`
и
`--target=wasm32-unknown-emscripten`

я не смог.

У кого получится — поделитесь рецептом.
>в release версии 1,1Mb
понятно, следующий
$ rustup target add --toolchain nightly wasm32-unknown-unknown
$ cargo +nightly --target=wasm32-unknown-unknown
Спасибо Antti
Смог cобрать TodoMVC с флагом `+nightly --target=wasm32-unknown-unknown`
395Kb

image

Чтобы ещё "зашакалить" вес результирующего WASM бинарника, используют/-вали wasm-gc, wasm-snip, wasm-opt из binaryen. Детальнее есть в этой статье.
Общее желание и тенденция к уменьшению WASM-бинарников наблюдается.


К тому же, WASM by design парсится прямо во время скачивания, соответственно у него нет фазы парсинга и компиляции после загрузки, как у JS.

Если честно чувствуется усталость от ежедневного появления новых фреймворков.
Посмотрим на сколько хватит энтузиазма у разработчика.

А какие ещё есть wasm-фреймворки на расте?
Вообще есть, но не для веба.
Вы пишете: отладка WebAssembly — это сложный вопрос…

Как все таки выглядит процесс разработки целиком? Можно ли ошибки находить и исправлять прямо в браузере ( как при разработке на JS ). Есть ли плагины типа FireBug что ли для того чтобы видеть что там происходит в программе? Как увидеть значения переменных?

Кроме браузера — эту программу можно отладить как то еще? В дебагере каком то запустить?
Как все таки выглядит процесс разработки целиком?

Если скомпилировалось — значит всё работает и багов нет. Если баг есть — то он в бизнес-логике, и найти его можно просто медитацией над соответствующим кодов.

Работая в студии со удобными средствами отладки я раньше и не думал, что такое возможно. Поработав с солидити полгодика, где нет никакой IDE и дебаггера (кроме неработающего remix), просто от безысходности начал ловить баги, просто просматривая исходный код. И то солидити, где у меня куча багов была связанна с отсутствием ошибок при доступе по неинициализированному значению, опечатки в переменных циклов потому что нет нормальных итераторов, и прочих, а то раст…

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

Кроме браузера — эту программу можно отладить как то еще? В дебагере каком то запустить?

Можно дебажить с полноценным таргетом, там дебаггер будет, но браузерное окружение будет эмулироваться, и если баг сильно специфичный для браузера то так его не поймать. Но, как сказано выше, скорее всего этого не произойдет. Компилируемые языки потому и имеют такие «противные» компиляторы, что builds == runs реальная цель, которую они таким образом достигают.
Все поглядываю на Yew. Честно говоря, пока что использовать «чистый» wasm гораздо удобнее. К сожалению, либо я не внимательно читаю, либо в статье этого нет, в чем приимущество перед «чистым» wasm?
Очень хотелось бы какой-либо пошаговый how-to с этим фреймворком. Прям шаг за шагом. Я понимаю, что есть примеры в репе на гитхабе, если несколько статьей около Yew.
Но нет никаких блогов/постов о том как шаг-за-шагом создать что-либо более-менее сложнее hello world с использованием сего фреймворка (мне, например, очень интересно, как работать с событийной моделью).
Если кто знает такие, буду признателен, если поделитесь линком.
Если браузер старый, без поддержки WebAssembly, то потребуется emscripten. Это, грубо говоря, эмулятор WebAssembly для браузера.

<зануда> Emscripten — это не эмулятор WASM, это LLVM-бекенд для генерации Asm.JS/WASM, JS-рантайм для сгенерированного кода и, видимо, ещё пачка всякого разного (вероятно, включающая и интерпретатор). </зануда>

Самое узкое место в производительности веб-приложений — это ресурсоемкие вычисления при отрисовке DOM. Насколько я понимаю, WASM вообще никаким боком тут помочь не может. Зачем нужно городить ui-огород на Rust, если взаимодействие все равно просиходит через то же DOM API что и на JS? По моему, это какое-то нецелевое и малоэффективное использование WASM, хотя, конечно, эксперимент очень интересный.

В Elm мы просто создаем новую модель и отображаем ее на экране. Предыдущая версия модели остается неизменяемой.

разве она не будет «подчищена» сборщиком мусора после рендеринга?

В том же Elm вряд ли существует проблема какого-то конкурентного доступа. Старая модель нужна только для того, чтобы понять, когда производить рендеринг.

А как же концепция time travel?
Sign up to leave a comment.