Today I made a difference..

Felipa: It can if you are being explicit about what you import.

Trucchi: It can’t unless that variable is only set once in the code and doesn’t depend on any runtime data

Trucchi: But if you’re being explicit about what you import, that brings us back to static anyway

Comrey: Trucchi: module bundler would not care what variables you use in your code if you explicitly import just specific properties, e.g. import {foo, bar} from baz;

Trucchi: Right, but that’s static ****ysis – I thought you wanted dynamic?

Gleichman: You are mistaking me with someone else.

Talleut: Gajus:

Kobylarz: Dekok: Sorry, don’t understand what these examples have to do with statically ****ysing required resourced.

Baughman: Man, it ****s to go back to backbone views after using react

Loeper: Gajus: in the first example, any binding that isn’t a or qux in module c can be removed from the bundle. In the others it’s not possible to do any ****ysis because in one there’s a dynamic projection you need to execute the code to verify what property it is, and in the other, the object b escapes to another function. You can do a more extensive

Sowders: I am having trouble trying to get sub DOM elements. i have div id=”parent”span id=”child1″/spanspan id=”child2″/span/div and JS: el = do***ent.getElementById’parent’; if el { /* it does get to here */ el.getElementById’child1′. and this gives an error saying getElementById is not a function.

Holahan: Gajus: basically, for anything the tool is able to know without executing your code, it can do DCE.

Fair: Dekok: import { a } as b from c; a; “a” would be undefined here.

Paulis: Zap0: id’s are unique, so you use do***ent.getElementByID again

Carello: There’s no point to getting nested elements by id

Stromain: Gajus: a can’t possibly be undefined there. It’s a compile-time error to import a binding that isn’t exported

Nasalroad: But you could el.querySelector’#child1′

Demartini: Nucleartide: why do you need to use backbone views?

Ontko: Nucleartide: backbone views and React accomplish different things

Toop: Nucleartide: you can use backbone views with React

Heafner: Why the **** are y’all even arguing about this

Mcswain: Like nobody but yourselves are benefitting from the argument/discussion

Landgraf: One might be better than the other, but that doesn’t matter for now, and it won’t matter for a while

Sillman: Gajus: oh, ES6 only has import * as b from c? That’s by design, then

Simson: Dekok: yeah, import * as b from c would indeed not allow dead code elimination. Thats exactly why we are having this talk.

Greenlow: Gajus: import { a, b } as c from d is exactly what ES6 modules are trying to avoid :

Nasalroad: Why do you have dead code ?

Escuriex: I have described it here,

Bankard: Although that particular syntax is still statically ****ysable.

Desha: L8D: we’re using backbone at work, haven’t migrated over to react yet. i use react at home.

Trad: L8D: eventually i’m going to do the react inside backbone view thing, but that’s for later

Hittner: Hey guys i have a problem i want to disable the main scrolbar if i am in a div with a scrolbar any ideas?

Trucchi: Dekok: it is, but I *can* see the benefit in keeping the static ****ysis within the bounds of the actual import syntax

Trucchi: Rather than having to ****yze all imports AND all things that refer to the imports

Krumsiek: Trucchi: particularly I don’t think it’s very useful

Trucchi: True. it would save on the complexity of doing dead code elimination, but not by a lot given that dead code elimination is already gonna be pretty complicated

Guttmann: Today I made a difference. Started a discussion.