JavaScript は何処へ行く? 97
ストーリー by reo
まっすぐ行って左 部門より
まっすぐ行って左 部門より
cheez 曰く、
JavaScript が今日最も重要なプログラミング言語の 1 つであることは、その善し悪しは別として疑いようもないだろう。各ブラウザは JavaScript エンジンのパフォーマンス向上に力を入れ、一種の競争のようなものが生まれている。そんなクライアントサイドウェブの共通言語ともいえる JavaScript にはこれからどんな未来がひらけているのだろうか? (InfoWorld の記事、本家 /. 記事より) 。
Google は「JavaScript の根本的な欠陥」を打開した新たな言語「Dart」を近々発表すると告知しており (/.J 記事) 、一方 Intel は並列処理機能を追加した「River Trail」で JavaScript の機能拡張を実現しようとしている (Publickey の記事) 。
一つ明らかなのは、JavaScript への需要は高まる一方であり、その結果この言語の限界がより一層浮き彫りになっているということであろう。JavaScript は今後開発者らの尽力によってより一層進化した第一級の開発プラットフォームを目指していくのだろうか? それとも現在の原子力発電を巡る世界的動向のように「より良い環境を求めて撤退」という道を進むのであろうか? もしくは、その両方を併せた新たな領域があるのだろうか?
新言語、必要? (スコア:3, すばらしい洞察)
> Google は「JavaScript の根本的な欠陥」を打開した新たな言語「Dart」を近々発表すると告知しており
JavaScriptが今注目を浴びている最大の要因は、既にブラウザ用言語として広く利用されている故に、動作環境が広く普及していて、開発者も数多くいることだと思うのだけど。
もしも、その利点を投げ捨ててもいいのなら、わざわざ新言語作らなくても、Perl/Ruby/Python/PHPなどの既存言語を、組み込み関数やら標準ライブラリをブラウザ用に整えて使えばいいんじゃないのかな?
もしも、JavaScriptが根本的な欠陥を抱えている、あるいはJavaScriptは好きじゃないけど仕方なく使っている、という人がそれなりにいるのなら、他言語をブラウザにもってくる、という方向になぜ進まないんだろう。
# 本当にないのか探したら、デスクトップアプリ用で、Javascript以外の言語も使えるのがあったので貼っとく。
# http://d.hatena.ne.jp/yuichi_katahira/20100219/1266592521 [hatena.ne.jp]
1を聞いて0を知れ!
Re:新言語、必要? (スコア:1)
JavaScript以外の言語の組込、今でも(昔から)実現してみせているのがInternet Explorer。XMLHTTPといい、妙なところで気が利いている(本分のHTML/CSSの解釈はまったくだめだめなのだけど)。
最初からJavaScript(当時はJScriptと言っていたっけ?)とVBScriptが使える上、サードパーティの実行エンジンすら組み込める、ActivePerl、ActivePython、ActiveScriptRuby……(今はActiveScriptRubyはRuby側のスレッド処理の都合でIEでの実行を拒否するようになっているはずだけど)。
#今だったら、JavaScriptで他言語のインタプリタか何かを書くほうが現実的かもしれない。
Re:新言語、必要? (スコア:1)
むっかーし見たことあるような、とか思ったら ja.wikipedia にすら書かれている [wikipedia.org] PerlScript on IE とかはどうでしょうか。
Re: (スコア:0)
Google Web Toolkit [google.com]
ってのもありますよ
Re:新言語、必要? (スコア:1)
そのGoogleが、例えばPythonでも組み込めばいいと思うんだけど。
なぜPythonなのか、よりも、なぜ新言語なのか、の方が難しい問いなんじゃないかなぁ。
1を聞いて0を知れ!
Re:新言語、必要? (スコア:1)
それだったら、新言語も流行らない、ということになるのでは?
1を聞いて0を知れ!
高機能化を求む (スコア:3)
ウィンドウベースの GUI 自体、使いづらいし古臭い感じになってきましたね。今後は、あらゆるアプリケーションがタッチパネルで操作するのが前提の、シンプルなものになっていくんだと思います。
従来の、ごちゃごちゃとしたメニューや意味不明の小さなアイコン、雑多な設定項目がいっぱい。そういうアプリケーションはどんどんメトロUI、タブブラウザ+タッチパネルを使う現代的なUIのものに変えていくべなんでしょう。
そのクライアントサイドの基盤、とても重要な言語が JavaScript となると・・・。言語仕様はよいです。プロトタイプ・プログラミングの書式は、オブジェクト指向の機能としては十分、なはず。
しかし、Java/Swing で提供された 表とか、リストとか、ダイアログ、ディバイダ、雑多な GUI パーツ。グラフィック関連の小回りの効く API がまだ、足りてないんじゃないでしょうか。Java/Swing の機構に乗っかって、なんとか提供できた機能を、JavaScript で同じようなものを作り直すとなると、果たして何倍時間がかかるのか。
Re:高機能化を求む (スコア:1)
たとえばExt.jsじゃ不足ですか?
あくまで簡易環境では? (スコア:2)
インタフェースはHTMLで準備されたフォームやIMGなどを配置するだけでよいので、 いわゆるGUIプログラミングを覚えなくても、ボタンやテキストのやり取りができたのが、 更にとっつきやすくしていたと思います。
他にもあくまでブラウザ上のサンドボックス内で動くので、 プログラムミスがシステム破壊につながるようなことがないのも良い点かもしれません。
自分も今ではいろいろな言語で書くようになりましたが、 一番最初に覚えたプログラミング言語になるのかなぁ。
未だにちょっとしたテキスト整形ツールなんかはJavaScriptで書きますね。
Windows上でちょっとプログラムしたいと思ったら、他に選択肢ないと思うんですよね。
# Linuxならawk・bash・vimマクロでやるわい。
Re:あくまで簡易環境では? (スコア:2)
Windows上でちょっとプログラムしたいと思ったら、他に選択肢ないと思うんですよね。
vbscriptのこともたまには思い出してあげてください…。
まあ、VBAコードのポーティング用にあるみたいなもんですが。
Re:あくまで簡易環境では? (スコア:1)
ああー・・・自分が使わないだけであるんでしたね・・・。
実際、vbscript使いの人はやっぱりぱぱぱーっと書けちゃうものなんですかね?
Re:あくまで簡易環境では? (スコア:1)
VBやVBAがIDEでぱぱぱーっと書けるのと比べたら、そういうのがない状態のVBScriptは一段劣ると思います。Visual StudioなりScript EditorなりIDEを使えれば、それなりに書けます。
ただ、ご存じかもしれないですが、VBScriptで書けることはだいたいJavaScriptでも書けるので(しかも近頃はVisual StudioもJavaScriptサポートしていますし)、あんまりVBScript使う必要性無いよなあと思います。JavaScriptのほうがだいたいのことは便利ですし。
とはいえ、それでも物足りなくて、私は最近Ruby使っています(人に使ってもらうものでもない限り)。
Re:あくまで簡易環境では? (スコア:1)
VBScript にあって Javascript にないのはOption Explicit と sleep だったかな。
両者に欲しいのは 64bit の整数と浮動小数。
# PowerShell が軽くなるといいのに
Re:あくまで簡易環境では? (スコア:1)
Windows Scripting Host が大抵標準で入っているので VBScript/JScript on WSH はまずほぼ確実に使えますし、Windows Vista 以降や XP でも .NET Framework を入れていれば C#/VB.NET コンパイラーが入ってると思いますけど。
ブラウザーを使わずに実行できるという点でも、この 4 つ (2 つ) が基本的な選択肢では?
# ローカルファイルアクセスをしないテキスト整形ツールがどの位嬉しいのかはわかりませんが。
Re:あくまで簡易環境では? (スコア:1)
と思っていた時もありましたが
Windows上だと標準ではないにしろ大抵アンチウィルスソフトが入っているので
WSHでちょっとADODB.Streamとか使うだけで
ウィルス扱いされて動かないことがある
Re: (スコア:0)
簡易なのはいいけど、安易にやってしまう向きが多い、気がします。
文字列を数値に変換するのに eval() 使え、と書いてるサイト、ずいぶんありますね...
Re: (スコア:0)
Re:あくまで簡易環境では? (スコア:1)
> 一番普及してる開発環境・実行環境がそうだというだけで
今後、Javascriptがブラウザ用言語の枠を越えて、広く利用されていくにあたって、なにげにこれ、問題だと思うんだよなぁ。
数多くの似たような独自仕様が乱立して、面倒なことになりそう。
1を聞いて0を知れ!
Re:プログラミング言語に貴賤無し[Re:あくまで簡易環境では?] (スコア:1)
こういう話もありますから。
俺は○○言語のプログラマーよりは上だ | スラッシュドット・ジャパン [srad.jp]
原発? (スコア:1)
どこから原発の話になるんだいったい。
Re:原発? (スコア:2)
まあ、タレコミの末文を「うまいことまとめ」なきゃ、と感じるあまりつい強引に落とす形になっちゃうことは多いよね。(タレコんだことないけど想像)
意外とcheezさんもその口で、政治信条云々はあんま関係ない。ってのが真相だったりするのかもしれない。
#余談ながら「うまいこと言わなきゃ」な風潮は世間一般にも蔓延しつつあるような気がしないでもない。あんまよくない傾向だよね、とか私は思う。
Re:原発? (スコア:1)
単に cheez さんはネタ元を翻訳してくれただけだと思うんです。
Hiroki (REO) Kashiwazaki
Re:原発? (スコア:2)
The answer seems to be a little of both.'"
英語が読めないんじゃ無いんだ、元ネタ読んでなかっただけなんだ
誤記 FireFox
巫女 Firefox [mozdev.org]
引用の要件 (スコア:0)
で、あれば、どこからどこまでがネタ元から取ってきた部分なのかが明示されるように編集する必要がありますね。
Re:引用の要件 (スコア:1)
Hiroki (REO) Kashiwazaki
Re:引用の要件 (スコア:1)
編集者がやらなくても、タレこむ人がそうすればいい。
# んじゃ、よろしく。
1を聞いて0を知れ!
Re:引用の要件 (スコア:1)
人より先にタレこめばいい。ヨタ話はともかく、重要なニュースに関してはそれでカバーできる。
文句のつけようのないタレコミを改悪されたなら、そのときは指摘すればいい。
それでもなお不満なら、よいタレコミをいっぱいして信用を得てから、自分も編集者になれないか、編集者のうちの誰かに相談してみるといい。
1を聞いて0を知れ!
Re:引用の要件 (スコア:1)
他の編集者に、reoさんの分まで余分に働けと?
1を聞いて0を知れ!
Re:原発? (スコア:1)
JavaScriptはこれから仕様の拡張を行おうと思えばできますし
開き直ってJavaScriptとの互換性を維持しつつ新しい言語を作ることも可能です。
それがどうして原発と関連付けなければならないのか説明してください>>cheezさん
Re:原発? (スコア:1)
「これも小泉失政のツケか…」的な
Re: (スコア:0)
>現在の原子力発電を巡る世界的動向のように「より良い環境を求めて撤退」という道
そんな道がどこにあるんだ。
Re:こういうあざといやり口が (スコア:0)
かえって自分の支持する政治信条への忌避を買うことを分かってないんだろ。
ネトウヨサヨと同じくらいに頭悪い。
Re: (スコア:0)
単に「なくすべきか」「変革すべきか」という問い掛けを時事ネタに絡めただけだと思うんですが・・・
イベントハンドラどうするの? (スコア:0)
Content-Script-TypeはHTML5で廃止されてしまったわけだが(イベント属性に書かれるスクリプトはJavaScript決め打ち)。
イベントハンドラをHTML属性として直書きすること自体がオワコン?
Re: (スコア:0)
Re:その前にだな (スコア:1)
誤記 FireFox
巫女 Firefox [mozdev.org]
Re: (スコア:0)
Firefoxをつかうと、/.Jがスクリプトを使わなくなるの?
Re:その前にだな (スコア:1)
NoScript または RequestPolicy などの拡張機能を入れろって意味だと思われ。
Re:その前にだな (スコア:1)
ええ、それは知っている。
だからこそ、『NoScript または RequestPolicy などの拡張機能を入れろって意味だと思われ。』と拡張機能によるアドバンテージを示したつもりだったのだが...
Re:その前にだな (スコア:1)
おお、そうなんだ。知りませんでした。具体的なブラウザの名前を教えてくれると助かります。
僕としてはサイト毎に設定できるのがFirefoxくらいしか知らなかったからなんだけど、その前提は崩れたようなので、Firefoxでなくても良いじゃないかな。
Re:その前にだな (スコア:1)
ああ、ある意味「やっぱり」でした。さすがOperaですね。
もう一度使ってみる気になりました。
どうもありがとう。
Re:その前にだな (スコア:1)
IE ですら制限サイトに突っ込めば、制限サイトの基本ポリシーによりスクリプトが無効化されますけど。
# まぁ他にもいろんなものが無効化されますが。
Firefox (というより Gecko) のアドバンテージは、JavaScript の中でも任意の機能を (それこそメソッド単位で読み出しは許可するが書き込みは禁止とかまで) サイトごとに on/off することができる、という点でしょう。
そこまでできるものは他には知りません。
Re: (スコア:0)
JavaScript自体は好きではないけど、/.Jレベルなら別に使っていてもいいのでは?
古すぎるブラウザを使ってるならまだしも、
今普通に使われているブラウザならエラーが出るわけでもないし、
そんなに重くなるわけでもないじゃないか。
JavaScriptを頑なに否定してる人って、
Webセーフカラー信奉者と同じにおいがする。
# 何かの絵がカーソルを追いかけてくるのだけは勘弁な
Re:その前にだな (スコア:1)
JS実行に関わる一式は脆弱性が潜みうるところですから、可能であれば殺しておきたいというのは、決しておかしな願いではありませんね。
便利か、セキュアか、両方か。ま、人それぞれ鞍点が違うってことですか。
Re:その前にだな (スコア:1)
昔は、Javascriptもそんなに使われてなかったし、切っても差し支えない場合が多かったから、そういう方法も有効だったけど、
最近じゃJavascriptないとまともに使えないサイトも増えてきたし、現実的でなくなってきてる気がする。
# Flashも同様。Javaアプレットは、もともと多くなかったけど最近さらに見なくなった気がする。
1を聞いて0を知れ!
Re:その前にだな (スコア:2)
そういう場合は大抵「about:blank」を信頼済みにしておけばOKです。
MSHTML(いわゆるIEコンポーネント)を使用している場合、最初にドキュメントオブジェクトが生成されたとき(中身が空白の状態)の扱いが「空白のページ」になるためです(デフォルトの状態ではabout:blankはインターネットゾーンです)。
Re:その前にだな (スコア:1)
おおう。参考になる。モデ権がないのでコメントで。
LIVE-GON(リベゴン)
Re:その前にだな (スコア:1)
再現するようなら一番下にある「バグ報告」のところがいいと思います。再現しなくても大丈夫だけど、それだとあまり改善は期待できない。
LIVE-GON(リベゴン)
Re:いろいろ安くなるからねえ (スコア:1)
テンプレートとなるHTMLをますブラウザに送っておき
後はXMLHttpRequestでJSON送ったり受け取ったりで
転送量が格段に抑えられるし ←機能を追加したはずなのに転送量は3/4とか
サーバのCPUにもやさしいし ←HTMLよりはJSONに整形する方が楽なのね
そんなわけで、スクリプトまみれになるのは、勘弁してくれよ。
その結果、スクリプトが解釈できなかったり、適切な状態に遷移するのが面倒な読み上げブラウザーや点字ディスプレイなどで壊滅的に使いづらいサイトになって、アクセシビリティー最悪になるんですね。
わかりますわかります。
検索エンジンにも引っかからなくなって一石二鳥ですね。
静的 HTML を主体としたサイトにして、補助的にクライアントサイドでスクリプトを利用させて「より便利に使える」くらいの使い方の方がサーバーの CPU には優しいですし、圧縮きかせて転送量が 3/4 になって嬉しいと思えるほどのコンテンツを送り込んでるとしたら、元の転送量がでかすぎるでしょう。
サーバー側の負担は軽くなるかもしれませんが、XMLHttpRequest でコンテンツ受け取って HTML に変換して出力するのは、万遍なくクライアントサイドの CPU コストを上げることになるし、非力なスマートフォンなどの端末を考慮するとあり得ない選択肢としか思えませんが。
ついでに言うと、セッションが張りっぱなしのまま通信できるそれなりに短い間隔での通信でないと、セッションをちょこちょこと張りなおすことによるサーバー側のコスト増もあるのではないでしょうか。
Re:いろいろ安くなるからねえ (スコア:1)
その辺りの話については、普段のアクセス量とサーバー群の数などでもまったく状況は変わるわけです。1byte 削減の効果がどれだけのインパクトがあるか、という点を考慮しましょう。
というか Google の「あの無味乾燥なトップページ」は JavaScript が無効でも利用できますし、検索結果もそうですよね。
ただ、元のコメントは「検索結果ページのベースだけ」サーバーが HTML として出し、検索結果などをすべて JSON で流し込んで転送量を削減する、という話になるんですけど。