Re: add stage4 constraint - ease-of-minification

fyi, i benchmarked minification-performance of google-closure-compiler and terser against a "classic" es5-compiler (uglifyjs-lite). google-closure-compiler is comparable to es5-compiler (but slow to compile), while terser is significantly worse: minifiying jquery-v3.3.1.js uminified:

Re: add stage4 constraint - ease-of-minification

> npm google-closure-compiler handles transpilation and minifiction. > and it's just 2 deps, itself, and Java. > https://www.npmjs.com/package/google-closure-compiler > hmm, google-closure-compiler actually has 29 dependencies (57mb total)

Re: add stage4 constraint - ease-of-minification

I suppose your argument isn't about 'not want to rely on babel' but 'not want to rely on anything'? I don't really understand where you're coming from it's like I missed the first half of the thread... I mean, I abhor babel; it has such huge dependancies. npm google-closure-compiler handles

Re: add stage4 constraint - ease-of-minification

sorry that came out wrong, but i'm generally uncomfortable with the dearth of reliable/correct es6+ compliant minifiers. and i feel its an industry-concern which slows product-development. On Tue, Feb 12, 2019 at 6:35 PM kai zhu wrote: > Yes, exactly. minification-tooling is a real-concern for

Re: add stage4 constraint - ease-of-minification

Yes, exactly. minification-tooling is a real-concern for any consumer-facing javascript-product, and not all of them want to rely on babel. Are you arguing all new javascript-products should be coerced to integrate with babel, because it has a monopoly on such critical-tooling? On Tue, Feb 12,

Re: add stage4 constraint - ease-of-minification

So effectively, you're arguing that stagnant tools should hold back evolution of the language, even when non-stagnant alternatives exist? On Tue, Feb 12, 2019 at 3:26 PM kai zhu wrote: > > Can you expand on what you mean by this, or provide an example of a > > feature that can't be "easily

Re: add stage4 constraint - ease-of-minification

> Can you expand on what you mean by this, or provide an example of a > feature that can't be "easily minified”? fat-arrow/destructuring/es6-classes comes to mind. if you have legacy build-chain that doesn't use babel or terser, is it worth the effort to retool the minifier to support these

Re: add stage4 constraint - ease-of-minification

On Tue, Feb 12, 2019 at 7:44 AM kai zhu wrote: > i think there’s an industry-painpoint (at least from my experience), of > resistance adopting es6+ features because legacy-toolchains cannot be easily > retooled to minify them. > > i’m not sure the best way to address this problem? i favor

add stage4 constraint - ease-of-minification

i think there’s an industry-painpoint (at least from my experience), of resistance adopting es6+ features because legacy-toolchains cannot be easily retooled to minify them. i’m not sure the best way to address this problem? i favor requiring 2 independent minifiers to be able to handle a

Re: New Proposal: Number.range (Yes, range again)

I'm really cheering for the slice-notation range extension proposed in https://github.com/tc39/proposal-slice-notation/issues/19#issuecomment-421453934 ```js for (const i of Number.range(0, 43)) { console.log(i) // 0 to 42 } const fakeData = [...Number.range(1, 21)].map(x => x ** 2) ```