技術検証もこのブログを運用している一つの目的なのですが、今までは主にバックエンドをいろいろな言語とフレームワークで書き換えてきました。 今回は心機一転フロントエンドをNuxt.jsからReScriptに書き換えました。

なぜReScript

まず、ReScriptは2020年末まではReasonmlという、OCamlライクなプログラミング言語でした。 このReasonmlは様々な理由から現在ReScriptという名称にリブランディグされた、と言う経緯があります。

個人的にOCamlが大好きなので、Reasonmlの勉強をしていたらいつの間にかReScriptに変わっていた、という流れです。

ReScriptも、OCamlコードがそのまま利用できます。（最新のOCamlに導入された関数などは使えませんが） しかし、ReScript自体は「フロントエンド開発に最高の体験をもたらす」ということを目的としているようです。

そのため、「関数型プログラミング」、「非同期」、「静的型付け」というような文言は意図的に使わないようにフシがあります。 そういった思い切りの良さが個人的に気に入っています。

個人的にはJavaScriptが好きじゃないですし、TypeScriptも可能な限り触りたくない派なので、今後はプライベートでも仕事でもフロントエンド開発はElmかReScriptで進める予定です。

さようならSSR

さて、ReScriptはOCamlベースの強力な型システムがあります。 普段の開発ではそのReScriptの型システムを使って高速に型エラーをチェックすることが出来ます。

ただし、最終的には当然JavaScriptにトランスパイルします。 ReScriptはそのトランスパイルまで面倒を見てくれますが、SSR機能はありません。 なのでこのブログも今まではNuxt.jsを使ったSSRさせていましたが、もうこのReScriptバージョンをリリースした時点からSSRはしていません。

個人的にはSSRは非常にサーバリソースを食う割に、旨味がOGPタグを扱えるぐらいにしか活かせていなかったのでそもそも廃止したいなと考えていました。 そういった経緯も有って、ReScriptを導入している精神的敷居はほとんどありませんでした。

CSSフレームワークの除去

フロントエンド開発をしていて、個人的にはプログラミングよりCSSヂカラの方が重要だと思っています。 なので自分のCSSヂカラを向上させるために今回は思い切ってCSSフレームワークは使わないようにしました。

また、SSRをなくしたことで、クライアント側でDOMの生成が行われるので画面のガタつきが発生します。 この部分もデフォルトのDOMとCSSで工夫してガタツキが発生しないようにしました。

ReScriptのメリット

山ほどありますが、静的型付け言語で、型チェックが恐ろしいほど高速に動作します。 また、所謂関数型プログラミング言語と呼ばれるものと同様の機能を揃えています。

ReScriptのデメリット

圧倒的に逆引き的に扱えるドキュメントが少ないです。 まぁコレは時間が解決するかなと思います（ReScriptが流行れば）

ReScriptはファイル名自体がモジュール名になって、ディレクトリ名は全く考慮されません。 そのため、異なるディレクトリであっても同じファイル名でコードを作成することが出来ません。 コレは本当に何とかしてほしいです。。。 一応今後名前空間考慮するかも、と言う話はコミュニティ内で出ているっぽいので期待するしか無いです。