JavaScriptフレームワーク選定の議論 - Qiita
相談内容 既存の管理ツールを新しく作り直すために新しいJSフレームワーク/言語使いたいのですが、何を選んだらよいでしょうか？ ここで選んだものは今後新しく作る時にも使用していく予定のため、学習コストよりメンテナンスしやすいものを選びたいと考えています。 利用者は社内外で特定の権限を持った人のみであるため、サーバサイドレンダリングはしない予定です。 言語は型があるものを利用したいのですが、TypeScriptとFlowのどちらがよろしいでしょうか？ 時間に余裕があれば、テストフレームワークやビルドツールについてもお聞きしたいです。 現在のページ/チーム jQueryなどで書かれている部分が多いですが、変更を加えることが難しくメンテナンスコストが高いです。 サーバサイドをやってる人が片手間で書くJavaScriptといった状況です。 今回新規で数ページを追加する必要があるため、何を利用すれば良
Travis CIでtextlintの指摘をPull Requestのレビューコメントとして書き込む - Qiita
textlintをTravis CIで動かして継続的に文章をチェックする - Qiita の続き的な話です。 textlintのチェックが失敗したら、Pull Requestのコメントとして書いてくれるものを作る仕組みの話です。 一般にLint系をCIで走らせると、どこで失敗したのかを確認しにくくCIまで見に行くのは面倒だし分かりにくいです。 GitHubではレビューコメントで該当行にコメントを書けるので、直接そこへ指摘のコメントある方が良いです。 Houndがまさにそういうサービスですが、任意のツールには対応していません。 Saddlerというツールが同じことをTravis CIやCircle CIから行う事ができます。 変更したファイルにrubocopやjscsを実行して pull requestに自動でコメントする – Saddler - checkstyle to anywhere
JavaScriptライブラリ/プロジェクトのファイルサイズの問題点を見つける方法 - Qiita
ブラウザ向けのJavaScriptだとファイルサイズはある程度気になると思います。 この記事では、ファイルサイズの計測方法やボトルネックとなってるライブラリの見つけ方についてできるだけ簡単な方法をまとめます。 ファイルサイズと一言にいっても、ブラウザでは大体minifyしてから配布するのでminify後のファイルサイズも重要です。 ソースコード自体のファイルサイズ minifyしたファイルサイズ minify + gzipしたファイルサイズ コメントの多いソースコードはminifyするとかなり小さくなったりすることが多いので、ソースコード自体のファイルサイズでは比較しにくいです。 また、ソースコードにおいて assert モジュールを使っているとファイルサイズが10kb弱程度minify後で変わります。 assertモジュールは通常外しても問題ないので、unassertでビルド時に取り除き
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
