Re: Rails を主戦場としている自分が今後学ぶべき技術について

この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io

[toshiwo]

mizchiがサーバーサイドにただならぬ恨み持ってるのがよくわかる文章だった

[tackman]

本題じゃないけど、歴史編のくだりで「フロントエンドは声のデカさで政治してる」という批判が出る理由が分かる気はした

[glass-_-onion]

RailsにしろNext.jsにしろそこでしか生きていけない人たちの縄張り争いな印象。言語にもフレームワークにも縛られたくないですね。サービスの要件と規模に見合った技術を選択すれば良いだけ。

[aikawame]

PHPやっていた頃にRails界隈からフルボッコにされていたのを思い出す。

[for-my-internet-demo]

ts好きだけどフルスタックフレームワーク云々の流れはめっちゃ嫌な予感してる

[KoshianX]

まあおおむね賛同。Rails はすばらしい思想でこの20年の問題を解決してくれたけど、これからの10年の問題を解決するフレームワークではないんだろうな。ただ ruby で書きたい気持ちはまだずっとあるなあ

[hnw]

"SQL のレスポンスタイムの数百 ms のオーダー" 過去の現場がアレだっただけでは…。SQLクエリ一本が5msだと激遅、10〜30クエリ投げてるAPIのレスポンスタイムが100msオーバーは激遅、という肌感覚なんじゃが…

[nijitaro]

フロントエンドエンジニアがJSON色付けおじさんになってしまったのでRailsもJSON吐き出しフレームワークになっちゃったんだよな。そうするとRailsの少し仰々しい感じはわかる

[koyancya]

いくらなんでもそんなことある？びっくりした -> “要は 「Perl6 化」する可能性を懸念しています”

[dbr0]

この投稿を炎上芸だと思うような奴ははてブに毒され過ぎてることを自覚した方が良いぞ

[d4-1977]

ユーザやビジネスがフロントエンドに求める事が増えてきて、Railsがそこにはあまり応えてくれてなくかったけれど、ReactやTypescriptや宣言的なUIなど設計思想がハマり、フロントエンドはRailsの必要がなくなった話だと思った

[yuzutas0]

mizchiさんを雇えるレベルに到達したベンチャーの多くはRailsだったと読み替えていいのかな。それならRailsは超魅力的に思える。 "一番多かった業務内容がSprocketsのAsset Pipelineを捨てながらcommonjs/ESMのコードを追加すること”

[el7]

「サーバーサイドHTML生成」と「フロントエンド側のフレームワークで生成」のどっちがいいかの話、ケースバイケースなのでどっちがいいという話にできない

[iwasiman]

こちらはフロントエンド強者の方の反Railsのポジショントークの入った意見。JSも2000年代半ばから復権してここまで来たし、PHPもなんのかんのでしぶといし、さて未来はどうなるでしょう。

[kei_0000]

Rails のフロントエンド周りは限界 Rails は文化的にパフォーマンスに対する指向を持たない ActiveRecord の賞味期限は Rails と同じ 型による大規模化への伸びしろの有無が決定的な差になってきた

[sharaku3eyes]

最近rails案件も増えてきたんだよなあ。興味なくなった人が放り出してんだろうな…

[koogawa]

みんなちがって、みんないい

[onesplat]

なんや話の展開がゴチャゴチャしてよくわからん記事だが、要はJSON吐くだけのお仕事にrailsは不要ってことでしょ。それには同意。

[hamichamp]

メモ

[nilab]

「Web に関するものは一旦 Node.js に集約」が良さそうな感じがするけど、Ruby on Rails に近いところで Go と Java がけっこう使われていると思うのでそのあたりが気になる。

[machataka]

typescriptやnext.jsなどの利点を書けば良いのに、railsが余程嫌いなんだろうね。もっと建設的な記事を読みたい。

[toro-chan]

Railsとフロントエンドが全く合わないことは同意する。でもJS(TS)でバックエンド側も全部書くのはいやだ。。バックエンド側はRubyのほうがまし。まだどれも「これ」ってものがない状態だと思ってる。

[boomerangj]

昔は型なんて要らない！結局テストを書かないと意味ないからや！みたいな謎理論でイキっている人が多かったイメージなので、時代は変わるもんだなと思う。

[inurota]

こういう論争、普段は遥か彼方を見据えて最前線でバチバチやっている上弦の鬼たちが「Railsとは何か」「Next.jsとは一体」と足元を振り返り、最新の知見から俯瞰的な視座を与えてくれてメリットしかないのでどんどんやれ

[awkad]

この人、そんな語るほどバックエンドやってるの？しかも大事なのは新規構築より維持保守。長くシステムの面倒見ずに渡り鳥のように会社うつったりフリーランスやってる人が語るアーキテクチャって即物的っぽいね

[justgg]

matzの拘りによって普及し、matzの拘りによって衰退するのか。違う未来も見てみたかった気もする。が、正直もうGoでいいやとなってしまった。ActiveRecordの話にしても、GORMも十分良くできてるし、RDBの比重も減ってる。

[ptpadan]

フロントとバックエンド分かれればまず、解決じゃないのかなって気がするけど、何でまたフルスタックフレームワーク推しなんだろう？　tsフルスタックは興味あるけど、バックエンドまでやるとしてもモノレポで分けた

[asayamakk]

5Gみたいな外部環境の変化で国内ではnon-SPAなサービスでも十分に速くて満足できるみたいな未来こないかなあ。GoogleMapみたいな特殊なアプリを除いて

[mricopp]

パフォーマンスを蔑ろにするとあとでまじで泣くし詰む。どんどん手がつけられなくなって負の遺産と化す。しかも目に見えないところだからそこに手を加えるにもお金も積みにくい。だから設計は大事。

[newnakashima]

5年前はもうjQueryとか死んでいくんだと思ってたけどリッチなLPとかではバリバリjQuery使われてるし油断するとwp-contentなどのパスが見えてたりするし、死ぬと言われた技術が文字通り死んだのまだ見たことない

[t-murachi]

RoRに留まる人と、フロントエンドの先を追う人とで、技術的視界に広がる風景に大きな差がついている。そこに前者の人々が気付けないままでいるのが界隈の不幸なのだと思う。廃れているはずのRoRの仕事中々減らない('A`)

[umai_bow]

Rails憎しすぎでしょ。とは思うけど、まあ単純に脳死で選択されたRailsのせいでフロントエンドのチューニングが気軽に行えない、みたいなことはよくある

[khtno73]

「開発の花はDBとビジネスロジックや！お前らフロントはバケツリレーとバリデーションでもしとけや」vs「モバイル含めたマルチプラットフォームのキー技術はもはやフロント側なんですけどｗｗｗJSに合わせろや原始人」

[masa_w]

毎度静的型付けでマウント取られるのうんざりなので、rubyの人たちはできるところからcrystalに移行していきましょうぜ

[fjwr38]

これなぁ / “前にも書きましたが、フレームワークや言語は死んでも、そこで培われた思想は残るので… "

[sakuro]

Hanami と ActiveRecod の関係について kwsk

[dai-pmax]

わ

[ukayare]

なんというか小〜中規模の大したメンテも必要ないSPAの開発と言う状況での選択ならそう言う意見になるかなって感想

[gfx]

フルスタックWAFはAPIサーバとかSPA作るときとかにはいらんよねという話。「Railsのフロントエンド周りのサポートはすべて忘れる」という決断を早めにできればそんなに問題はないんだけど。