TypeScript & CoffeeScript & Browserifyによるフロントエンド開発環境 - Qiita
この記事の内容は古くなりました、新しい記事はこちらです。 Browserifyの記事が増えてきましたが、 自分でもフロントエンド開発環境を構築してみて、納得のいく構築が出来ましたので公開します。 GitHubへのリンク 2015/03/26追記 独自タグによるalias指定をoptionalに変更し、 require時に相対パス指定か、aliasがある時はalias指定のどちらも使えるように修正しました。 概要 このプロジェクトは、以下の機能を持っています。 TypeScript、Browserifyの差分ビルド gulp.watch、Watchifyの変更監視による自動ビルド TypeScript、CoffeeScriptのソースファイルを混在出来る ファイルごとに型が欲しいか、短く書きたいか、で好きな方を選べばいい CoffeeScriptで書いたクラスをTypeScriptでrequ
モジュールの開発にJavaScriptトランスパイラを使わないという選択 - Shinnosuke Watanabe
これまで100個以上のnpmモジュールを作成してきましたが、そのほとんどを素のJavaScriptを使って書いています。つまりCoffeeScriptなどのJSに変換されるメタ言語や、ES.nextなシンタックスを現在利用可能なコードに変換するbabelなどのツールを使用していません。 （これはモジュール作成の際の話です。Webアプリケーション開発においては、寧ろ積極的に活用しています。） そういったトランスパイラを使って書いていた時期もありましたが、現在ではほぼ全て素のJavaScriptで書き直していますし、今後新たにモジュールを作る際も使わないつもりです。 これは「リポジトリ全体の可読性」を考えてのことです。ファイル単位で見れば、エレガントなシンタックスで可読性が向上するかもしれません。しかし、トランスパイラを使うとなれば、JSへの変換手順の用意（npm scriptやgulp.js
俺のJSライブラリの世界観(2014末版) - Qiita
http://qiita.com/advent-calendar/2014/frontrend 概論 ここ近年のモダンJSは特に理由がなければcommon.jsのrequireスタイルで記述され、webpack/browserifyでビルド/読み込むことを前提にしてよい。今やビュー層を除いてブラウザとnodeのライブラリの境界は非常に曖昧である。 識者諸君においては常にどちらの環境でも読み込めるようなライブラリを提供するように心がけることを切に願う。 今日はライブラリの名前しか出さないんで各自ググるように。 立場 サーバサイド~ゲームプログラミング出身node寄りフロントエンドエンジニア このサイトのスタッフだけど他のことに手一杯でQiitaのフロントはまだそんなにいじってない すまんな 他ってなんだろうな 言語 CoffeeScript TypeScript 最近DDDっぽい構成を目指し
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
