- From: Hawk Ticehurst <notifications@github.com>
- Date: Sun, 31 Dec 2023 03:19:13 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1035/1872924099@github.com>
> How do those dynamic updates occur, though? That's the point of contention here. For JS based frameworks this question is answered; you use the same library to do the updates as you use for the HTML rendering. For non-JS frameworks there is no answer, and I would say cannot be answered, because making this a feature of HTML means that you have to use the same tech on server and client (or duplicate work, which no one will do). Was casually reading through this thread and got to the end and I really like this last question you posed @matthewp –– made a lot of things click for me. With that said, I'm genuinely curious if I've misunderstood something: I thought there _is_ an answer for a lot (if not all???) of these non-JS frameworks, and the answer is the same as JS frameworks –– you also just use the same library to do the updates because under the hood all non-JS frameworks _do_ have to use some amount of JavaScript at the end of the day. Based on my understanding of the frameworks you've mentioned –– especially the ones that use a strategy of "RPC + DOM diffing" such as Phoenix LiveView, Laravel Livewire, and Ruby Hotwire –– the vast majority of "work" in these frameworks does indeed happen on the server, but once newly generated HTML is sent back to the client there is _always_ some amount of runtime JavaScript present to mutate the DOM so the new changes are replaced with the old changes. I've always understood these frameworks to effectively be a tool that abstracts away the need for developers to directly handle dynamic updates in JavaScript and instead author dynamic websites in *{insert flavor of backend}*, but that doesn't mean JavaScript is somehow removed from the equation –– it's just hidden from the framework user. If the focus of DOM Parts (at this point) is strictly a way to mark specific DOM nodes/attributes that will be changed, couldn't these frameworks also benefit from this API to make it easier to easily mark/access the node(s) that need to be changed/replaced and then make said change(s) using whatever method/implementation makes most sense for them? Again I feel like I'm missing something though, so would love any clarification :) Also here are references to the runtime JS in the above-mentioned frameworks for the curious: - https://github.com/phoenixframework/phoenix_live_view/tree/main/assets/js/phoenix_live_view - https://github.com/livewire/livewire/tree/main/js - https://github.com/hotwired/turbo/tree/main/src/core -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1035#issuecomment-1872924099 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1035/1872924099@github.com>
Received on Sunday, 31 December 2023 11:19:20 UTC