HotwireはRailsを「ゼロJavaScript」でリアクティブにできるか？前編（翻訳）｜TechRacho by BPS株式会社
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Hotwire: Reactive Rails with no JavaScript? — Martian Chronicles, Evil Martians’ team blog 原文公開日: 2021/04/12 原著者: Vladimir Dementyev -- Evil Martiansリード開発者。 サイト: Evil Martians -- ニューヨークやロシアを中心に拠点を構えるRuby on Rails開発会社です。良質のブログ記事を多数公開し、多くのgemのスポンサーでもあります。 長文につき前編と後編に分割しました。 サマリー The HEY stack: - Vanilla Ruby on Rails on the backend, running on edge - Stimulus, Turbolink
ブラウザレンダリングの仕組み
Webの用語を100秒で解説するチャンネルを作りました！ よかったらチェックしてみてください！ はじめに 以前書いた記事「Webページがブラウザに表示されるまでに何が起こるのか？」で ブラウザレンダリングについて詳細に知りたいという意見をいただいたので、調べてまとめてみました。 全体図 レンダリングの大まかな流れです。 HTMLのダウンロード サーバから送られてきたHTMLをダウンロードします。 HTMLの解析 サーバから送られてきたHTMLファイルは、「0」と「1」でできたデータになっています。 ブラウザは、サーバから受け取ったデータをそのままHTMLとして解釈することはできないので、自分で扱うことができる形、つまりDOMに変換する必要があります。この作業を 解析 ( Parse ) と言います。 HTMLをダウンロードしたら、すぐにこの解析作業に入ります。作業は以下のようなステップにな
控えめなJavaScript - Wikipedia
控えめなJavaScript（ひかえめなジャバスクリプト、英語: Unobtrusive JavaScript）とは、WebページでのJavaScriptの利用における一般的なアプローチである。この用語は正式には定義されていないが、基本的な原理は一般的に次のようなことが含まれると理解されている。 機能（behavior layer）の、Webページの構造・コンテンツ、表示との分離[1] 伝統的なJavaScriptプログラミングの問題（ブラウザによる違いや拡張性の欠如など）を回避するためのベストプラクティス 高度なJavaScriptの機能をサポートしない可能性のあるユーザーエージェントをサポートするためのプログレッシブエンハンスメント[2] 新しいパラダイム[編集] 歴史的にJavaScriptは本格的なアプリケーション開発には適さない、扱いにくい言語とされてきた[3][4]。これは主に
Hotwireとは何なのか？
はじめに HotwireはBasecampが発表した、モダンなWebアプリケーションを作るための新しいアプローチです。名前もHTML OVER THE WIREから来ているように、HotwireではHTMLをサーバーから送ります。「それ普通のWebアプリケーションでは？」と思う方もいるかもしれませんが、SPA + APIサーバでJSONが使われるのに対し、SPAと同様の体験をHTMLを中心に置いて作るアプローチであることを示す表現です。 僕個人は、最初は「ふ〜ん」という感じだったんですが turbo-railsを読みつつHotwireのデモアプリをPhoenixに移植してみたり WebSocketではないTurbo Streamsのsourceを作ってみて遊んだり と、ある程度触ってみて良さが理解できてきたので、Hotwireを使うと何が嬉しいのか、Hotwireの各要素の紹介を記事として
サイトマップやDOM構造など、階層構造のツリービューをリスト要素で実装するスタイルシートのテクニック
サイトマップやDOM構造や家系図のように親ノードから複数の子ノードに接続線で繋げ、階層構造を明示するツリービューをHTMLとCSSで実装するテクニックを紹介します。 HTMLはul要素でシンプルに実装されており、接続線のカラーや幅や間隔などは自由にカスタマイズできます。 Tree view from unordered list まずは、実際のデモをご覧ください。 See the Pen Tree view from unordered list by Ross Angus (@ross-angus) on CodePen. 1つ目の「DOM構造」と2つ目の「サイトマップ」の実装は、基本的には同じです。順番に見てましょう。 DOM構造のツリービュー HTML 1つのul要素で3階層分まで、4階層目からは新たにul要素が必要となります。矩形は「DOM構造」では<code>、「サイトマップ」で
MEGA HOKI : SLOT GACOR & BANDAR TOGEL TERBAIK 2024 SITUS SLOT PULSA TANPA POTONGAN #1
Ratehoki88 situs slot online yang selalu memberikan Mega hoki dan Big hoki terbesar sepanjang masa dengan menyediakan Mesin slot gacor terbaik saat ini yang selalu menurunkan scatter hitam dan Megawin terbesar di dalam permainan pragamtic play dan Pg shoft salah satunya di game online yang sangat di incar adalah Mahjong ways 1, 2 dan 3, 88 Mega 777 juta juga menyediakan pasaran togel atau situs to
ReactはウェブやHTMLとは特に関係のないライブラリです - Qiita
みなさんReactやってますか。やってますよね。最近React Native流行ってるし。 んでいきなりなんですが、あのReactとかいうやつ、実は 特にウェブとは関係ないライブラリ なんですよね。ええぇ……。なのでこの記事ではそれについてだらだらと説明したいと思います。 この記事の背景 最近のReact Nativeブームで「React is 何」「React Nativeについて3行で教えてくれ」みたいなアレコレがよく発生するんですが、その際に「Reactはウェブ向けライブラリである」という先入観がだいぶ素直な理解を阻害しているなーと感じました。 「Reactはウェブ向け」って登場初期は全然間違ってなかったんですけど、厳密には2015年には全く違う状況になって、2019年とか2020年になると完全に間違ってると言える状況が発生し出したので、改めて説明させていただこうと思いました。 別に
HTML標準めぐりブラウザー業界団体とW3Cが合意--主導権は業界側に
Apple、Google、Microsoft、Mozillaのブラウザーベンダー大手4社が構成する業界団体が、ワールドワイドウェブ（WWW）の標準化団体であるWorld Wide Web Consortium（W3C）と合意し、主導権争いに勝利した。これは事実上、業界団体側がサポートしなければ、W3Cがウェブ標準を規定できないことを証明するものだ。 業界団体のWeb Hypertext Application Technology Working Group（WHATWG）は2004年に結成された。団体結成は、W3Cが現代的なHTML標準を開発するペースが遅かったことと、XMLに似た構造を持つXHTMLにHTMLを移行させるW3Cの計画を受けての動きだった。ブラウザーベンダー側は当時、XHTMLに賛成していなかった。 当時Apple、Mozilla、Operaが構成メンバーだったWHATW
GoでシュッとWebスクレイピングする
12. 12 使ったパッケージ 例）タイトルタグの中身を取得 doc, _ := goquery.NewDocument(url) doc.Find("title").Text() 例）クラス名を指定して取得 doc, _ := goquery.NewDocument(url) doc.Find(".hoge-list > li") 13. 13 使ったパッケージ doc.Find(".hoge-list > li ").Each(func(i int, s *goquery.Selection) { s.Find(“a > span”).Text() }) 例）取得した複数のliをループする jQueryでDOM操作をゴリゴリしたことがある 人にはきっと使いやすい ※goqueryの詳しい使い方はググる
W3Cで現在公開されているHTMLとDOM仕様は将来廃止されます - 水底の血
まえがき W3C（とWHATWG）からの公式なアナウンスはまだ確認していませんが、何度目かに結成されるW3C HTML WorkingのDraft Charterと、このCharterから辿れるDRAFT Memorandum of Understanding Between W3C and WHATWG（Memorandumは日本語で覚書などと訳されるので、ここでも覚書と呼びます）がブログエントリーのタイトルのソースになります。もっとも、今確認できる覚書もドラフトですから、変更があるかもしれません。しかしながらURLで観測できるわけですから、大筋でW3CとWHATWGとの間で合意が取れているのではないかと推測します。あとは、覚書だけでなくCharterもドラフトということになっていますが、以下の文章では面倒なので省略します。最後にお約束ですが、このブログエントリーは「だいたいあってる」感
Why isn't it <style src="">? | CSS-Tricks
The way JavaScript works is we can do scripts as an inline block: <script> let foo = "bar"; </script> Or, if the script should be fetched from the network… <script src="/js/global.js"></script> With CSS, we can do an inline block of styles: <style> .foo { color: red; } </style> So why not <style src=""></style>? Instead, we have <link href="">. Harry Roberts asked about that the other day on Twitt
実際のところ「ブラウザを立ち上げてページが表示されるまで」には何が起きるのか - Qiita
9月15日(土) DNSについて追記しました。バックエンド？今はクラウドがきっと上手くやってくれるので深く考える必要は無いんですよ（知らないので書けません😔） 問題のツイート 面接の質問で「ブラウザを立ち上げてページが表示されるまでの仕組みを全て知ってる限り説明してください」ってのをやると結構Web系の知識どれだけあるか分かると思ってる — 🍛🍺 (@tan_go238) September 10, 2018 解釈 今回は「ChromeのURL欄に入力してからページが表示されるまで」をやります。ブラウザの起動云々はWeb系の話じゃないと信じてます。 1. HTTPリクエストが飛ぶ HTTP2のヘッダ圧縮技術に全て書いてありました。 (追記)下のリクエストヘッダはテキストで書かれていますが、実際にはこれをバイナリにしたものが飛んでいるとのことです。segfoさんありがとうございます！
HTML Standard
Firefox1+Safari1+Chrome1+Opera8+Edge79+Edge (Legacy)12+Internet Explorer5.5+Firefox Android?Safari iOS?Chrome Android?WebView Android37+Samsung Internet?Opera Android10.1+ Categories:Flow content.Phrasing content.If the type attribute is not in the Hidden state: Interactive content.If the type attribute is not in the Hidden state: Listed, labelable, submittable, resettable, and autocapitalize-inhe
target="_blank" のセキュリティリスク(デモ動画あり)
HTMLを勉強する際に最初に覚えるものの1つにa要素(タグ)があります。HTMLのアイデンティティと言っても過言ではない、ハイパーリンクを実現する大事な要素です。 href属性に設定されたリンク先のURLをどのウィンドウ等に表示するかを決めるtarget属性というものがあります。任意の値を設定してウィンドウに名前を付ける事で、複数のa要素から同じウィンドウへリンク先URLを表示する事もできますし、常に新しいウィンドウを開く_blankのような、あらかじめ挙動が設定されている値もあります。 target="_blank" のセキュリティリスク リンクの開き方を決定するtarget要素ですが、この挙動を利用してリンク先からリンク元のウィンドウを操作できるというセキュリティリスクが公開されています。 Target="_blank" - the most underestimated vulner
[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう - YoheiM .NET
[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう こんにちは、@yoheiMuneです。 ブラウザのレンダリングの仕組みはHTML5 RocksやHow browsers workで詳しく解説されてきました。しかしそれらはとても詳細で、読破して理解するのは大変です。 今回のブログでは手軽にレンダリングの概要を理解できるように心がけました。またより詳しく学べるようなリンクも記載しました。 そしてブラウザのレンダリングの仕組みを理解した上で、どのようなJavaScriptを書くべきかについても記載しました。 目次 ブラウザのレンダリングの仕組み この章では、HTMLとCSSが読み込まれてから画面に表示されるまでの間に、ブラウザがどのような処理を行っているかを説明します。 ファイル読み込みから表示までの一連の流れは以下図の通りです。 [1]
![[フロントエンド] ブラウザレンダリングの仕組みを理解して、ブラウザに優しいJavaScriptを書こう - YoheiM .NET](https://cdn-ak-scissors.b.st-hatena.com/image/square/705cdef7654f2f96a242f9a2834ce643b78de75c/height=288;version=1;width=512/https%3A%2F%2Fwww.yoheim.net%2Fimage%2F336.jpg)
JavaScriptフレームワークはもうこりごり | POSTD
JavaScriptでフレームワークを書くのはもうやめましょう。 JavaScriptフレームワークというものは、あたかも避けられない死と税金のようなもの、絶対にぶちあたる避けられないものといわれています。こっそり聞いてみましょう、新しいウェブプロジェクトが始まるとき、一番初めに聞かれる質問は？十中八九は「どのJSフレームワーク使っているの？」でしょうね。昨今の業界においてJSフレームワークというものは本当に根深く浸透しているのです。でも、だから必須だというものではないのです。実際、もう使うべきではないのです。 どうしてこういった結論に至ったのか、振り返ってみましょう。 AngularにBackbone、Ember・・・ ここのところ長い間、 ウェブプラットフォーム とはHTML+CSS+JS、と簡潔に技術用語の羅列でまとめられてしまっていましたが、そこにはもっとぴったり表す用語“大混乱”
Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3)
Navigation Timingだからできる、Webアプリを俯瞰したパフォーマンス計測(3/3) 川田寛（ピクシブ株式会社） いよいよHTMLドキュメントのダウンロードと、画面上への表示です。この動作の仕組みから、TATの「終了」がいつなのかを追ってみましょう。「終了」についてはかなり奥が深く、Web標準でもそのプロセスを「The End」として定義はしていますが、それだけでは語りきれない難しさがあります。 4. TCP接続、5. HTTPリクエスト/レスポンス 名前解決で得られたIPアドレスを使って、HTMLドキュメントが置かれたサーバへ「4. TCP接続」します。いわゆる、3ウェイハンドシェークというものです。サーバとの接続交渉が終わると、HTTPリクエストをサーバへ送信し、HTTPレスポンスを受け取ります。 HTTPレスポンスの結果からリダイレクトであることが発覚した場合、「2.
そろそろ Simple HTML DOM Parser を使うのはやめたほうがいい - localdisk
Simple HTML DOM Parser といえば定番のスクレイピングライブラリで、僕も随分お世話になったわけだけど遅いし重いので Goutte 使ったほうがいいという話です。某サイトをスクレイピングするのに比較したら特にメモリ消費に大きな差がでました。 比較したスクリプトは Github においてありますので自由に使ってください。なおプロファイラは @koriym さんが Qiita にポストしたものを使用させていただきました。 PHPの簡単ベンチマーク プログラム スクレイピング対象のサイトはこのブログにしました。あざといですね。タイトルのリストを出力するプログラムです。 Simple HTML DOM Parser <?php require_once './vendor/autoload.php'; require_once './profiler.php'; $html =
AngularJSのスゴさが伝わるデモ
当サイトの趣旨 AngularJS のキモは動的なデータバインディングにあり、データを変えたら View が動的に変わるということです。これをクライアントサイドのみでのデモで実感するのは難しい ところがあります。そこで当サイトではサーバーサイドとの通信をまじえた実用的な AngularJS のデモを構築しました ソースコードなどを見たりしつつ、あそんでみてください。 (このデモサイトのサンプルコードは AngularJS と node.js で記述されています。) サインアップフォーム 簡単な管理画面風のデモ こちらのコードは github.com/tokuhirom/demo.64p.orgで確認できます こんなデモもいれてよ、みたいな提案があれば p-r で送っていただければホスティングします。 ここを見て! AngularJs のキモは、データをかえるといいかんじに HTML がかき
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Explore DOM Events