ブラウザ、今後 5 年でどう変化する ? 70
ストーリー by reo
表現はリッチに、動作は軽快に 部門より
表現はリッチに、動作は軽快に 部門より
ある Anonymous Coward 曰く、
O'Reilly Radar にて、Opera の Charles McCathieNevile 氏へのインタビュー「What will the browser look like in five years? (5 年後、ブラウザはどう変化している? )」が掲載されている (本家 /. 記事より) 。
McCathieNevile 氏によると、ブラウザは今後コンピュータのインタフェイスの一部となり、今よりも目に付かなくなるだろうとのこと。人々が 5 年前、OS とその OS 上で動くソフトを元にコンピュータを選んだように、これからは人々はブラウザを選ぶようになるという。この 2 〜 3 年におけるブラウザの最も特筆すべき進化としては、JavaScript のスピードと機能の進化などを挙げながらも、長い目で見て最も影響が大きいものとして WAI-ARIA の登場を挙げている。
そして話題のタブレットコンピュータは「多様なプラットフォームを前提として開発することの重要性」を改めて浮き彫りにするのではないかと見ているそうだ。/.J 諸兄方の考える「5 年後のブラウザ」とは? 今後 5 年でどう変化する (して欲しい) とお考えだろうか?
ブラウザがどう変わるか、ではなくネットワークの使われ方の問題 (スコア:2, すばらしい洞察)
クラウドコンピューティングやらユビキタスネットワークやらが今後浸透していくにしたがって、ネットワークの先にデータがあり、ネットワークは常につながっているという状況になる。
そうなれば、自然とブラウザインタフェースがコンピュータ自体のUIになる。
ただし、UIはブラウザだが実際の処理はネットワークの向こうのリソース上で行われている可能性が高い。そこまでひっくるめてブラウザと言っていいのかは微妙かと。
しもべは投稿を求める →スッポン放送局がくいつく →バンブラの新作が発売される
IE6 (スコア:2)
とりあえず (スコア:2)
生涯の伴侶となる (スコア:1)
Memristor が従来の CPU&MEM を駆逐し、超小型高速大容量多値演算の人工知能が出現する。
未使用の周波数帯域が、インターネットの通信路に追加され、常時高速通信が可能となる。
マンマシンインターフェイスは、直接、脳とやりとりする。
かくして、AndroidX は字義どおりのアンドロイドとなり、額に貼られたシールだけが、その存在を示す。
表面は、高効率の太陽電池なので、目玉を描けず、美しくもない。
本人が寝ている間も、嗜好に合った情報を収集し続け、睡眠学習させる。
数年も経てば、人間が、AndroidX の伴侶になってしまう。
Re:生涯の伴侶となる (スコア:1)
さらに数年経つと、人間は要らなくなって、AndroidXだけが残った。
Re: (スコア:0)
俺の嫁
その後
俺が嫁
ということですか
ブラウザがプラットフォーム化した後の世界 (スコア:1)
ブラウザと呼ばれていたものの上で動作する「コンテンツビューア」なるものが。
そのコンテンツはマークアップランゲージで書かれている。
# そして歴史は繰り返す。親亀子亀の如く。
Re: (スコア:0)
んじゃオレ様はブラウザの機能のうち、システム関連でユニークな物をスピンアウして外部で管理する方法を提唱する。
それにより、ブラウザをハードの差異による問題から隔離しよう。
Re: (スコア:0)
縦書き (スコア:1)
Re:縦書き (スコア:1)
# これは過去のブラウザにあったのだっけ？
あんまり。。。 (スコア:1)
たいして変わらないような気がする。
クライアントサイドなんか意外とそんなもんだよね。
ふーん。 (スコア:0)
Re:ふーん。 (スコア:1)
そういう意味では、あのときMicrosoftの言い分が通っていたら、今の世界はどうなっていたんだろう。
クラウドという言葉が流行るのが2年くらい早まるとか・・・。
Re:ふーん。 (スコア:1, 興味深い)
有る意味ChromOSってのは、あの騒ぎと一緒ですからね。
昔の悪と言われていたものが逆に持て囃されたり。
ってのは、Javascriptなんかではもっと顕著か。
10年前程度だっけ?諸悪の根源とか言われていた時代は。
Re: (スコア:0)
ほとんどのWebサイトで使われているJavaScriptは、HTMLの至らない部分を補うハックであり、それで満足するのではなく、HTMLの規格をどんどん太らせたほうがいいと思います。
Re:ふーん。 (スコア:1)
HTML の仕様としては、スクリプト部分やスタイルシート部分を取り込まず、独立した「文書の仕様」として存在しているのはとても重要な点です。
これにより、ユーザーエージェント側では、任意の文書形式、任意のスクリプト言語、任意のスタイルシート言語を組み合わせて利用することができます。
これが HTML にスクリプト言語仕様などが取り込まれていると、それを解釈できないソフトウェアは HTML を操作できるソフトウェアとは見做されませんし、HTML 仕様に沿った文書は、もはや文書ではなく専用のアプリケーションデータと化してしまいます。
端的に言えば、プレーンテキストのファイルなどではなく、Excel のようなファイルとなってしまう、という感じですね。
スクリプト言語仕様が分離されていれば、ユーザーエージェント側が任意の実装 (*1) を行うこともできますし、JavaScript にとっては特定のデーター固有の言語 (*2) でもなくなることができます。
これらの点を踏まえると、HTML の至らない部分を補うハックという形で存在しているのは当たり前の事ですし、HTML としては、その至らない部分があることこそが汎用的な文書形式として存在するには重要なポイントです。
また、HTML の規格をがっつりと太らせた結果の一つとして XAML (for XBAP) などが既に存在しているように思えます。
規格を太らせるということは、それを満たす実装を用意することが非常に困難となり、結果、特定のソフトウェアベンダーに縛られやすくなったり、オープンソース系の実装が出てくることを阻害する要因となりやすいかと思います。
現状でも、企業の資金が投入されていないモダンな Web ブラウザー (*3) やオフィス文書用の編集系実装なんてありましたっけ? という状態なのですから。
(*1) IE が VBScript でも実行可能だったように、Perl や Ruby、Python などをユーザーエージェント側でサポートしていれば選択可能
(*2) Word や Excel における VBA のような存在ではなく、Netscape の Web サーバーで利用されていたようなサーバーサイド JavaScript や PDF 等における JavaScript の採用といった形で、特定のデーター形式やプラットフォームに依存しなくなります。
(*3) w3m は Web ブラウザーではありません。Web にもアクセスできるテキストビューアーです。
Re:ふーん。 (スコア:1)
JavaScript を前提とした形で作成しているとはいえ、JavaScript しか利用できないよう可能性すら失わせてしまうよりははるかにマトモだと思いますよ。
また、HTML の仕様にスクリプト言語を取り込んでしまった場合、ECMA-262 の改訂に合わせて HTML の仕様が改訂されない限り、Web ブラウザー等のユーザーエージェントでは最新の JavaScript 仕様を利用することはできなくなってしまいます。
XMLHttpRequest は IE の独自オブジェクトとして生まれたものである訳ですが、あなたにとっては Ajax を基盤技術にした各種 Web アプリなどはすべて否定される対象ということですね。
互換性はとても重要ですし、相互運用面でも独自規格は避けた方がいいというのは確かに同意できることです。
しかし、HTML には HTA のような使い方もあるのですし、完全に否定するようなものでもないように思いますよ。
Re:ふーん。 (スコア:1, すばらしい洞察)
gnomeはデスクトップ統合環境を実現しますが、OSと可分です。
Re: (スコア:0)
まあ、現実としてXもgnomeもマルチプラットフォームのレイヤとして
基盤といえるほど普及してないし、今後も普及しないだろうからね。
そっちは捨てて別の現実的な方を進めるのが吉。
Re: (スコア:0)
Webブラウザを動かすためにWebブラウザに特化したOSを作るのと、OSのUIをWebブラウザと同じ見た目にするではえらく違うような気が・・・。
Re: (スコア:0)
でも、それは売り物が違うだけでユーザーにとってはどっちも一緒。
作って居る本人たちは相手の方が間違っていると騒ぐかも知れないが。
Re:ふーん。 (スコア:1, 興味深い)
＞ユーザーにとってはどっちも一緒。
いや随分と違うんだが。
IE6専用の車内アプリを使っている場合なんかが顕著だけど、
・(MS的に)OSと一体化している → ブラウザのアップデートが事実上不可能
・ブラウザは単なるUIアプリ → 複数ブラウザをインストールして用途に応じて使い分け
開発側も随分と違って、
・(MS的に)OSと一体化している
→ ブラウザのアップデートはOSのカーネルに深刻な影響を与える可能性アリ
→ ブラウザのアップデートは金も時間もかかる。
・ブラウザは単なるUIアプリ
→ ブラウザのアップデートがOSのカーネルに影響を与える可能性は低い。
Re: (スコア:0)
少なくとも今は。
Re: (スコア:0)
Re: (スコア:0)
>ブラウザのアップデートはOSのカーネルに深刻な影響を与える
これはないだろ
Re: (スコア:0)
それはそれ、これはこれ！
ということで、HTML5レベルで互換が取れていて欲しい。
あとWebGLじゃなくても良いけど3D関係の標準化。
そこまで行けば、かなりのアプリがブラウザによりマルチプラットフォーム化が・・・。
# ぶっちゃけ、もうブラウザをfatにするしかないでしょ。
Re: (スコア:0)
いやブラウザを FAT にするのは勘弁してください。
せめて NTFS ですよ!
# え? 何か勘違いしてる?
5年前に同様の予想はなかったのかな? (スコア:0)
5年前の予想があったら今どれくらい当たってるか知りたい。
当時からブラウザのマルチプロセス化を予測できた人はいるかな? デュアルコアプロセッサがぼちぼち登場し始めたころだから不可能な予測ではなかったはず。
Re:5年前に同様の予想はなかったのかな? (スコア:1)
特に出典は知らないけど、3～4年前のJava Scriptベースのリッチクライアント(Google Readerとか)は多少もっさりして過負荷ぎみだったので、「JavaScript のスピードと機能の進化」は必然だったと思います。
翻ってマルチプロセス化は果たしてメリットあったんでしょうかね？マルチプロセッサのメリットは従来のマルチスレッドでも充分生かせるわけで。手元の環境上のChromeは、Flashは相変わらず重いし、タブが落ちる時は他のタブも同時に落ちる事多いし。(自分の環境だけだったりして…ドキッ)
Re:5年前に同様の予想はなかったのかな? (スコア:1)
マルチプロセス化はプロセスのメモリ空間が分離される点や、プロセス単位の権限分離が行いやすいという点で、速度的なメリットよりもセキュリティー面としてのメリットの方が大きいでしょう。
プロセスのメモリ空間が分離されることで、親ウィンドウ、他のタブやウィンドウで保持している内容へアクセスするにはプロセス間通信を行う形を取らざるを得なくなります。
権限を分離して一般ユーザーよりもより小さな権限しか持たないプロセスとすることで、一般処理時において攻撃可能な操作や情報を激減させることが可能です。
これらはマルチスレッドではかなり難しい実装となります。(同一プロセス空間内で利用しているユーザー権限がコンテキストにより異なる状態が発生し、管理が複雑になりやすすぎる上に、スレッドごとにユーザーを切り替える実装系を OS レベルに対して搭載する必要がある)
MAC 等がない状況における *NIX での実装ではこの形は困難ですが、MAC フレームワークを利用することでこのメリットを享受することは可能なのではないでしょうか。
Windows では IE における保護モードの実装でこの点を既に行っていますね。この点は、Windows Vista 以降のユーザーは (IE 等の対応ブラウザを利用していれば) ユーザーはメリットを享受しているはずです。
一般ユーザーにとっては非常にメリットとしては見え辛く、気付きにくいどころか気付いてさえもらえない、実装によってはユーザーの操作を阻害するだけにしか見えないデメリットにしか見えないでしょうけど。
実際に、Vista の初期出荷時では IE の保護モード下において IME のユーザー辞書が利用できないといった点がありました。これは低権限のプロセスから IME の辞書に書き込みができるようにする = そこを攻撃の起点とすることができるという点で、ユーザーの安全性を意識すると正しい挙動であったと思っています。
描画領域ごとに su や RunAs で個別のプロセスを低権限ユーザーに切り替えた状態みたいなものですから、低権限時の専用辞書を使う程度であれば問題はないでしょうが、一般ユーザー権限時の辞書へそのまま書き込めるのは問題であると言えます。
# ATOK が Vista 対応版で最初から同様に書き込めたのは、利便性を重視したというよりもセキュリティーに対する配慮の低さからではないかと思っています。JustSystems はその辺りの面での意識は決して高いとは言えないし。
Re:5年前に同様の予想はなかったのかな? (スコア:1)
うーん、なんというかなぁ。
最近の/.Jって、ピント外れ文をダラダラ書く人が多くて対処に困る。(もともとこんな感じだっけ？
速度 vs セキュリティという話はしてないっしょ。
アクセス制限等をOSのプロセス管理に任せれば実装が磐石になるけれどオーバーヘッドが大きい
だなんてスレッド vs プロセス議論の原点だし
> スレッドごとにユーザーを切り替える実装系を OS レベルに対して搭載する必要がある
これは妄想臭いな。WebのユーザをOSユーザにマッピング可能なHTTPサーバの話を、ブラウザと混同してる。
> MAC 等がない状況における *NIX での実装ではこの形は困難ですが、MAC フレームワークを利用することで
日本語でおｋ
Re:5年前に同様の予想はなかったのかな? (スコア:1)
言っているのは「マルチプロセス化によるメリット」についてです。また、"「JavaScript のスピードと機能の進化」は必然だったと思います" と前コメントに速度面についての言及があったため、「その点ではメリットないだろうけど、別の面にメリットがあるよ」という話をしているのです。
IE の保護モードがどのようなことをしているのかを調べてみてはどうでしょうか。
MAC フレームワークと書かれているにも関わらず理解できないのであれば、たとえ強制アクセス制御と書いても理解できるようには思えませんね。
Re:5年前に同様の予想はなかったのかな? (スコア:1)
マルチプロセスにすることのメリットを言っている訳で、何か問題があるのでしょうか。
これをオーバーヘッドの少ないマルチスレッドで実現するには、スレッドごとに権限を分離できる実装が必要になる、という話をしているのですが、何か不思議な点はありますか?
以前のコメントと鏡を見た方がよろしいかと。
Re:5年前に同様の予想はなかったのかな? (スコア:1)
元コメントからたどって、前に言っている「プロセス」と「スレッド」と、あなたが言っている「プロセス」と「スレッド」の意味的な違いを考えた方がいいのではないでしょうか。
一部のコメントだけ拾って言われても困ります。
Re:5年前に同様の予想はなかったのかな? (スコア:1)
本話題におけるあなたの発言の異常さにびっくりしました。
今後、今回のように意味不明な発言を一切なさらないようお願いします。
Re:5年前に同様の予想はなかったのかな? (スコア:1)
申し訳ないですが、#1766452 [srad.jp] や #1766580 [srad.jp] のような意味不明で異常さに溢れているコメントは、なかなか見かけられませんよ。
そういう意味では貴重な体験でした。
Re:5年前に同様の予想はなかったのかな? (スコア:1)
ID でログインしたところで、テキなりなんなりの指定をした上でスコア補正で沈めたらいいんじゃないでしょうか。
Re:5年前に同様の予想はなかったのかな? (スコア:1)
この話題の大前提となる、「Chromeにマルチプロセスが導入された理由」をくどく長々と書いても良い反応は得られないでしょう。
今後は長文を書く前に、あなたの書きたいことを相手が知っているかどうか
そしてあなたに説明を求めているかどうか、確認してから長文を書くことをおススメします。
Re: (スコア:0)
マルチプロセスとマルチコアにはあまり相関ないかと。マルチコアに対するソフトのマルチスレッド化は今もって最重要課題なんで。
マルチプロセスはセキュリティ強化とメモリ肥大化が要因でしょう。メモリバカ食いのIE8やChromeなんてXP世代のハードじゃ無謀。たとえセキュリティ面が強化できても
Re:5年前に同様の予想はなかったのかな? (スコア:2, すばらしい洞察)
外れてても良いんだよ。
「どうなってると思う？」っていうのは、予想というより
自分の夢や希望を語っちゃう前向きで熱い場所であるべき。
ネイティブアプリの終焉 (スコア:0)
ネイティブアプリもブラウザへ移行していくと思う。
OpenGLはWebGLでラップされつつあるし、もう時間の問題。
ネイティブで残るのはデバイス直のユーティリティや制御系、計測系くらいじゃないかな。
ま、単にアプリケーションレイアの下に『ブラウザ』っていう階層が増えるだけだけどね。
Re: (スコア:0)
ブラウザはコンテンツ保護の仕組みを持っていないので、
音楽・動画・ゲームなどに関わるものは難しいと思います。
DRMの必要ないAJAXビューワー [livedoor.biz]なんてものも公開されてますが、
「データがブラウザのキャッシュに残る」
ということすら全く考慮されてなくて残念な感じです。
Re: (スコア:0)
たいした障害ではないと思う。
現状でも「音楽・動画・ゲームなどに関わるもの」が山ほどあるし。
少なくとも3D部分が何とかなったら、かなりブラウザゲーム側に
スライドするだろうなぁ。
ブラウザは今後コンピュータのインタフェイスの一部となり (スコア:0)
一方俺のブラウザは (スコア:0)
時を経るにつれ表現がエッチに、動作はますます重くなるのだが
何でだろうか？
それはPET論です (スコア:0)
デジャヴュ (スコア:0)
Re:デジャヴュ (スコア:1, おもしろおかしい)
>Opera の Charles McCathieNevile 氏へのインタビュー
Opera死亡フラグだな...
Re:結局変わらない (スコア:2)
より進化するにはブラウザ以外のものになる必要があるのではないかな。
はたして5年後かどうかわからないけど。
一般人が「情報を閲覧する」のと同じくらい、「情報を発信する」ことが同時並行に行われるようになるのではないかと。
ネットワークもv6が当たり前になれば、今のブログやtwitter、YouTubeのようなことが特別なインフラに依存せずに行われる。
ネットの常時接続性やキャパシティはキャッシュの仕組みでカバーされ、検索性や一覧性は言わずもがな、いろんな手段がある。
サーバインフラもクラウドのように汎用化してきたし、ブラウザのように「なんでも見れる」汎用ソフトのように「なんでも発信」のように集約されるかもしれない。
手元のPCがGoogleのノードのように情報を発信したり引っ張ってきたり、お互いに補完したり。
あれ？結局人々がシステムに組み込まれるのか？それなんてマトリックス？
ブラウザ=OSになるとか、どうでもいいかも。必ずそうなる必然の理由もないし。情報を見るだけなら他の機能を切り捨てるのはアリだろうけど。今は「情報は見るだけ」に偏りすぎてるきがする。話すことと聞くことが同列に扱われる電話のようになっていくかも。
ただの妄想なんで、あまり突っ込まないで。