jQueryで楽になる部分、楽にならない部分、顧客が本当に必要だったもの - Qiita
俺も昔はお前のような jQueryスパゲッティジェネレーターだったのだが、膝にReactを受けてしまってな… 基本的な方針 とくにライブラリ設計者において、小さなモジュールを単機能で分割する以上、ライブラリ設計者は可能な限り依存を減らすことを求められます。node環境ならdependency hellの回避のため、フロントエンド環境ならファイルサイズを減らすためです。 ライブラリ設計者ならずともコードのポータビリティを維持するため、できるだけライブラリに依存しないコードを書くのが望ましいです。 Githubみてる限り、最近書かれるJSのライブラリの多くはjQuery非依存です。ユーザーから見る限りは、jQueryElement渡すかHTMLElement使うかぐらいの違いですけどね。 また、Angular, React等のSPAをスクラッチで設計する場合、気づいたらjQueryを使っていな
筋の悪さ | tech - 氾濫原
JS しか書いてないんだなって人は筋悪いものをありがたがっていたりする印象はある。しかし筋悪いものをありがたがるみたいなのはどこにでもいるので、JSがどうとかは直接は関係がないはずではあると思う。JSしか書いてない人とPHPしか書いてない人は似たようなもんで、単に広範囲の知識に興味がないだけな気がする。 それはともかく「これは筋悪そうだな」っていう感覚がどこからくるのかよくわかってないので、現時点で思いつく限り雑にメモしておく。 割の合わなさ 「これは何の問題を解決してるんだろう」と思ってドキュメント読んだりソース読んだりした結果、大したことを解決してなくて、その割に実装量が多いとか学習コストが高いと、筋悪いなあと思う。 フットプリントや学習コストに対して提供されるモノが「割に合わない」のは筋が悪く感じる。 将来性のなさ 「あ、これはただの流行だな」みたいな、5年後には消滅してるなというも
JavaScript(ES2015)でvarやletを使う必要はほぼ無い - id:anatooのブログ
ES2015でvarやletを使う場面はほとんど無いので、まずconstを使う。constだとダメな場合にはletを使う。 背景 ES2015では、変数を宣言するための文法としてconstとletが導入された。 const foo = 'foo'; let bar = 'bar'; constは再代入できない変数を宣言できる。letは再代入できる変数を宣言できる。 const foo = 'foo'; foo = 'hoge'; // ERROR let bar = 'bar'; bar = 'hoge'; // OK あれ、じゃあvarとletは同じなの？っていうとそうではなく、letやconstはvarとは違って、関数スコープよりも細かなブロック単位のスコープを提供する。例えばconstやletを使うと、if文やfor文などのブロック中でのみ有効な変数を宣言できる。 で、プロジェクトに
hiddenなinput要素のXSSでJavaScript実行
脆弱性診断をやっていると、たまにtype=hiddenのinput要素にXSSがあるけど、現実的な攻撃には至らないものにぶちあたることがあります。サンプルコードを以下に示します。 <body> 入力確認をお願いします。 <?php echo htmlspecialchars($_GET['t']); ?><br> <form action='submit.php'> <input type='hidden' name='t' value='<?php echo htmlspecialchars($_GET['t']); ?>'> <input type='submit'> </body> 正常系の呼び出しは下記のようになります。 http://example/hidden-xss.php?t=yamada HTMLソースは下記の通りです。 <body> 入力確認をお願いします。 yamad
あのライブラリは何故誕生したの?のまとめ - Qiita
はじめに 最近、フロントエンドのライブラリ乱立問題について盛り上がってました。 自分はnobkzさんの以下の文に全てがまとまっていると思います。 僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールやフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか? 「最近のフロントエンドへの違和感 - nobkzのブログ」より 裏を返せば、新しいライブラリの内容、特に「どのような問題を解決するためにこのライブラリが生まれたのか」という思想を把握しておくことは重要だと言えます。 つまりは、 "How?(ライブラリの使い方)" よりも "Why?(なぜそのライブラリが必要なのか)" を学んでおこう ということです。この記事では どのような既存の問題・要求を どう解決して
10年のツケを支払ったフロント界隈におけるJavaScript開発環境（2016年4月現在）。 - 日々、とんは語る。
2015年はCSSが普及した以来となる10年に1度のフロントエンド大変革期で、それまでのツケが一気に回ってきたと個人的に感じていました。目まぐるしく状況が変化していきましたが、2016年になり、個人的にだいぶ落ち着いてきたと感じているので、ここらへんでまとめておきたい思います。 最初に結論を書いておくと、 『React + Redux + react-router + material-ui + axios + ES2015 + Babel + webpack + ESLint + Airbnb JavaScript Style Guide』 という組み合わせが、いま僕の採用しているJavaScriptの環境です。 主要ライブラリは React A JavaScript library for building user interfaces | React 去年、一気に普及したReact
春からはじめるモダンJavaScript / ES2015 - Qiita
春ですね！人の配置がリファクタリングされ、コードもリファクタリングの季節です。 では僕がここでモダンなJavaScriptとES2015の利点を語る役をやるので、みなさんはチームを説得する役をやってください。 JavaScriptの歴史 まず最初にJavaScriptの歴史を踏まえることで、今学ぶべきものとその理由を確認しましょう。 なぜ2016年の記事でES2016ではなく、ES2015なのか、と疑問に思った方もいるかもしれません。それは、ES2015がただの年次アップデートではなく、これから始まる毎年のメジャーバージョンアップの起点となるバージョンであり、またES5から飛躍的に仕様が増えたバージョンであるからです。 簡単に(雑な)歴史を紹介します。 ブレンダン・アイクによってNetScapeに実装/搭載された古の時代〜IE6 (1996~2005) ES3: 一時はシェア7割を誇ったレ
僕なりのフロントエンド開発環境2016年版 - Qiita
ちょっとバージョンアップ http://qiita.com/koh110/items/f6ecbdc03093675a9527 自分なりに使いやすいフロントエンドの開発環境を整えて使っていたけれど、だんだん時代の流れにそぐわない箇所が出てきたのでその部分を書き換えてアップデートしてみた。 http://qiita.com/koh110/items/9c750fb67e40481e52cd 昔のバージョンはv1.0.0というブランチに切り出し https://github.com/koh110/minjsapp やめたもの gulp-load-plugins run-sequence bower モジュールやライブラリへの依存度を下げたかった 変更したもの gulp-babel -> webpack + babel-loader requireしたかった 追加したもの sassコンパル 生c
テストを使いサービス開発を駆動していくために取り組んでいること - クックパッド開発者ブログ
技術部の松尾(@Kazu_cocoa)です。 最近、 @moroや私を中心に、テストから開発を駆動するという方向で、とある活動を始めました。その活動の中では、 @t_wadaさん を 技術顧問 として巻き込んで活動を進めています。そんな取り組みを少しここにまとめます。 取り組みの前段階 先日、私はテストエンジニアというロールに焦点を当ててテストという言葉に対する2種類の話をいたしました。TDDのようにテストによって開発を駆動していく側面の話と、人の認知・感じ方に寄った仕様自体含めてテストしていく側面の話です。 クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアのあり方〜 を開催しました！ クックパッドエンジニアトークナイト 〜クックパッドテストエンジニアvol.2 Testing編〜 を開催しました！ その際、会の傍でt_wadaさんらと私たちが開発するWebアプリケーショ
Lodash/Underscoreは必要ない（かも） - Qiita
Robert Chang氏によるYou don't (may not) need Lodash/Underscoreを和訳しました。 意訳が含まれるため、誤りやより良い表現などがあればご指摘頂けると助かります。 原文：https://github.com/cht8687/You-Dont-Need-Lodash-Underscore LodashとUnderscoreは必要ない（かも） LodashとUnderscoreは素晴らしいモダンなJavaScriptユーティリティライブラリであり、フロントエンド開発者に広く使われています。しかしながら、モダンブラウザがターゲットとなる場合、ES5やES6のおかげでネイティブにサポートされたメソッドが多くあることに気づくでしょう。プロジェクトの依存関係を減らし、ターゲットブラウザが明確になっているのであれば、LodashとUnderscoreは必要
Scriptular - Javascript Regular Expression Editor
Scriptular is a javascript regular expression editor. Inspired by Rubular it gives you a simple way to test javascript regular expressions as you write them. Start by entering a regular expression and then a test string. Or give this example a try. Learn more about regular expressions in javascript.
旧石器時代のJavaScriptを書いてる各位に告ぐ、現代的なJavaScript超入門 Section2 ～CommonJSモジュールと仲良くなろう～ - Qiita
はじめに この記事は「旧石器時代のJavaScriptを書いてる各位に告ぐ、現代的なJavaScript超入門」の2つ目の記事です。 シリーズの最初から読みたい方は 旧石器時代のJavaScriptを書いてる各位に告ぐ、現代的なJavaScript超入門 Section1 ～すぐにでも現代っぽく出来るワンポイントまとめ～ へどうぞ。 また、このシリーズではECMAScript5を概ね対応するブラウザを対象としています。 もっと平たくいうと、IE8以下は切り捨てます。ご了承ください。 そしてプロによるマサカリ 対策として一つ重要な注意書きをします。 この記事中で出てくる「CommonJSモジュール」という表現は全て「CommonJSのModules 1.0仕様をベースとして、Node.jsが独自に拡張したCommonJS派生のモジュール仕様及びインターフェース(require/exports
旧石器時代のJavaScriptを書いてる各位に告ぐ、現代的なJavaScript超入門 Section1 ～すぐにでも現代っぽく出来るワンポイントまとめ～ - Qiita
はじめに ネットには様々な情報が溢れており、JavaScriptに関する情報も多数存在しております。 その中には、「今時こんな書き方しねえよ…」と思わずツッコミを入れたくなるような、本当に、本当に古い内容について書かれている古文書も存在します。 そんな罠記事の情報に囚われてしまって、いつまで経っても現代的なJavaScriptが書けない皆さんのために、このシリーズの記事では、各セクション毎に分けて、旧石器時代の記述と、現代の記述を紹介する形で、文明開化をしていきたいという思いで記述する。 最初は、現在比較的メジャーなブラウザで一通り動作する「ECMAScript 5」までの内容に関してポエムを書き連ねていき、最終的には一連の内容を読むだけで「ES6(ES2015)」による新機能や、絶賛提案中の「ES7」の一部提案内容についても把握し、おおよそ現代人を育成することを目標とする。 …なんてめっ
意外と知らない？ JavaScript トレンド 2015 - Gaiax Engineers' Blog
Gaiax Advent Calendar 2015 18日目担当の @hoto17296 です。 昨今の JavaScript は状況がめまぐるしく変化していて、それほど関心がない人にとっては追随するだけでも一苦労なのではないでしょうか。そこで今回は最近の JavaScript がわからない人向けに「昨今の JavaScript トレンド」について書きます。 トレンドっぽいキーワード一覧 ひとまずパっと思いつくキーワードを列挙してみます。 Node.js v4.2 "Argon" (LTS) npm v3 ES2015 / ES2016 Class Arrow Function let, const Promise Generator Async/Await co Observable 開発環境 Babel Gulp Browserify Webpack TypeScript アーキテク
JavaScriptフレームワークのコストを考える | POSTD
先日、私はBrightonで開かれたJavaScriptのカンファレンスFFConfで「(ここにライブラリやフレームワークの名前を入れる)を使おう。これこそ最強中の最強中の最強だ！」と題して話をしました。 ここに、そのプレゼンテーションの内容を書き起こします。もっと注目されるべき、最近のモバイルデバイスのフレームワークにかかるコストに関して、議論を広げる一助となればと思います。 2015年11月16日更新 – テーブルに1行、プロダクション環境下のReactについての行を追加しました。良いニュースをお伝えしますと、これはvanillaよりも3倍遅いですが、TodoMVCに関して言えば速いと言えます！PolymerのTodoMVCサンプルも最新バージョン1.2.2にアップデートされ、同様により速くなりました。 読むよりも見たい方へ、講演のビデオはこちらです。（必要なら、 スライドも入手できま
2015年までにWebのフロントエンドが辿ってきた道 - Qiita
背景 僕が本格的にWebのエンジニアになったのは2014年頃からで、早いものでもう丸2年ほど経ってしまうことになります。 Webに転向してからは主にフロントエンドエンジニアとして勤務してきました。 よく言われることですが、最近のフロントエンドの趨勢は本当に早いです。 最初はキャッチアップに苦労したことを覚えています。 しかし段々と新しい何かを覚えることは苦でなくなり、今はこの流れに身を置くことが楽しいと思えるようになってきました。 激動の趨勢の中で、Webのフロントエンドエンジニアが口にするパラダイムは日ごとに変化しています。 この記事は元々社内向けに書いたものです。 色々なバックグラウンドを持つエンジニアと一緒にフロントの設計を考える場面で、共通言語を持つきっかけになればいいなー、という思いから書いたものですが、いい機会なので外向けに修正して公開してみます。 Webのフロントエンドを新し
ESLint2について調べた - Qiita
Node.js Advent Calendar 2015の7日目の記事です。遅刻してごめんなさいごめんなさい。 sinopiaをs3対応して記事を書こうと思ったのですが、思ったより手こずってしまい、ESLintの2系のalpha版が出たので、そちらについて調べました。 ESLint v2.0.0-alpha-1 released 新しいルール 下記のルールが新しく追加される。 array-callback-return Arrayのfilterやreduceなど、callback内で値を返す必要があるのに返してない場合にエラーを出す。 no-implicit-globals 暗黙的にグローバルに定義されている変数がある場合にエラーを出す no-restricted-imports 任意のパッケージのimportを禁止する prefer-rest-params ES6のRest Parame
JavaScriptのトレンドを素振りして確認する方法 - Qiita
JavaScriptは流れが早いと言われますが、その流れをどう捉えるかの一つの要素として使える素振りの話です。 流行り廃れが早いのはちゃんと循環してるということなので問題ないですが、 トレンドと言われるものの半分ぐらいは誰かの主張にすぎない事があります。 そのため、主張だけを見て判断しないで中身を見て確認する必要があります。 自分はJSer.infoというJavaScriptの情報サイトを2^8週間ほど継続してやっています。(5周年記念イベントを1/16(土)にやります) JSer.infoで紹介するものは何かしらの方法でその主張がおかしくないかの確認をとります。 売り文句は素晴らしいが中身を見た時におかしな部分や問題がありそうなら、そこで引き返して追わないという判断もします。 仮にそこで引き返した事が間違えであっても、それが素晴らしいものなら別の誰かがそういう主張を書いてくれるはずなので
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
安全なJavaScriptを書く
JSオジサン as a Service.pdf
