add stage4 constraint - ease-of-minification

J Decker d3ck0r at gmail.com
Wed Feb 13 02:06:05 UTC 2019


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 <kaizhu256 at 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 <kaizhu256 at 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 <ljharb at 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 <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
>>>>
>>> _______________________________________________
> 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/794e7ccb/attachment.html>


More information about the es-discuss mailing list