r/webdev🔥 51
💬 44
Chrome 148でついに登場！宣言的パーシャルアップデートでWebアプリが劇的に変わる
fiskfisk
1日前
ディスカッション (44件)
0
fiskfiskOP👍 51
1日前
Chrome 148にて、待望の「宣言的パーシャルアップデート（Declarative partial updates）」が実装されました。これにより、ページ全体を再読み込みすることなく、必要なパーツだけを効率的に更新できるようになります。UX向上に直結するこの新機能を、ぜひプロジェクトに取り入れてみてください。
1
yksvaan
👍391日前
またブラウザの互換性問題が増えるのか。たった数行のコードで解決できるようなことなのに。それとも2025年になってもDOMノードの追加方法を知らない人がいるのかな？
2
beephod_zabblebrox
👍41日前
ポイントはコードを使わないことなんだけどね。とはいえ、またGoogleがまともな標準化もなしにクソみたいな仕様を押し付けてきてるのは確かだ。
3
el_diego
👍2約20時間前
フラグ付きのAPI機能がどうして「人々にクソを押し付ける」ことになるんだ？
4
beephod_zabblebrox
約19時間前
だってGoogleはある時点で誰でも使えるようにするだろうし、そうなれば開発者は他のブラウザ向けにポリフィルを使うようになる。すると、ポリフィルではパフォーマンスが出ないから、他のブラウザも実装せざるを得なくなるんだ。
あるいは、同じような経緯で他のすべてのブラウザに入り込んでいくんだろうね。
こういうことは初めてじゃないよ。RFCやW3Cが存在するのには理由があるけれど、Googleはシェアを握っているからそれを無視できちゃうんだよ。
5
el_diego
👍1約16時間前
記事によると
Webプラットフォームへのこれらの追加機能は、他のブラウザベンダーや標準化団体からの肯定的なフィードバックを得て標準化が進められています。関連する標準は、これらの新しいAPIを含める形で更新されるプロセスにあります。
6
beephod_zabblebrox
👍1約16時間前
なるほど、見落としてたみたい。Googleのいつものやり方じゃないといいんだけどね。
7
fiskfisk
👍14約24時間前
ライブラリでよく実装される機能がネイティブで提供されるのは良いことだし、Webを前進させる適切な方法だと思うよ。今はフラグ付きだから公開環境で使うには早すぎるけど、実際に使えるか試したり、一般公開に向けた課題を見極めたりするのにはいい機会だね。Googleはフラグ付きのまま消した機能も過去にあるけど、メインストリームのブラウザでテストできるようにするのは妥当なステップだと思う。
8
krileon
👍5約23時間前
だったらもっと標準化された形で実装すべきだ。あの構文を見て「これでOK」なんて思える人はいないでしょ。新しい要素（例えば<html-stream>とか）にするか、<template>の拡張にすべきだった。これはただの茶番だよ。ブラウザに押し付ける前に、破棄されるか大幅に改善されることを願う。
9
electricity_is_life
👍12約23時間前
これは他のWebプラットフォームの変更と同じように、whatwgで議論されている よ。ちゃんと標準化のプロセスに乗っている。
10
private_birb
👍5約21時間前
記事にもある通り、これらの変更は関連する標準への追加プロセスが進んでいて、他のブラウザベンダーからもポジティブなフィードバックが来ているよ。それに、今のところはポリフィルも用意されているしね。
誰かが実装を極端にサボらない限り、他の機能と比べて「ブラウザ非互換」が問題になるようなことはなさそうだよ。
11
ISDuffy
👍5約21時間前
Firefoxが何ヶ月か前にこれについての動画を出してたな。この機能、ブラウザを横断してポジティブな反応が得られてるみたいだよ。
12
catsupatree
👍101日前
サーバーサイドレンダリングのアプリが、実際に処理を変えることなくクライアントサイドレンダリングのようなUXを実現するための手段に見えるな。手っ取り早い解決策としてはいいかもしれないけど、クライアントサイドレンダリングには「First Contentful Paintを速くするために重い読み込みを後回しにする」以外にも多くのメリットがあるんだよ。
13
electricity_is_life
👍51日前
両方を組み合わせる理由はないよ。例えばSvelteKitは一部のデータを非同期で取得してHTMLに追記できるけど、それはJavaScriptが正しく起動した場合に限る。このAPIを使えば、そのプロセスを完全にHTMLだけで完結させられる可能性があるんだ。もちろん計画通りにいけば、最終的にはJSが走ってページがクライアントレンダリングにアップグレードされるけどね。https://svelte.dev/docs/kit/load#Streaming-with-promises
14
krileon
1日前
Safariで動かない3つのAPIを使ったり、山のようなポリフィルと格闘したりするくらいなら、自分はHTMXでいくよ。あと5年くらい経ったら乗り換えを検討するかもしれない。
15
electricity_is_life
👍21日前
HTMXには、こういう順序不同のストリーミングを処理する組み込み機能ってあったっけ？
16
krileon
1日前
この機能の主な用途は、テンプレートソースからHTMLコンテンツをストリーミングすることだね。俺ならHTMXを使ってエンドポイントから直接ストリーミングするよ。同じことだし。
17
electricity_is_life
👍21日前
「エンドポイントから直接ストリーミングする」ってどういう意味？この機能の肝は、サーバーが同じレスポンスの中で後からHTMLを順次返せるってことだろ。別途エンドポイントやSSEを用意する必要なんてないんだよ。
18
krileon
約24時間前
「同じレスポンスの中で後からHTMLを返す」って、それSSEかロングポーリングを使っている場合だけだよね。それ以外ならfetchとか他の方法でパッチを当てる必要がある。それらを使わずに同じレスポンスでやるのは、divの描画を遅延させるメリットでもない限りほぼ無意味だよ。どっちもHTMXならブラウザ依存なしで、しかもこんなイカれた構文を使わずにずっと前からできていることだしね。こんな代物じゃなくて、<template>の挙動を拡張すればよかったんだ。本当、XSLの時代に逆戻りだね。
19
electricity_is_life
👍3約23時間前
これはSSEやロングポーリング、fetchとは全く別の話だよ。サーバーがチャンク転送エンコーディングを使って、同じレスポンスの一部としてHTMLをさらに送信している だけなんだ。メリットとしては、生成に時間がかかる要素（常に同じシェル、データベースから取得するメイン記事、別のバックエンドから取得する関連リンクなど）があるページで、準備ができたものから順次サーバーが送信して、ブラウザ側が遅い部分を待たずにレンダリングを開始できる点だね。
「ブラウザ固有」という点を気にする理由がよく分からないな。もし代わりの手段として自分でJSを書くつもりなら、それはポリフィルとどう違うの？ブラウザの普及を待つならそれはそれでアリだけど、HTMXにはこの機能が存在しないみたいだし、比較している理由がよく理解できないよ。HTMXと併用することだって何の問題もないはずだし。
20
krileon
約23時間前
チャンクレスポンスを使っているのは分かってるよ。でも、SSEがあるのにわざわざそれを使う奴なんていないだろ。チャンクレスポンスには接続が切れた時の再接続機能なんて一切ないんだから。唯一のメリットはイベントに名前を付けなくていいってことくらいだ。
「ブラウザ固有」という点を気にする理由がよく分からないな。もし代わりの手段として自分でJSを書くつもりなら、それはポリフィルとどう違うの？（以下略）
なぜかって、構文があまりにひどいからさ。Googleがまたいつものように、自社のサイトの超ニッチなニーズを満たすためだけに、デタラメな仕様をブラウザに押し付けようとしているようにしか見えない。具体的には、この機能はくだらないAIのレスポンスのために開発されたものだ。君にとってはそれがどうでもいいことかもしれない。それはそれでいい。でも俺にとっては大事なことなんだ。
21
electricity_is_life
👍2約23時間前
「わざわざそれを使う奴なんていない」っていうのは事実じゃないよ。例えばSvelteKitもMarkoも実際に使っているしね。
「Googleが自社のニーズのために強引に押し付けている」という点については、WHATWGで数ヶ月にわたって行われている詳細な議論を見ても、Google以外の参加者から多くの意見が寄せられているわけで、その主張を裏付ける根拠は特にないと思うよ。
22
yksvaan
👍1約16時間前
標準機能ではないけど、実装は簡単だよ。<head>内にスクリプトを置いて、参照先のHTMLブロックを取得して指定位置に挿入し、htmxのイベントリスナーを登録すればいい。その関数を呼び出すHTMLをストリームで流し込めばOK。初期レスポンスでも使えるし、Ajaxならチャンクを受け取るたびに同じことをするだけだよ。
23
electricity_is_life
👍1約16時間前
それってHTMXとはあんまり関係ない話じゃないかな？JavaScriptでポリフィルを書くのはもちろん可能だし、記事内でも紹介されてたと思うよ。
24
bzbub2
👍5約24時間前
5年後に良くなっているなら、そこまで悪い話でもないでしょ。
25
krileon
約23時間前
構文がここまでひどいものじゃなければ同意できたんだけどな。
26
philo23
👍51日前
Webには間違いなくこういう機能が必要だけど、このシンタックスはどうしても好きになれないな…。なぜわざわざ既存のHTMLタグの形を完全に破壊する必要があるの？<placeholder name="something"></placeholder>みたいな伝統的なやり方で何が悪いんだ？フォールバックなしならこれだし、placeholderの内容を入れたいなら<placeholder name="example">一時的なコンテンツ</placeholder>でいいじゃん。<?marker>とか<?start>/<?end>なんて使うと、非対応ブラウザでのフォールバックとかポリフィルがめちゃくちゃ面倒になりそう。Chromeがまたいつものように独走しているとしか思えないね。
27
electricity_is_life
👍51日前
この機能に非対応のブラウザで<marker>が要素としてレンダリングされるのを避けるために、あえてこういう書き方にしてるんじゃないかな。確かな理由はわからないけど、それが実装上の主な理由に思える。
28
tajetaje
👍2約24時間前
ポリフィルってすでにあるんじゃないの？
29
ramones13
👍10約23時間前
幸いなことに、こうした決定の経緯はしっかりドキュメント化されていて、すべてのブラウザベンダー間で行われた議論をここで読めるよ - https://github.com/whatwg/html/issues/11542 （関連するリンク先も併せてチェックしてみて）。MozillaとAppleも、この件に関してかなり突っ込んだ意見を出しているね。
30
philo23
👍3約22時間前
なるほど、あれを一通り読んでみたら少し納得できたかも。構文の見た目は相変わらず好きじゃないけど、理由は理解したよ。
構文的にボイド要素にできない理由は、テーブル等との奇妙な干渉というよりは、後方互換性やポリフィルが実質的に不可能だからという点が大きい。個人的にはこれがかなり大きな論点だと思ってる。
31
mgr86
👍1約21時間前
そもそも処理命令（Processing Instructions）はHTMLを壊すものじゃないよ。もしHTMLをSGMLの派生と考えるなら、SGMLにはもともとそういう形式で処理命令が存在していたわけだしね [0]
32
mgr86
👍41日前
ブラウザからXSLを削除する先頭に立っていた企業が、今さらXML処理命令を採用するなんて興味深いね[0]。[0]まあ、確かCライブラリが放置されてたのが主な理由だったはずだけど。CやRustでモダンなXMLツールがあればいいんだけどな。JVMにはSaxonみたいに素晴らしいXMLツールがあるけど、1万件のドキュメントに対してXPathを走らせたいだけなのに、JVMを立ち上げて起動コストを払うのは嫌なんだよね。XPath 1.0ならCライブラリで爆速で処理できるのに、結局Javaのラッパーを作ってスレッド管理して、JVMを一度だけ起動するように工夫しなきゃいけない。実際、手元にはXMLが溢れてるんだよ。
33
electricity_is_life
👍31日前
これすごくいいね。今までいろんなフレームワークでHTMLストリーミングを使ってきたけど、結局JavaScriptを使って非同期コンテンツを正しい場所に挿入しなきゃいけなくて、いつも不格好だと思ってたんだ。このアプローチならずっとクリーンで読みやすいし、フレームワークをまたいで標準化できそう。
34
tom-smykowski-dev
1日前
これでGoogleはAI OverviewのためにWebサイトをスクレイピングするコストがさらに安くなるんだろうな。
35
fiskfisk
👍2約22時間前
逆だよ。たいていの場合、Googleにとってはコストが高いほうが都合がいいんだ。競合他社を締め出せるからね。
36
tom-smykowski-dev
約20時間前
Googleは独占企業だよ。競合がいないからね。
37
fiskfisk
👍1約20時間前
ある意味そうかもね。LLMは、ここ25年以上で彼らの検索エンジンに対する初めての真の競合だよ。ChatGPTで直接答えを得られるようになったら、人々はGoogleで検索しなくなり、トラフィックが移動しちゃうことに彼らも気づいたんだ。
これが可能になった唯一の理由は、2017年のGoogle発のTransformer論文のおかげで、LLMが安価になり、競合他社が構築できるようになったからだよ。
https://arxiv.org/abs/1706.03762
だから、コストが下がったことこそが、ここ20年でGoogleに対する唯一の脅威だったんだ。もしそうでなければ、Googleのトラフィックを奪うために、これほど巨大なインフラを構築するリスクを冒す奴なんて誰もいなかっただろう。
GoogleはOpenAIがGPT-3/ChatGPTをリリースするずっと前からSBERTを動かしていたけど、非常に低速で多くのハードウェアを必要としたんだよね。
38
tom-smykowski-dev
👍1約19時間前
興味深い。つまり今やコストが安くなったから、みんなこぞってオープンウェブを死ぬほどスクレイピングしに行こうとしてるわけか。
39
CollectionAdorable24
👍241日前
JavaScriptのフットプリント削減にはすごく期待できそうだけど、新しいブラウザAPIの常として、Safariが実装してプロダクションで使えるようになるまで何年待てばいいのかってのが問題だよね。山のようなポリフィルなしで使えるようになるのは……2030年くらいかな？
40
AbdullahMRiad
👍2約18時間前
*Firefox
というか
*Chrome以外のすべて
41
ImportantTree7632
👍1約23時間前
ずっとこういうのを待ってたよ。部分更新のために自分でfetchとDOMの差分更新をせっせと実装するのは、車輪の再発明をしている気分だったからね。複数の更新がバラバラの順番で届いた時の競合解決をどう処理するのかが気になるところ。
42
vk6_
👍1約20時間前
これ、1995年にNetscapeが導入したmultipart/x-mixed-replaceを思い出すな。どちらもサーバー側がドキュメントの以前の部分を置換できるようにするためのものだったし。昔は同じユースケースでx-mixed-replaceが使えたけど、モダンなブラウザはだいぶ前にHTMLとやり取りする機能を削除しちゃったからね。
43
OMGCluck
👍2約20時間前
streamHTMLUnsafe
これが将来的に悪用される未来しか見えないね👍
.epubのようなオフラインHTMLがこれによってどう影響を受けるのかは気になる。