>>650
おまえは全てのコードで try-catch するのか？
例外を発生させたい状況は全くないのか？

つかんでも要らなかった例外は投げ捨てればいいだろｗ

例外をキャッチしたい箇所で例外処理を施すのが普通だよな？
>>651が何言ってるのか理解できん。なんで全てのコードとか言い出すんだ？

try {
　i++ ;
} catch {
　alert('エラーが発生しました')
}

意味のわからんレスするな

try {
>>651
} catch (e) {
throw e; // いらねｗ
}

例外の発生条件は全て把握するのが基本だから try-catch はほとんどのケースで必要ない
だが、人間のする事に間違いはつきもの
予想も出来なかった不具合があれば、処理が停止する仕様である事が望ましい
setIntervalは例外が発生しても後続のタイマー処理は止まらない
setTimeoutを再帰呼び出しすれば後続のタイマー処理は働かない
setTimeoutを再帰呼び出しする実装がより安全な設計といえる

なにいってんだ？ setIntervalでタイマー処理を
止めたほうががいいかどうかは場合によりけりだろ。
なんで止まる方がいい前提で語ってんだ？

>>649
JavaScriptのフレームワークの選定について
http://ja.stackoverflow.com/questions/2576/
BackboneとAngularを比較する
http://www.infoq.com/jp/articles/backbone-vs-angular


Angularがあちこちで流行ってるけど、これにドップリで巨大なフロントエンドを
構築するとAngularが廃れた際に乗り換え先が無さそう
Angular仕様ロックインで、覚えた技術の再利用ができない
Google主導だから大丈夫だろうと思いきや、過去にいくつものサービスや
APIを捨ててるし

Web Componentsが普及したらAngularの時代は終わりだろうな。

AngularがJavaScriptを意識させないでHTMLをかけるのはいいんだが、
HTMLにAngularのための属性が散らばることになる。

HTMLはシンプルでなければならない。

Web Componentsが普及すれば、Angular専用の属性はタグに変わるだろう。
AngularがWeb Componentsに対応するかも知れないけど、
Web Components+JavaScriptで事足りるので、Angularを使うまでもないだろうな。

最後に生き残るのはWeb標準技術とJavaScriptとDOM。
そしてこれらの技術を効率良く使うための軽いライブラリになるだろう。

Web ComponentsのPolymerもgoogleでしょ?
わざわざAngularが廃れる方向にはしない気がする
googleデファクトスタンダードで技術の囲い込みが嫌な方向に進む未来もあるかも

＞HTMLはシンプルでなければならない。

今時こんな事言ってるのは無能でしかない

複雑になってもおｋだと考える奴がアホだろ
プログラマーに向いてない

最近は脱jQueryって流れなのかね？
DOM操作とかならいいのかもしれないけど、凝ったエフェクト系の演出とか
jQuery以外でまとまってるフレームワークってあるの？

>>663
大事なのはユーザーエクスペリエンス
そもそも出力されるHTMLは人間が読むものではない
そんな考えだから三流なんだよ

でも、レンダリングソースがHTMLである以上、
デバッグや動作確認で読みやすい状態になっていて欲しい。

デバッグツール使えよ

みんなはもうjQueryは捨てた？
何使ってるの？

>>668
jQuery以外を捨てた。

結局はウェブ標準。

jQueryはウェブ標準・・・の書き方を少し関数型言語っぽくした
軽いライブラリという扱いで使っている。

>>665
お前Web Component知らないだろw

”出力されるHTMLは人間が読むものではない” と
言っていることから推測するに、
人間が読むGものが、HTMLとは別にあるってことだろう？
"その言語" で書いてHTMLを生成しているわけだろう？

Web Componentはまさに、"その言語" なんだが。
複雑なHTMLを隠蔽し、人間が読みやすい書き方で書くことが出来る。

人間が読む必要ないってすごい
プログラミング言語の進化を無視してるけど
一流の人間はアセンブリで開発してのけ？

>>669
たしかに良くも悪くもjQueryが標準になってるけど、最近になって
いろいろとフレームワークが乱立してるのが気になってるんだよね

仕事だとAngularJS使うプロジェクトが増えてるけど、上の方にも
あったみたいに先が見えない
Reactive Programmingってのがこれからの主流にはなりそうだけど
Vue.jsやfacebook主導のReact.js、片やReactive.jsなんてもの別にあったり

Backbone、Knockout、AngularJSなどのMVVMを信奉してる人たちはjQueryを捨てろと言う
でも、スライドショーとかパララックスなんかはjQueryプラグインに一日の長があるし

>>671
お前は根本的にわかってないから
黙っててくれないか？ｗ

>>672
> Backbone、Knockout、AngularJSなどのMVVMを信奉してる人たちはjQueryを捨てろと言う

フレームワークとライブラリの違いだよ。

フレームワークを使うとその技術に深く依存してしまいやすい。
なのでフレームワークが廃れてしまうと負債になってしまう。
その負債でアプリ全体が作られている。

ライブラリは、部分的に導入したり、導入を辞めたり出来る。
使おうと思えば、すぐに使えるし、使わないと思えば少しづつ辞められる。

JavaScriptの世界が他の言語と違うのは、ウェブ標準というフレームワークが存在していて、
それがブラウザの機能としてネイティブに搭載されていく所。ブラウザに搭載されていない機能を
JavaScriptで頑張って実装している。というのがJavaScriptフレームワークの本質。
だからいずれブラウザに機能が搭載された時JavaScriptのフレームワークは必要なくなる。

だけどjQueryは、ウェブ標準（正確に言えばDOM）をより簡潔に記述できるようにしたものにすぎない。
だから息が長い。もしjQueryが無くなる時があるとするならば、DOM APIすべてが再構成された時だろう。

>>665
minimizeの話じゃないよな？
人間が読めないHTMLを吐く具体的な開発環境を教えてよ。
出力されるHTMLのコードのサンプルもあるならみせて。

>>672
>でも、スライドショーとかパララックスなんかはjQueryプラグインに一日の長があるし
jQueryのアニメーション関連のUIはパフォーマンスや実用性に問題が出てきてる感じ。
jQuery UIとかひどい。slideとか単純な動き以外は使えない。

アニメーションライブラリのvelocity.jsも脱jQueryしたし、jQueryのanimateはわざわざ使う必要性が無くなってきてる。

angularはgoogle製なのが嫌
googleのプログラムは変なクセが強い印象

でも、もう世界的にwebブラウザはGoogle Chromeとその派生品の勝利ってことで決着が着いた模様

"Did the browser wars finally end in 2014?"
http://www.zdnet.com/article/did-the-browser-wars-finally-end-in-2014/

もう少し範囲を広げると、WebKit/Blinkベースのブラウザの勝利

そういえば、スマホ用のブラウザゲームとか作ってる業界だと
jQueryは使わず、DOM操作やイベント処理系をラップした独自の
ライブラリを社内標準的に使ってる会社と
jQueryのサブセット的な製品であるzept/App Framework(旧jqMobi)
あたりを標準的に使ってる会社とに別れる気がする

オレ的にはAngular離れが進んでる認識なんだが

同感
AngularJS採用してるプロジェクトは、いずれ地獄のコードメンテと高い移行コストを
代償として支払うことになるんだろう

【翻訳】Angularチームは、どうかしちゃった？
http://postd.cc/have-the-angular-team-lost-their-marbles/
AngularJSは今すぐ生まれ変わるか死ね
http://diary.hatenablog.jp/entry/2014/10/06/165007
Angularが嫌い
http://mizchi.hatenablog.com/entry/2014/10/06/162103

>>667
お前が可読性無しのHTMLコードで使ってるツールってなに？

>>670
コンポーネントはコンポーネントであって言語ではないだろ

>>683
> コンポーネントはコンポーネントであって言語ではないだろ

マークアップ言語。正確には新しいタグを作れる。

>>676
> アニメーションライブラリのvelocity.jsも脱jQueryしたし、jQueryのanimateはわざわざ使う必要性が無くなってきてる。

俺は、アニメーションライブラリとしてjQueryを見てないけどね。
DOM操作を簡潔に記述するためのライブラリ。

なぜアニメーションが脱jQueryをしたか？
その理由は簡単で、ブラウザにそのための機能（CSSアニメーション）が
搭載されたから。

>>674で書いたことと同じだよ。
ブラウザにネイティブに搭載されることで、フレームワーク及びライブラリは不要に
なっていくのがブラウザで動作するJavaScriptの世界。

Web ComponentsはAngularJSを置き換えるものになる。

マークアップ言語はHTML
コンポーネントは抽象化の手段、概念

＞なぜアニメーションが脱jQueryをしたか？
＞その理由は簡単で、ブラウザにそのための機能（CSSアニメーション）が
＞搭載されたから。

因果関係が真逆だ
css animation が実装されたので、それを便利に制御するjQuery animateなどのアニメーションライブラリが出てきた

css animation ができたのはCSS3からで
対応ブラウザは、IE10以上だぞ？

jQueryは何時の時代からあると思ってるんだ。
初期のjQueryはIE5.5対応だぞ。

>>686
マークアップ言語はHTML
コンポーネントは抽象化の手段、概念

そしてWeb Componentsは
コンポーネントという概念を実装したもので、
HTMLの要素に相当するものを自分で作り出せる。

言語を拡張することが出来る仕様。

>>688
だから、css animationの登場はそれを制御するライブラリの必要性を強化するのであって
「脱jQuery」に向かう理由には全くならない
それとも素のCSSでエフェクトとか全部書いてるのかい？

>>690
>>687から主張が変わってるじゃないか

>>685
＞なぜアニメーションが脱jQueryをしたか？
＞その理由は簡単で、ブラウザにそのための機能（CSSアニメーション）が
＞搭載されたから。

ちがう。単にパフォーマンスの問題。

＞>>674で書いたことと同じだよ。
＞ブラウザにネイティブに搭載されることで、フレームワーク及びライブラリは不要に
＞なっていくのがブラウザで動作するJavaScriptの世界。

ライブラリ無しでアニメーションするメリットは皆無。

>>670
人間に読めないHTMLとか言ってるのは論外だが、「複雑なHTMLの隠蔽」ってのも正しくない。
カプセル化されてるのはDOM,javascript,event,cssで構成された「コンポーネント」。

googleはプロダクトだけじゃなくデザインのガイドラインもものすごく力入れて普及してるし
影響力がますます強くなりそう。

いまだにprototype

http://twitter.com/kai_ri_no/status/548921681549340672/photo/1
htmlファイルをローカルに置いたら jQuery UI も 使えなくなるIE11

>>696
さすがにこれは @kai_ri_no の頭が固いとしか思えない
テストが面倒なだけで IE11 の不具合じゃないだろう
しかも、ローカルテストなんてローカルにサーバを立ててテストするのが基本

ブラウザ間バージョン間の違いをすべて吸収できる書き方ができれば何でもいいんだよｗ

>>685
＞Web ComponentsはAngularJSを置き換えるものになる。
ちょっと調べたけどgoogleはそう考えてないようだな。

>>699
勝手にGoolgeの気持ちを代弁するな