- From: Robin Berjon <robin@w3.org>
- Date: Mon, 22 Sep 2014 17:02:15 +0200
- To: Anne van Kesteren <annevk@annevk.nl>
- CC: Karl Dubost <kdubost@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, "L. David Baron" <dbaron@mozilla.com>, www-archive <www-archive@w3.org>
On 22/09/2014 16:31 , Anne van Kesteren wrote: > On Mon, Sep 22, 2014 at 4:25 PM, Robin Berjon <robin@w3.org> wrote: >> On 22/09/2014 16:15 , Anne van Kesteren wrote: >>> Although DOM and XMLHttpRequest have a two-way dependency with >>> HTML, effectively making them just another page that happens to be >>> maintained by someone else. >> >> I don't think that two-way dependencies are an issue. It's actually a fairly >> expected feature of systems of any complexity. > > Ask the Blink team. A two-way dependency between modules makes it > effectively the same module as you cannot update one without the > other. > > Think about it, if you imported Fetch as a module. Would you want that > to drag in XML, HTML, and DOM as well? At that point you failed to > modularize. And the answer is, of course, "it depends". If you're talking about library-like modularity then sure enough it's a problem. For instance if there were a Node library that did fetch "like a browser" I'd really want to use it, and I'd be happier if it didn't also load up a complete implementation of HTML. But if you're talking about editorial modularity then I reckon you can live with well-defined interlinking points. Also, I am somewhat reluctant to bandy about words like "refactoring" but cutting things up into smaller pieces can help with the former. Having "HTML <-> Fetch" isn't the same as "img -> Fetch -> FormData" (making this up, but you get the idea). -- Robin Berjon - http://berjon.com/ - @robinberjon
Received on Monday, 22 September 2014 15:02:28 UTC