のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,908人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレJavaScript ライブラリ総合質問所 vol.4

    JavaScript覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    651 = :

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

    652 = :

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

    653 = :

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

    655 = :

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

    656 = :

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

    657 = :

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

    658 = :

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

    659 = :

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


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

    660 = :

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

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

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

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

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

    661 = :

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

    662 = :

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

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

    663 = :

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

    664 = :

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

    665 = :

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

    666 = :

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

    667 = :

    デバッグツール使えよ

    668 = :

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

    669 = :

    >>668
    jQuery以外を捨てた。

    結局はウェブ標準。

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

    670 = :

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

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

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

    671 = :

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

    672 = :

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

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

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

    673 = :

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

    674 = :

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

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

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

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

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

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

    675 = :

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

    676 = :

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

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

    678 = :

    でも、もう世界的に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ベースのブラウザの勝利

    680 = :

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

    681 = :

    同感
    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

    682 = :

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

    683 = :

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

    684 = :

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

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

    685 = :

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

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

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

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

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

    686 = :

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

    687 = :

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

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

    688 = :

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

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

    689 = :

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

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

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

    690 = :

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

    691 = :

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

    692 = :

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

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

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

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

    693 = :

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

    694 = :

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

    696 = :

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

    697 = :

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

    698 = :

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

    699 = :

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

    700 = :

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


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / JavaScript一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について