>>845
let a=1;
・・・
let a=2;
を防げるって意味じゃないの？

for-const-inは流石に苦笑。。。
[...Array(10).keys()]とかハッキーなの使うくせにconstに拘るとかわかわかめ

constまだやってんだ・・・
もうどっちでもよくね？そもそもIE11以上ってかなり限られない？

fo inは遅いからなるべく++（できれば--）を使うように
記事などを見るが今それは古いのか

正：for in

IE11以上前提てうらやましいわ
最新のCSS使えるし
もっともそうだとしてもクライアントが「やっぱり」と言いかねないから最初からそれ以前対応で書くけどね
ある程度でいいとはいえロボットもどこまで理解してくれるかわからんし

>>852
たぶんあんたとは技術力に大きな差が有るんだと思うね
俺の場合、良いコード＝短くシンプルで可読性が高いコードを
書いてきたら自然とconstだけで十分だと理解した。

上から押し付けられたのではなく、自然とそうなったんだよ
たぶんあんたはまだ理解できてない段階

そういう人は技術力が高い人（俺じゃなくてGoogleとかの人）の
意見を素直に聞いたほうが良いよ。技術力が低いのに
今までこのやり方でやってきたんだ、これからもこのやり方でやる
っていうのは一番ダメなパターンだから

自分ひとりならそれでも良いけど、若い人にあんたのやり方を押し付けたらいけない
技術力が高い人のやり方とどっちを押し付けたら良いかは言うまでもない話だろう？

>>853
> もうどっちでもよくね？そもそもIE11以上ってかなり限られない？

いや？ Babel使って変換すればいいからIE6以上対応だよ

それ（Babelを使う）ができないっていう人は、できない理由を
書いてくれたら良い

>>850
> 再宣言ならまだしも再代入だけを防げて本当に嬉しいケースって滅多に無いだろって意味だろ
コーディングのレベルにはいくつかの段階が有ると思うんだ

例えば、動けばいいという人
動くのは当然でわかりやすいコードでなければダメだという人
動くのは当然で短いコードでなければダメだという人
動くのは当然でテストしやすいコードでなければダメだという人

コードに品質を求めない人は動けば問題ないという扱いなのだろうが
コードに品質を求める人は動いていたとしても「こういうコードは良くない」という
レベルでも修正対象とする。

つまり高い品質を求めている会社はvarやletは品質が低いという扱いなんだよ。
品質が低いコードを書く人を吊るし上げる方法でも有るｗ
あ、冗談だよ。本当は教育対象になるだけ。教育受けてください。

>>854
> 記事などを見るが今それは古いのか
古いだろうね。その記事の日付を見ればわかると思うよ

>>858
babel？ 今でもそんな化石使ってるところあるの？

そりゃあるでしょｗ IE11以上限定で羨ましいって言ってるんだから

あれあれ？それともbabelが不要なほど新しいブラウザ限定でいい
古いブラウザ対応してる所に対して化石だって
馬鹿にしてるんですかね？ｗ　それ俺じゃないですね
>>853や>>856ですねｗｗｗ

>>860
おまえ馬鹿だろ？ 話の流れで古いブラウザ対応
する必要があるからbabelなんだよ。もちろんtypescriptでも良いぞ？

こうして>>861みたいなのがトレンドから遅れていくんだな・・・

>教育受けてください。

うぜ～～～ｗ

constのためにbabel使えってわけじゃないよな、まさか

>>862
え？ IE11未満のブラウザに対応しなきゃいけない人用の
トレンドって何？ babelを使うとダメな理由がわからない。
それはbabelを使うことで実現できなくなること？
あんたの言うトレンドとは何のことを指すのか具体的に言ってほしいな

>>864
そりゃそうだよｗ

今IE11未満に対応しないといけないという要求があったとする。
過去のコードはしょうがないかもしれないけど、新しく作るものは負債にしたくないだろ？
babelを使うのはIE11未満に対応しなくて良くなった時に、古い書き方のコードを
減らすために使うんだよ。つまり古いブラウザ対応とトレンドを両立するためにbabelを使う

こんなことを書くとbabelは完璧じゃないと言い出す人がいるが
俺は0か1かの話をしているんじゃなくて、どれだけ古いコードを
「減らせるか」の話をしている。なので些細な問題があったとしても
大局を見て減っていれば目的は達成

負債ってほどでもないだろ
まだまだvarで解説してるものの方が圧倒的に多い
別に後々大幅変更を伴うわけでもなし

いや負債だよ。アロー関数があるのとないのでは
lodashのコードの書きやすさが違いすぎる
他にもクラスとかasync/awaitとか重要だしさ
Template Stringsとかも地味に便利だし
細かい書き方で改良がたくさん加えられてる

なんか勘違いしてそうだけど
俺はconstのためにbabel使えってわけじゃないよなって
聞かれたから、babelはconstのためだけじゃなく
IE11未満対応が必要な場合にもっと多くの機能を提供してくれるから
babel使えって言ったんだ。と訂正している。

bubleってどうなん？ 使ってる人おるん？

TypeScript派とEcmaScript（babel含む）派に
わかれたよな

>>872
TSはCSとかと違ってESに追従しながら型周りを整備しましょうというスタンス
ESもTSを意識しつつ徐々に型周りを整備していきましょうというスタンス
両者は将来統合されることが想定されているのであって敵対する関係ではない

lodashの機能全部使うかどうかわからないのでrange以外でめっちゃ使う機能だけ教えてください

>>870
路線変更ですね、わかります

>>874
2系のドキュメントおすすめ。
よく使う機能から実装されやすいので2系ぐらいが
ちょうどよいと思う
http://lodash.com/docs/2.4.2

4系はあると便利なんだろうけえど、増えすぎだとも思う

>>875
変更してないよ。
constを使えないブラウザがある！というならば
babelを使えば良いと言っただけなんだから。

この文章を見て「constのためにbabel使えと言ってる」と解釈するなら
俺は「const使えないブラウザのためにvarを使えってわけじゃないよな、まさか」
と言い返すよ。

だってそうだろ？ たかがconst使えないブラウザがあるってだけで
varを使う理由にはならないんだから。babel使えばいいだけ

>>873
> 両者は将来統合されることが想定されているのであって敵対する関係ではない

敵対する関係なんて言ってないよ？

現時点でTypeScriptで書く人とEcmaScriptで書く人に
別れたって話をしている。

別れた分岐が将来統合するか、平行線のまま行くかの話はしてない
それに将来統合するっていうのなら、現在は別れているってことでしょ

>>878
だからその分け方はおかしいと言っているんだよ
分けるんならピュアJSモダンブラウザ派と、トランスパイラ派にしないと
BabelをES派に入れちゃうのは良くない

だってトランスパイル使うんなら、Babelだって未だESでない機能有効にできるわけだしね
実際ES2017が勧告される前からasync-awaitとか使ってた人も多いし
ES+を幅広い実装でという観点ではTS使いと変わらんのよ

>>879
そのわけかたのほうがおかしいだろ？

例えば俺がおまえにプログラム制作を依頼して
あんたはES6でコードを書く。

あんたが作ったものES6で書いたプログラムだろ？
それを否定するのかって話だよ。

>>879
> BabelをES派に入れちゃうのは良くない

その理屈だと、将来ブラウザネイティブでTypeScriptをサポートした時
今のトランスパイラ使ったTypeScriptコードは
TypeScriptコードではないということになって意味不明だぞｗ

どの言語でコードを書いたかと
どうやってそのコードを実行するかは
別々に考えるべきこと。

まあここまで書いたけど、やっぱこの人が何を言いたいのか分からんわ。

babelはトランスパイラであって言語ではない
EcmaScriptという言語で書いたコードもってこい！
それを古いブラウザで動くようにしてやるぜ！
（ここ重要。持ってこさせる言語はEcmaScript限定）


という機能を提供しているトランスパイラというだけだろう？
それ以上でもそれ以下でもない。いや正確にはJSXにもflowにも
対応しているからそれ以上では有るんだが。

追加済みの要素をprependして並べ変えしたいときに
$('#elm2,#elm1,#elm3').prependTo($parent);
て一度にやると、どうやら#elmの取得順に追加しちゃうみたいで
現並びが<#elm1><#elm2><#elm3>のときと<#elm3><#elm2><#elm1>
のときとで実行結果が変わってしまうようです？
なのでforで$('#elm')みたいに一つずつ追加しているのですが
これは仕方ありませんかね？

帰ってきてから答えるけど
分かる人どうぞ

ソートすればいいじゃん

念の為補足しときますね
http://jsfiddle.net/ewqvho2w/
$('#hoge').find('.elm1,.elm2,.elm3').prependTo($('#hoge'));
$('#fuga').find('.elm1,.elm2,.elm3').prependTo($('#fuga'));
どちらもほぼ同じコードですが結果は異なってしまいます
期待していたのは$(".elm1,.elm2,.elm3")の並び順に取得して
<elm1><elm2><elm3>という順で追加されないのかな？と思ったのです
（でもよく考えるとそれだと<elm3><elm2><elm1>になりますね）
なのでforで一つずつ$(elm+i)したりソートしたりするしかなく、
何かjqueryにそういう順番を守る？みたいなオプションはないのかなと

ただいま

>>884
セレクタは文書の登場順に要素が取得されると決まってるよ。書いた順ではない。
例えば、<div id="hoge> みたいな要素があったとして、
$('#hoge, div')なんてセレクタだと2回取得されるのか？って
なっちゃうでしょ？ 書いた順番に取る方法はない。
ついでにいうと、addを使ってつなげたとしても文書の登場順になる。

だからといってやり方がないわけじゃなくこんな感じでできる

var elements = $.map(['.elm1','.elm2','.elm3'], function(selector) {
return $('#fuga').find(selector).toArray();
});
$(elements).prependTo('#fuga');

もしくはES6スタイルで

const elements = $.map(['.elm1','.elm2','.elm3'], s => $('#fuga').find(s).toArray());
$(elements).prependTo('#fuga');

もちろんprependToをつなげて書いても良い

また、prependToではなくprependを使うとtoArray()を消せる

var $elements = $.map(['.elm1','.elm2','.elm3'], function(selector) {
return $('#fuga').find(selector);
});
$('#fuga').prepend($elements);

ついでに$(selector, context)の書き方を使うと、ここまで短くできたよ。
$('#fuga').prepend($.map(['.elm1','.elm2','.elm3'], s => $(s, '#fuga')));

>>887
> 何かjqueryにそういう順番を守る？みたいなオプションはないのかなと
jQueryは基本的に順番を保持しないセットとして扱うからね。

順番を保持したいのであれば$([elm1, elm2, ...]) を使う必要があるわけだ
http://api.jquery.com/jQuery/#jQuery-elementArray

>>889-890
どうも参考になりました、早速取り入れてみます
ありがとうございました

イベント内であるノードを操作するとき、
その度に取得したらいいのかそれとも変数に格納しておくのが良いのか
よくわからないのでどちらがいいのか教えてください
$hoge=$('#hoge');
$('button#fuga').click(function(){ $hoge.text('操作'); });
//がいいのか、それとも
$('button#fuga').click(function(){ $('#hoge').text('操作') });
//がいいのか
//双方メリットデメリットがあるのか、など

せっかくjQuery使ってるのにわざわざキャッシュとかする必要ないよ
できるだけ簡潔に書けばいい

>>893
いや、そんなことはないよ

>>892
jQuery使っていてノードを変数に入れて
置きたくなるのは単に作り方が悪いだけのことが多い

そうでない場合はその都度取得した方がいい
何故かと言うとウェブページは動的に変更されるという
前提にしておいた方が良いから

要素は追加されたり削除されたりする。
必ず１つ有るとは限らない。ないかもしれないし複数あるかもしれない
jQueryを使わない場合は、そういう動的に変更されるという
前提で作るのは難しいが、jQueryを使えばほぼすべてを
0個以上の要素があるという前提で書くことができる。

このスタイルはCSSに似ている。CSSだって要素がなくても複数あっても
問題なく動くだろ？CSSと同じように宣言的に書くことができるのがjQueryなんだ。

話がそれたが、$('#hoge')みたいなIDを指定して取得するのは
jQueryを使っても時間はかからないので気にする必要はない。

作り方が悪いと言うか、センスがない
折角抽象化ライブラリ使ってるのに変に気を掛けるとかアホくさ
そんなに気になるんなら愚直に書いてもキャッシュしてくれるvDOM系使うか
生DOM APIで好きなだけ効率的に書けばいいよ

>>896のようなのを使わないという前提で

同一関数内で数回同じ値（上でいう $('#hoge')）を使う場合
かつ同一関数内で動的変更がない設計でもその都度取得したほうがいいのだろうか

また、同一関数内で動的変更の可能性がある場合、かつ処理時間がかかる場合
一旦変数に入れた方が矛盾なく確実ではないのだろうか

また、同一関数内で動的変更の可能性がある場合は
メソッドチェーンなどを使うので一旦変数に入れる必要がない。
つーかサンプルじゃなくて実際のコードを持ってきたら？
一旦変数に入れるほうが良くないって説明してあげるから

メソッドチェーンは限度あるな
1行で全て処理できない場合、end()などで対応できない場合も考えられる
$('#hoge')の処理→他の処理→$('#hoge')の処理、のように

>>899
> 1行で全て処理できない場合、end()などで対応できない場合も考えられる
だからサンプルじゃなくて実際のコードを持ってきたら？
なんでいっつも想像なのかな？ｗ