Chivers: _.mixin_.string.exports; even _.string is undefined

Studt: But I’ve got the minified version of underscore.string added to the html do***ent. omg

Kovacic: Why dont very many people use es6 modules?

Treglia: Laserco: there’s no reason to use them. They’re limited, by design, so there’s literally zero benefits in choosing them over things that you already use today, like Node modules.

Hay: Dekok: what were they made for then?

Seat: Http://jsfiddle.net/ps8u8p3x/ here. I can’t get underscore.string to work. I’ve tried dasherize on it’s own I’ve tried exportig _.str and _.string but niether exist.

Iino: Laserco: static ****ysis for efficiently fetching dependencies over HTTP inside a web browser. Which is 1 a bad use case, since you’re going to be bundling everything in a single file to avoid HTTP requests anyway; 2 not usable outside of the browser; 3 not usable inside of the browser either because nothing implements ES6 modules yet.

Hosendove: Dekok: interesting. I guess I saw someone made a es6 module lib called “rollup” on the premise that it outputs cleaner code post-bundle.

Metzker: Laserco: ES6 modules make it easier to do a limited form of tree shaking for DCE, given that they’re second cl***. But you lose some very important features, like generative parametric modules

Dancer: Though if the person doesn’t mean that they do DCE by “outputs cleaner code post-bundle,” then it’s a really useless statement.

Dobrinin: Nobody cares about whatever you output in your bundle code, since you’ll be using source maps to see it in the debugger anyway

Craze: Yea, one point they made was that it’s more optimisable

Stakkeland: As its not wrapped in an object

Richlin: Laserco: not by much anyway. You can do the same with optimistic optimisations in Node modules for the same access patterns.

Birckett: Wrapping things in objects or not is irrelevant anyway.

Constantin: You get no performance benefits from not doing it

Pecher: Finally figured out the culprit in our jsonp

Wreath: Our ajaxprefilter which does the retry is causing the issue which is Uncaught TYpeError: JQuery112214214214 is not a function

Abelardo: If you have var a = require’foo’.bar, and never change a, the engine will just do constant propagation, which will result in faster code. If you have var a = require’foo’; and then use a.b everywhere but don’t let a itself leak, then the VM will also compile that to a fast load, and in many cases, just do constant propagation. So, again, no

Panozzo: Performance benefits.

Moesch: When i disabled the retry, i have never seen anymore issue for 30 mins

Nasalroad: Utils, when you use it inside a browser it’s in window.s like http://jsfiddle.net/progysm/ps8u8p3x/2/

Carrales: Laserco: it’s kinda weird that someone would state something about performance/optimisation without considering the thing that’s going to run the code O.o

Suydan: So the culprit is the retry when using jsonp. I am not sure if there is good way to solve it

Ochinang: Dekok: this is their example if you want to take a look https://github.com/rollup/rollup#dont-minifiers-already-do-this

Sowders: How do i grab the first part of a string upto the first instance of a specific char ?

Manard: Zap0: in ES6, you could use findIndex to find the character, and then slice up to that index

Hollingshed: Laserco: they’re wrong about “you can’t do this” by the way. obj doesn’t leave that scope. All of the information there is statically ****ysable.

Wakley: Zap0: String.prototype.slice – JavaScript MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/slice

Opalka: Usman: he’d still need to retrieve an index though?

Mcmackin: He knows the char, not its position

Wakley: Zap0: String.prototype.indexOf – JavaScript MDN https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/indexOf

Snoderly: I’m thinking in portals