+ JavaScript の質問用スレッド vol.125 +
レス数が950を超えています。1000を超えると書き込みができなくなります。
JavaScript を自ら学ぶ人のための質問スレッドです。
>>2-4のテンプレを読んだ上で質問してください。
■質問を書く上で
(1) 煽り、コード制作依頼等、人を不快にさせる投稿はご遠慮下さい。公序良俗を守った応対を心がけてください。
(2) 他の人に迷惑をかけるスクリプトの質問はご遠慮ください。
(ブラクラ、[戻る], [閉じる], [クリック] の妨害、画面占有など)
(3) 質問者及び議論を行う人はメール欄を空欄にし、名前にレス番を入れることを強く推奨します。回答者はなりすましを判断できませんので、なりすましが現れても自己責任となります。
(4) 常に自発的に調べる心構えを持ってください。
具体的には「自分で調べてから質問する」「回答をもらってわからない単語があればGoogle検索してみる」など。
わからない内容を代わりに調べてくれる回答者をお望みの方は余所で質問してください。
(5) 出来るだけ一般的な用語を使用してください。脳内オレオレ用語は混乱の元です。
(6) 出来るだけサンプルコードを掲示してください。言葉による説明は行き違いが生まれる場合があります。
※必ず「問題の事象が再現されること」を確認してください。
必要な部分だけ切り出したつもりで現象が再現できていなかったケアレスミスがしばしば見られます。
(7) サンプルコードに HTML が含まれる場合は http://validator.w3.org/ で [Check] してみてください。
(8) 質問を具体的かつ詳細に書くと回答を得られやすいです。>>2の質問テンプレートを活用してみてください。
(9) 時にはあなたが望む「答え」だけでなく、「意見」などが寄せられる場合もあります。
前スレ
+ JavaScript の質問用スレッド vol.124 + [転載禁止](c)2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1427008785/
（ライブラリ禁止条項は、多数の意見によって廃止されました。ライブラリの質問もOKです） Selenium WebDriverはjavascriptもあんだからjavascriptのコード教えてやればいいじゃん
npmも使ったことない初心者に新しい言語覚えろとか相手にされるわけないだろ ruby使うやつってこんなのばっかり。
禁煙の立て札の前でタバコ吸って注意した人の顔面に煙吹き掛けるようなやつら。 Socket.IO（というよりEngine.IOやwsののperMessageDeflate）の質問です
デフォルト設定ではサーバーからクライアントへ送信するパケットのpermessage-deflateによる圧縮はメッセージ部が1024バイト以上でないと圧縮されないことになっていますが、これは今のPCスペックでも設定を変えない方が良いですか
現状ネットワーク帯域が逼迫しており何らかの対策を考えています
この1024バイト以上でないと圧縮しないというのはEngine.IO 1.6.0で定義されたと思われます
perMessageDeflateに関してはwsライブラリを参照するように書いてあり、wsのドキュメントにパフォーマンスの問題から制限を掛けたということが記載されています
備考
wsに1024バイト以上の制限がかけられたのは2.0.0の2016年12月30日
Engine.IOに1024バイト以上の制限がかけられたのは1.6.0の2015年11月29日 jQuery とか、広告1つでも、30KB もあるのに、
1KB 以下の話なんて、無意味だろw >>854
> 現状ネットワーク帯域が逼迫しており何らかの対策を考えています
別の所に原因がある 854です
ピーク時に2万3000クライアント程が同時接続しててその時にネットワーク帯域が不足するのでどうしたものかと悩んでいました
とりあえず半分の512バイトで圧縮するように設定して負荷検証してみました
実際のパケット自体は100バイト未満が6割、600〜900バイトが3割、1割はそれ以外（MAXは986バイト）
結果としては問題なく捌けているみたいですが、他のサーバーに比べるとCPU使用率が10%ほど高くなるみたいです（元々が20%前後なのでCPU負荷的には問題なさそうです）
メモリに関しては長時間の使用によってパフォーマンスが落ちるとの事なので1週間様子を見て大丈夫そうであればこれで行くことになりそうです
パケットログとサーバーの送信直前（emit直前）の時間の差はツールの問題で1ms単位でしか見れませんが遅延も問題になるほどではありません（最大の遅延で3msほどで済んでいます） 不足するなら送る対象を減らせばいいじゃない
ユーザーをパーティに分けてリーダーにだけ送信して
他のメンバーにはリーダーからP2Pで送らせるとかさ ファイルがダウンロードされたら、自動的にそのファイルをローカルファイルとしてJavaScriptで操作できないでしょうか？
Chromeだけでもよいので。 一応確認したいんだが、
mouseoverとmouseoutの発生順って、規定されてないよね？
○○の場合だけならこの順、てのもないよね？ >>862
バブリング、キャプチャリングのことか？ >>863
いや違う。書いたとおりmouseoverとmouseoutの発生順だ。
mouseout->mouseoverの順で固定されていればコードが減らせるんだが、
そうだとは誰も書いてないし、以下見る限りやはり駄目っぽいんだが、
誰か知らないかなと思って。
https://stackoverflow.com/questions/282245/what-is-the-event-precedence-in-javascript 正確に言うと、「余分なコードを書かなくて済む」だな。
単純に、固定されていないと、
・mouseout->mouseoverの順で発生した場合
・mouseover->mouseoutの順で発生した場合
の両方を想定して書く必要があるだろ。
どっちかに固定されていれば片方だけで済み、その分コードが少なくなる。
だからプログラミングモデルとしては、固定されていた方がいいんだよ。
例えば、.NETは割と固定されてる。
ただ、上記リンクを見る限り、ブラウザの実装の余地を残す為（というのは後付だろうが）
放置って感じか。 >>865
10年前のstackoverflowは見なくていいから仕様を読もう
https://w3c.github.io/uievents/#events-mouseevent-event-order
10年経ったら君の街でさえもあちこち変わってるだろう？
Webの世界なんてそれとは比べものにならないよ >>866-867
おお、サンクス。
確認したところ、05 November 2013 -> 25 September 2014で導入されてるね。
つか、「JavaScript mouse event order」でググッても引っかからないのは、
googleさんもうちょっと頑張ってくれ、とは思うが、
このレベルの詳細についてはMDNも未対応なのは認識した。
> コードを書いて検証してみたのか？
それは意味無いだろ。
このコードで良いかの確認は出来ないのだから。
> Webの世界なんてそれとは比べものにならないよ
それは買いかぶりすぎだ。この点はWebは10年遅れてたと断定出来る。
.NETは最初からイベントの順番は決まっており、遅くとも2005には固定されてた。
全てがWebが早いわけではないし、Webが早いってのも嘘だよ。
Webは仕様の更新頻度が高いだけ。
相変わらずおまえら信者レベルが酷いが、JavaScriptが全て良いわけではないし、
最先端な訳でも全然無いぞ。そこはマジで理解した方がいい。
asyncだってC#の方が先に導入したろ。
そしてJavaScriptはPromiseというゴミを抱えることになってしまった。
お前らは「難しくて」「最先端な」JavaScriptを使いこなす俺カッコイイ、
じゃないと困るみたいだが、全然それはないから。
JavaScriptは「簡単」だし「遅れてる」面も結構ある。
他言語をやれば分かる話なのに、理解出来ないのは、他言語が全く出来ないからだよ。
まあ全般的にHTML周りはよく出来ているのも事実だが。
むしろ他言語で実験/検証済みのこの機能が2014まで導入されなかったことが問題だ。
だから意図的に残したのか、という解釈だったが、方針変更ならさておき、
その他の件見てもJavaScriptの仕様委員会は馬鹿だから、気づかなかったのか？とも思える。 せっかく教えてやったのにこの態度か。死んでしまうといい。 >>869
その変化の遅い１０年越しの変更にもついてこれてないあんたは何も言えないよ JSが新しいなんて一度も思ったことないし、最先端が難しかったら何の意味も無い
.NETだってそもそもTaskあってのasyncなんだが つうかわざわざ例まで出して変化が早いから情報の鮮度に気をつけてねという意味で
「Webの世界なんてそれとは比べものにならないよ」と言ってるのに
「JSは他よりも進んでるんだぜ」と言ってるように思われるなんて心外 >>869
> googleさんもうちょっと頑張ってくれ、とは思うが、
> このレベルの詳細についてはMDNも未対応なのは認識した。
こういう認識の人がJavaScriptの何たるかを語っても説得力がまるでない
二次情報をあてにして、振り回されるだけ 2014になってようやくイベント順を固定した事なんて、全く威張れる話ではない。
それを「Webは速い(ｷﾘｯ」とか、マジでヤバいってことだよ。
個人的にはWPF(2007)はHTMLを丸飲みすべきだったと思っていたが、
しなかった（出来なかった）理由はここら辺にもあるのだろう。
全般的にJavaScriptの仕様委員会の奴らからはコードを書いているニオイがしない。
これが多分、今のJavaScript界の一番の問題だ。
この仕様ではコードが書きづらい、というところが結構ある。（放置されている）
今回もそう。仕様もイマイチおかしいだろ。
プログラミングモデルとして整備するなら、
A: enter -> over -> out -> leave …入れ子(6パス=150%)
B: over -> enter -> out -> leave …W3C(5パス=125%)
C: over -> out -> enter -> leave …最速(4パス=100%)
Aのように入れ子にするのが妥当だが、何故かBになってるだろ。
これは enter は over の、leave は out の従属イベントになっていることを示唆している。
実際、実装上はそうだから、Cの順なら最速になる。(BはC比125%遅い）
ただしCはプログラミングモデルとしては意味不明だから、
一般的には「保証されていない」と表現されることになる。(for-inがこれ）
ところがこれもないだろ。
プログラミングモデルとして整合性も無し、最速でも無し。
コード書いてる奴らならAかCにする。ここら辺がちょっと違和感がある。
元々「規定無し」で来てたのをわざわざBにする意味はない。普通は決めるならAにする。
結果的にこういった間違った仕様の選択がJavaScriptを静かに殺していく。promiseもそうだ。
なお、WPFはどうなのかな？と思って確認したが、mouseover自体がない。
おそらくenter/leaveがbubbleするようになってて、それだけだ。
彼らはover/outは冗長だと判定したようだ。 仕様書Figure2のmouseover(C)の方が分かりやすいかな？
2のoverが発生した後にenterがキャプチャ順で発生している。
本当は2のoverは5.5の所にないといけない。
そしたらenterがキャプチャ順、over/outがキャプチャ/バブル、leaveがバブル順で
綺麗に入れ子になるだろ。
C++の場合はリソース管理上厳密に入れ子必須なのだが、
JavaScriptの場合はここら辺が甘いから上達しないってのはある。
元凶は仕様委員会がゴミだから仕様がゴミになっていること。
結果、JavaScriptではゴミコードしか書けなくなっており、
お前らは美しいコードを見たことがなく、感覚が鈍いままになってる。
C++が良いとも思わないが、ある程度「ちゃんとした」環境がないと上達しない。
動けばいい、でやっている限り、動けばいい程度のコードしか書けないままだ。
JavaScriptは仕様委員会の連中がこの程度なのが最悪だ。
何を目指してこの仕様にしたのか、どういうユースケースを想定しているのか、さっぱり分からない。
お前らと話していると、技術的な面にはだいぶズレを感じる。
何度も言っているが、お前らは分かってないし、上達してない。これは自覚した方がいい。
ただ、ググッても出てこないような仕様を抑えている点を見ても、
お前らが努力してないって事はないんだろう。(これも前に言ったが)
今のお前らでは気づけないのだろうけど、
JavaScriptにはお前らの上達を阻害している要因が結構ある。
それは自覚して回避することは可能だから、信者になってマンセーするのではなく、
良い点と悪い点を冷静に見極めて行った方がいい。
そうすれば割とあっさり上達するのかもしれん。 >>873
今更変更してて、しかもMDNに4年後も反映されてないってのは想定外だった。
もっとも、仕様化されている≠今の実装がそうとは限らない、もガンな所だが。 >>874
JavaScriptが「プログラミング言語全般からすると」比較的簡単な言語だ、
と認識しているのならそれで問題はない。
> .NETだってそもそもTaskあってのasyncなんだが
それはない。
JavaScriptでpromiseが既に要らない子なのと同様、
C#では既にtaskは要らない子だよ。この点はC#も失敗してる。
JavaScriptは仕様委員会がパヨク化していて、ポリコレを振り回しているのがいけない。
asyncが見えていたのに「○○はpromiseを返します」なAPIとか、
httpsでしか使えません、とか、腐ってるだろ。
httpsにするかしないかはユーザ判断であって、JavaScriptの仕様委員会が決めることではない。
技術的な話に徹しておらず、結果的におかしな仕様選択になっており、次第に腐って行ってる。
何でこんなになってしまったのかは知らんが。 >>875
他言語も最近はかなりの頻度で仕様変更してる。
JavaScriptの変化が特段早いわけでは全くない。
ただ、Webは下地が固まってないのを変更しているから、変更が大きく見えるだけ。 >>876
俺はMDNは一次情報扱いだ。
ただし4年も遅れているとは認識出来ていなかった。
googleは結局Webページの巡回であって、pdf文書やGithubの中身の網羅までは出来てないって事だ。
冷静に考えれば当たり前だが、俺は気づいていなかった。 > 全般的にJavaScriptの仕様委員会の奴らからはコードを書いているニオイがしない。
DOMの話なんだからJavaScriptの仕様とは関係ないだろ
そういうふうに詰めが甘いから、お前からは素人臭してしてこないんだわ MDNが一時情報？
個人のブログからネタ拾って紹介したりしてるぞ？ 一次情報と言ってもJavaScriptの一次情報じゃない
APIの一次情報でもない、DOMの一次情報でもない
MDNはブラウザが実装している機能の一次情報 >>883
> DOMの話なんだからJavaScriptの仕様とは関係ないだろ
> そういうふうに詰めが甘いから、お前からは素人臭してしてこないんだわ
まさにその通りなんだが、「お前ら」は ID:qM8cSWzB に訂正しておいてくれ
DOMをJavaScript以外で扱ったことがないようだ
「Promiseが既に要らない子」はFetch全否定だし、仕様書をまともに読んだことがないのだろう >>886
MDNはFxの一次情報
あなたはFxだけ対応すればいいと考えているのだな >>888
くぷぷｗｗｗ
Firefoxだけの一次情報なわけないだろｗｗｗｗ 全般的にお前らは無駄に意識が高すぎて、形式に拘りすぎだ。
要するに、自分にとって一番良さそうな資料を読めば良いだけ。
仕様書を読んでる俺カッコイイとか、必要ないんだよ。
俺にとってはMDNが一番マシだから、俺はそうしてる。
仕様、説明、サンプルコード、互換表、注意点、が載ってる。
仕様書は仕様しか載ってない。
MDNに同項目があるのならそっちの方が便利だ。
MouseEventOrderについて丸々抜け落ちている理由は分からない。
MDNを書いている奴らからはコードを書いているニオイはするから、
この項目の重要性が認識出来ていないとは考えにくい。
ブラウザに未実装なのか？
しかしあの仕様はどっちかというとJavaScriptの他項目と同じで、
「美しい仕様を考えた」よりは「現状のブラウザの実装を調べた」に近いから、
これも考えにくいのだが。
とはいえ、この件で妥当な「載せなかった理由」が無ければ、
MDNの項目の選定もおかしいことになり、
お前らの主張「仕様書を読め」も妥当だということになるが。 良さそうもなにもMDNは
ブラウザが実装している機能の
一次情報だろ http://hkdnet.hatenablog.com/entry/2017/10/22/100000
> んで、これをちょっと読んでたんですがサンプルコードがわけわかんなかったんですよね。
> 僕が作った例のがイケてるんじゃね？と思ったのでコントリビュートしてみました。
一次情報がなんだって？ｗｗｗｗｗ >>869
このオジサンは
Web > 君の街 という比較例を出しただけなのになんでC#とかasyncとかの話勝手に持ち出してきて発狂してるの？？？ >>895
それが分からないのはお前が馬鹿だからだ。
他の連中は反発しつつも、
「何故俺がそれをここで言うか」についてはついて来れてるだろ。 >>896
ああそーーっすかぁ
>>JavaScriptは「簡単」だし「遅れてる」面も結構ある。
他言語をやれば分かる話なのに、理解出来ないのは、他言語が全く出来ないからだ
こんなマウント取りやっといて10年前のstackoverflow漁ってたの図星されたから悔しかったわけじゃないんすねー
俺がバカだったんすね
すいません勉強しまーーーす つかマジでお前ら文系プログラマっぽいよな。
突っ込んでくるところがおかしい。
折角877で仕様の不自然な点を挙げているのだから、（技術論）
仕様に詳しいつもりならそこに突っ込んでこいよ。
俺を言い負かしたいのならそこが格好の攻撃ポイントだろ。
なんつーか、マジでお前ら『文系的』揚げ足取りしかしないよな。
C/C++スレの連中も十分狂ってるが、あいつらは基本的に技術論だからいいんだよ。
お前ら、こんなレス読んでてもなんの足しにもならんだろ。
そういう姿勢が上達を妨げている、ってのもあるよ。
幼稚園児レベルの「言われたら言い返す」ではなくて、もうちょっと大人になれ。 >>897
俺がお前らにマウント取って、何の意味があるんだよ？
> こんなマウント取りやっといて10年前のstackoverflow漁ってたの図星されたから悔しかったわけじゃないんすねー
こういう風に取れる＝お前はマウント取りをしたがっている、と分かる。
まあ、若いんだろうさ。
もちろんやりたければやればいいんだが、
それをしたところで何もお前の為にはならないといい加減気付け。
JavaScriptがどうなのか、というのは比較論であって、
当たり前だが他言語も知ってないと何も言えるはずがないんだよ。
そして他言語を知ってれば、マンセーではなくて、
いいところも悪いところもある、と分かるはずなんだよ。
お前らからはこの感じを受けない。
だから知りもせずにマンセーしてんじゃねーよ馬鹿共、と言っているわけでさ。
他言語と比べれば、
> JavaScriptは「簡単」だし「遅れてる」面も結構ある。
のは事実だし、具体的に挙げたろ。
それについて技術的に突っ込んでくるのではなく、
こう言ったことに対し感情的に突っ込んでくるうちはお前らは上達しないよ。 Javascriptはプログラマがオブジェクトの生存期間をコントロールしにくい。
どこからでもいつでも生存期間を延長しようと言語仕様そのものが狙ってくる。
従ってアプリ固有のマクロ程度が使用限界となる。 >>881
意味わからん
誰も他言語と比較なんてしてないんだけど
君自信も「仕様の更新頻度が高い」と認めてたじゃないか？
>>899
までに色々書いてるけど全部自分に跳ね返ってないか？
一番人の発言を変な捉え方して、意固地になってるのは君だと思うよ
そもそもね
Webって「完成物」じゃないからね、常に発展途上で皆で作っていくのがWebなの
仕様だって沢山定められているし機関もあるけど、別にそれらがWebの支配者なわけじゃない
MDNに無い？ なら書き加えればいいじゃん？ と思われるだけ
現状の改善のためには不満を持つことは大変よいことだけど
少なくともここはその不満を書き散らすような場所じゃない
君は街の観光案内所に行って、この街は遅れてる！認めろ！とか叫ぶ人なのか？ WebはGoogleの思い通りに改変されていくものだからね。
Googleとの対決に負けて以降、W3Cは機能していないんだから。 いつまでW3Cに固執してるんだよ
まともなやつならWHATWG追うだろ W3Cの方がGoogleよりも属人的だったぞ
名前は忘れたがXHTMLガン押しのカリスマおっちゃんいたジャン
その後にHTML5を進めた貢献者もそのおっちゃんだけど
良くも悪くもそのおっちゃんのセンスに振り回されてたのが昔だよ
一方Googleはデータ主義だし、各専門科は狭い分野を担当している
仕様も分散してカリスマがいない事によるデメリットもあるけど
どちらかというと今の方が個人的には気に入ってる > XHTMLガン押し
俺はXHTMLには否定的だったな。
XSLTは最悪の技術だった
自分のセンスが正しいことが証明されたよ XHTMLなら決定性のあるアルゴリズムで解析できるので、セキュリティ的な意味合いで良さがあった。
カスタム・タグのセキュリティについてはHTML Tidyのプロジェクトで議論しているのでよかったらどうぞ。
基本的に悪い方向に向かっていると思います。
これを安全に扱えるのは最早Googleしかいないんじゃないでしょうか。 「XHTMLが悪かった」というのは局所的に見過ぎてる
後方互換性がなかったのが問題だった
これについては、MSの功罪が大きい
MSがIEをアップデートしていたならば、XHTML2が生き残る道はあった 構造化された文章ならその価値はあるだろうが
Webサイトと言うのはもはやそういうものとは限らないからな タグの動作を拡張できるというのは非常に危険なことです。
Googleの野心にウェブ全体が付き合わされる必要はないんじゃないでしょうかね。 ウェブ屋さんはちょっと変わった人が多いんだよね。
ネットスケープはとにかく落ちるブラウザで、直前に読んでいたページのせいで次のページが落ちるなんてこともよくあった。
ネットスケープに一番苦しめられてたはずのウェブ屋さんは何故かネットスケープマンセーしてたんだよね。
そして今、グーグルに一番苦しめられてるはずのウェブ屋さんがグーグルマンセーなんだよ。
おそらくこれ知能指数の問題じゃないかとにらんでる。
ウェブ屋さんの平均知能指数は他の業種より低いはず。 ウェブ屋さんが昔よく言ってたのは、Javascriptはたった二週間で作られた、天才じゃなければそんなことはできない、天才が作ったんだから最高の言語だ、こんな感じ。
僕は、たった二週間で作られた言語がそんなにいいわけないと考えるんだけどね。 最近のウェブ屋さんが良く言うのは、リビング・スタンダードね。
固定することなく次々仕様が改良されていく、とても素晴らしいってね。
仕様がころころ変わって一番いじめられてるはずのウェブ屋さんがそんなこと言うんだから、面白いよね。 XHTML も XSLT も別に悪いもんじゃない。もちろん JavaScript もだ。
XML Schema はだめ。 Javascriptは駄目すぎですよ。
早く捨て去った方が良い。 アンチJS見るのだいぶ久しぶりじゃない？
最近はJSer同士の喧嘩がほとんどだった気がする
いいぞ、もっとやれ XMLは正直、SGMLよりはるかにマシだと思うけどな。
決定的なアルゴリズムと言う面でも、別にカスタムタグがあるからといって非決定的になるわけでもなく、カスタムタグ通りに動くだけであって、カスタムタグを想定していないガバガバな方がよろしくないかと。
そこまで否定的な事言ってたか？確かにTidyのIssueで何度も上がってるが、その文脈での反論には「そもそもvalidatorじゃ無いんだよ？」とツッコミ入ってたかと。
Javascriptがダメと言うのは、もう論外の発想では？ Living Standardを否定する人は老害じゃないかと思う
なんのための標準化なのか >>912
俺はたった二週間でできるわけないので、
その情報の出処はどこなのか、どの部分を二週間で作ったのか
それまでに似たようなものを作っていたのではないのか？って思うけどね。 >>918
Javascriptは明らかに駄目だろう。
元々はちょっとしたマクロのようなものを想定していたんだろう。
その程度のものをアプリに使おうというのが無理筋すぎる。
しかもそれがネットを介して作動するのだから、もはや気がくるってる。 >>923
だから改良されたでしょ？
今のJavaScriptは昔のJavaScriptとはぜんぜん違うよ >>925
だめではないね。最新のJavaScriptは
他のどんな言語よりも優れてる ウェブ屋さんはなぜ考えることをやめてしまうのだろう。 みんなが考えた結果がJavaScriptの進化では？ 新しいJSと他の言語の比較はwasmが本格化したら考えてくれれば良いけど
最新の仕様に無頓着なのは完全に別問題、言い訳もクソもない >>923
違うよ。当初から単なるマクロは想定してない。だろう論で話さずに、lispが作りたかったんや！って本人が言ってるあれ読んできたら良いよ。
ネットを介してが何を指してるかもわからんけど。
ブラウザ≒ランタイムなのが気に食わないのかな？ Web屋ではないけど、どうして考えることをやめたんだろう、と考えることをやめた人に言われたらちょっと面食らうな。 >>901
> 意味わからん
そりゃお前が馬鹿だからだ。
ただお前、866か？
ならそれは有効な情報だったし、多少はマジレスしよう。
今のお前の価値観は、完全に「Webしか出来ない意識高い系」そのものだ。
非Web系言語を何でもいいから一つでもやってみるといい。
そうすれば、JavaScriptの糞な所が理解出来、
自分の発言のどの部分が間違っているか分かるだろう。 > 非Web系言語を何でもいいから一つでもやってみるといい。
> そうすれば、JavaScriptの糞な所が理解出来、
> 自分の発言のどの部分が間違っているか分かるだろう。
意訳
説明ができない。相手を説得できるだけの根拠がない
せや、相手にJavaScriptの糞な所を自分で見つけさせよう
相手が糞な所を調べられなければ、相手のせいにできるし
相手が糞な所調べれば、一石二鳥
俺って頭いい！ >>934
ということで、お前の卑怯な戦略は封じたので、
さっさとJavaScriptが糞な所をお前が説明しろ なんか伸びてると思ったらまた例の自称他分野の上級者くんがわいただけか
XHTMLの仕様を引き合いに出すのになぜかW3Cじゃなくて日本語wikipedia持ってきて頓珍漢なこと書いた挙げ句2018年にHTML6とかいうワード出してきたLiving Standardの存在すら知らない化石だろ
仕様書の中身覚える必要は全くないけど仕様を知りたくなった時に適切な場所で調べる能力がないのはエンジニアとして終わってんだよなあ 俺明日からTypeScriptでサーバサイドを書く仕事するんだ。楽しみ 「俺がJavascriptが糞だと思う根拠を俺は説明できないからお前が他の色々な言語と比較して俺の意見としてよろしく説明しろ」 「お前はYESと言った、俺の意見はNOだ。お前は俺の代わりに調べてNOであることを証明しろ」 Webに限らず普通はまず仕様を調べて、それから実際のところどうなってんのか実装を見るものだと思うけど…… さすがにJavascriptが素晴らしいってのはないわ。 うむ、JavaScriptは素晴らしくない
昔よりだいぶマシになったとは言え書かずに済むなら書きたくない言語だ てかお前ら必死すぎ。
何でそんなに信者になるのか分からん。
お前らが馬鹿なままで居続けるのはお前らの自由だ。
同様に、お前らが俺のアドバイスを信じてみるのも自由だ。
結果は周りの奴ら、つまりお前らの同僚や後輩が判定してくれる。
今と同様に間抜けなことを言い続けたら馬鹿だと見なされるだけ。
JavaScriptが糞かどうかは別として、
他言語を学ぶのは上達への一つの方法ではあるから、やってみるといい。
そうすれば、JavaScriptがどうなのか客観的に分かるだろう。
そもそも、良い/悪いってのは比較論なんだから、
他言語を何一つ知らない奴が言っていい事ではないんだよ。 JSは昨日動いてたコードが今日のブラウザのアップデートで動きませんを回避するために、
ES5以前のこの動きは駄目だろうと言いたくなる仕様が沢山あって初心者が中級者に上がる所が辛い言語だと思うわ。
肝心のES2015も新サポートの構文増え過ぎで、勉強し始めは「これらは本当に同じ言語なのか…？」と戸惑うところが結構あったし。
でもまあ、モダンな環境に一通り触った今ならそんな糞言語だとは思わんな。 >>941
それは非Web系の常識だ。
JavaScriptは特に悲惨で、仕様と実装が全く同期してない。
だから割と出たとこ勝負で、それが嫌だから例のnpmの件、
・作者がnpmと揉めてコードを引き上げたら、
それをリンクしていたWebサイトが突然軒並み動作しなくなってプチ祭り状態、
どんな凄いライブラリなのかと思いきや、なんとたった1行！
他言語の連中の反応はマジで冷ややか、『こいつらはコード書けないのか？』
なんて事が起きる。
仕様と実装が同期していないのも、普通に考える「実装が追いつかない」ではなく、
・仕様化されているが、実装されていない
・仕様化されているが、異なる実装になっている
・実装されているが、仕様化されていない
（リファレンス実装無し＝物によって動作がバラバラ）
の全部ある。
だから仕様を調べて…という『一般常識』だと盛大に空振りすることもよくある。
俺はこれがJavaScriptの最悪なところだと思うけど、
JavaScriptしか知らない奴はこれが普通と思っているから、話が通じない。 Haxe は良いけど、JS ではプログラミング出来ない
プログラミング部分はRuby でやって、
Rails から、jQuery, Vue.js とか使うのが一番 Rails 5.1で作るVue.jsアプリケーション 〜Herokuデプロイからシステムテストまで〜
https://youtu.be/ycOeM2umXkY
伊藤淳一 Junichi Ito の動画
Rails 5.1 から、Vue.js を使う まぁそもそもJavaScriptが嫌いなら無理して使わなくてええんやで？
ヘイトぶちまけたいなら愚痴スレ行け
ちなみに俺は素のJSは馴染まないから理由がない限りTypeScript使う レス数が950を超えています。1000を超えると書き込みができなくなります。
