はじめに

いままでのフロント開発環境としては、システム開発によくある旧PJの開発要件に縛られたレガシーな状態で開発していました。
上記で述べているレガシーな開発というのはブラウザ上で動作するフロント側の動的振る舞い(Script実装)をjQueryベースにガシガシ書く、スタイルはScssを用いて実装していました。
書いた内容の簡易チェックとリリース時を想定したminifiy化はタスクランナー(Gulp)を用いてある程度は作業を自動化していました。

旧開発環境の問題点

jQueryベースで実装をするのは悪いことではないけれど、最近のフロントエンド関連のフレームワーク、ライブラリ、ツールを導入する場合、ネイティブなJavaScriptでガシガシ書けないと使いこなすことができないと知る...

→ jQueryというJSライブラリはいろんなjQueryプラグインが作成されていて、便利。
書く文字数も少なくて済む！！

しかし、jQueryというライブラリをメインで使い続けたままではその他のフロントエンド関連のフレームワーク、ライブラリの流行に乗り遅れてしまうと感じた。((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

脱jQuery環境へ向けて行動開始！！

次期案件では旧開発に縛られたPJではなかったため、新たにフロントエンド開発環境の見直しと一新を行いました。
取り組んだことをあげると以下のとおりです。

	1. フロント側のスクリプト言語としてTypeScriptを導入。
	2. browserifyの導入
	3. scss、TypeScriptファイル内コメントをベースにドキュメントの自動生成

フロント側のスクリプト言語としてTypeScriptを導入

TypeScriptを今回導入した経緯としては、クラス概念のあるプログラミング言語の開発経験を開発チームに経験してもらいたいということ、JavaScriptのes5、es6などに振り回されないようにaltJSの採用を行いました。

TypeScriptを書いたあとはコンパイラにes5 or es6に変換をお願いする考え!!

browserifyの導入

いままではjQuery本体とjQueryプラグインを配布サイトまで訪れてDLしていました。
いい加減この手動でDLとバージョン管理を行う環境どうにかならんかと調べていた結果、npm上に公開されていればnpm経由でDLできることpackage.jsonでバージョン管理できることを知りました。
ただし、npm経由でDLしてきたモジュールをブラウザ側で認識できるようにするにはbrowserifyによる変換が必要だったので今回導入しました。
実装サイト内のページ単位のスクリプト内容をbrowserifyに変換、bundle化の実行を行うようGulpタスクを用意しました。
また、ES6の書き方がスクリプトファイル内に存在するとbrowserifyはES6の記載を認識できないのでエラーが発生するようです。
今回はbrowserify + tsifyの組み合わせでTypeScript → JavaScriptへの変換を実現しました。

Scss、TypeScriptファイル内コメントをベースにドキュメントの自動生成

前回のPJの反省として極力ドキュメント作成に時間をかけないこと、実装時にメモを書く感覚でドキュメントが生成できると実装後のドキュメント作成・整理が効率よくできると考えたため、コメント内のメモ書き程度の内容で自動でドキュメントを作成できる環境を用意しました。
今回スタイルシート(scssファイル)と紐づくドキュメントを生成するためにFrontNoteというスタイルガイドジェネレーターを導入しました。
FrontNote GitHubページ
初めてスタイルガイドジェネレーターというものを導入しましたが、開発初期に複数人でサイト内の再利用する部品(コンポーネント)を実装する際にマークアップの状態とスタイル適用時の状態が説明文付きでブラウザ上で確認できるため、非常に便利でした。
また、modifireの状態なども生成できるため、ボタンコンポーネントに複数のmodifireが設定されていてもドキュメントからすぐに確認することができます。
TypeScript用のドキュメント生成ツールとしてはtypeDocを採用しました。
デフォルトでmarkdownを用いたコメントを書くこともでき、ドキュメントの一部として生成してくれるので、利便性は高いと思いました。
上記ドキュメントの自動生成はそれぞれGulpタスクの実装を行い実現しました。
特に導入で難しい点はないので、ドキュメント作成でお困りの方は一度導入してみることをおすすめします。

脱jQuery行動の結果

はじめに脱jQueryの結果を申し上げると現状は完全には脱jQueryをすることができませんでした。

どうしても一部のjQueryプラグインの代替となるnpmモジュールの調査または機能実装を行う時間が確保できなかったため今回は妥協しました。
次回以降は完全に脱jQueryな状態で成果物を作り上げることはできる感触はつかめました。

脱jQueryをしてみた感想

jQueryベースでガリガリ書いていたときは実際にブラウザ上で実行しないと正しく動作するか確認できなかったが、TypeScriptの導入によりクラス概念が生まれ、ケアレスミス程度の軽度な実装ミスをコンパイル時にエラーを通知してくれるようになりました。
browserifyの導入によりnpm上に公開されているモジュールのダウンロード・バージョン管理が簡単に行えるようになりました。
実装時にコメント記載の手間が取られるようになったが、トータルの資料作成の工数は削減できた手応えが実感できました。
何より、実装時に変更があった場合に実装作業とあわせてドキュメントにも合わせて反映できるようになったのが大きい利点だと思います。
クラス概念を自分以外の人に説明・理解してもらうのは難しい...あと、MDNのリファレンスとは日々にらめっこ状態です。
他の言語と違ってほんっとにフロントの開発環境は使うツールが多い...ツールが個別に機能改善・発展していくのうれしいけど誰か用途パターンに合わせたツール一式のパッケージを用意してくれると嬉しい。

今回browserifyの部分もwebpackで実現しようかと思いましたが、webpackの中でさらに覚えることが分岐しそうだったので、単純に設定と呼び出すだけのbrowserifyを今回採用しました。
近々時間あるときにwebpackでもコンパイルできるように環境を整えたいと思います。
脱jQueryをやってみたが、何が何でもjQueryを断固使わないという姿勢は個人的に必要ないかなと思いました。

jQueryでやったほうが簡単に実装を実現できるならコスト・実装工数的にもjQueryを利用してチャッチャと実装を終わらせてしまえばいいし、チーム内のスキルが上がってきたらjQueryを基本的には使わない方針へシフトしてしまえばいいと思います。

ただし、流行のフロントエンド開発に取り組みたいなら、jQueryをメインにゴリゴリ書くことは辞めて、JavaScriptの書き方を覚えたほうが手っ取り早いのは間違いないと思います。

今回は体験記事みたいな内容になっていますが、時間があるときに今回脱jQueryに向けて取り組んだ技術的部分の詳細を記事に落とし込んでいきたいと思います。
以上！！( ｰ`дｰ´)