Popular posts

No. You actually got this all wrong. The "Shadow DOM" is part of the DOM that doesn't show up if you use "inspect element" in the dev-tools.

Which is a STUPID concept since if you wrote it to the DOM why the blazes doesn't it exist, and why would you want it not to?

NOT that the pages I've read about it ACTUALLY show making changes to the DOM, or if they do the method I understood was the best way of doing it is the one they're saying not to use, while the method they are promoting (innerHTML) is the dumbass one I thought we were supposed to STOP using a decade and a half ago!

The concept of a "Virtual DOM" is something completely different. The Virtual DOM is used to make updates to the DOM without affecting the "real" DOM until you are ready to write to the screen. When you are ready, you diff the virtual DOM with the real DOM and update all the needed DOM-nodes in one go.

Which is an equally ignorant BS concept based around NOT actually accessing/working with the DOM, since changes are deferred until AFTER scripting execution ends anyways if you bother using the DOM correctly -- and the renderer certainly isn't triggered.

The ONLY way that the 'virtual DOM' BULLSHIT could do what they describe is by NOT using the DOM and instead going full Pakled with innerHTML.... which is why most every damned example of it uses innerHTML...

That again I thought we were supposed to stop using a decade and a half ago OR MORE in favor of createElement and createTextNode.

Which if you use them and do so properly, makes the "shadow DOM" nonsense completely meaningless and the "Virtual DOM" a pointless halfwitted waste of memory and code!

But in Shadow DOM's case there's this noodle-doodle bizzaroland BS about how doing this:

var host = document.querySelector('button');
while (host.firstChild) host.removeChild(host.firstChild);
host.appendChild(document.createTextNode('こんにちは、影の世界!'));

Results in some sort of unnamed side-effects or undesired behavior that nobody can quite explain. It's not like it immediately renders -- it's not like unless you're doing full pakled stepping through the execution line-by-line what it does in the inspector matters, and it's not like this:

var host = document.querySelector('button');
var root = host.createShadowRoot();
root.textContent = 'こんにちは、影の世界!';

Does ANYTHING useful other than break backwards compatibility and make it HARDER to maintain since what's on the visible DOM no longer matches the bloody render! HOW is that useful, much less why the blue blazes would you even want that?

I don't see the real world usage case for where you would even WANT the one behavior it provides -- showing something OTHER than the actual content as written. Doesn't that just take something simple and make it more confusing, harder to work with, and harder to debug?

What's the benefit? Where's the payoff?

Virtual DOM is totally different from shadow DOM. And yes sometimes you may want to have an element in a page that is hidden from the outside. This is so that you hide your implementations in the shadow DOM so other styles and scripts can't reach to it. That's the sole purpose.

Also not a BS terminology by the way :)

You are still misunderstanding Shadow DOM. It's not an abstraction... The Shadow DOM is things like the default controls on a <video>-tag, the slider that appears when you give an <input>-tag the type of "range". Things that doesn't show up in the DOM that you are able to manipulate. There is (was?) no way to style the default knob of the default slider in a ranged input until recently. The solution is (was?) to hide the default slider, and build your own with your own components.

And you are still mixing up virtual DOM and shadow DOM, it has nothing to do with each other...

Christian Wattengård I'm not mixing them up, I'm saying they're the same type of silliness and stem from the same mentality.

... and really if we wanted to style those things what was wrong with just hiding the element and using an aliased DOM element that's semantically neutral (like DIV and SPAN)? You know, like how scriptless modals and scriptless hamburger menus work? (or at least should work?)

It just feels like extra code, confusing/pointless methodology, and convoluted thinking all to address a non-issue.

Hence my comparison. I'm not saying they're the same thing, I'm saying they stem from the same lack of thought. You know, the literary concept of a simile?

and before someone in the peanut gallery chimes in, I did not just misspell smilie.

A select box is built as shadowdom, videoplayers are built as shadowdom. Your comparison seams a bit beside the point about shadowdom it's basically a grouping mechanism that allows you to restrict the access to the inner parts.

You can ofc do without, but your reasoning seam to sidetrack a bit. Shadowdom is just a basic tool that can be really useful.

@cutcodedown Be honest, you just like to sanctimoniously belittle things. Shadow DOM is straight up part of web standards, one of the constituent technologies for Web Components. You're always griping about people not knowing and using pure JavaScript, HTML, and CSS, but here you are demeaning that very practice.