JavaScriptは消滅すべきだったよな (767ﾚｽ)
上下前次1-新
437(2): 2012/10/14(日)20:35 AAS
通信上でデフレートしてるのはともかく、
HTMLもJSも、「最悪でも人間が読める」ために冗長にソースをそのまま転送してるからな。
JSを圧縮・難読化して転送とか、CｏｆｆｅｅScriptみたいなJS変換なんてナンセンスすぎるわ。
さっさとクライアントサイドスクリプトの戦国時代に入って、3年くらいで決着付けてくれ。Java以外でな。
438: 2012/10/14(日)21:44 AAS
みんな抽象的な話しかしないから全く話が進まないな
439: 2012/10/14(日)22:09 AAS
アップル、グーグル、マイクロソフト、三者それぞれ思惑があるからな
いまさら足並み揃えてクライアントにjavascript以外のスクリプト言語を載せるのは難しい
各自が独自のスクリプト言語載せたらコンテンツ提供側がついてこないだろうし
440(1): 2012/10/15(月)15:59 AAS
>>474
minimizeとかpackerとか知らんのかお前…
441: 440 2012/10/15(月)16:01 AAS
めっさ間違った…
×>>474
○>>437
442(1): 2012/10/16(火)06:24 AAS
ライブラリの読み込みやそのタイミング制御すらフレームワーク毎に手作りなのは
どうにも。
個別のフレームワークにはとても感嘆するし便利に使わせてもらっているけれども、
組み合わせて使おうとした途端に「混ぜたら危険」状態になるのはどうにかならない
ものか。
443: 2012/10/16(火)20:41 AAS
>>442
具体的に何と何を混ぜたいの？
444: 2012/10/31(水)09:30 AAS
言ってみれば大昔のFM-8, X1, PC-8801等々が乱立してそれぞれのプラットフォームごとに最適化されてるみたいなもんか
445(1): 2012/10/31(水)10:48 AAS
今なんか同じハードでもブラウザごとに最適化しなくちゃいけないとか馬鹿なことやってるよ
446(2): 2012/10/31(水)11:40 AAS
Webアプリはプラットホームの違いを吸収する（キリッ
447(1): 2012/10/31(水)12:49 AAS
>>445-446
最近はそのあたりライブラリ作ってる側が考えてくれてるけどね
個々のアプリ作者がブラウザ最適化うんぬんって言ってる奴は十中八九ライブラリの存在も知らずに全部手書きしてるバカ
448(1): 2012/11/04(日)09:21 AAS
>>447
でもそれも限界があるぞ。
ベンダーが個々に走ってるのは止まってないんだから。
特にレンダリングやCSS3に依存するインタラクションとか(必要かどうかはまた別問題)。
449: 2012/11/05(月)00:17 AAS
>>448
ベンダーが個々に走らないライブラリってなんだ？
ウェブ以外で。
450: 2012/11/06(火)16:18 AAS
>>446
うむ。しかし、オーバーヘッドがとんでもないことになったりしていい気がしない。Bubble Safariで600MBもメモリ食うとか、
やっぱり嫌気がする。
451(1): 2012/11/12(月)04:37 AAS
馬鹿とuyには無理
452: 2012/11/12(月)07:02 AAS
死ねゴミ共が
死ねゴミ共が
453: 2012/11/15(木)20:20 AAS
これ答えてあげてください
uyさん
外部ﾘﾝｸ:detail.chiebukuro.yahoo.co.jp
454: 2012/11/17(土)22:02 AAS
>>451
あれ？その２つ同じじゃね？
455(1): 2012/12/22(土)09:04 AAS
>>437
スクリプト戦国時代なんて、4，5年前に始まって、昨年ぐらいには終わった
456: 2012/12/22(土)10:51 AAS
javascriptは戦争での唯一の生き残りにこそなれなかったが
「ブラウザにとってのアセンブラ」という新たな地位を確立した
他国はjavascriptへコンパイルされる道を選び、
そして彼らの圧力のため、javascript自体も常に変革を迫られる存在となった
457(1): 2012/12/22(土)18:44 AAS
>>455
サーバサイドスクリプトじゃなくて？
LAMPとか確かに流行ってたが。
クライアントサイドPythonやRubyってあったか？
> 「ブラウザにとってのアセンブラ」
これ完全にJSの勝ちじゃん。
x86みたいに、今後30年以上JS意識しなきゃならんのか。
458: 2013/01/06(日)10:34 AAS
皆が、いつまでもperl使ってるときに、ajaxやrailsブームが来た
で、みんながpythonやrubyなんかの他言語を使い出した。
ここまでは技術的に当然の流れ。
それに便乗してきた、どうにもならない関数型がhaskell,ocaml。
多少なりともjvm上で動くことで実用性があったのがscala,clojure
最初から居て最後まで残ったのがjavascript。
ダグラス・アダムスが万物に対する究極の答えに42を選んだ具合に、
世の中の皆がPHP、jsで良いかと、何となく最後まで残ってしまった言語
459: 2013/01/06(日)17:39 AAS
俺の書いた駄レスをコピペしたアホだれだ
460: 2013/01/07(月)11:18 AAS
>>457
JSが敵不在のまま勝利って感じ。
今、一番稼働している言語はJSじゃない？
世界中のPC、携帯端末で動いているんだから。
461(1): 2013/01/07(月)14:34 AAS
いや、どう考えてもCだろう
と思ったが、
CPU時間の累計で考えると確かにJSかもな…
462: 2013/01/08(火)01:31 AAS
>>461
Cで書かれたスクリプト言語のランタイム実行中は
どう計算するんだ？
463(1): 2013/01/08(火)09:51 AAS
まあ、たいていのスクリプト言語の処理系は、Cで書かれてるだろうから…。
JS処理系はJSにカウントでいいでしょ。Javaで書かれたJS処理系とかもあるし。
464(1): 2013/01/08(火)22:04 AAS
>>463
無知をさらけ出した
465: 2013/01/09(水)18:22 AAS
>>464
プログラミング言語の実装の大半がC(or C++)言語で作られているは事実だろうし
この話の本質はJavaScriptのランタイムで動いているものはJavaScriptで
カウントすべしだろうから、それはそれでいいんじゃないかな。
少なくとも私はそっちの意見で賛成。
466(1): 2013/01/09(水)20:41 AAS
Javascriptで書かれた自前の処理シーケンスを記述した
データを解釈してバッチ処理をするプログラムは
自前の処理シーケンスという専用言語を実行していると
解釈されそうな気が
JavascriptのランタイムだってCから見れば
同じ様なものだろう。
上下前次1-新書関写板覧索設栞歴
あと 301 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.026s