- はじめに -
9月くらいから趣味でフロントエンド周りをやっていたので、その勉強過程のまとめ。
何が良かった悪かったとか、こうすればよかったとか、所感とか。
- 前提 -
前提として9月頭くらいの私のフロントエンドに対する理解と技術的な知識はこんな感じ。
- 5年程前まではjQueryで謎のWebサービスや動きモリモリのプロフィールページを作ったりDjangoで研究室のWebサイトを作ったりしてた
- Railsチュートリアルはやったことある
- 仕事では普段機械学習モデル作ってるが、機械学習のデータやモデルの変更が及ぶ場合に既存のPHP、Railsアプリの改修をしたり、簡単なFlask、FastAPIでの機械学習Webアプリ作成とかはちょいちょいやってた
- TypeScriptなプロジェクトの改修も1度だけやったがnode.jsでの開発経験はほぼゼロ
これくらいのレベルからこうやって学んでいったぞという記録になる。
- どんな感じで進めたか -
4つWebアプリを作った。3つは友人の手伝い、1つは以下のWebAssenblyを組み合わせたWebアプリで、これは1人で作成した。
最初の開発
最初、ElasticSearchを使ったデータ検索系のサービスを趣味開発チームのメンバーが作ろうとしていたので、並び替えやランキングに機械学習が必要だろうという事でバックエンドのElasticCloudや機械学習モデル作成を手伝った。その過程で検索フォームやサジェストが必要になって既存のReact部分を触らせてもらった。
この時は、そもそもComponentという概念が全く理解できておらず、なんかclass作ってStateとPropsでやり取りするらしいくらいの感じでコードを書いていた。友人にFluxかReduxを使ってと言われたので、オススメの本を聞いたら「本でもブログでもなく公式のチュートリアルを見てやれ」「本ならとにかく新しい本を買え」との事だった。
今にして思えば、このアドバイスは神だった。
最初はこれを2日程かけてやった。
ja.reactjs.org
react-redux.js.org
React Devtoolsが便利だとか、Reduxが何故必要なのかがよく分かった。
他のブログ記事の野良チュートリアル的なのも見たは見たけど、公式が最新のバージョンでコードを上からコピペしていけば動くのでどこよりも良い。アドバイス通りだ、当たり前だけど。
非同期処理なんかもjQueryで適当に書いていた頃とは勝手が違っていて苦労したが、何故かTwitterで回答が得れたりした。
Node.js非同期処理ムズすぎ問題
— ばんくし🎃 (@vaaaaanquish) 2020年10月3日
ライブラリ選定時点で Promise 持たないのを除外してるし、標準API も fs/promises とかを使ってる。それでもだめな場合は util.promisify つかって、それで駄目なら自分で Promise でラップする
— OSSタダ乗りおじさん (@mizchi) 2020年10月3日
mizchiさんただのOSSタダ乗りおじさんだと思ってたごめんね。
頭のおかしい友人は「前時代から入ってきた人はまずはこれでしょ」と言ってAtomic Designを薦めて来たが、この時はマジでよく分からなかった。
atomicdesign.bradfrost.com
Brad FrostのAtomic Design簡単に読んでみたけどサービス設計段階で人類がここまで考えられるような話なのかわからない…(経験が圧倒的に足りてないのかも知れない)
— ばんくし🎃 (@vaaaaanquish) 2020年9月27日
後述するが、後々にWebアプリ2,3個作った辺りで「あーなるほど」と思う事があった。
9月ぐらいにBrad FrostのAtomic Design読んでめちゃ難しかったが、何個かWebアプリ作って今はちょっと恩恵について理解できてる気がする。やるの大事だ
— ばんくし🎃 (@vaaaaanquish) 2020年12月20日
実際に作ってみてから読むと、良いコンポーネント設計が出来るようになる感じはするので時間が空いたら、開発手法を学ぶ的な意味合いでAtomic Designはオススメできる。本家が難しければググれば解釈がいくつか出てくるのでそちらでも。
その辺りで、もうちょっと体系的に学べないかと思って調べて、アドバイス通り「新しめの本」ということで以下を読んでみたが、これもなかなか良かった。
これ読んだ辺りから、Qiitaやはてな、Zennで流れてくるフロントエンドエンジニアの間で話題の記事をかなり難なく読めるようになったので、チュートリアルとこの本は結構効いた。
理解できてきて記事のシェアが増えてきた
React Hooks での状態管理と副作用の表現 - mizchi's blog https://t.co/rbv3nudkTg
— ばんくし🎃 (@vaaaaanquish) 2018年10月27日
他にもこの辺りでのReduxとの出会い、TypeScriptの学びは大きかった。
Reduxの機構を見た時、「本当にこんな壮大な仕組み必要か?」と思ったが、実際使ってみると簡単で便利だった。後にReact Hooksで多くの機能が代替できる事を知って移行していったが、状態というものが何なのか意識できるようになったのはRedux使った後からだったように思う。最初からHooksでも良い部分が多いけど、Componentやnode.js周りの開発がどれだけ良いか体験できるのも良い。例えばFluxなプロジェクトをReduxに書き換える、Hooksに書き換えることを経験したが、状態管理が1ライブラリで切り離されているので、移行の労力がかなり小さかった。これがいわゆる近年のnode.js開発の良さの1つなのだろう。
TypeScriptへの移行もやった。この辺りにもnode.js開発プラクティスの恩恵があるんだなと感じる体験で、Componentで分かれているのでComponentごとに1つ1つ変えていけば良いし、何よりTypes書けば推論してくれる便利さ、ビルド時のチェック、エディタの補完の進歩が最高だった。以下の本も読んだら良かった。
フォロワーが書いてるからと思って読んだが、この書籍でNext.jsと組み合わせた時の強力さも知れた。書いてある内容がちょっと古いけど、筆者が追加で最新分に対応した解説しているのでこちらも見ると良い。Nuxt.js TypeScript - 実践TypeScript アップデート - - Qiita
最初のアプリの小話だが、友人はElasticCloudのオススメ設定みたいなので進めていて全盛りプランでお金掛かりまくる感じになっていてヤバと思った。流石フルマネージド。結局まるっと構成を変えてインデックスも機械学習モデル入れやすいように貼り直したりして大変だった。
TypeScriptとNext.jsを使った開発
次のWebサービスも辞書のようなサービスを手伝う形だったが、途中まで書かれたサンプルがwebpackだけ使ったCSRだったので「いやこれTwitterでシェアされたりすること考えるとSSR必要じゃないか」という話になってNext.jsをやった。
Google検索やTwitterに出たかったらSSRだNextをやれと最初に知りたかった気もちょっとした。
この辺りまでwebpack.config.jsをダラダラ書きまくっていたが、どうやらNext.jsではpackage.json、tsconfig.json(あるいは.babelrc)の簡易なフォーマットを書けば良く、ルーティングもディレクトリ、ファイル名でよしなにできる。Routerの分岐をコツコツ書かなくて良い(すごい)。静的なファイルの配信もクライアントサイドのレンダリングも簡単で、ほとんど何も考えずComponentを書いていけば開発できる事がわかった。すごい。
(最初はなんでGoogleクローラやTwitterのOGPなんかのために頭良い人達がSSRだの何とかRだのに振り回されてんのと思った正直)
これも出来るだけ公式のチュートリアルをなぞった方が良い。
nextjs.org
野良のやってみた、ベストプラクティスみたいな記事は半年以内くらいじゃないと若干古かったりDeprecatedだったりする。
今日は開発チームメンバーに「それは半年くらい前に非推奨になったからやめて」と2回言われて全部書き直したら1日終わった
— ばんくし🎃 (@vaaaaanquish) 2020年12月17日
コンポーネントやライブラリの使い方がちょっと違うくらいならいいが、特にディレクトリ構成が変わる系(publicとかsrcとか)は後から変更するのが大変な場合もあるのでちゃんと最新バージョンの情報を見たほうが良い(大変だった)。
この辺りでMaterial-UI: A popular React UI frameworkとかのドキュメントをひたすら上から試したり、About splash-screens - AppscopeやFavicon Generator for perfect icons on all browsersでfaviconやスマフォ向けの画像作ったり、Google Analytics、OGPなんかを一通りやった。
Tailwind CSSやSemantic UIも比較のために触った(Web上の記事も読んだがあんまり良い悪いの比較が理解出来ずmaterial-uiで良いんじゃないという気がするが理解が足りていない気もする)。
アプリ手伝いから自分のアプリ開発まで
3つ目はNuxt.jsなアプリをちょっとだけ手伝った。あんまりNextとやってる事は変わらないと感じたけど、逆に変わらないのがすごいなと思った。外枠変わっても書いてるTypeScriptのコード変わらないのすごい。まあでもつまりNext.jsとTypeScriptができれば結構いろんな事に対応できそうだという事もここでわかった。
この辺りで、WebAssenbly nightというイベントを聴講して、「あ、こりゃ面白いな」と思って自分のサービス作ってみようとなった。
emsn.connpass.com
Rustで機械学習がどれくらいできるか試して
vaaaaaanquish.hatenablog.com
その機能がwasm-packやEmscriptenでバイナリにしてNext.jsで配信できるか試して
WebAssenblyで形態素解析するサンプルつくった https://t.co/LOB42DrsrW
— ばんくし🎃 (@vaaaaanquish) 2020年12月18日
できてた
できてた
— ばんくし🎃 (@vaaaaanquish) 2020年12月26日
『ばんくし』は俺以外でした https://t.co/MxSTPmKVWL #oreka_oreigaika via @vaaaaanquish
前のブログに書いた通り、wasm周りは結構大変だったが、技術的に面白いものが何だかんだで1万人強に使ってもらえていて、楽しい気持ちになった。
wasm-packやemsdkでビルドしたjsが素直に読み込めた時はwebassembly最高ってなる。他は修行僧の気持ちに近い。
— ばんくし🎃 (@vaaaaanquish) 2020年12月22日
今ちょうどWebAssenbly+Nextな機械学習Webアプリを興味本位で試してるけどAPIの方が都合良いこと多いですね。エッジケースを考える必要がありそう。
— ばんくし🎃 (@vaaaaanquish) 2020年12月14日
この辺りは本心で、かなり大変な上に「機械学習エンジニアにとってwasmでサービス展開したいモチベーションが薄いので量子化やホスティングまでを考える人が少なくPythonやAPIがソリューションになる」「逆にフロントエンドエンジニアやバックエンドエンジニアが機械学習モデルの量子化をやるのかと言うとそれはそれでとなる」という状況で、一部のエンジニアを除いて多く人にとってはちょっとしんどい気もした。
こういうWebサービスやりたいよという会社があったら呼んで下さい。
御託はさておき、GAEやFirebaseであまり考えずにNext.jsでWebサービス展開ができるようになった。
- できてないこと -
趣味で3ヶ月やってみたものの、まだ出来てない事、分かってない事がいくつかある。
- ツールチェインのベストプラクティス
先に挙げた「Material UI、Tailwind CSS、Semantic UI」もそうだし、「Express、Parcel、Deno、Gatsby...ないし任意の技術は良いぞ」というのが飛び交っていてまだまだ試す事が多い
- Babelが何をやってるか
これ結構わからない人多いと思うけど私だけなのかな。使い方は出てくるけど、ES構文とは何なのかとかを知らないと把握できなさそうだなと思う。
こういう所が、こんなツイートにも繋がっている。
5年前にゴリゴリjQueryで作ってた所からほぼJS書かず、ここ2ヶ月で一気にReact、TS、Next、Nuxtと来たのでそれぞれの良し悪しを全然把握できていない感ある
— ばんくし🎃 (@vaaaaanquish) 2020年12月11日
歴史的な背景を知ってたり継続している人には勝てない…
— ばんくし🎃 (@vaaaaanquish) 2020年12月11日
これマジでわからん。ESLintどの粒度で書くのが正解なのか、気付いたらNext.js含む回帰テストみたいになってしまう。これを読めみたいなやつないのかな。
わからん。デザインツールから出てきたscssを適応するのも、既存のCSSを改修するのも1日以上かかったし、css-loaderやscss-loaderがCSS Moduleになったからなんぼのもんじゃいって気持ち。PostCSSになっても適切にdisplayやpositionを適切に一発で設定できたことなし。これを使えみたいなやつないのかな。
- パフォーマンス最適化
この書き方がどういう理由でパフォーマンスが良い、高速であるというのをあまり把握できていない。これを読めみたいなやつないのかな。
- 複数人での継続的な開発
アトミックデザインなりのnode.jsなり良いところはこの辺にあるんだろうと体感していて、複数人が手を入れても、モジュールのバージョンアップデートも変更もこりゃやりやすいだろうと思うんだけど如何せん仕事じゃないので機会が訪れなさそう。
- 所感 -
たしかにnode.js開発しやすい。jQueryをゴリゴリ書いていた時を思うと、Releaseまでの速度も改修のしやすさも、他人のコードの読みやすさも段違いに良い。Railsとの比較が近年多いけど、私はまだRails書きまくってるわけじゃないから何か機能の比較は難しい。それでも大きなフレームワークとは違った、色んな開発の概念を学べてよかったので色んな人がやると良いと思う。
情報の古さみたいなのがヤバいので公式を見に行く精神を忘れるとしんどい。ライブラリの開発がやりやすいこと、早いことが起因しているのだろうけど、ついていけている開発者も少ないのではとちょっと思った。
自分の作ったサービスが使われるのを見るのは楽しい。
機械学習エンジニアの悩みどころの1つに「小さいサービスではやることがない問題」というのがあって、最初から機械学習を前提としていたりしない限り、データやユーザが小さかったり需要がないために(概ね習熟した問題に対して改善フェーズじゃなければ)機械学習モデリングは実は簡単に終わってしまって分析屋かPdMになっていくという事象はよくあるのだが、私は開発に比べたらあんまりという気持ちなので、もうちょっと開発の範囲を広げる方向で何か考えていた。バックエンドやフロントエンドをやってみるのは楽しかったので今後も継続したい。
- おわりに -
あんまりこういうまとめ書く気はなかったけど、最近「初心者のうちに初心者な記事を書かないと、初心者の読者と乖離した記事しか書けない」みたいなツイートを見て「それもそうだ」と思ったので書いてみた(元ツイート見つけられなかったごめんなさい)。
結構楽しかったので普段フロントエンド触ってない皆さんも年末のお供にどうぞ。
- 追記 -
2020/12/28
分からなかった事が分かりそうなgistが作られてました。
- ツールチェインのベストプラクティス
— azu (@azu_re) 2020年12月27日
- Babelが何をやってるか
- ユニットテスト
- CSS
- パフォーマンス最適化https://t.co/NJ0BPOR18a
めちゃくちゃありがたい。やっていきます。