Is it misuse though? A common pattern is to switch between tabs and accordion for the same content depending on viewport size. Using different elements doesn’t work well for that.

How does what I said cause what you said?

What should we protect ourselves *against*? What is the danger?

I was talking about JS!

You’re not wrong! Try/catch is the (I believe) one exception (no pun intended 😁) where there is actual value in doing that.

Unfortunately, none of these very insistent AI suggestions were in a try/catch block…

I write a lot of code that is meant to be used in third-party environments or codebases I don't control — Symbols ensure no clashes.

They’re also a way to keep data hidden in plain sight — private enough that it won't be accessed accidentally, but still accessible if you really need to.

“But aren’t proxies super slow?”

Nah. Depending on the browser it ranges from 50% slower to exactly the same.
Which unless you’re creating millions of symbols, is inconsequential.

jsbenchmark.com#eyJjYXNlcyI6...

(Yes, I know that for this particular use case you can have a regular constructor return a Proxy)

Turns out the type of side effect may play a role, e.g. a side effect that is more comparable to the function body shows completely different story (by @codemix.com): jsbenchmark.com#eyJjYXNlcyI6...

Doesn't explain why the console.log() example is *consistently* faster w/ proxies though.

Yes, in all Safari the proxy is slower, though not tremendously so in desktop:

Thanks! Does the existing subclass factory pattern not work well for this? (I have my own reasons against it, but I'd love to hear yours)

Chrome seems to support a surprising variety of languages, but for some non-English languages (e.g. Greek) confidence seems to always be 0%.

Firefox claims to support it with an about:config flag (media.webspeech.recognition.enable), but all I get is "Error connecting to the service.". Is it like that for everyone else too?