Comments 18
Ну вот, javascript зажимают со всех сторон :)
Не зажимают, а расширяют. Правда производительность WebAsm пока под вопросом. Плюс пока еще частое обращение к JS API…
Почему под вопросом если WASM проектировался как с учётом более быстрого времени выполнения, так и с учетом более быстрой доставки на клиент?
Из свежего, например, вот годная статья. Из неё же по результатам:
Из свежего, например, вот годная статья. Из неё же по результатам:
The WebAssembly binary is in average 86 times faster than the actual Javascript implementation. The median of the speedup is 98.
JavaScript настолько брутально заоптимизирован в современных браузерах, что в случае изолированного кода для бенчмарков, wasm ещё и проигрывает нередко.
Есть ожидания, а есть реальность. Я просто оставлю это здесь js vs webasm
Ну черт его знает… Прогнал все бенчи. Примерно 50/50. Там где JS уделывает — как правило, разница не большая. А вот у WASM в некоторых бенчах есть прям x2/x3 прирост.
Не могу сказать, что реальность прям так уж и расходится с моими текущими ожиданиями. Но, видимо, у нас с вами просто разные ожидания.
Не могу сказать, что реальность прям так уж и расходится с моими текущими ожиданиями. Но, видимо, у нас с вами просто разные ожидания.
И отлельный вопрос производительности произведенного golang кода wasm.
Меня довольно удручает еще и невозможность собрать минималистичный wasm код, без лишнего из рантайма.
Никто JS не зажимает, человек просто наглядно демонстрирует нам возможности.
Наглядная иллюстрация того как можно из пушки палить по воробьям.
А можно ли в wasm подключать сторонние библиотеки? Например для работы с КриптоПро.
Везде надо стараться выбирать оптимальный инструмент, на любом языке программирования можно сделать куча извращений. Только зачем?


Создание любой штуки, обычно, приследует некоторые цели.
Какие цели этого експерементального порта? Потому что можем?
Грустно становится, годика 2-3, и go гляди в франкинштейна привратиться…
Какие цели этого експерементального порта? Потому что можем?
Грустно становится, годика 2-3, и go гляди в франкинштейна привратиться…
Спасибо, статья годная. Нужно теперь какую-то обёртку для вызовов syscall/js, манипулирующих DOMом. В идеале — порт реакта.
По поводу шаблонизатора есть предложение не использовать mustache, он плохой. Как и стандартный. Предлагаю посмотреть на quicktemplate от автора fasthttp, не пожалеете
По поводу шаблонизатора есть предложение не использовать mustache, он плохой. Как и стандартный. Предлагаю посмотреть на quicktemplate от автора fasthttp, не пожалеете
Для манипуляции DOM или упрощения работы с, есть небольшая обёртка: https://github.com/dennwc/dom
Спасибо за хорошую статью. Кстати, ещё есть очень неплохой react-подобный фреймворк Vecty:
github.com/gopherjs/vecty
Он пока не умеет WASM, всё через gopherjs, но ирония в том, что работать с syscall/js+wasm и gopherjs – это фактически одно и то же, там буквально синтаксически чуть поменять код :)
На vecty написан goplay.space, например.
github.com/gopherjs/vecty
Он пока не умеет WASM, всё через gopherjs, но ирония в том, что работать с syscall/js+wasm и gopherjs – это фактически одно и то же, там буквально синтаксически чуть поменять код :)
На vecty написан goplay.space, например.
имхо всё же myitcv/react более готов к продакшену, чем vecty
Sign up to leave a comment.
Как сделать поиск пользователей по GitHub на WebAssembly