These make stack traces a pain in the ass to debug. This kind of magic is great for prototyping, but I'm very unconvinced it has a general purpose role in maintainable code.

You're quite correct. My team just inherited a large node codebase that had proxy sprinkled everywhere, complete with a custom undocumented dsl written using proxies. It was a nightmare to learn, hard to extend without breaking and resulted in quite a few refactoring sessions.

I think proxies have their place, but most apps don't need them imo

I've been using Immer which relies on proxies to give you a plain object interface but also copy on write immutability.

It's very nice and I think is a practical example of when proxies make sense. However it does at times suffer from the cost of doing magic: you handle them in unusual ways and suddenly they break a lot.

Yea, you’re right, I can see that working in the right context. These ARE essentially DSLs, though, so their success largely depends on hard to define things like documentation, coupling, and quarantining to expected places.

Absolutely!

I wouldn't exactly call Proxies metaprogramming. It's not wrong but it's just not the best example of what metaprogramming is.

If I understood correctly, The Reflection part of the Metaprogramming can be broken further into multiple parts like, - Introspection: Code is able to inspect itself - Self-Modification - Intercession: Acting behalf of somebody else

To me, Proxy is more into the category of 'Intercession', isn't it?

Proxies trace back their origin in mirrors/mirages in metaprogramming for OO languages. (shoutout to AmbientTalk) It's a very Smalltalk way of doing reflection and intersection.

Do you mean that it lacks syntactic abstractions to be called metaprogramming?

The author mentioned that metaprogramming is treating "code as data" which Proxies themselves don't really do.

Awesome Discussions, Learned from it, Thanks!

Looks like PHP magic methods for JavaScript.