他人の回答に、因縁を付けてくる奴がいるから、もめる。
そいつが荒らし

どう回答するかは自由。
JavaScript の質問に、Haxe で答えたり、CSS の質問に、SASS で答えたって良い。
それを見た他人が、JavaScript に翻訳してくれることもある

誰も書き込まないよりはマシ。
少しは正解に近づく

何も1人で、正解を書かなくても良い。
何人かで正解を作りあげても良いし、正解に近づくだけでも良い。
本来、便所の落書きは、気楽なもの

荒らしは、回答者の努力に対して、因縁を付けてくる

対応ブラウザがどうのと因縁付けてくる奴もいるしな

回答に対してこういうのもあるよとか、こうした方がよくないとかはいいと思うけど、それはダメだこうすべきとかの押し付けや宗教は他いけ

現実問題
誰かがこうすれば？と書いて
その次に別の人がこうした方がいいよと書けば
それだけで喧嘩になりうる

>>954
沸点低すぎな人が、たまにねｗ
HAHAHAそういう考え方もあるよねガイズ！
ですませば良いのに

>>952
> 対応ブラウザがどうのと因縁付けてくる奴もいるしな

それは因縁じゃなくて注意点だな。
質問者が、教えてもらったコードで自分のブラウザで動作テストして
リリースしたら動かないってクレームが来ました。
どうしてですか？って後から追加質問がくる可能性あるだろ

その可能性がある以上、対応ブラウザについて注意をうながすのは
回答者の義務だよ。もちろん回答者が忘れたりすることもあるだろう
そういう場合は他の人が教えてくれる方がみんなのためになるよ

>>953
> 回答に対してこういうのもあるよとか、こうした方がよくないとかはいいと思うけど、それはダメだこうすべきとかの押し付けや宗教は他いけ

良くないとか言いたいなら、少なくとも別のやり方を提示するべきだろうね
そうでないと質問者も動くコードが有って解決してるのに、
なんで喧嘩してるの？このコードがなんでだめでどうすればいいの？って戸惑ってしまう

もし質問者が僕のIE9で動きませんと言ったら？
プログラマーである回答者の義務はChrome使えということだろ
IE9で動くようなコードをこの2017年に新しく教えてネットのゴミを残すことではない
大アホが

このタイミングでそれ書けるハートの強さしゅごい

>>959
> IE9で動くようなコードをこの2017年に新しく教えてネットのゴミを残すことではない

え？ for文使ったらダメってこと？
IE9でも最新のブラウザでも動くコードならOKでしょ

ここ数レスの発言を考慮して、荒れないようにテンプレ書き直した
次からはこのテンプレを守って欲しい

特にこれ↓
> ・他人の回答を見たくないのであれば、文句をつける代わりにNGにして見えないようにしてください。文句をつける＝荒らしです


+ JavaScript の質問用スレッド vol.131 +
http://mevius.2ch.net/test/read.cgi/hp/1511269113/

>>958
君はIE9は切り捨てればいいと言えばいい
他の人はIE9で動くコードを書く

この２つの回答が出て終わりだよ

そこでネットのゴミを～とか言い出すのはダメ
他人を批判しないように。流れを黙って見てろ

誰か、>>933,>>934をお願いします。

>>961
意に沿わない内容を独善的に消して都合のいい内容に書き換えてるだけじゃん
そこまで別スタンスにしたいなら>>947の言うように別スレとして立てりゃいいのに

>>963
headはscriptの間違いだという仮定の上でレスするよ
type属性に"module"の値があるとES Modules形式のスクリプトとして読み込む仕様があるから
それを実装しているブラウザだとindex.jsがES Modulesとして実行されるせいだと思う
普通のスクリプトとして実行するぶんにはtype属性は要らないよ

>>933
答がつかないのは、headなんて書いてるからだよ。scriptが正しいだろ？

<script src="./index.js"></script>は
<script type="text/javascript" src="./index.js"></script>と同じ
外部JavaScriptスクリプトを読み込んでいるだけ

昔のIEはJavaScriptとは別にvbscriptも対応していた
その場合は <script type="text/vbscript" src="./index.vbs"></script> と書く

vbscriptに対応してないブラウザで↑の書き方をした場合はどうなるか？
そう、text/vbscriptなんて知らないから、なにもしない。読み込まない

もうわかっただろ？
ES modulesに対応してないブラウザでは、type="module" をつけると
知らない言語扱いで読み込まないんだよ

あー、そうか、普段最新のJavaScript使えーブラウザ使えーって言ってる人は
ブラウザが対応してないという現実を見るのが悔しいって可能性もあるな

>>965
>headはscriptの間違いだという仮定の上でレスするよ
その通りです。単にここに書くときに間違えただけです。実際は<script>タグです。
>>966
>ES modulesに対応してないブラウザでは、type="module" をつける
ひょっとしてそういうオチかもしれません。
他のブラウザでも実行してみます。ありがとうございます。

一部のモダンブラウザが対応しているからって
今よく使われてるブラウザは必ずしもES Modulesに
対応しているとは限らないからね
最新のブラウザだけでテストしていると動かないってことになる

ちなみにwebpackあたりを使って変換すれば
非対応のブラウザでも動くようになる

>>943
jQueryの質問に対する答えなら関係ある話題と認める
だが、スレのローカルルールを守るのは大前提であり、jQueryスレでやれ

スレのローカルルールなんてVol.1から変わってきてるだろ
現実に合わせて変えれば良いんだよ

一部が対応してないとか言ってるといつまでも使えないけどな
ESMは間違いなく今が使い始めどころ
心配ならnomoduleでアラートでも出しとけ！

だからwebpackやbabelを使おうって話になるんでしょ？
こちとら何年も前から旧ブラウザ対応かつES6対応ができてる

それにブラウザがネイティブにModuleに対応したとしても
ファイルが分割されたままだと遅くなるので
どちらにしろビルド処理は必要になる

Moduleは使えるなら使うけど、無くても問題ない機能だよ

JS の規格がコロコロ変わるし、各ブラウザで挙動が変わるから、
純粋なJSだけの話では、解決できない。
そこが他の言語と違う所

だから、jQuery, Lodash, React, webpack, babel などが、JSスレに入ってくる

これらの混合技術は、現実との折り合いを付けた結果。
純粋な言語の、JS部分だけを分離できない

柔軟な反面、扱いにくいってことだな

>>972
だからというのはおかしくないか？
別にWebPackなんかを使うんなら標準でサポートされてる必要が無いんだから
いつまでもポリフィル使うと言ってるのと同じことだぞ

誰も柔軟とか言ってないし
扱いにくいとも言ってない

単にブラウザで動くJavaScriptは
他の多くの言語と違い、同時に複数の
実行環境に対応しなければいけないという
課題があるということ

そしてブラウザ、バージョンがことなれば
使える機能(言語だけではなくAPI)も違う
実装がばらばらなのでどうしても抽象化
レイヤーが必要になる

>>975
なんでいつまでもポリフィルつかうの？
ほとんどのブラウザが対応したときに
ポリフィル使うのやめればいいだけじゃない

より正確には無視していいほど、
少なくなった時だろうね

ポリフィルつかったら、ずっとポリフィルを
使い続けなきゃいけないという
発想がよくわからない
ポリフィルは将来けすことを前提に使うものだよ

将来消すというのは理想だが実際はありえないことだけどね

それぞれのサポートポリシーの問題としか言えなくね
公的サービスとか100%にリーチしなきゃいけない場合はともかく

>>981
しらんがな
一般的な話をしている時に
お前の悩みを言われても関係ない話だ

>>971
> 一部が対応してないとか言ってるといつまでも使えないけどな
そもそもES Moduleなんて使う必要あるの？

モジュールシステムはやっぱり必要
どうせならimportキーワードを使って公式にサポートされてる方がいいだろう

PHPみたいになんでもかんでもつっこんどけばおｋ

でもminifyや難読化、WebAssemblyとかを使うと
結局ビルド環境は必要になるんだよね

必要なのはビルド環境がなくてもES Moduleを使ったライブラリを
使いたいってときぐらいかな

ライブラリを作る方からすればES Module対応で作っておけば、
ビルド環境でもブラウザだけでも使えるので楽ってことぐらいか

どう見ても、なんでもいいから次の新環境が必要なのにGoogleはとりあえずDartのChromeへの
搭載再開しろよ。
このままだと10年後もJavaScriptでみんなで摩耗してそう。

>>988
DartはChromeに搭載しないと決定したじゃん

Googleは“モアベターなJavaScript”をねらったDart言語をChromeでサポートしないことに決定
http://jp.techcrunch.com/2015/03/26/20150325google-will-not-integrate-its-dart-programming-language-into-chrome/

うん、だから、「再開」してほしいと。
クソ言語使ってみんなで必死こいて生産性あげようと、ずっとやってて馬鹿みたなんだけど。
それで次から次へといろんなフレームワークでてきて。

「クソ言語」使って「超がんばる」より
「そこそこ言語」使って「そこそこにがんばる」方が百倍ましなんだから、

多少のえり好みとかは置いといて主要ブラウザでなんでもいいから新言語作ってまとめろよな。

chromeのローカルストレージを他の環境にコピーしたいです
以前はサイトごとに分かれていない
単にサイトごとのローカルストレージ用ファイルをコピーするだけで事足りたのですが
今は実装がLevelDB
というものになっているようで、
サイトごとにデータを簡単には取り出せないようです
特定サイト用のローカルストレージのデータを移す方法やツールがあれば
教えて下さい

×以前はサイトごとに分かれていない
○以前はサイトごとに分かれていて

でした

>>990
JavaScriptを改良するほうが遥かにいい
TypeScriptやBabelという下地が出来てしまったから
今は新しい仕様のJavaScriptを変換するだけで
すぐに使えるようになった

はっきり言って今のJSは十分良い言語
どちらかと言うと他のWeb標準仕様が問題
未だにPromise対応してないものが多くあったりだとか
特にIndexedDBはセッションの問題があるから自作でラップは難しいし
どうにかして欲しいよね

どこがいい言語なんだよ、それは他の優秀な人がクソ言語の上に頑張ってフレームワーク作って
それ使ってるだけだからだろよ。

それにWeb技術の流行り廃りがはげしいのは、元になるJavaScriptがクソだから
安定しないで、いろんなライブラリ・フレームワークが生まれ消えるのが激しいいんだよ。

もっとJavaScriptがまとな言語だったなら周辺ライブラリ・フレームワークの流行り廃りももっと安定してるわ。

もうちろんいい言語使うときにもフレームワークとか使ってたりするだろうけど。

馬鹿すぎだろおまえら。

意味不明
プログラミング言語は、どこかしらイケてない
しかも「なんでそこをそのままにした？」って不思議になるくらいイケてない
そんな中でJavaScriptは、そんなに悪くない
むしろいい方の言語だと思うけどね

たとえばpythonにはいまだに定数すらない
年次ごとのアップデート体制を整えたJavaScriptは相当進んでるだろ

本の紹介。Stefanov も書いてる

入門 React ――コンポーネントベースのWebフロントエンド開発、2015

Reactビギナーズガイド ――コンポーネントベースのフロントエンド開発入門
Stoyan Stefanov, 2017

なんで、pythonあたりの古い言語と比較するんだよww

>>999
機械学習も関係して今一番流行ってるから