Comments 18
Ну вот, javascript зажимают со всех сторон :)
0
Не зажимают, а расширяют. Правда производительность WebAsm пока под вопросом. Плюс пока еще частое обращение к JS API…
0
Почему под вопросом если WASM проектировался как с учётом более быстрого времени выполнения, так и с учетом более быстрой доставки на клиент?
Из свежего, например, вот годная статья. Из неё же по результатам:
Из свежего, например, вот годная статья. Из неё же по результатам:
The WebAssembly binary is in average 86 times faster than the actual Javascript implementation. The median of the speedup is 98.
0
JavaScript настолько брутально заоптимизирован в современных браузерах, что в случае изолированного кода для бенчмарков, wasm ещё и проигрывает нередко.
0
Есть ожидания, а есть реальность. Я просто оставлю это здесь js vs webasm
+1
Ну черт его знает… Прогнал все бенчи. Примерно 50/50. Там где JS уделывает — как правило, разница не большая. А вот у WASM в некоторых бенчах есть прям x2/x3 прирост.
Не могу сказать, что реальность прям так уж и расходится с моими текущими ожиданиями. Но, видимо, у нас с вами просто разные ожидания.
Не могу сказать, что реальность прям так уж и расходится с моими текущими ожиданиями. Но, видимо, у нас с вами просто разные ожидания.
0
И отлельный вопрос производительности произведенного golang кода wasm.
Меня довольно удручает еще и невозможность собрать минималистичный wasm код, без лишнего из рантайма.
0
Никто JS не зажимает, человек просто наглядно демонстрирует нам возможности.
0
Наглядная иллюстрация того как можно из пушки палить по воробьям.
+1
А можно ли в wasm подключать сторонние библиотеки? Например для работы с КриптоПро.
0
Везде надо стараться выбирать оптимальный инструмент, на любом языке программирования можно сделать куча извращений. Только зачем?
-1
Создание любой штуки, обычно, приследует некоторые цели.
Какие цели этого експерементального порта? Потому что можем?
Грустно становится, годика 2-3, и go гляди в франкинштейна привратиться…
Какие цели этого експерементального порта? Потому что можем?
Грустно становится, годика 2-3, и go гляди в франкинштейна привратиться…
0
Спасибо, статья годная. Нужно теперь какую-то обёртку для вызовов syscall/js, манипулирующих DOMом. В идеале — порт реакта.
По поводу шаблонизатора есть предложение не использовать mustache, он плохой. Как и стандартный. Предлагаю посмотреть на quicktemplate от автора fasthttp, не пожалеете
По поводу шаблонизатора есть предложение не использовать mustache, он плохой. Как и стандартный. Предлагаю посмотреть на quicktemplate от автора fasthttp, не пожалеете
0
Для манипуляции DOM или упрощения работы с, есть небольшая обёртка: https://github.com/dennwc/dom
0
Спасибо за хорошую статью. Кстати, ещё есть очень неплохой 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, например.
+1
имхо всё же myitcv/react более готов к продакшену, чем vecty
0
Sign up to leave a comment.
Как сделать поиск пользователей по GitHub на WebAssembly