add stage4 constraint - ease-of-minification

Jordan Harband ljharb at gmail.com
Wed Feb 13 00:27:32 UTC 2019


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 <kaizhu256 at 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. <jackalmage at gmail.com> wrote:
> >
> > On Tue, Feb 12, 2019 at 7:44 AM kai zhu <kaizhu256 at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190212/4dde1e3d/attachment.html>


More information about the es-discuss mailing list