Read/Write Stack | JavaScriptアーキテクチャ
autoscale: true Read/Write Stack | JavaScriptアーキテクチャ 自己紹介 Name : azu Twitter : @azu_re Website: Web scratch, JSer.info This is Bikeshed.js :bike: 抽象的な話が多いので、実装はコード見て(Pull Request投げて！) これが正しいという話ではないです。 自転車置き場の議論なので！ 中規模以上のJavaScript 設計が必要になる 正しい設計はない Bikeshed.js :bike: 人、目的、何を作るかによってアーキテクチャは異なる 前回の続き? : How to work as a Team 用語 設計の目的 中規模以上のウェブアプリ SPAというよりは、画面が複雑なElectronアプリのようなイメージ スケーラブル 人、機能追加、柔
Measuring Client-Side JavaScript Test Coverage With Istanbul
Testing is a vital part of any development process. Whether a project’s authors are hoping for scalability, fewer bugs, or just code that stands the test of time, a solid test suite is essential. It’s all well and good writing tests, but how do you know that you’ve tested the code that matters? Did you cover the most important components? Did you test the sad path? The edge cases? What about the z
あのライブラリは何故誕生したの?のまとめ - Qiita
はじめに 最近、フロントエンドのライブラリ乱立問題について盛り上がってました。 自分はnobkzさんの以下の文に全てがまとまっていると思います。 僕の最初の違和感は、「技術的な流行り」に乗ることに何の価値があるのだろうか?ということである。もちろん、最新のツールやフレームワークはより何かが良くなってるかもしれない。しかし、 それをあなたのプロジェクトで採用するには何の価値があるだろうか? 「最近のフロントエンドへの違和感 - nobkzのブログ」より 裏を返せば、新しいライブラリの内容、特に「どのような問題を解決するためにこのライブラリが生まれたのか」という思想を把握しておくことは重要だと言えます。 つまりは、 "How?(ライブラリの使い方)" よりも "Why?(なぜそのライブラリが必要なのか)" を学んでおこう ということです。この記事では どのような既存の問題・要求を どう解決して
You Don't Need jQuery - Qiita
注意とお願い この記事の内容はもはや古いです。ここに書いている方法では動かないものをいくつか見つけました。参考にする際は動作をよく確認してから使ってください。 ひとつお願いがあります。「あれ、動かないぞ」というコードを見つけたら是非コメントか編集リクエストで教えてください。解決方法までなくても結構です。「これはもう動かないよ」という印をつけたいのです。 この記事はYou Don't Need jQueryの日本語訳と同じ内容です。 先日ひょんなことからYou Don't Need jQueryの日本語訳をさせていただきました。著者のCam Songさんからも快諾をいただけたので1、Qiitaでも公開させていただきます。 なお、本家の英語の説明は継続的にメンテされているので、この記事の情報は古くなっている可能性があります。 追記 この記事は当初は「もうjQueryは必要ない」というタイトルで
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
StackPath