前回「
OpenShiftでASP.NET Coreを動かしてみました。」という内容で投稿を行いましたが、今回は「
ASP.NET Coreのフロントエンド開発環境に関する考察」の結果のご報告です。
<アウトライン>
- 結論
- 理由
- 具体例
- IDEがCLIの一部のコマンドをサポートしていないことがある
- スタックを自分で組み立てたい事が多い
- フロントとバックが分割されていた方が容易
- 余談
- 参考
<結論>
「
Cordovaによるハイブリッド・アプリ開発」や、「
ReactによるSPAアプリ開発」(コレについては後日、所感を書きます)の評価を実施してみた結果、某弊「
Open棟梁プロジェクト」のSPA・モバイルなどのフロントエンド開発環境を、「
Visual Studio」から、 各種「
Node.js製のCLI」と「
Visual Studio Code」などの任意のエディタを使用する開発環境に移す。という結論に至りました。
<理由>
<其の1>
これは、昨今のフロントエンド開発環境は、Node.jsのnpmを中心としたエコシステムを形成しており、「
Visual Studio」を使用するメリットがあまり無いという理由に依ります。
<其の2>
また、フロントエンド開発に精通した要員は希少で、その要員が「
Visual Studio」のスタックに精通していないケースが多いということが挙げられると思います。
<其の3>
更に、フロントエンド一つとっても幅広いため、
- サーバーサイド技術とフロントエンド技術のバイリンガル
- IDEでのフロントエンド技術とバックエンド技術の統合
が、困難なこともあり、サーバーサイド技術との切り離した方が効率が向上します。
<其の4>
その他、インターネット上の情報も、例えば、「
Visual Studio」+ Reactのスタックの情報より、任意エディタ + create-react-app のスタックの情報のほうが多数あるという点が大きいかと思います。
<具体例>
私の場合、以下のような考えでこの結論に至りました。
<IDEがCLIの一部のコマンドをサポートしていないことがある>
例えば、IDE(
Visual Studio)の拡張が、「
Cordova」のCLIのコマンドをサポートしていないことがありました。具体的には、プラグイン・インストールのコマンドです(config.xmlにオプションを持つもの)。リリース・サイクルが合わないと思うので、統合が難しいと言ったトコロか?などと感じました。
<スタックを自分で組み立てたい事が多い>
「
Visual Studio」(
JavaScriptServices)の生成するテンプレートなど、非常に優れているのですが、やはりフロントエンド・エンジニアが慣れているスタックに組み上げたいケースが多いということが挙げられます。
例えば、「
Visual Studio」では、AltJS、トランスパイラに「
TypeScript」を、サーバーサイドに「
ASP.NET Core」使用しますが、「
create-react-app」では「
Babel」を使用しますし、サーバーサイドには「
Express」を使用するのが一般的です。
IDEと統合されたテンプレートを使用する場合、プロジェクトに合わせて下位スタックを組み立てるには、これを解きほぐす必要があるので、更にハードルが上がってしまいます。
<フロントとバックが分割されていた方が容易>
フロントエンド技術とバックエンド技術の「IDEによる統合」や「バイリンガル」、が難しいため、結局、夫々を分割して、WebAPIと「
CORS (Cross-Origin Resource Sharing)」で連携できさえすればイイと言う話になります。
<余談>
上記で、フロントエンド技術とバックエンド技術の統合は困難と書きましたが、昨今、JavaScriptServicesでサーバーサイド・レンダリングなどと言ったサーバーとの統合を目指しているような動きがあるようです。しかし、これは上手く行くかどうか、良く解らないので暫く見守りたいと思います。
<参考>