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