On Fri, Aug 15, 2014 at 2:43 PM, Ian Hickson <i...@hixie.ch> wrote: > On Fri, 15 Aug 2014, John Barton wrote: > > On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson <i...@hixie.ch> wrote: > > > On Thu, 14 Aug 2014, John Barton wrote: > > > > > > > > But since the only way the client can know that it needs a.js and > > > > jquery.js is if the server tells it [...] > > > > > > There's at least four ways this can happen: > > > > > > - the server tells the browser that it needs file a.js when the > server is > > > sending index.html, then tells the browser that it needs query.js > when > > > it is sending a.js, and the server doesn't preemptively send > anything. > > > > > > - the server sends the browser all three files at once, preemptively. > > > > > > - the server tells the browser that it needs file a.js when sending > > > index.html, then when a.js is requested, it preemptively sends > > > jquery.js at the same time as telling the browser that it'l need it. > > > > > > - the server tells the browser that it needs files a.js and jquery.js > at > > > the same time as when it is sending index.html, and the server > doesn't > > > preemptively send anything. > > > > > > The first is too slow, since it requires one RTT per file. It's what we > > > have now, and what ES6 modules describe in the absence of server > support. > > > > > > The second is too slow, because it implies sending resources that > aren't > > > needed, possibly using up bandwidth that could be used for other > purposes. > > > It's something that can be supported by packaging and other solutions > > > already being developed, if people want it. > > > > The second method is faster than your method. It results in the same > > three file transfer in one less round trip. > > > > The second method does not imply sending any more or less resources than > > any other method listed. > > The second is too slow because there's lots of other files involved in > practice, for example the default style sheet, the scripts that are needed > straight away, the Web components that are needed straight away, all the > default images, etc. The whole point of the discussion in this thread is > that we're talking about files that are not needed straight away, and how > to obtain them promptly once they are needed. >
Loading all of the files in a web page in the order they are needed is great goal and one that I think would make a great improvement in the Web. It is certainly true that data for pages is "chunky": we need a mechanism for loading a group of related files at the right time. Within each chunk we need all of the files if we need the root of the chunk. But that is exactly the ES6 case: if we need the root of the dependency tree, then we need all of the tree, that is the declarative design. Having a design where the browser gets all the names, sends all the names back to the server, and gets the tree is just wasting a trip. Simply send the tree when the browser asks for the tree. That's why in my opinion 'bundles' or 'packages' make sense: they combine the related dependencies and allow them to be loaded in one trip. Divide this problem in to small pieces: ES6 bundles, HTML Imports, and some bundle/package loading solution. Don't use the same fine-grained solution for all layers. > > > > > The second and third require server-side support beyond what many > > > authors will be able to do. HTTP2 can provide this if people want it, > > > I believe. > > > > > > The fourth is what I'm looking at. > > > > > > The fourth consists of the server having no built-in knowledge except > > > what is in-band in the HTML file, namely, predeclared dependency > > > trees. > > > > By humans writing markup? That's not happening, at least not for more > > than trivial programs. > > It turns out that on the Web, there are lots of "trivial" programs. When > you have trillions of Web pages, even the smallest of fractions ends up > being significant numbers of pages. > Such programs don't need the kind of features we are discussing. > > > > No one is going to write hundreds of lines of dependency declaration > > already specified in their JS files. > > Maybe not hundreds, but maybe dozens. Also, not all these dependencies are > written in their JS files. Also, it turns out that people will do lots of > things to make their pages quicker, and it's a lot easier, in many cases, > to adjust their markup than to adjust their server configuration. > But the JS ones are written in JS files. And the non-JS ones are written somewhere. Inventing a mechanism that causes devs to duplicate all of this info is crazy. Just to be clear: I think dependency loading web pages is an awesome direction. Using a duplicate declarative solution? Not so much. > > > > And if you allow a tool running on the server (eg a build) then its the > > same as bundling with an extra unnecessary round trip. > > The tool is likely to not be running on the server, but on the developent > machine. It's unfortunate, and I don't really understand it, but it's a > fact of life on the Web that many authors have only minimal control over > their servers. > Many is now most. This what success looks like: browser page devs no longer work on servers. We have to design for this case. > > ... > > > > You can specify dependencies in `instantiate()` returns. > > That is not "before the load"; q.v. the subject line of this e-mail. > The list is known before the load and it is placed into the ES6 dependency system by returning an object from `instantiate()`; this is the way that bundling works as far as I understand it. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
