At the last meeting, I expressed some concern I had about Object.observe
based on feedback I got from Kris Selden of the Ember Core team (the
primary maintainer of our binding system and all-around performance guru).
At the meeting, I was under the wrong impression that Kris had attempted to
implement the Ember binding system on top of Google's Object.observe
polyfill. It turns out that his feedback was based on an analysis of the
API, not an actual implementation attempt.
He has since had a conversation with Rafael and has come to the conclusion
that there are no performance blockers in the current API. He is persuaded
that the current API offers enough capabilities so that his initial
performance concerns could be worked around with additional userland
bookkeeping.
Kris and I both still have concerns with the ergonomics of the API, and
believe that the workarounds we arrived at with Raf will end up being
commonly necessary even in basic usage and will necessitate wrapper
libraries to avoid infinite observer loop footguns.
Since API ergonomics can be improved over time, and Google seems eager to
move ahead with the API (and is unpersuaded by our ergonomics objections),
let's continue to move this API forward.
Yehuda Katz
(ph) 718.877.1325
At the last meeting, I expressed some concern I had about Object.observe
based on feedback I got from Kris Selden of the Ember Core team (the
primary maintainer of our binding system and all-around performance guru).
At the meeting, I was under the wrong impression that Kris had attempted to
implement the Ember binding system on top of Google's Object.observe
polyfill. It turns out that his feedback was based on an analysis of the
API, not an actual implementation attempt.
He has since had a conversation with Rafael and has come to the conclusion
that there are no performance blockers in the current API. He is persuaded
that the current API offers enough capabilities so that his initial
performance concerns could be worked around with additional userland
bookkeeping.
Kris and I both still have concerns with the ergonomics of the API, and
believe that the workarounds we arrived at with Raf will end up being
commonly necessary even in basic usage and will necessitate wrapper
libraries to avoid infinite observer loop footguns.
Since API ergonomics can be improved over time, and Google seems eager to
move ahead with the API (and is unpersuaded by our ergonomics objections),
let's continue to move this API forward.
Yehuda Katz
(ph) 718.877.1325
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140527/9c83641d/attachment.html>
At the last meeting, I expressed some concern I had about Object.observe based on feedback I got from Kris Selden of the Ember Core team (the primary maintainer of our binding system and all-around performance guru).
At the meeting, I was under the wrong impression that Kris had attempted to implement the Ember binding system on top of Google's Object.observe polyfill. It turns out that his feedback was based on an analysis of the API, not an actual implementation attempt.
He has since had a conversation with Rafael and has come to the conclusion that there are no performance blockers in the current API. He is persuaded that the current API offers enough capabilities so that his initial performance concerns could be worked around with additional userland bookkeeping.
Kris and I both still have concerns with the ergonomics of the API, and believe that the workarounds we arrived at with Raf will end up being commonly necessary even in basic usage and will necessitate wrapper libraries to avoid infinite observer loop footguns.
Since API ergonomics can be improved over time, and Google seems eager to move ahead with the API (and is unpersuaded by our ergonomics objections), let's continue to move this API forward.
Yehuda Katz (ph) 718.877.1325