Re: [w3c/webcomponents] Cleaning up (undefining) custom elements? (#754)

> I think that would imply in turn that new OriginalConstructor would need to throw.

That's a given; there totally needs to be behavior like that.

This downgrade process may be complicated, but ability to clean up memory usage is a critical part of designing any API that creates memory usage.

Even if we (any one of us) haven't seen a use case where memory growth from defining new elements is a specific problem, just the act of designing any re-usable and repetitive API with irreversible memory growth is simply bad practice that should be avoided.

"Downgrading" elements has intricacies to think about, but it's probably something important to think about for the longevity of web-tech beyond simple short-running applications.

<details>
<summary>Hypothetical Scenario 1, Users with many windows and tabs:</summary>

Imagine everyone drops React/Angular/Vue for plain Web Components. Now imagine a user that has 30 Chrome windows open, with let's say an average of 10 tabs per window (I've seen worse than this in practice).

Now imagine that after loading custom elements in many tabs, and switching routes (etc), on average each web app in every tab uses 300 custom elements over the app life time, and on average only needs 20 custom elements at any moment.

Without disposing any custom elements, and with current state of APIs (no cleanup of definitions), this means we'll load 90,000 Custom Element definitions.

Now, if there was a way to clean things up, this number would be reduced to 6,000 loaded at any point. That's a lot better, and could improve user experience when switching tabs often, especially on mobile devices.

</details>

<details>
<summary>Hypothetical Scenario 2: Web-based OS</summary>

A web-based OS that loads "micro apps" by loading Custom Elements in a shared DOM (not the best idea, but still). Over time, memory growth from using many apps will grow and never shrink.

</details>

<details>
<summary>Hypothetical Scenario 3: low-power low-cost embedded devices</summary>

We need to squeeze things into small amounts of memory. Easy to imagine problems here...

</details>

<details>
<summary>Hypothetical Scenario 4: Long running game</summary>

Like Half-life, this game might be an infinite world game, and we'd need to unload the components as we leave various areas of the game. All the cool kids like efficient game engines and micro-optimizations that eventually add up.

</details>

<details>
<summary>Hypothetical Scenario 5: Testing</summary>

It is simple to write tests without having to make new elements names for every test.

</details>

<details>
<summary>Hypothetical Scenario 6: Live code editors</summary>

Replacing elements with new implementation on code changes. If we do something like add an incrementing number to the end of an element name, then the user CSS won't work unless you painstakingly write a system for that too, because selectors with tag names will break. And then it won't be "just CSS" anymore.

</details>

<details>
<summary>Hypothetical Scenario 7: Live code pushes/patches or HMR</summary>

Imagine an in-app purchase system upgrades some objects with 3rd-party extensions from an extension store. The objects reload (maybe they are covered with a loading icon for aesthetics), and now the objects have the new features.

</details>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/754#issuecomment-562372933