Hacker News Reader

Comment by olavk | Hacker News Reader

You can be certain the ECMAScript committee is not going to break any of the more popular libraries (like JQuery, Angular etc) either. It just because these libraries were better designed in the first place that it hasn't been an issue.

View on HN

> Zones monkey-patches global asynchronous operations such as setTimeout() and addEventListener(), which is why Angular can easily find out, when to update the DOM.

https://blog.thoughtram.io/angular/2016/02/01/zones-in-angul...

I can imagine Angular zones becoming problematic in exactly this kind of way in a few years...

Monkey-patching is not in itself a problem though since it just overrides the built-in functionality. The problem in shooshgate was (if I understand correctly) specifically monkey-pathing Array and relying on the added property to be enumerable. This meant JavaScript could not introduce a non-enumerable property with the same name without breaking code.

While monkey patching in general is problematic, monkey-patching Array or Object is much worse than monkey-patching Window.

You're right, it's not as bad. But the metaproblem here is making the assumption that the global environment is not going to add new APIs.

In the case of Angular zones, if additional async APIs are added to the browser, Angular needs to be updated to patch them with its own zone implementation.

This wouldn't break existing sites, but could leave, for example, sites on older angular versions unable to use new browser APIs, use libraries that use new browser APIs, or install security updates to dependencies if newer versions rely on new browser APIs.

Reply on news.ycombinator.com