妄想的DHH理解2:概念的距離の圧縮 - Qiita

Caution この記事はDHHファンの妄想によるシナリオが多分に含まれます。 というかほとんどです。 成り立ちや考え方が間違ってることも当然あるように思うので話半分で読んでください。 これは一体 前回かいた妄想的DHH理解のエピソード0的な話です。 妄想的DHH理解では、DHHがどういう過程で今のRailsフロントエンドに達したかの話が主題でしたが、そこでは「なぜ〜を選ばなかったか」は説明されていませんでした。 彼はモノリシックを愛したり、トレンドと真逆のアプローチでフロントエンドに新しいレールを引き始めたりするので、単に彼が天邪鬼であったり車輪の再発明大好きおじさんとして捉えられがちですが、実は太い太い一本筋をもった技術選定をし続けてるってことが広まればいいなと思ってるファンの記事です。 前提知識 前回とほぼ同じです。 Railsの生みの親、Rubyist。 実はカーレーサーでもありま

[yarumato]

“仕事以外の趣味や家族のために時間を作りたい。だから「概念的距離の圧縮」で開発の効率を上げる。アプリケーションとDBの距離を圧縮(≒密結合)したActiveRecord。HTMLとJSの概念的距離を極端に縮めるReact、Vue、Stimulus”

[cl-gaku]

“単純な技術力の問題”それはそうだけど簡単に言ってくれるなあ…とはなる。アレはヘボのコードから全体を守るためにも有効なんや…

[rararoro-ryo]

ネットを通したとしても、DBを使っていたとしても オンメモリの変数だけのローカルネイティブアプリを作るみたいな感じにしたい。みたいな。

[mas-higa]

「概念的距離の圧縮」おもしろい

[katsyoshi]

第2弾。マイクロサービスの下りは同意しかない。