ちょっと訳あって仕事の一貫としてReactNative + Scala.js の技術検証している。あたまには「全部C#」のライフベアさんの事例がある。弊社、最近メンバー増えてきたけどまだこの規模だと「あのひとはあれができるけどあのひとはこれができなくて」がボトルネックになりうるので、 筋の良い 共通の基盤技術を持つという選択肢のひとつとして検証したいというのがモチベーションとしてある。というわけで、
- Reduxは使ってない。「Scalaを基盤技術にしてどこまでできるのか」が検証の目的だから。
- Vue.js + Scala.jsでElectronアプリ作ったときと同じ感じで、MVWhateverのVとWhateverの部分は素直にJSで書いている。分厚いMをScalaで書き、UIだけReactNativeで記述する。
以下ファーストインプレッション
- pros
- cons
- ReactNativeは比較的簡単にネイティブに降りられるんだなということはわかった。が、普通にJSで書いていても、インフラストラクチャ層では「JS -> ネイティブのバインディングを自分で書く」という必要がある(コレ自体には納得感があり、筋の良さすら感じる)上に、それをScala.jsから利用するために「Scala -> JSのfacadeも自分で書く」あるいは「RNで使われるライブラリへのfacadeも自分で書く」というのは結構発生する雰囲気で、そこは正直だるさ感じるのがある
- そもそもswiftとかKotlinで書けばよくね?
- ていうかScala.jsもReactNativeも「枯れた技術」から遠すぎるよね
- prosと鏡合わせだけど、HTMLの知識役に立たん。むしろネイティブの知識が役立つ
という感じです。
わたしは「クライアントサイドのアプリケーションの寿命はサーバーサイドのアプリケーションの寿命より短い」ということを信じているので、クライアントサイドでは「枯れた技術」にこだわる必要ないのではないかという立場(異論反論あろうとは思います)なんだけど、そういう立場であってもプロダクション投入に対してはかなり慎重にならざるを得ないなこれ(頑張ればなんとかなるけどその頑張りはペイするか…?)って感じです。とはいえ、夢はあると思います、Scala.js + ReactNative。様々なプラットフォームに、少ない人間で対応していくという目的に対して、Redux + JSによるマルチプラットフォームを基盤技術にするよりずっと筋がいいという感じがしているのもたしかです(動的型付け言語で複雑な状態管理をするとか正気か!?)。一方、「たとえ合理的だったとして、そんなニッチな技術選択して誰が採用できると言うのだ……」という問題はある。
こちらからは以上です。