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 transpilation and minifiction. and it's just 2 deps, itself, and Java. https://www.npmjs.com/package/google-closure-compiler It also does source amalgamation without transpiling; and seems to be kept up to date On Tue, Feb 12, 2019 at 5:09 PM kai zhu <kaizhu...@gmail.com> wrote: > 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 <kaizhu...@gmail.com> wrote: > >> 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, 2019 at 6:28 PM Jordan Harband <ljh...@gmail.com> wrote: >> >>> 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 <kaizhu...@gmail.com> wrote: >>> >>>> > 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 syntaxes so you can use it? also any >>>> feature which introduce new symbol/symbol-combo which requires re-auditing >>>> minifier's regexp-detection (private-fields, optional-chaining, etc.). >>>> >>>> there’s also the argument using babel in minification-toolchain defeats >>>> the purpose of reducing code-size. >>>> >>>> > On 12 Feb 2019, at 4:02 PM, Tab Atkins Jr. <jackalm...@gmail.com> >>>> wrote: >>>> > >>>> > On Tue, Feb 12, 2019 at 7:44 AM kai zhu <kaizhu...@gmail.com> 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 requiring >>>> 2 independent minifiers to be able to handle a stage3-proposal before >>>> advancement (indicating retooling is feasible), but that may be >>>> overly-restrictive to some folks. >>>> > >>>> > Can you expand on what you mean by this, or provide an example of a >>>> > feature that can't be "easily minified"? >>>> > >>>> > ~TJ >>>> >>>> _______________________________________________ >>>> es-discuss mailing list >>>> es-discuss@mozilla.org >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>> _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
