Trucchi: Twirl: $someDOMNode.find’h2′ would get all elements of type h2 taht are descended from the node. If you want children, you can use $node.children’h2′ though

Benisek: Gajus: I mean, with ES6 modules, not with what WebPack/Babel implement because those aren’t ES6 modules

Stigler: What platform natively supports ES6 modules? so I could test.

Trucchi: There are polyfills for it that let you use System.import to do runtime imports tho

Lamendola: Trucchi: well its element a h2 so might as well use find?

Trucchi: But any actual use of ‘import foo’ is ****yzed statically that’s what ES6 modules do

Rosemore: Yeah. Dekok, I would be very surprised if that did not work.

Laduc: I would be very suprised if it did, since it basically defeats the whole purpose of ES6 modules :/

Biccum: But I suppose they might have tried to strike a balance. Still very odd.

Neyman: Well, that would literally break people expectations about how JavaScript works if id didn’t

Trucchi: Lodash also has sub-modules for most/all of its methods

Trucchi: Gajus: ES6 modules are second-cl***

Zingler: Gajus: all semantics of ES6 modules already do that :

Trucchi: That means no runtime evaluation

Trucchi: Unless you use System.import, which will do an import asynchronously and return a promise that resolves to your expected import

Tunick: The problem is that, if you get an object from import * as x from y, you can’t have any of the benefits from ES6 modules by using x.

Garrido: But also, if you can p*** x around, you can’t track that without evaluating anyway, so there’s that

Sermon: Trucchi: we’ve been over this lol

Mcgrant: They’ve been complaining about modules for an hour

Trucchi: Anyway, there’s be no way to dynamically only get one export from a file without downloading the whole thing to the browser unless you had some kind of backend runtime that bundles on the fly before sending your imports

Trucchi: Which is part of why it’s statically ****yzed to begin with

Herkstroeter: The result of an import isn’t an object?

Trucchi: It is, but it has to be downloaded and p****d first

Cusenza: Trucchi: wait. if it is an object then it be used dynamically, i.e., ajaxMethodToGetRandomLodashFunctionNamename = { _name; };

Varnell: And then dead code elimination is not possible

Trucchi: Right, but it isn’t an object until it’s actually hit the browser. which means the AJAX call has to get all the code in the module, and its dependencies, before it can resolve everything

Wise: Tcsc: it would be an object only if you use the import _ as _ syntax. Local bindings are just links to the names in the other module, no objects there

Trucchi: THEN it could only give you what you need and garbage collect the rest

Trucchi: But that isn’t really dead code elimination

Pingleton: It is DCE, just not done before shipping.

Portillo: You can always compile your things and do DCE there

Arrez: I am talking about backend process of bundling code, though. My argument is that dead code elimination is only possible when explicitly importing specific properties. Dead code elimination is not possible when importing the entire module.

Trucchi: Oh. Well if you bundle, you can’t have any of it be dynamic anyway

Fredieu: Unless of course _Math.random is not possible in ES6 browser.

Mathai: Gajus: unless the projections can be inferred statically from the code, and your object doesn’t leak, yes, it’s not possible.

Trucchi: It has to be statically ****yzed, since the server doesn’t know what the code’s going to do when it runs what kind of data it’ll have, etc when it bundles

Trucchi: So yeah, dead code elimination is essentially based on looking at module imports and variable references, but even then it can only go so far because it can’t account for someObjsomeVar