WebAssemblyに初対応したFirefox 52がリリース 60
ストーリー by hylom
レガシープラグインを使っていたサイト、どうなる 部門より
レガシープラグインを使っていたサイト、どうなる 部門より
あるAnonymous Coward 曰く、
Mozillaは3月7日、ブラウザ上でプラットフォーム非依存のバイナリ実行ファイルをサポートする「WebAssembly」に対応した「Firefox 52」を公開した(プレスリリース、OSDN Magazize、Engadget Japanese、PC Watch)。
WebAssemblyは、JavaScriptに代わる実行ファイルフォーマットとして主要ブラウザメーカーが共同で開発しているもので、これによりブラウザ上でもネイティブに近いパフォーマンスが期待できるとされている。一般向けブラウザとしての対応は今回が初となるという。同様の仕組みとしてはasm.jsが存在するが、こちらはあくまでもJavaScriptのサブセットであったため、パフォーマンス上の制約がかかっていた。
一方、Firefox 52では兼ねてより発表されていたNPAPIプラグインのサポート終了も行われている。かつ、本バージョンはWindows XPとVistaに対応する最後のメジャーバージョンになるともアナウンスされている(Slashdot)。
ESRも (スコア:2)
バージョン52はESR(延長サポート版)のベースにもなっています。
52のタイミングでNPAPIを廃止してXP・Vistaのサポートを最終としたのも、ESRのリリースに合わせたものですね。
XP・VistaでFirefoxを利用している場合、自動更新でESR版に差し替えられます。
Re:ESRも (スコア:1)
e10s 非対応なレガシーアドオンを使用しているので ESR に移行します。
確認される方は「Add-on Compatibility Reporter」を入れて、アドオンマネージャからご確認を。
(どこか mozilla のサイトでも確認できたはずですが、見つからず……)
Re:ESRも (スコア:1)
Are we e10s yet? [arewee10syet.com]で、2000人以上のユーザーがいるアドオンのe10s対応状況が確認できるね。
Re: (スコア:0)
e10sって必須になった?
Firefox51あたりまでは、extensions.e10sBlockedByAddonsを立てとけばよかったけど。
e10sが有効だとusercontent.cssが効かなくなるバグがあって、無効にしてた、
https://bugzilla.mozilla.org/show_bug.cgi?id=1046166 [mozilla.org]
って、これ53がターゲットになってたからまだ先だと思ってたら直ってるな。
Re:ESRも (スコア:1)
ただしESR 52では、通常版の52とは異なりNPAPIのサポートは継続される。したがってNPAPIサポートの有無をバージョン番号からは判定できない。またFirefox 50からClick-to-Playでブロックされているときはnavigator.mimeTypesなどから隠されるようになったので、機能検出もあてにならない。
Re:ESRも (スコア:1)
らじるやradikoやTBSラジオのストリーミング放送がWindows PCで聴取
できるのはたまたまこのおかげだったのか。
Adobe Flash Playerには過大な期待はしていないけど
利用できたものがもし利用できなくなるのならばそれなりに痛い。
Re:ESRも (スコア:2, 参考になる)
FlashはNPAPIプラグインのサポート終了の例外で、素のFirefox 52でもサポートされるよ。
Firefox 52以降はFlash以外のプラグインが使用不可に こっそり使い続ける方法とは [hatenablog.com]
Re:ESRも (スコア:1)
ご教示多謝。
紹介してもらったURIの説明を読んだら、
文体がユーモラスだけど無駄口もない簡潔平明とこの上を望むべくもない
優れものだったのでアツくなれました。
地味にイヤなのが (スコア:2, 興味深い)
Linux版はPulseAudioに依存するようになったこと。54まではALSAか選択できますけど。
Re:地味にイヤなのが (スコア:1)
alsaはインターフェイスとしてはいいんだけど、同時発音の実装は腐ってるから他にどうしようもない。
Re: (スコア:0)
PulseAudio の何が嫌なの?
Re: (スコア:0)
選択肢がなくなるのが嫌なんでしょ
Re: (スコア:0)
今までAlsaだけで運用できていたシンプル清らかな環境が汚されるから
Re: (スコア:0)
・個人使用の範囲ではほばなくてもいい存在(柔軟かつ多機能にはなるけど)
・勝手なことしてトラブルの原因になる(なってた)
・音を出すすべてのアプリケーションがPulseAudio前提で開発されているとは限らないのでコンフリクトの原因になりうる(なってた)
・公式サイトのドキュメントがクソ古いまま更新されない(いまどき man なんてみたくねえ)
まあ最近は大丈夫なのかもしれませんけど PulseAudio = controversial software っていうイメージはまだ強く残ってる(はず)。
Re: (スコア:0)
時代は --helpだな
Re: (スコア:0)
ALSAがあるさと思ってたら
使えないってなると困るだろ?
Re: (スコア:0)
少し前から、firefox って jack に対応しているんだけど、そっちは残るのかな?
Android版のほうが最近は重要 (スコア:2, 参考になる)
独自レンダリングエンジンでセキュリティ修正もしてくれているため、
古めのAndroid端末ではFirefoxが非常に重宝しますね
これのおかげで中古端末ではiPhoneよりもAndroidのほうが安全と言えます
iOS9で脆弱性大量放置のままサポート切れし、ブラウザもセキュリティ大量のSafariコンポーネント利用必須の環境より
なおSafariのタブは3つ開くと後ろでどんどんタブやアプリが死んでいく模様
Chrome 57もWebAssemblyがデフォルト有効に (スコア:1)
Google Chrome 57 Released with WebAssembly Support, 36 Security Fixes [bleepingcomputer.com]
9日にリリースされたChrome 57も、WebAssemblyがデフォルトで有効になったそうです。
実際試してみたら、WebAssembly公式サイトのデモが動きました。
# しかし2日遅れで話題はFirefoxに持っていかれてしまった模様。
WebAssemblyって (スコア:0)
ゲーム以外に使い道あるのかなあ。
いまJavaScriptで構築されているWebサイトが、JSを捨ててHTML + WebAssemblyになったりするんだろうか。
Re:WebAssemblyって (スコア:1)
今のJSへのトランスパイルはJSを強く意識した言語が多いけれど、
アウトプットがバイトコードのレベルだと出力結果の言語形式を意識する意味が無くなってくるから、
変換元言語がもっと多様になってくると思う。
JSは好き嫌いの意味では必ずしも人気のある言語ではないと思うし、実行時の不利なく他の言語が選べるならという需要は実は大きいと思う。
JSはかなり柔軟に書けるようになったとはいえ、Webアプリを作るうえフロントのプログラムはライトに作る意識は底流にあっただろうと思う。
しかし完全なプログラム言語の体を成すようになるとすれば、重厚なプログラムも主流になってくるのではと思う。
#思うばっかり。
Re:WebAssemblyって (スコア:1)
キラーアプリが出るかどうか、だと思うけどね。音声処理とか画像処理のライブラリとか。あとは、閲覧者にビットコイン発掘させたり。
Re:WebAssemblyって (スコア:1)
まだDOMは使えないのは。そもそも、開発言語がC/C++だし。
Re: (スコア:0)
ゲーム以外だとクラウドなOfficeツールとかIDEとかのパフォーマンス改善が期待できそうです。
MicrosoftやGoogleが積極的なのもそのあたりかなー、と
Re: (スコア:0)
「JSを捨てて」というか、今でも素のJS(やcoffeescriptやtypescript)からJSにトランスパイルして
デプロイしてるのが、
トランスパイルじゃなくて、JSからWebAssemblyにコンパイルしてデプロイになるんじゃないですかね。
Re: (スコア:0)
むしろゲームが動くようにして Steam の市場を奪いたいというのが本音では。
Re: (スコア:0)
とはいえ、Unity は 5.6β版でも、うまくビルドできないケースがあるみたいで、
Unity 開発者が WebAssembly を使うようになるのは、まだ先になりそうです。
4月に出ると言われる 5.6 リリース版でも、人柱扱いでしょうね。
WebGL 版が、安定して使えるようになったのが、Unity 5.0 が出て、
半年から1年ぐらいかかったから、WebAssembly もそんぐらいかかるのかな
Re: (スコア:0)
SteamってストアとDRM付のインストールパッケージのシステムで
大半はスタンドアローンアプリじゃん。
WebAssemblyごときで何が奪えるの?
Re: (スコア:0)
Re: (スコア:0)
JSよりは見かけ上難読化されてるっぽいとか?
# Webフォント絶対殺すマンでもFlashでの使用はガバガバとか、世間では技術的事実とかけ離れた判断が往々にしてなされる
Re:WebAssemblyって (スコア:1)
ほかにも同じことを言ってる人がいるが結局これは中間コードを配布してブラウザが解釈する方式に変更するわけだから現状のソースコードを丸ごと配布する形式と比べれば可読性は劇的に低下するだろう。少なくともコメントはなくなるし変数名も意味もない記号に置き換えられる。記号というか番号か。
大体ソースコードの中のプログラムとコメント分を区別してコメント分を無視する処理も無駄ですし。
あえて言うならJavaの中間コードを読めるような人には問題ないしそういう人はいることにいる。
Re: (スコア:0)
「ウェブブラウザ作るよ」
「いつもどおりOSの構築からかな」
「よし、巻き返すぞ」(アンチウィルスベンダー)
「(おこちゃまでも…おっとごにょごにょ)
誰でも使えるスパイウェア作成ツールだよ安いよ」(出遅れたウィルス開発者)
Re: (スコア:0)
UIもCanvasとかにすれば、普通に実行環境として魅力的になりえるかも。
結局のところ (スコア:0)
Flashみたいなもの?
Re: (スコア:0)
Javaみたいなものだよ。
また一歩javascriptがJavaに近づいたな。
Re: (スコア:0)
もうちょっと詳しく言うとJavaバイトコードみたいなものだな。
Re:結局のところ (スコア:1)
一般的には中間言語方式のコンパイラ・インタープリタですかね.
古くはUCSD pSystem [wikipedia.org]とか, FIG FORTH [forth.org], それにMS-BASICあたりから続く方法ですね.
多くの中間言語インタープリタがスタックマシン [wikipedia.org]モデルで実装されていたりするんだけど, 今回のはどんな構造なんだろう?
Re:結局のところ (スコア:2, 興味深い)
今回もスタックマシンです
CやC++で書かれたプログラムをwebassemblyにコンパイルするのが最初の目標です
emscriptenで普通のjavascriptやasm.jsにコンパイルするのはやっぱり強引だったということでしょう
Re: (スコア:0)
中間言語としてはスタックマシンではなく AST を保っているはず。
ASTのエンコーディングがスタックマシンになっているだけで。
Re: (スコア:0)
FIG FORTHの実装って中間言語だったのか・・・
Re:結局のところ (スコア:1)
30年以上前に移植したことがあるんですが, スタックマシンを構築するプリミティブなワードと中間言語を処理する内部インタプリタ, そしてOS/BIOSを直接叩くIO部分だけはアセンブラで組む必要がありますが, それ以外は基本的にワード定義の並びのままワードへのポインタ(相対アドレスだったかも)がリストになっています. この様な構造のため, 最小限の手間で多くのCPU/動作環境に移植できたわけですね. CPU/動作環境が雑多で, ハードウェアの制限が多かった1970年台末から1980年台初頭らしい作りです.
ただこうした構造から, 動作速度, 特にFORTHらしい多重のワード呼び出しはオーバーヘッドが大きくてかなり遅く, 当時の8bit CPUでは実用にはかなり厳しい状態でした. 速度が問題になる部分はアセンブラでワードを組んで, それをFORTHプログラムから呼び出すという感じですね.
Re: (スコア:0)
threaded codeというやつですな
https://en.wikipedia.org/wiki/Threaded_code [wikipedia.org]
fig forthはdirect threadingタイプ
Re: (スコア:0)
JavaApplet再びなのかとおもってしまったおっさん
Re: (スコア:0)
ただのFlashじゃないぞ。
Flash、JavaApplet、ActiveX、Unity、Silverlightといった先行ライバル技術を首尾よく排除することに成功したWeb業界が、
満を持して開発した「おれのかんがえたさいきょうのFlash」だぞ。
伏して拝領しろ。
Re: (スコア:0)
JavaAppletは無関係に衰退したし
Silverlightはわりと自滅だし
Flashはまだまだ普通に使われてるし
ActiveXはWindowsの骨組みだし
Unityに至ってはわが世の春じゃねーか。
Re: (スコア:0)
三者闘争には直接関与せず、一者独走になった時点で脆弱性につけこんでしれっと成り代わった普みたいなもんか。
Re: (スコア:0)
将来性ないってこと?
マジな話、何で同じこと繰り返すんだこいつらって思ってしまう。
レガシー拡張機能のサポート終了準備 (スコア:0)
大丈夫なんですかね?
レガシー拡張のままだとエンジン刷新も困難だからWebExtentionに移行したいのは分かるんだけど、WebExtention普及のための広報が弱すぎませんか。
ずいぶん前からWebExtentionに移行すると言ってる割りに、ユーザーがレガシー拡張を見分ける手段を提供してこなかった。
自分が使ってる拡張機能がWebExtentionかどうか、Add-onsで公開されてる拡張機能のどれがWebExtentionなのか分からないから、新規にWebExtention拡張を作った人がいてもそれを見つけることが出来なかったし、大半のユーザーはWebExtention拡張を探そうとさえ思わなかった。
WebExtention拡張が驚くほど少ないことをユーザーに分かる形で知らせておかないと、WebExtention拡張を作成する人のモチベーションも沸かないと思うんですが。(作ってもユーザーが来てくれないので)
Firefoxが実際にレガシー拡張を捨てればその時にWebExtention拡張の需要が爆発的に増える(というかFirefoxを使い続けるにはそれしかない)けど、それまでずっとWebExtention拡張の少なさを隠し続けたいのかな…
先に知らせるとChromeに逃げるユーザーが出てくるとか考えてるんですかね。
ろくなアナウンスも無い状態で完全移行する方がもっと酷いことになるだろうに。
そもそもChrome拡張と互換性があるとされてるけど、本当に互換性があるんでしょうか。
互換性があるならとっくにWebExtention拡張が普及してると思うんですが…
Re:レガシー拡張機能のサポート終了準備 (スコア:1)
APIに互換性があっても、最近のWebブラウザーでは各開発元の公式ストアに提出して審査を通らないと使えないので。
というかChromeのAPIに毛が生えた程度のことしかできない(従来API比だと「ほとんど何もできない」ってレベル)だから、移行が進まないのは当たり前。アドオン作者やユーザーの視点では何もメリットがないもの。
NACLとの違いがわからない。 (スコア:0)
PNACLと同じなのかな・・