俺のJSライブラリの世界観(2014末版) - Qiita
http://qiita.com/advent-calendar/2014/frontrend 概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指し
ReactRubyをリリースした。
先日、React をテンプレートとして使えるRubyライブラリの ReactRuby をリリースした。 このブログは自作のブログエンジンで動いていて、気が向くたびに作りなおしている。何か使いたい技術やライブラリがあって試してみたいというとき、ブログエンジンというのは結構良い題材だと思っていて、実際今までもNode.jsを使ったりAngularJSを使ったりしてきた。 今回はFacebook製のコンポーネントフレームワークであるReactを使って、フロントエンドを作成しようと思い立った。Reactを選んだ理由として、Angularだとサーバーサイドでビューを生成できないので不満に思っていたことが挙げられる。 今まで、コンテンツページに関してはHAMLを使ってサーバサイドで生成していて、Angularのテンプレートキャッシュを使って読み込んでいたのだが、これだとフロントサイドでビュー生成してい
Victor.js - 2D Vectors for JavaScript
A JavaScript 2D vector maths library for Node.js and the browser. Use Anywhere Victor can be used in both Node.js and the browser. Builds come with an UMD wrapper so it can be used in CommonJS and AMD environments, or as a global object. Install Victor with bower, npm, or download the latest release. Open Source Victor is licensed under the MIT license and can be used without restrictions. Fork Vi
npm とフロントエンドのパッケージ管理の未来
JavaScript 系パッケージマネージャの重複問題 npm は言わずもがな Node.js のパッケージマネージャだが、フロントエンド開発においては Bower も利用するのが一般的になっている。この現状の問題点は、package.jon と bower.json という似たような管理ファイルを二重で管理しなければならないということだ。 現状の使い分けをおさらいをしておくと、次のような感じになる。 タスクランナー（Grunt/gulp）・モジュールシステム（browserify/webpack）・テストスイート（karma/testem）などの開発環境系の管理が npm の主なお仕事。インストールされたパッケージは node_modules 内に展開されて、CommonJS スタイルのモジュール管理から利用する。 本題につながる話としては、ブラウザで動くライブラリの一部は npm にも
browserify をはじめてみる
Browserify を触ってみたメモ。 Browserify とは CommonJS のモジュールの仕組み、つまり Node.js の require をブラウザ上でも使えるようにするもの、ということでいいみたい。Readme を読む限りは、npm にあるモジュールをブラウザ上にもっていくために作られ始めたような印象をうけるが、ちまたのエントリーをみていると AMD に代わりに CommonJS でフロントエンドの依存関係の管理をする (RequireJS ではなく、Node.js 感覚で require 関数をフロントエンドで使う) ためのツールとしても使っていいようだ。 やりたいこと 複数の js ファイルの依存関係を記述したい 最終的に、依存関係を考慮した順番で、ひとつの js ファイルに結合したい 作りたいのは第三者のサイトに埋め込んでもらうスクリプト (サードパーティスクリプト
Loki.js: Mongo風APIを持ったクライアントJS/node両対応のストレージエンジン - Qiita
某アプリでストレージどうしようかなーという感じだったので適当に探してて、昨日echo.jsで偶然紹介されてたライブラリ、試してみたらチョット便利だったので紹介。 Lightweight javascript in-memory database: LokiJS 注意: 自分はnode環境下で試したので、以下のサンプルはnode用です。ブラウザでも動くはずです。 特長 Mongo風API。 var DB_PATH = process.env.HOME + '/.loki.json' var db = new Loki(DB_PATH); var items = db.addCollection('items'); items.insert({a: 1, b: 2}); items.insert({a: 2, b: 3}); obj = items.findOne({a: 1}) // sea
小さいライブラリを採用する - mizchi's blog
僕がJavaScriptでライブラリを選定する際、迷ったら小さいものを使う。その理由について。 前提 前提として、枯れた環境で大きいフレームワークができるのは理解できるし、メリットも大きい。あるいは言語それ自身と区別できないぐらいに発達したフレームワークに依存するのも理解できる。RubyにとってのRailsとか、ErlangのOTPとか(いや、これは詳しくないけどそうなんだろうなっていう予想なんだけど)。 危険信号 今のJS界隈は動きが早すぎて、何に依存するのも危ない。とくにフレームワークと銘打たれたものは、でかすぎてどれも危険信号を放っている。 数年後、廃れてしまったフレームワークで開発し続けるのは、僕個人としてもあまり関わりたくないし、現場の離職リスクとして数字に出るだろうし、採用後の教育コストの問題になる。だいたいそういうものは元の設計者もいなくなるものだ。プロダクトの死を意味する。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
