WASMとRustはVue.js/React.jsを打倒するのか？ - JSへの侵略の歴史
はじめに 「Typescriptの次はRustかもしれない」という記事がバズってるのを見かけました。 なかなか面白くて、PAとしてのWASMとRustを比較している記事です。ちょうど最近「レガシーおじさん、SPAを始めてみた。そして限界を知る」でも書いた通り最近SPAに手を出してみたのですが、いろいろやろうとするとSSRのためのBackend for Frontend (BFF)等が必要になるとわかり「これJSでやる必要なくない？」とも感じていたのでちょうど良かったです。 こういうのを見るとRIAやGWTのように似たアプローチで廃れた技術や、登場が早すぎたMeteor、今も頑張ってるMSのBlazorなど色々頭をよぎります。といわけで歴史を俯瞰する意味でHTML + JavaScriptとそれ以外の技術のせめぎ合いの歴史やMSのBlazorやRustのyewなどWebassemblyを使う
Firefox 58でWebAssemblyの起動を大幅に高速化 - Mozilla Flux
WebAssemblyは既にメジャーなブラウザすべてでサポートされており、その用途も、たとえばGoogle Earthが移植されるなど、ゲームに限られなくなってきている。もっとも、これまではダウンロード後のコンパイルに時間がかかるという問題があった。Firefox 58では2つの新技術でこの問題に対処し、WebAssemblyアプリケーションの起動を大幅に高速化する。 Making WebAssembly even faster: Firefox’s new streaming and tiering compiler – Mozilla Hacksによれば、1つ目の新技術はストリーミング（Streaming）という。ダウンロードの完了を待たずにコンパイルを開始するもので、この技術はWebAssemblyのファイル形式と相性がいい。単一のファイルのうち、最初にコード部分がダウンロードされる
巨大 WebAssembly ファイルのコンパイル時間
funcs というのは、wasm 内に何個関数が入っているか、です。1 func の場合は Function body が約 25Mb、100,000 funcs の場合は約 2.5kb、500,000 funcs の場合は約 0.5kb です。 Chrome では 20秒〜1分 ほどかかっています。なおこのコンパイル処理は現在の Chrome の実装だとページをロードする度に必ず発生するので、巨大 WebAssembly が存在するページを Chrome で開いた場合、キャッシュの有無等と関係なく相当待つ必要があります。 Firefox だと、Function Body のサイズによって処理時間が大きく変わります。1 つしか関数がないときはクラッシュしましたが、Function Body が小さくなるにつれて速度が向上しています。例えば Emscripten 等で出力される巨大な Web
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
