2021年の振り返り

脱SPA、からのMPA、からの・・・

なんでもSPAにするんじゃねぇ！という主張のその先 - console.lealog();

「とりあえずReactでNext.jsでSPAでよろしく！」みたいにやってくる案件を、「ほんとにSPAにする必要あんのけ？😒」って切り捨てる係をやってた。

もちろん、ほとんどのケースにおいてSPAである必要はなかった。

ただし巨SPAではなくても、

• いくつかのページは、SPAでやるべき多機能さ
• いくつかのページは、SPAでなくていいけど、ちょっとだけJSほしい
• いくつかのページは、完全に静的でいい

みたいな複合ケースがほとんど。で、それをいい感じにまとめてやるためのソリューションって、意外にないのだなあ〜ってなってたのが今年のハイライト。

• Next.js
• SvelteKit
• ViteのMPAモード
• WMR
• etc...

などなど試したけど、どれも一長一短って感じで、すべてのニーズを満たすものではなかった。

SPAでもMPAでもないとなると、いわゆる`#transitionalapps`か？！ってなるかもしれんけど、そういう系は受託の会社でやすやすと手を出せるものではない。

Transitional Apps by Rich Harris の要点まとめ - console.lealog();

手離れよく納品するためにはSSR成分を採用するわけにはいかず、そうなるとSSG側に軸足を置くしかなくて、トレンド的に発掘されてないがゆえに手札が足りない状態って感じ。

なのでとりあえずはNext.jsを採用しつつ（どうせとりあえずReactでよろしくって言われるし😇）、あらゆる機能を使わず、ただのwebpackラッパーとして使うパターンがずっと鉄板になってた。

`next build && next export`に対する不満としては、

• Reactってところ
  • 詳しくは後述
• バンドルサイズのデカさ
  • Preactにすればいいっちゃいいけど
• webpackの遅さ
  • Viteに慣れてしまうと・・
• そもそも欲しいものではないことによるギャップ

かな〜。

Cloudflare Workers

話題のエッジワーカーでAPIをいろいろ作ったり、弊社のメディアで連載を書いたりもした。

サーバーレス実行環境Cloudflare Workers | CodeGrid

このブログでもCloudflareの回し者か？ってくらい記事を書いた気がする。

ことEdge Workerに対する評価は、

• Node.jsではないがゆえにあらゆる資産が使えない
• プロトコルもHTTPしか通らない

という縛りさえ受け入れられれば、

• ユーザーとのレイテンシも大きく減らせるうえ
• 軽くて速くてあらゆる用途に使える

丁度いい選択肢なのかなと。

ただその他にも細かい制約はあるので、例えばLambdaがオワコンかと問われると、まだまだ全然そんなことはない。

ツール回りとしては、Worker環境をNode.jsでエミュレートする`miniflare`がとにかく便利。2021年に読んだOSSのコードの中でいちばん感動した。ほんとすごい👏

GitHub - cloudflare/miniflare: 🔥 Fully-local simulator for Cloudflare Workers

ただまぁ日本国内向け用途限定で考えると、CDNもたった2拠点しかないし、単なるFaaS代替としてしか見ないなら、そんなにコスパは良くないのでは？って思います。
プロトコルがHTTPしか使えないので、全体の構成を設計しなおさないと厳しい！って話もありそうで、エッジでリクエスト受けて高速化や！って言っても、裏でDBのデータを引くために海を渡ってきますしばし待ってて・・みたいなケースもありそう。

というか結局DBのデータがすべてであり、もとよりそれをキャッシュしていたならば、エッジのWorkerで処理したいことってなんぞ？ってなると思うし、今までのアーキテクチャに当てはめてユースケースを探っても、大してハマらない気がしてる。

ではDBまでエッジに持ってく未来はあるか？って考えると、まあなくはないのかもしれんけど、結果整合性とうまく付き合ってグローバルにやりくりするのは大変すぎるはず。そのあたりの点については、Durable Objectsが一石を投じるのかなーと思いつつ、これからどうなることやら・・ってフェーズ。

このへん、SvelteKitやらRemixやらCDNエッジで動かせます系フレームワークが一般化してくれば、もう少し開拓が進むのかなーと。みんな大好きNext.jsもそのへんは見据えてると思うので。

それ以外の0ベースでアーキテクチャを模索する動きは、すぐには日の目を見なそう。`Content-Type: multipart/mixed`でストリーミング再評価な流れないかなー？RSCがそうですって？

あとはエッジWorker各社の互換性も問題になってくるのもこれからやと思うし、その名の通りエッジな技術であるなあって感じ。

第二外国語としてのRust

仕事で使う機会はまったくないけど、RustでLeetCodeをやったり、年末恒例のAdventOfCodeをやったりしてた。

ただ何か作りたいものがあって勉強してるっていうよりか、ただ何もしないまま時間が過ぎていくのが嫌なだけ。

とりあえず何か未来の投資になればと思い、1日1問LeetCodeをやり続けるBotと化してる今日この頃。ただしアルゴリズムとか競プロにはあまり興味が持ててないので、あくまでエンジニア一般教養として継続することを目的に。

Write less code

これは、要点を抑えた簡潔で必要十分なコードを、いかに少ない行数で表現できるかに、心血を注ぐということ。

メタプログラミングしろってことではないし、オーバーエンジニアリングなんか以ての外。エンジニアたるもの、ちょうどいいエンジニアリングがしたいなーと。

コード量は、増えれば増えるほどバグを生む可能性が高くなり保守性も下がっていくし、後からキャッチアップするのも大変になる。なので不用意な抽象化は避けて、トリッキーな外部ライブラリも使わず、単機能なものを愚直に組み合わせてコードを書くことを心がけてた。

書いてる当時はキマってたオレオレルールも、時間経ってからみるとなんで？って絶対なるから。いやほんとに、1年も持たずにそうなるから。愚直に書かれてて、そこにあるものを読めばわかります状態になってるほうが圧倒的にマシ。

日々のメンテが継続的に繰り返される生きたコードベースや、重厚な事業ドメインが必要な案件に腰を据えるならば、もう少し中間レイヤーを厚くしたりとか、それこそDDD的なエッセンスを拝借するとかもいいと思う。

けど、運用が存在しない受託ワールドにおいては、おそらくこれが正解なんじゃないかなーと思ってる。

速いは正義

端的にいうと、パフォーマンスを意識したコードの書き方をするということ。パフォーマンスを意識した技術選定をするということ。

ここで言ってるパフォーマンスは、クライアントにおける表示速度やJSの実行速度はもちろん、APIのレスポンスもテストの実行速度や開発時の快適さまで、ありとあらゆるもの。

アルゴリズムとかあんま興味ないって書いたけど、こういうとこには何か通ずるものがあるかも？

一貫性を追求する

コードベースにおいて、

• 変数名
• エラーハンドリング
• 関数の大きさ
• 処理の流れ・債務
• 引数の順番・構成
• コメントの書き方
• ディレクトリ名やファイル名
• etc...

といったあらゆるものの一貫性を、徹底的に保つということ。中途半端なコードを残さないということ。読んでて「？」ってなる瞬間をひたすらに潰すということ。

普通のことに見えるけど、実際は簡単ではないと思ってる。他の人のコードを読んでると己のムジュンに気付いてないな？っていうのもよくあるので。そういう意味では、整理整頓が得意な人は誰でもそこそこのWebエンジニアになれると思います。いやほんと。

普通の運用案件にも当てはまるとは思うけど、これも手離れよく納品するためにはシリーズかも？

なんかツールの使い方やら新しい技術の〜って感じじゃなく、こういうとこにばっか目が向くようになったの、老いを感じるな・・🙄

Reactってなんであんな難しいの

それなりの年数でReact案件をこなしてきて、チョットデキル状態になった今、改めて思ってること。

UIをコンポーネントで定義するとか、単方向なデータフローとか、なんでもリアクティブな構造にするだとか、もちろん物事を正規化して単純化する方向に動かした功績はあるとしても、Hooks以降のAPIってなんであんな難しいんやろうって。

UIライブラリとしても、扱う必要のあるAPIがテクニカルすぎるというか、知っておくべき必要のあることが多すぎるというか、なんというかそういう感じ。

別にディスるつもりはないし、仕事では結局「とりあえずReactで〜」が実情であり、現世で日銭を稼ぐために必要なので使うけども、なんかこう心の底から迎合できないというか。

I find it truly disturbing how professionals can make their and everyone’s lives so difficult, how deeply disconnected React is from the actual practice of programming, which is all about understanding how your code executes. My mind is boggled by 5 by 5 zoom calls of well-paid “staff engineers” chatting about React and writing tutorial upon tutorial like any of this normal. And these are the loud ones. I pray for the entry-level programmers, the contractors, the voiceless, who aren’t beefing on Twitter, who do not have a sense of how strange this kind of development is and don’t have the courage to speak up.
https://news.ycombinator.com/item?id=29422397

これ。

とにかくReactの使い方や考え方ばっかを覚える必要があって、本来考えるべきところにリソースが余らないというか・・。（その上でちゃんとThinking in Reactできてる人ってそうそうおらんと思ってるし、自分も怪しいところある）

そういうわけで、このままついて行ってええのか？って思ってるときに、React Forgetとか言われて更にその思いを強めた年の瀬。

React Forget is cool... but what if other frameworks already do that by default?

I re-created the TodoList demo in @Huxpro's talk using idiomatic Vue 3: https://t.co/eg6M3h2sqA

— Evan You (@youyuxi) 2021年12月10日

かといってSvelteなら難しくないのか？って聞かれると、それはそれで即答できんけど、まぁReactよりはマシでは？とか。htmxまで回帰するのは流石に抵抗があるけど・・。

UIライブラリの域を越えつつある最近の機能とか、Nextとのがっちり感とか、この先さらにその傾向が強くなる予感がして落ち着かないのです。

「できれば内製できるようになりたいので、とりあえずReactでお願いします」っていう案件も耳タコくらい聞いてきたけど、そんなマインドで扱えるシロモノではない！ってことだけ。

子持ちエンジニア 勉強会 無理

子が生まれてから、登壇はおろか勉強会への参加が本当に厳しくなったと思う。

まず18時〜な時間帯は、晩ごはんとお風呂と寝かしつけというゴールデンパスなので無理。
21時〜とかだとするとワンチャンあるけど、それでも大きな音を出せないし、貴重な夫婦の時間でもあるし、気が気でない。

土日なんかもちろん無理で、奥さんにワンオペを強いてまで出たい勉強会なんかあるか？みたいになる。

子がもう少し育ってくれたら、変わってくるもんなんかなー。みんな平日の日中にやってくれたらいいのに。