jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな… 基本的な方針 とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。 ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。 Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。 また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていな
春からはじめるモダンJavaScript / ES2015 - Qiita
春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点となるバージョンであり、またES5から飛躍的に仕様が増えたバージョンであるからです。 簡単に(雑な)歴史を紹介します。 ブレンダン・アイクによってNetScapeに実装/搭載された古の時代〜IE6 (1996~2005) ES3: 一時はシェア7割を誇ったレ
テストがないJS環境にモダンなテスト環境を導入していく - Qiita
Qiita:Teamに投げた社内ドキュメントだったけど、特に問題ないのでQiitaにも投げる。 前提として browserify-rails とbabelify が導入されている状況を想定してる。 基本方針 新規コードはES2015で書く 本番はbrowserify(-rails)でコンパイルする。 単体テストは node 環境下で走らせる テスト環境下では jsdom で window, document をモックする 単体テストでは ブラウザ特有の挙動はテストしない 裏側の環境(browserifyやspec-helper)は難しくして良いが、利用者からみえる範囲は複雑にしない(npm install; npm testで走る) Universal JavaScript に寄せることでコードのポータビリティを上げる 事前準備 browserify-railsを導入する。 .babelr
JavaScriptのモジュールシステムの歴史と現状 - Qiita
社内向け資料。自分が書いたコードを説明するために資料作る羽目になった。 昔のことはうろ覚えで雰囲気で書いてる部分もあるので、そこらへん勘弁。 古の時代(~2010) 前提としてJavaScriptは名前空間がwindowの一つしかない。 昔Prototype.jsがあった。もうみんな忘れたけどあの時期はプリミティブなオブジェクトのprototypeを生やしまくって、それが衝突しまくってprototype良くない的な雰囲気が生まれたり生まれなかったりした。 その反省があってか(歴史的に若干微妙な気がするが) jQueryは名前空間を一つに集約した。いわゆる jQueryPlugin は、jQueryのプロトタイプにヘルパを生やしまくっていた。グローバルを汚すのは駄目だけどjQueryの名前空間を汚すのはいいよね、ぐらいの考え。 jQuery非依存なライブラリは、「GoodParts」として、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
