Hotwire or React? ~Reactの録画機能をHotwireに置き換えて得られた知見~ / hotwire_or_react

JavaScriptフレームワークを取り巻く状況は、常に変化を続けています。近年では、サーバーサイドレンダリング(SSR)とクライアントサイドレンダリング(CSR)のバランスは、重要な検討事項です。 ChatGPTのRemix採用 2024年9月、ChatGPTがNext.jsからRemixに移行したことが明らかになりました。この出来事は、Remixの母体であるReact Router系のコミュニティで大きな話題となり、移行の理由について様々な憶測を呼びました。 JavaScriptエキスパートのWes Bos氏(学習動画教材とかを作っている人)は、ChatGPTのフロントエンドのソースコードを分析し、OpenAIがRemixを採用した理由について独自の考察を展開しました。 www.youtube.com 緊急で動画を回すWes Bos氏 Wes Bos氏の分析によると、ChatGPTのア
経緯 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
筆者はES6以前のVanilla JSがあまり好きではありませんでした。 そこで、バニラJavaScriptをなるべく書かなくていいように、2000年代を通じてさまざまなアプローチを追求してきました。最初はRJS(Ruby-to-JavaScript)、次はCoffeeScriptでした。どちらのアプローチも、バニラJavaScriptより楽しく書けるソースコードを、ブラウザが実行できるバージョンのJavaScriptへトランスパイルするものです。ある程度は、うまくいっていました。 とはいえ、これは明らかにその場しのぎの手段に過ぎず、ブラウザがより洗練されたJavaScriptを理解できる日を待ちわびていたのです。ただ、そんな日が来ることはなく、永久にその場しのぎでやり過ごすのかと思われる時期がしばらく続きました。 しかし、幸いなことにJavaScriptは改善を続け、2015年にはES6
こんにちは! 中部オフィスでエンジニアをやっているichienです。 5月に入社してfreeeプロジェクト管理の開発を担当していました。 今回はfreeeプロジェクト管理のJS(JavaScript)バンドルサイズを削減した話を紹介します。 改善前はバンドルしたJSファイルが5MB以上に肥大化しておりダウンロードに数秒かかっていました。 その分、ファーストビューの表示もその分遅くなり、ユーザ体験に課題がありました。 今回は次の3つの施策を実施して、5MB→1.7MBまで削減し、ダウンロード時間も70%短縮できた話をします。 gzip圧縮の適応 webpack-bundle-analyzerで現状の可視化と削減対象の決定 不要な日付・祝日データの排除 また、今回の取り組みは一度にすべて対応したわけではありません。次の様にstep-by-stepで進めることを意識しました。 現状を可視化し理解
感想です。 何をしたか 現状でBlitz.jsで本番サービスを運用できるかの調査。 Railsで運用している本番サービスの一部機能を、3日間ほどかけて移行を試してみた。 結論 (Railsの主戦場でもある)新規事業開発の文脈でのクイックな立ち上げを想定するなら、本番運用するにはまだ厳しい。 特に、RailsユーザーとしてはActiveRecordがないのが厳しい。 開発効率そのものはRailsと比べて多少落としても、Railsよりもスケーラブルで型安全に開発したいなら、割と良い選択肢に思う。 もろもろ可能性は感じるので、引き続き応援していきたい。 良かった点(=Blitz.jsに興味を持っている理由) 型安全な開発 サーバーもフロントも全てが型に守られた開発、そしてIDEの恩恵を受けられるのは、いうまでもなく心地がいい。 型は補助輪のようなものなので、ユーザースキルが高ければ必須ではないく
この記事の内容 blitz-js が生まれた背景 prisma の紹介 blitz で簡単なブログを作ってみる blitz を vercel にデプロイしてみる tldr blitz-js は next.js + prisma で rails を再現しようとしているフレームワーク Prisma ORM それ自体が良い。blitz の理解のためにも、まず Prisma を学べ blitz-js 自体はまだ α 品質だけど、今から注目しておく価値はある。デファクトになるかは不明。思想は継承されそう。 はじめに next.js はとても良いフレームワークだが、永続層を持たない。なのでフロントエンドとフロントサーバーに閉じている。 永続層、つまり DB を持たないので、初学者や流行りのプログラミングスクールの教材に選ばれない。また、JavaScript の学習資料が散らばっている。 要は Rail
12/23の朝方、DHHが以下のツイートを発信しました。 Hotwire aka NEW MAGIC is finally here: An alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This includes our brand-new Turbo framework and pairs with Stimulus 2.0 😍🎉🥂 https://t.co/Pa4EG8Av5E — DHH (@dhh) December 22, 2020 取りあえず様子を知りたかったのでDHHのツイートを追ってみました。お気づきの点がありましたら@hachi8833までお知ら
実際に週1日で何やってるの?Findyで副業フロントエンドエンジニアに実際にお願いしたタスク達 2018.07.11 こんにちは、@ma3tk です。突然ですが、今この記事を見ていらっしゃる方は副業やっていたりしますか?もしくは、副業やってみたいけど、具体的にどんなことをやっているのかなど、気になることも多いんじゃないでしょうか。 そこで今回は ハイスキルなエンジニアのプレミアム転職サービス Findy で一緒にフロントエンドを改善していただいているフロントエンドエンジニア達にお願いしている仕事を具体的に紹介することで、副業する時の参考になるといいなと思っています! 前提 Findy の開発に関わっていただいているフロントエンドエンジニアは2名います。 一人目のフロントエンドエンジニア ベンチャー企業でフロントエンドエンジニアとして活躍中 CSS周りにも長けていて、新しい技術を習得している
Co-Edoでエンジニア・webデザイナー飲み会『健康的にお酒を飲んでわいわい交流しよう!』というイベントに参加してきたので、そこでこんなLTしてきました。 元々ブログに書きたいと思っていたネタなので、スライドの内容を補足する形で久しぶりにブログにまとめておこうと思います。 最初に前置き的なこと スライドでも触れてますが、2014年7月〜フリーランスになったので、気づいたら3年弱経過してました。 1人で仕事やってるので 忙しい時に仕事の依頼が来てやむなく断ってしまう 目先の案件の仕事ばっかりになってしまってこの先必要な技術習得を疎かにしがち ということが、時々発生してました。 やむなく断ってしまう場合にも出来ることはやっておく 忙しい時に仕事の依頼が来てやむなく断ってしまうという件については、仕事内容、先方の雰囲気などを踏まえて誰か良さそうな人がいないか周りの人に声をかけてみるということを
Ruby on Rails の 5.1.0.beta1がリリースされましたね! weblog.rubyonrails.org 仕事でRailsを使うものとしてちゃんと触っておかねばと思い、まずは自分の好きなJavaScript周りがどれぐらい良くなったのか見てみたところかなりびっくりしました。JavaScriptすごく開発しやすいです。 webpack があって yarn がありますし、ReactやVue、angular まで rake タスクでセットアップできます。ちょっと前までRailsでJavaScriptやるのが辛いなんて言っていたのが嘘みたいです・・・。 今回はRails 5.1.0 で Vue.js を使って新しくプロジェクトを作るところまでやってみました。 rails new rails webpacker:install:vue Webpackでのビルド Hot Modul
投稿開発部の外村(@hokaccha)です。今回はReactについてのお話です。 ReactとSPA 最近JavaScriptやそれを取り巻くフレームワークなどの話題では、サーバ側はAPIのみを提供し、View(HTML)は全てJavaScriptで描画するような、いわゆるシングルページアプリケーション(以下SPA)についてよく語られます。 一方で、SPAを構築するにはコストがかかることも事実で、特にフロントエンドエンジニアが多くない環境では、従来通りサーバーサイドでViewを書きつつ動的な部分だけJavaScriptで処理するというアーキテクチャのほうが現実的な場合も往々にしてあります。 今回はこのような、サーバー側でHTMLを生成し、一部の動的な部分だけをReactで書くためのTipsを紹介します。 なお、基本的にサーバーサイドはRails前提ですが、RailsにおけるReactの開発
dotsで開催されたReactの導入を検討されてる方向けの勉強会でお話しました https://eventdots.jp/event/597088
ども、@kimihom です。 Rails5.0 の正式版がついにリリースされた。 Riding Rails: Rails 5.0: Action Cable, API mode, and so much more Rails 5といえば、 ActionCable での WebSocket によるサーバープッシュのリアルタイム処理が注目されがちだが、個人的には今後のシステムの開発指針を Rails が示した重要なリリースになっていると感じている。その原動力となっているのが、 あの "Turbolinks" だ。 マルチプラットフォーム開発に対する提案 ではどんな話かっていうと、まず Rails としては JavaScript で複雑なロジックをたくさん書いたり状態を管理するような処理を書かないことを選んでいる。以下の動画は今後の Rails において非常に重要な意味を持っている。 Rail
原文: The React on Rails Doctrine ジャスティン・ゴードン(2016年1月24日) このドキュメントはRailsの基本理念(訳注: 日本語版)に対する拡張と補足です。まだそのドキュメントを読んでいない場合、先にそちらを読むことをお勧めします。 React on RailsのREADMEの中で述べているように、このプロジェクトの目的は、Ruby on RailsとモダンなJavaScriptのツールやライブラリを統合するための、強固で最適なフレームワークを提供することです。react_on_railsに何をいれるべきかを考えるとき、その機能が RailsとモダンなJavaScriptとの共通部分と関連があるかどうかを自問します。RailsのビューとReactコンポーネントを統合するためのビューヘルパーがよい例です。答えがイエスである場合、その機能はここにあるべきで
本記事はRubyについて書かれたものではありますが、Python、JavaScript、Javaなど、全ての言語コミュニティに当てはまる事実を述べたものです。依存関係が引き起こす負の連鎖は誰のためにもなりません。 上の図は、私がこれまでに使用した全てのRailsアプリの依存関係を可視化したものです。以下の例はいずれも、どこかで聞いたことのあるものではないでしょうか。 何百ものエントリを含むGemfile 本番環境で読み込まれるテスト用Gem 数百メガバイトもRAMを食うRailsのプロセス Rubygemsシステムは、それを再利用する誰もが容易にRubyのパッケージを作ることができるという点で、賞賛に値するものです。しかし、その便利さが意味するところは、そうしたGemと他のGemを非常に安易に結び付け、さらにそれが、「インターネットでダウンロード」され、数百もの依存関係を持つRailsアプ
RailsのAsset PipelineとPrecompileをNode.jsのみで処理できるgulp-sprocketsを作った 仕事ではRailsアプリを書いていて、JSやCSSなどのフロントエンドはRailsのAsset Pipelineの仕組みに則ってビルドしてる。 普通にRailsアプリ作ってると普段Sprocketsについて特に意識しないと思う。 Sprocketsはそこが凄くて、あまり考えなくてもドキュメント通りにやってれば、必要なAssetを結合できて、リリース時は変更がなければブラウザキャッシュから、変更があれば 新しく読み込まれるみたいなことをやってくれる。 なんだけど、もうそろそろ新しい機能はES2015で書きたいよねという人が増えてきた。 とはいえSprocketsは独自のディレクティブ以外は使えなくて、SprocketsWayから外れると途端に脆い。 ES2015
Sendagaya.rb #114に来たので、目標のブログ記事を書いてた。 今日はsendagaya.rbへ行ってブログ記事を一本仕上げるのが目標。— Koshikawa Naoto (@ppworks) August 10, 2015 今日は、React.jsの会なので、RailsからReact.jsをざっくり使って見る準備をしてみます。 目指すもの sprocketsのままとりあえず進む jsのライブラリをnpmで管理したい React.jsをES6で書きたいし、JSX書きたい herokuで動かすぞ! react-railsは使いたくない 方針 sprocketsと共存するために、browserify-railsを利用し、ES6はBabelを利用します。ライブラリはそのまま、npmで管理します。 npmを入れます もし入っていなければnpmを入れましょうね。 brew install
「俺の最近のRailsのJS開発環境」 for フロントエンドエンジニア TL;DR 「片手間のJS」ならhogehoge-railsで大丈夫(e.g. browserify-rails, sass-rails, etc.) 「本気でJS書く」ならsprocketsから切り離す(e.g. SPA, etc.) 迷えるフロントエンドエンジニアに愛の手を ※ 個人の見解です はじめに 本記事の内容は個人の見解であり、所属する組織の公式見解ではありません. 本職は学生,片手間にRailsエンジニア,そのさらに片手間に過激派フロントエンドエンジニアやってる人間の戯言です. 『俺の最近のRailsのJS開発環境を教えてやる』を受けて,フロントエンドエンジニアの視点から見たRailsのJS環境を考察してみた記事になります. 元記事をdisっているわけではなく,むしろリスペクトしたうえで視点を変えてみた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く