Either way this discussion is stupid as updating the DOM is stupid simple even without a framework. The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic.
> The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic.
One of the bizarre realities with those forced to write their own "virtual DOM" library, as I have done, is to deal with all the so-called hidden state. Form field values, the user's current text selection, scrolling position. Without a virtual DOM, simply replacing existing nodes with innerHTML or replaceChild will stomp this away. I'm not of the opinion that you need a full framework to handle this state (I wrote my own 10-line helper function which works in most cases I care about [0]), but you do need something more structured than just replacing nodes wholesale.
It seems you wrote this article; have you read it back? You bury the lede under 1230 words explaining some social concepts rather than anything programming-related.
Additionally, you use many complex words to describe simple subjects. And you do this knowingly: for example, you felt the need to link the definition of "acquiescence" to the word. If you felt that it was complex enough that this was warranted, why not instead rewrite the surrounding content?
If the purpose of this article is to convince people that disagree with your statements, you have certainly lost those people by the end of the article.
I don't even disagree with you; the DOM is great and WASM is definitely just another option and not a replacement for JS.
Finally, I have to note: there aren't any citations for your claims in the programming section. One might otherwise wonder where you get an idea like
> That DOM mechanism will allow a WASM application to execute DOM methods without having to provide its own DOM application, but it will be limited to markup within the WASM application.
when I haven't been able to find anything indicating this elsewhere on the web.
A wiser man than me once said its hard to have rational conversations on this matter because delusional people more invested in their opinions than they are in the work they perform.
> If the purpose of this article is to convince people that disagree with your statements
You missed the point. It isn't about disagreement. Its about not throwing away evidence to retain a challenged opinion. The first two thirds of the article was very explicit about this.
> when I haven't been able to find anything indicating this elsewhere on the web.
Then you didn't search very hard. The article specifically mentioned this is in relation to the web assembly host bindings proposal. The first search on any search engine brings me to the spec on github. As far as DOM work you would have to dive into the DOM string portion of JS API integration section: https://github.com/WebAssembly/webidl-bindings/blob/master/p...
If you are confused as to what the article says then submit a pull request with a superior recommendation. It is on github after all.
> You missed the point. [explanation of the point]
If it's that simple, could you consider replacing the first 1k words with this instead? I'm entirely serious.
> Then you didn't search very hard.
Okay, I'll bite. I searched for the phrase "host bindings extension to WASM" (the literal phrase included in your treatise) on DuckDuckGo, which brings me to https://duckduckgo.com/?q=host+bindings+extension+to+WASM&ia.... The first result is https://github.com/WebAssembly/webidl-bindings/blob/master/p..., a 404. If you want someone to find something so badly, link it instead of making claims about how much effort they might have put in. The onus is on you to prove the claims you make, and I wish this were something you took the time to link instead of the definition of "acquiescence".
> As far as DOM work you would have to dive into the DOM string portion of JS API integration section: https://[...]
You don't make clear which part I'm supposed to be looking at, and I don't explicitly see it stated that DOMString will be the only way WASM can interact with the DOM; there's just an example of how a WASM function might take a DOMString and return a DOMString, and how the binding machinery works in that case.
Additionally, after some additional searching, I found https://github.com/WebAssembly/function-references/blob/mast... including "Easier and more efficient exchange of function references between modules and with host environment" and information about closures. I'm not certain about it, but doesn't this run counter to your point about code running against `window.document`? After all, you could (if I'm reading this correctly?) pass in a bunch of closures that directly manipulate `window.document` through something like this.
> If you are confused as to what the article says then submit a pull request with a superior recommendation.
If I don't understand the article (you've just told me I don't), how do I help you make it better?
One does wonder what the point is of trying to communicate something, if the speaker does not care about whether the listener understands their message...
This can be seen in scientific papers as well as in some books.
It is based on the literacy of the powerful that we know from the dark ages. To use complex language as a substitute for easier formulations is a tool for literate people to prevent lesser educated people from understanding their texts.
This article claims Web Components could replace frontend frameworks. React is a component library often used in a frontend framework.
React wraps the DOM with a Virtual DOM that provides a declarative abstraction for stateless updates. That is, you can write a plain function - given data X, produce DOM state Y - and React works out all the DOM calls required to arrive at the desired DOM tree from the current actual DOM tree.
So, with React, a developer does not need to make granular element-by-element, attribute-by-attribute changes. Many developers have found that leaving this diff / patch work up to the computer is easier than working out all the DOM calls themselves. Even more so than the concept of components, this has enabled architectures that many developers find pleasing.
Now, you can call that stupid or delusional if you like, but at least understand what's being referenced here.
I would argue that for what the OP was discussing `textContent` (From the linked example) is very much like `innerHTML` (As it’s a safer version of the former). I’m not sure what you mean by the DOM being neither stateful or stateless, or describing an implementation of logic. Could you clarify?
The DOM is a model of a markup language instance plus access methods. State describes memory of properties resulting from a change. For example HTTP is stateless.
The DOM can be both stateful and stateless, neither, or one of. The statefulness depends on your application logic rather than any intrinsic quality of the DOM itself.
Any stateful data structure is stateless if it’s not changed. That doesn’t seem to me to be a particularly deep revelation about the DOM.
Back to your original point, that code example you linked attatches a shadow dom, creates an element in it and then puts text in it. I fail to see how that’s declarative or stateless, and AFAIK that’s the only way to populate a shadow DOM (the original HTML of the document cannot put elements there).
Also I would say that the statement "The DOM is extremely challenging and working to the DOM destroys architecture" is a straw-man here, or at least a red herring.
The DOM is not all that challenging. It can be a tedious API, though. React shifts much of the effort to manage element and attribute changes to an algorithm, thus relieving tedium. Many folks find managing the DOM through a functional paradigm to be an enjoyable & productive approach to working with client side web apps.
What does that mean? The methods provided by the web components spec appear declarative as do the methods provided by the DOM spec. Declarative example with nothing like innerHTML: https://developer.mozilla.org/en-US/docs/Web/API/Element/att...
Either way this discussion is stupid as updating the DOM is stupid simple even without a framework. The DOM is neither stateful or stateless, but rather that describes the implementation of your application logic.
* DOM - https://prettydiff.com/2/guide/unrelated_dom.xhtml
* state - https://en.m.wikipedia.org/wiki/State_(computer_science)
* stupid - https://github.com/prettydiff/wisdom/blob/master/Delusional_...