kishibashi3 / es6-test

ES6でNodeJSアプリを書きたい！

背景

ご存知、nodejsはJavaScriptのサーバーサイドフレームワークです。 JavaScriptは確かに簡単に書く事ができます。なんといってもブラウザで動くというのは、動作環境を用意するのにこれほど簡単な言語はありません。 さらに高速で、約束事が少ない言語です。 Javaのように、JDKをインストールして、mavenをインストールして、プロジェクトを作って、pom書いて・・・などとしなくても簡単に動かすことができます。

しかし。それゆえに多くの弱点があります。

1. ブラウザ上で動作する言語という歴史的背景から、仕様のばらつきが大きい。
2. 約束事が少ない事から、お決まりのパターンがなく、好き放題のカオス。
3. サーバーサイド言語としての歴史が浅く、プロジェクト回りが素のまま。(npmはmavenやgradleほど完成されていないように見える）

 - node_moduleによるライブラリのロードの切り替えや  - dependencyコントロール  - import/exportやrequireなどのモジュール問題

4. ブラウザ上での高速化のためにシングルスレッド、コールバックモデルを採用したが、サーバーサイドでは苦痛なだけ。
5. コールバックを避けるために様々な方法が提案されているが、どれもデファクトスタンダードとは言い難く、同じような方法が溢れていてどれを選べばいいのかわからない。

などなど、結局自由すぎるがゆえに何が正しいのか分からない状況になっているように感じます。 ES6という道筋が示された今、なんとかその道に乗り、現在の状況から逃れたいという思いがあるのではないでしょうか。

ES6のフィーチャー

class

これまでもclassは使えましたが、正直JavaScriptのclassは、”書ける”というだけです。 オブジェクト生成のシンタックスシュガーに過ぎず、継承、オーバーライド、オーバーロード、private/protectedなにもありません。 つまり、classを使うメリットはそれほどありません。

import/export

これまではモジュールとしてはcommonJSスタイルのrequireが業界標準的に使われてきたようです。 ようやくJavaScript仕様としてモジュールが仕様化されました。 es6を使うのであれば、requireではなくimport/exportを使うのは当然でしょう。

Promiseとasync/await

これまで長く我々を苦しめてきたcallbackですが、これに対して多くのソリューションが提示されてきましたが、 それらがようやくJavaScript仕様に取り込まれました。 これらを使う事により、callbackを意識することなく同期的なプログラムを書く事ができるようになりました。 これこそが待ち望まれた機能です。

iteratorとgenerater

これは正直わかりません。 世の中には様々な言語でこの機能を持っていますが、持っていなければできないことというのはあまりないように思います。 そもそも関数とバッティングするように思いますが・・・

Map, Set, for-in, for-of

コレクション系にも多く手が入りましたね。使わせてもらいましょう。

Node.jsとES6

現在公開されているNode.jsのバージョンは、デフォルトではES6に対応していません。対応させるには以下のように起動する必要があります。

$ node --experimental-modules --harmony

experimental-modulesがimport/exportが使用できるようになるモードで、harmonyが、async/await回りが使用できるようになるモードのようです。 ようするに！ これらはまだ実験実装（experimental）段階であり、実仕様に耐える段階ではありません。

我々がNode.js上でES6を使えるようになるには、まだまだ時間がかかりそうです。 しかし、世の中には気の早い人たちがおり、なんとかES6に対応していない環境でもES6を使うための「トランスパイラ」という仕組みが開発されています。

これがBabelです。

Node.jsとES6とBabel

babelは、コードをロードするときにES6コードを旧来のコードにトランスパイル（翻訳）します。 これにより、どのような環境でも、ES6コードが「疑似的に」実行可能になります。 ただ、Babel-es6は、ES6仕様とは微妙に異なるようなのです・・・なんということでしょう！

Cloud9とCloud

Cloud9はAWS上で使えるようになった統合開発環境です。 コードはAWS内のEC2上で実行されます。つまり、セキュリティーを気にすることなく、テストコードがAWSサービスに接続できるのです。 セキュリティーは開発環境にログインすることでクリアされます。 つまり、ローカル開発環境などというものが存在しません。 DEV環境上で開発できるのです！

これは素晴らしいことではありませんか？ そもそもローカルリソースを使って開発する必要などないのです。 localdynamoやローカルRDBなどを準備するのはノートPCには重いです。これらが全く不必要になります。 開発用のdynamo、RDBを作成し、これを使えばいいではありませんか。

DBインスタンスが被るのが嫌なら、開発者事に分ければいい。そんなのは余裕です。 testコマンドさえ投げれば、AWS AZ内でテスト実行は完結します。なにもローカル環境から接続しにいくわけじゃない。