David Bruant wrote:
This M.O. is exacerbated by the reality that most of the folks
writing these specs are C++ hackers, not JS developers. For many,
WebIDL becomes a safety blanket that keeps them from having to ever
think about the operational JS semantics or be confronted with the
mismatches.
Interesting. I wasn't aware of that.
Any idea as to how to improve the state of things? It seems to be much
more a human problem than a WebIDL problem. Even if WebIDL improves,
people will likely still do the copy/paste dance, no?
What Alex describes is inherent in having any IDL language between
native implementations and JS clients. Going through the exercise Alex
advocated earlier for testing API completeness, of implementing using JS
instead of C++, is one way to try to overcome this problem. Boris and
probably others have experience here, since Proxies in ES6 allow
implementation where JS without Proxies was insufficient.
We could get rid of WebIDL and specify interfaces only in JS, but
without enough declarative forms that is too abstraction-leak-prone and
high-overhead. Beating on WebIDL with the JS stick seems like the way to go.
/be
P.S.: Kudos to Alex, Arv, et al. for fighting the good fight!
