フロントエンドで使ってるものがあまり変わってない - No Regrets in Bathing
自分のスタックはあまり変わっていない。ほとんど10年のツケを払っていない。学習能力が低いせいでもあり、選んだスタックがバージョンを重ねている成果でもある。 毎回使う フレームワーク：Vue.js 消耗、などの意見が散見されたが、べつに今でも便利に使えている。 browserifyやwebpackがあれば便利だけど、なくてもいい、ってバランスが好き データフローは特に考えない。状態がそこにあるので書き換えれば良い。 あまり頭を使わなくていいのが助かる Reactの考え方は好きなのだけど、よっしゃFluxやるぞって気持ちにはならず、Reactのみでよしなにやるソリューションが広まったらいいなと思う。 ビルドシステム： browserify / watchify substackの作るものはどれも品質が高いので、もうsubstack製品だけ使っていればいいやという気持ちになりがち。余計な処理が全
uu59のメモ | browserifyとwebpack
webpack for browserify users browserify for webpack users browserify フロントエンド界にCommonJSスタイルを持ち込める 一部Node.jsのモジュールも使える。pathとかurlといった便利な小物から、zlibとかcryptoなどの本格派も移植されてる substackプロダクト。よってUNIX哲学へのこだわりが強く、必要なさそうな機能は本体で持ってない。 本体は単機能だけどwatchifyやdebowerifyやbundle-factorなどと連携して多くのことができる 当然ながらgrunt/gulpに組み込むことも出来る webpack フロントエンド界にCommonJSやAMDスタイルを持ち込める JS以外にもCSSとか色々扱える オプションやモジュールが色々あって気になったことは大抵できると思う grunt,
JavaScriptのモジュール管理(CommonJSとかAMDとかBrowserifyとかwebpack) | tsuchikazu blog
昨年のAdvent Calendarを眺めたり、JS周りの記事を見ていると、RequireJSとか、CommonJSとか、AMD、Browserify、webpackあたりが、同じような文脈で登場するんですが、それぞれ何を指しているのかよくわからなかったため、今更ながらまとめてみます。 前提 小規模にしかJavaScriptを使っていないWebサイトでは、jQueryを使ってDomイベントで色んな処理をして、Domに反映させる。というような処理が、ごちゃっとまとめて書くことが多いかと思います。ごちゃっととは、特にDomにしか情報を保持していない状態を指していて、イメージとしてはこのようなコードです。 $(function() { # イベントハンドラ $("#btn").on("click", function(){ $.ajax({ url: "api/resources", dataT
既存 JS ファイルを Browserify 用に書き直す - Qiita
以前書いた記事で Browserify の使い方とか Browserify でやりたい事が分かったと思う。 では実際に Browserify を使って今までに書いたコードを Browserify 用に書き直してみる。 といっても大したことはない。1つのオブジェクトなり関数にまとめるだけで良い。 例として、よくあるスムーススクロールのスクリプトを挙げる。 $(function(){ $(".anchorlink").on('click', function(e){ e.preventDefault(); var href = $(this).attr("href"); var speed = 500; var easing = 'swing'; var target = $(href == "#" || href == "" ? 'html' : href); var animatePara
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がブラウザ上のアプリで頑張ってモジュールロードできるようにし
React + BrowserifyプロジェクトでJS/CSS/HTMLを圧縮(Minify)する - Umi Uyuraのブログ
ReactとMaterial UIを組み合わせると、それだけでBrowserifyで結合したJavaScriptファイルが1MB超えてしまうので、やっぱり圧縮とかした方が良いのかな―と思い、やり方を調べてみました。 ※2015/08/03更新 Licensifyを開発された @t_wada さんから改良の連絡をいただいたので、Licensifyの最新版1.4.0をもとに内容を更新しました。 Licensify - Nodeモジュールのライセンスコメントを生成する JSファイルを圧縮すると、ライセンスが記載されているコメントが消えてしまうという問題があるということで、本題の前に、Browserifyと組み合わせて、読み込んだNodeモジュールのライセンスコメントを生成してくれる Licensify を試しておくことにしました。 インストールはnpmから。 $ npm install lice
最近あまり使ってない、流行っていた時期もあるフロントエンドもの
最近あまり使ってない、ちょっと前の流行りもの なんとなく書いてみます。Web アプリケーション開発屋さんなので、Web サイト制作屋さんとはかなり文脈ズレると思います。 jQuery ファミリー 個人的には jQuery って、協業用のツールという位置づけでした。jQuery でさえ書かれていれば、jQuery 書ける人材のほうが外からも調達しやすいため、人員の流動にも有効と考えられる頃が確かにありました。 DOM に触れてくれるな勢の台頭 ところが昨今では AngularJS や React、その他ライブラリでも DOM 操作が大いに抽象化されていることが多く、jQuery で直接 DOM を操作すること自体が相性良くないケースが散見されます。今思えば Backbone.js くらいのころが jQuery 需要の最終ピークだったように思います。 jQuery プラグイン の需要減 jQu
Polymer + Browserify + Gulpでユニットテストまでやってみた。 - Qiita
気づいたら八月になってました。私は夏が嫌い（主に暑いのと暑いのと暑いので）なので、疾く早くこの季節が過ぎ去ってくれることを期待して耐えます。最近は九月になっても暑いのでもう十月まで夏でいいんじゃないかな、と思っています。 どうでもいい話でした。 Polymerを利用して、Polymer Elementを作成していると、ふとテストってどうやるねん？という疑念がわき上がりました。ちょっと調べると、Core Elementに対するテストが作成されていました。 https://github.com/Polymer/core-tests 内容をみてみると、Mocha + Chaiで作成されており、各Elementに対するテストがhtml内に書かれており、それをiframe上に読み込む、という手法をとっているようでした。 実際、私もRequire.js + Polymerという環境でテストを作ってみた
browserifyを試してみる - Qiita
既にアドベントカレンダーの投稿予定の日は過ぎ去っていますが、、書きました。 最近までbrowserifyに関して、substackが作った何か、ぐらいのことしか知りませんでした。 今回、クライアントサイドでJavaScriptのモジュール管理が可能にできるツールだと人から教わり、実際に試してみました。 (nodeのコアライブラリが利用できる点などは特に触れません。) browserifyとは何か browserifyとは、クライアントサイドのJavaScriptでモジュールシステムを実現するnpmです。 公式サイトには、 require('modules') in the browser とあります。 具体的には、 という形でモジュールの読み込みが出来るようになります。 (モジュールシステムを提供する点ではRequire.jsと似ているようで、実際はだいぶ違うように思います。) 単純にこれ
browserify をはじめてみる
Browserify を触ってみたメモ。 Browserify とは CommonJS のモジュールの仕組み、つまり Node.js の require をブラウザ上でも使えるようにするもの、ということでいいみたい。Readme を読む限りは、npm にあるモジュールをブラウザ上にもっていくために作られ始めたような印象をうけるが、ちまたのエントリーをみていると AMD に代わりに CommonJS でフロントエンドの依存関係の管理をする (RequireJS ではなく、Node.js 感覚で require 関数をフロントエンドで使う) ためのツールとしても使っていいようだ。 やりたいこと 複数の js ファイルの依存関係を記述したい 最終的に、依存関係を考慮した順番で、ひとつの js ファイルに結合したい 作りたいのは第三者のサイトに埋め込んでもらうスクリプト (サードパーティスクリプト
むしろ駄菓子屋さんで | browserify概説
browserify(ぶらうぜりふぁい、と発音しているのを誰かから聞きました)は、その便利さに比して、利用例などが少ないため、お粗末ながら、今日までにわかったことをまとめてみようと思いました。ドキュメントが足りない状況はしばらく変わらないと思いますので、ハックヒント用に内部構造を含めて、概要を伝えられればと思います。 そもそもbrowserifyとは 御存知の通りnode.jsはブラウザでも動作するjsで記述します。ですから、サーバーとクライアントで共有できるコードは共有したいものです。ですが、それには幾つかの壁がありまして、思いつく分だけを書きますとこのぐらいになります。 モジュールシステム(CommonJS) node.jsの組み込みモジュール http要求を受け取って、ブラウザへコードを届ける仕組み これらを提供するのがbrowserifyです。 処理の概要 browserifyの流
Browserify: それはrequire()を使うための魔法の杖 - Qiita
JavaScript界のハリーポッターこと「Browserify」が最近元気ですね。Node.js的な var myModule = require('myModule')式の記述が、ブラウザのスクリプトでも使えるようになって、ついでに1ファイルにまとめるのもやってくれるツールです。ポストRequireJSとして期待されています。 ただ、公式ドキュメントがコマンドラインの説明に重点を置いていて、最初これだけだといまいち分かりにくい...。そこで、実際の開発で使いやすいように、ビルドツール(gulp.js)から実行するための最小構成を作ってみようかと思います。(Gruntでも同様のことは可能です) require!: Bowerも使えます 対象のスクリプトの中身は、例えばこんな感じ。この例では、ModernizrとjQueryと、独自スクリプトを組み込んでいます。外部ファイルを指定するだけで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://shokai.org/blog/archives/10316
SLOBSERVER - L'actualité de Second Life