特に結論はない。
前提
自分
自分はrailsを中心としたwebエンジニア。ここ1年半ぐらいはnode.jsにベットして活動してる。
node.jsは使われてるところでは使われてるけど、思ったより日本ではこねーな、というのが個人的な感想。
フロントエンドのツールチェーン作るならnode.jsだろうな、という感じ。
だけど、最近はツールチェーン作るならgolangなんじゃないかな、という気もしてきていて、手持ちのツールをgolangで試してみている。
node.js, npmにベットしているけど、特段フロントエンドエンジニアではないし、html, cssが弱い。
マネーフォワード社
マネーフォワード社の基幹技術はサーバーサイドにjava, ruby。クライアントサイドにandroid java, objective-c/swift。
mfクラウドチームでは、pc入力がメインなので、android java, objective-c/swiftがjavascriptに変わる。
javascriptでの開発もそれなりにチーム組んで取り組んでいる。
一方pfm(家計簿)チームは、まずwebから開発をはじめて、その次スマホアプリに全力でかじを切って、いまここというかんじ。
どこまでjavascriptに持っていく?
ここから、どこまでイマドキっぽいフロントエンド開発に持って行こうかな、持って行くべきなのかな、とぼんやり考えている。
イマドキっぽいってなに?
やらないこと
ライブラリはnpmで入れてwebpackでっしょー。railsのassets pipeline今すぐやめようぜ。railsの役割はapiサーバーまでにとどめよう。
みたいなのは、チームの状況を見るに、コストパフォーマンスもメリットも薄いなーと思ってしまう。nodeでサーバーサイドレンダリングやりたくないし。railsでいいじゃん。
やること
dom操作でjqueryでってのを過去分修正するかはともかく、これから作るのは精神に悪影響ありそう。
そのうちやること
rubyのgemでjavascriptをwrapしてますというのは、シシルイルイなのでやめたい。あれ筋悪。
同じ言語のgrunt-*, gulp-*, yeomanのgenerator-*, でもみんなしぬんだぞ。
ワンクッションrails-assetsやらbowerやら挟みたいが、どっちもしんでしまっているからな。
じゃあやっぱりnpm + webpackになってしまうではないか。
思うこと
これでjavascriptが会社の超主要言語なら、超やれ、当たり前だろ、って感じ。
でも、そこまでじゃない。サーバサイドやるならjava, better javaとしてscala, ruby, apiサーバー作りたいならgolang, あたりやるほうがコスパ良さそうに思ってしまう。
それかandroid java, swift。それかビジネス寄りに動いていくとか、データ分析側とか。やるほうがいいんじゃないかなーと思う。
javascriptはそれなりに必要な言語なんだけど、そこまでなあ、うん。
特に結論はない。