npm とか bower とか一体何なんだよ！Javascript 界隈の文脈を理解しよう - Qiita
背景 Javascript で Web アプリを作ろうとすると、よくわからないことだらけで超混乱します。 npm と bower の違いは？ npm はサーバーサイド用、bower はクライアントサイド用らしいよ えっ、でもなんで bower のインストールに npm が必要なの？ サーバーサイドは Rails で書きたいから npm 要らないと思うんだけど・・・ ていうかサーバーサイドJSとか node.js って何？ よく見る browserify って何？ こういった疑問が沸き上がるのは、各ツールが生まれた文脈がよくわかっていないからです。いろいろ調べてやっとちょっとわかってきたのでメモします。間違いがあったらご指摘ください。 「CommonJS」誕生 - Javascript は汎用プログラミング言語へ その昔、Javascript 大好きおじさんは言いました。 Javascrip
Webアプリのモックアップ作業土台を作る その3 Sass Source Map - cu39's diary
その1 と その2 Sprockets の続きです。が、今回の作業は その1 の途中からブランチしてます。 Google Chrome の Dev Tools は Sass/SCSS の Source Map に対応しているので利用できるようにしてみます。が、Source Map は仕様も実装も流動的な状態で、環境によって動作しない可能性も大ありなので、あくまで参考まで。 リポジトリ上では Sprockets も Bootstrap も Compass も導入する前の段階からブランチを生やしました。 https://github.com/cu39/workbench/tree/sass-sourcemap-on-plain 新仕様と旧仕様 CSS リクエストへのレスポンスでブラウザに Source Map の位置（パス）を知らせる必要があり、その方法は2種類あります。 レスポンスの HTT
Webアプリのモックアップ作業土台を作る その2 Sprockets - cu39's diary
前回のつづき。 前回作った作業台に Sprockets を導入して assets 提供を分離します。といっても Sprockets 使っていくかどうか自分でも確信持ててないのでリポジトリではブランチにしておきました。 https://github.com/cu39/workbench/tree/sprockets Sprockets を導入するメリットとしては、このままデプロイするケースを視野に入れたときに圧縮機能を追加しやすかったりプリコンパイルできたりするところでしょうか（どちらも今回はやってません）。 というわけで、まずは Gemfile に sprockets 関連の gem を追加して bundle。 gem 'sprockets' gem 'sprockets-helpers' gem 'sprockets-sass' ディレクトリ構成を変更 前回の最後では以下のようなディレク
Webアプリのモックアップ作業土台を作る その1 - cu39's diary
Slim, Sass/SCSS, CoffeeScript が使えて Livereload してくれるフロント周辺の作業環境がほしいと思いながらも自分にしっくりくる構成ができなかったんですが、最近 rack-livereload を見つけてピースが埋まった感じがしたのでまとめます。 https://github.com/cu39/workbench 記事を書くにあたり naoya さんのひな型に大いに影響されてますが、ここでは npm でインストールするのは bower だけにして基本的には Sinatra と Guard に任せています。 Sinatra, Slim, Sass, CoffeeScript 土台の土台としてシンプルな Sinatra アプリから。Gemfile を書いて bundle。 Gemfile source 'https://rubygems.org' gem '
昨今の自分用Webアプリケーションひな形 - naoyaのはてなダイアリー
ちょっと jQuery と簡単なサーバサイドの処理を組み合わせた処理を試しに書いてみよう･･･なんて時に、いちいち jQuery を取ってきて HTML を書いて script タグを書いてロードして sinatra 立ち上げて云々･･･というのが毎度面倒なので、ひな形になるアプリケーションを作った。 https://github.com/naoya/boilerplate ひとまず sinatra でサーバーサイドを書き、HTML は slim で、CSS は sass 。JavaScript は CoffeeScriptで書くにあたって jQuery、underscore、Backbone をロードしてある、というような構成にしてあります。 まあ、この類のことは人それぞれ自分なりにカスタマイズしてやっていると思いますが、どういうコンポーネントで構成しているかを、備忘録も兼ねてちょっと紹
JavaScriptでのモジュールロード方式とパッケージ管理についての勉強メモ(2015-03時点) - msakamoto-sfのはてなブログ
2015-03-23 JavaScriptでのモジュールロード方式とパッケージ管理についての勉強メモ(2015-03時点) npm Node.js Browserify Bower RequireJS webpack CommonJS AMD 2015-03時点でJSのモジュールロードとかパッケージ管理について見てみると、CommonJSだとかAMDだとかBrowserifyとかwebpackとかbowerとか色々出てきて混乱したので、整理してみた勉強メモです。各プロダクト・仕様のできることや役割について、まだまだ誤解してる部分もあると思いますので、勉強中ということで割り引いてください。 簡単な歴史と経緯 ※細かい歴史とか時系列は無視してます、というか知らないで書いてます。あくまでも自分の頭のなかでの整理用。 require.jsがブラウザ上のアプリで頑張ってモジュールロードできるようにし
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
