Hotwire的な設計を追求して「Web紙芝居」に行き着いた話 by Yasuko Ohba (nay3) - Kaigi on Rails 2023
私は昨年3月以降、Rails7でHotwireを活用して複数のアプリケーションを開発してきました。Hotwireは、SPAのような動きをRailsだけで実現できる良い道具だと思っています。開発体制やコードをコンパクトに保てる利点があります。 ただ、SPAではなくHotwireでやろうと決めるためには、Hotwireでどこまでできるのか？ Hotwireでできないことはあるのか？ が気になってくる点でしょう。この点について、今では私は以下のように感じています。 やりたいことは大体なんでも Hotwire で実現できる 最終的に実現できる機能の差よりも、どういう考え方で作るかにSPAとHotwireの大きな違いがある SPAとHotwireでは、アプリを構成するための物の考え方が大きく異なります。Hotwireを縦横無尽に使い倒すためには、Hotwire的な考え方で作る必要があるのです。この、
Railsの現在地 / Rails以外からTurbo(Hotwire)を使う｜kiha
Railsの現在地DHHらは、ビジネスモデルが確定していないレベルの初期のスタートアップにおいて、複雑なSPAでのページレンダリングを採用したWebシステムを構築することはオーバーエンジニアリングでは？ というところに、強い課題意識を持っているように見える。フロントエンド、サーバサイド問わず複雑なアーキテクチャにしすぎると生産性悪くない？というわけだ。あのTwitter社ですら儲かるか儲からないかわからないレベルの黎明期にはその思想に賛同してかRailsを採用していた。 近年DHHらは、RailsベースのGmailっぽいプロダクトをリリースしていて、新進気鋭のフレームワークであるHotwire(Turbo)を積んだRails 7でGmailの「あの操作性」を実現できるレベルに進化させた。ReactやVue.jsなどのライブラリを使わずとも実現できることを示した。 Turboの概観Turbo
Remove TypeScript - laiso
経緯 world.hey.com DHHが「オタクくん見てる〜？ 今からうちのレポジトリからTypeScriptを剥しま〜す」と宣言したことにより、Web開発者界隈でTypeScriptの是非自体の話になり騒ぎになった*1*2。 github.com その後、野次馬がたくさん集ってきてrevertプルリクエストを立てる人やTypeScript公式リポジトリから全ソースコードを消すプルリクエストを出す*3ようなキッズムーブをする人も出てきた world.hey.com 実際の変更 8617行のTypeScriptがJavaScript化された。(Sloc 便利) ❯ scc src/ ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blan
Hotwireの感想 - laiso
Hotwire https://hotwire.dev/ Turboを中心としたウェブアプリケーションのアーキテクチャの要素技術やコンセプトをPRするための名称 Hotwireというライブラリがあるわけではない 役割としてはMicro FrontendsとかReactのlearn once, write anywhereなどに似ている アプリケーション実装言語非依存だけど現状Railsアプリケーションしか実用できる基盤がない Hotwireの思想 アプリケーション開発者の生産性を上げることを目的にしていること サーバーサイド言語でフロントエンドを実装したいアレではなかった プログレッシブ(段階的に利用可能)であること 必要な技術だけを使い無駄なことをしないことで効率化する Hotwireが列挙する技術は1つづつ有効にできる クライアントサイドでViewを差分更新する現在の主流のシングルペー
実践ViewComponent（1）: 現代的なRailsフロントエンド構築の心得（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: ViewComponent in the Wild I: building modern Rails frontends—Martian Chronicles, Evil Martians’ team blog 原文公開日: 2022/10/12 原著者: Alexander Baygeldin（バックエンドエンジニア）、Travis Turner（テック編集者） サイト: Evil Martians -- ニューヨークなどに拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 日本語ブログ: 合同会社イービルマーシャンズ - Qiita 日本語タイトルは内容に即したものにしました。図はすべて元記事からの引用です。 また、"Algebraic effects"や
なぜ僕が「SPAはコストが高い」と考えているのか
どうもみなさんこんばんは ちょっと前に「個人開発者やスタートアップの初期からSPAで開発するのはコスト高いっすよね」みたいな事を書いたらフロントエンドエンジニアの皆様からバチバチに叩かれた僕です 彼らには彼らの考えがあるのでそれはどうでもいいのですが、どういう理由があってその発言をしたのか～と言う部分が気になっている方もいたようなので説明しておこうと思います ちなみに今でも全く意見は変わっておらず、この発言に同意できるかできないかは単純に視点の違い、規模の違い、スキルの違いだと思ってます 追記: もちろんSPAじゃないと実現できないようなサービスを作りたい場合はSPA一択ですし（インタラクティブにHPつくるサービスとか。でも世の中の95%くらいのサービスはそうじゃないと思います）、サイトの利用はログインした人にだけ提供するような業務系ツールなどはまた話が別です 前提の話 こういう記事ではコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Tips詰め合わせ｜猫でもわかるHotwire入門 Turbo編
