I purpose that logic programming is about decoupling how information was added to a system from re-actively taking action on that information. This model is particularly important in traditional browser/front-end applications. The current front end ecosystem structures applications in terms of the DOM, but its also valuable to view But really we need tools that can view the system through either the DOM view or the Action based view. To be concrete: traditional dom view: html when event then html/action/etc... action view action when event then html/action/etc... The key to having both these views is that the system be encoded in such a way that it can read itself and produce multiple views. The closest implementation i have seen to realizing an efficient version of this is https://github.com/oakes/odoyle-rum-todo. Though it doesn't actively try to realize multiple views, the data centric approach gives me how that tools can easily read it to provide this. Here we see the action that effects the footer.

[:what
      [::global ::all-todos all-todos]
      [::global ::showing showing]
      :then
      (let [*session (orum/prop)
            active-todos (remove :done all-todos)
            completed-todos (filter :done all-todos)
            active (count active-todos)
            completed (count completed-todos)
            filter-attrs (fn [filter-kw]
                           {:class (when (= filter-kw showing) "selected")
                            :on-click #(insert! *session ::global {::showing filter-kw})})]
        [:footer#footer
         [:span#todo-count
          [:strong active] " " (case active 1 "item" "items") " left"]
         [:ul#filters
          [:li [:a (filter-attrs :all) "All"]]
          [:li [:a (filter-attrs :active) "Active"]]
          [:li [:a (filter-attrs :completed) "Completed"]]]
         (when (pos? completed)
           [:button#clear-completed {:on-click #(run! (partial retract! *session)
                                                      (map :id completed-todos))}
            "Clear completed"])])]

I'm struggling to see what this has to do with Logic Programming in particular. The "decoupling" you mention is a characteristic of well-written programs in any language, and you're talking about reactive GUIs (React, Vue...), which can be (and are) described using non-Logic languages.

Odoyle rules is an implementation of a rules engine that can run in browsers which could offer more understandable semantics and better performance at the abstraction layer its tackling. It's not a new concept but I believe the novel feature of not disguighishing between rules and queries is an important step for the different viewing options i discuss above. Here is a link from precept another logic on the frontend library that, as you say, explains how logic/rules compete with what react does.

Using a rule engine allows us to know exactly what changes from one state to the next. This means we don't need React's diff algorithm or the concept of subscriptions. If we declare views as the consequences of rules, we can automatically point update them when the facts they care about change.

And richer discussion on reddit https://www.reddit.com/r/Clojure/comments/bqh0z4/virtual_dom_is_pure_overhead/eo4gyuj?utm_source=share&utm_medium=web2x&context=3

So it would seem a RETE network would be one way to achieve this?

But the question i would ask is, if your only concern is what is achievable via programming, then why discuss logic programming at all? Logic programming offers nothing new in terms of end results. What it offers is a mental model and decades of research in algorithms on how to fit problems into it. Given all that, I would still use a none logic based front end framework/library today. Why? because the ecosystem built around them isn't as rich. I'm worried that's because little to no discussion is generated around merging these two fields. The browser application ecosystem is ripe with places where applications of decades old algorithms and models could have huge impacts on peoples lives today. The future of programming is going to read more like math from a decade ago, we don't need to discover it, its already there, we need to apply it.