Agnew: Dekok, an AST should be ****yze that, though. like https://github.com/Runels/node-detective

Berlandy: When es6 modules come along, how is it fetching / actually getting the modules

Pegram: Without the shims / requires, how is it going to do it when it is native

Workinger: What’s the difference b/w chrome dev tools device emulation and just resizing the browser window?

Skarke: Pastry: should the interpreter load just ‘blah’? Just ‘bleh’? Both?

Mendosa: Pastry: node-detective doesn’t know, so Browserify includes both. That’s clearly suboptimal

Workinger: Is it the same? my site breaks responsively when making window size small

Workinger: But not in device emulation

Kment: Is mod in mathematics the same as % in JavaScript et al

Monden: Dekok, it’s the engine that should decide in fact

Miyose: Well, the import has the file path like require does. i ***ume the es6 browser would fetch the file when imported

Kelsheimer: When using stuff like webpack, you do both or you use code splitting

Turneer: Renlo: implemented natively, it’ll probably have an internal way of fetching the modules. It does allow separate compilation and dynamic linking, though, which CommonJS doesn’t.

Vanvoorhis: In browsers you use heuristics

Sheffield: What do you mean by ‘separate compilation’ ? like ‘preprocessing’ / ‘transpiling’ it?

Knerr: Pastry: that’s not what I said. What I said is that it’s not possible to *STATICALLY* ****yse that and figure out which one you should load at runtime. Static ****ysis requires you to be able to get all of the information without executing anything in the code

Kottwitz: I know at the end of the day its just compilation, just want clarification

Schnobrich: ES6 has been designed solely for static ****ysis, and thus it’s intentionally limited.

Duceman: Renlo: basically, the VM can compile each module separately, into its own internal representation and even cache that, so when it sees “import { x } from ‘blah'” it doesn’t need to run “blah,” it just picks up the previously compiled module and creates a binding x in the current scope that points directly to one of its objects.

Hammerstad: Static ****ysis means compiling, correct?

Whitfield: Is there going to be some form of ‘javascript bytecode’?

Scimeca: Renlo: no. Static ****ysis is just extracting information from a program without running the program. Compilers will usually do some static ****ysis, but a compiler is just a tool that translates one language to another

Barnick: Dekok, what’s the need to be able to predict runtime behaviour? packers don’t have the problem, and browsers are runtime, so what is that I am missing?

Sandez: Renlo: not really. But there’s Web***embly, which is going to be a binary AST format that will allow people to compile things to run in the browser efficiently.

Kernell: Pastry: why should I download 30 MB of modules that I won’t be using?

Rayford: Except for stuff like “requirewhatever + ‘/module.js’ of course

Deschomp: Binary abstract syntax tree format?

Mullens: Dekok, in-browser you mean?

Hutcheson: Apparently I need to learn a lot more haha

Diliberto: Pastry: ES6 modules only make sense in the browser, because it’s the only thing with the “needs to fetch things over HTTP” problem

Zachter: Well, you use heuristics as I was saying, if it’s dynamic you do it as soon as you’re sure you need it

Ruthstrom: Not before though, like webpack code splitting basically

Provance: Why would it be in a binary syntax tree format, and not in something like bytecode or the source code itself

Salmela: I understand that ***embly compiles to machine code, which is of course in binary, but i do not understand why it would be good to send around the ast of the machine code, which is what Im ***uming the binary AST would be

Suchan: Though my ***umptions are likely way off the mark