@noracodes so the thing is that a javascript literal like :⁠—

{
a: "value",
get b () {},
set b (x) {}
}

—⁠: is actually creating a data structure like

{
[[Prototype]]: %Object.prototype%,
"a": {
[[Configurable]]: true,
[[Enumerable]]: true,
[[Writable]]: true,
[[Value]]: "value",
},
"b": {
[[Configurable]]: true,
[[Enumerable]]: true,
[[Get]]: function () {},
[[Set]]: function (x) {},
}
}

a bit of code like :⁠—

a.b = c.d(e)

—⁠: is actually performing something like

a.[[Set]]("b", (
c.[[Get]]("d", c).[[Call]](c, e)
), a)

the more easily you can translate the javascript syntax into the actual underlying thing it is saying to the javascript runtime, the more flexibility you have in actually doing interesting things in the language. because that underlying thing is what the javascript runtime is actually running! and it’s generally a really flexible and powerful model (if you like the specific mix of functional and object‐oriented paradigms that JS rolls with).

but it takes a lot of time and kind of difficult work to gain that understanding. most people come to javascript bringing their own models of what the syntax is saying (usually simpler ones influenced by whatever other languages they know), and that works pretty well to start, but eventually people hit a wall where they are only writing the parts of javascript which are shared with other languages, and not writing the parts of javascript which are unique to javascript (because they don’t understand the underlying model of javascript to really grok the parts that are unique to javascript). gaining that understanding at that point can be really difficult because then you have a whole history of assumptions to unlearn.

i really wish that people spent more time teaching people what JS code was actually saying earlier, so that the models in people’s heads better matched the model actually being used by the runtime and in the specification.