add stage4 constraint - ease-of-minification

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

add stage4 constraint - ease-of-minification

kai zhu
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.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

Tab Atkins Jr.
On Tue, Feb 12, 2019 at 7:44 AM kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

kai zhu
> 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. <[hidden email]> wrote:
>
> On Tue, Feb 12, 2019 at 7:44 AM kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

Jordan Harband
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 <[hidden email]> 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. <[hidden email]> wrote:
>
> On Tue, Feb 12, 2019 at 7:44 AM kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

kai zhu
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 <[hidden email]> 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 <[hidden email]> 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. <[hidden email]> wrote:
>
> On Tue, Feb 12, 2019 at 7:44 AM kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

kai zhu
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. <[hidden email]> wrote:
>
> On Tue, Feb 12, 2019 at 7:44 AM kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

J Decker
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.

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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. <[hidden email]> wrote:
>
> On Tue, Feb 12, 2019 at 7:44 AM kai zhu <[hidden email]> 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
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

kai zhu
npm google-closure-compiler handles transpilation and minifiction.
and it's just 2 deps, itself, and Java.

hmm, google-closure-compiler actually has 29 dependencies (57mb total)


$ shNpmPackageDependencyTreeCreate google-closure-compiler

+ google-closure-compiler@20190121.0.0
added 29 packages from 72 contributors and audited 34 packages in 2.04s
found 0 vulnerabilities

[MODE_BUILD=npmPackageDependencyTree] - 2019-02-13T02:53:32.614Z - (shRun npm ls 2>&1)

/private/tmp/npmPackageDependencyTreeCreate
└─┬ google-closure-compiler@20190121.0.0
  ├─┬ chalk@1.1.3
  │ ├── ansi-styles@2.2.1
  │ ├── escape-string-regexp@1.0.5
  │ ├─┬ has-ansi@2.0.0
  │ │ └── ansi-regex@2.1.1
  │ ├─┬ strip-ansi@3.0.1
  │ │ └── ansi-regex@2.1.1 deduped
  │ └── supports-color@2.0.0
  ├── google-closure-compiler-java@20190121.0.0
  ├── google-closure-compiler-js@20190121.0.0
  ├── UNMET OPTIONAL DEPENDENCY google-closure-compiler-linux@20190121.0.0
  ├── google-closure-compiler-osx@20190121.0.0
  ├── minimist@1.2.0
  ├─┬ vinyl@2.2.0
  │ ├── clone@2.1.2
  │ ├── clone-buffer@1.0.0
  │ ├── clone-stats@1.0.0
  │ ├─┬ cloneable-readable@1.1.2
  │ │ ├── inherits@2.0.3
  │ │ ├── process-nextick-args@2.0.0
  │ │ └─┬ readable-stream@2.3.6
  │ │   ├── core-util-is@1.0.2
  │ │   ├── inherits@2.0.3 deduped
  │ │   ├── isarray@1.0.0
  │ │   ├── process-nextick-args@2.0.0 deduped
  │ │   ├── safe-buffer@5.1.2
  │ │   ├─┬ string_decoder@1.1.1
  │ │   │ └── safe-buffer@5.1.2 deduped
  │ │   └── util-deprecate@1.0.2
  │ ├── remove-trailing-separator@1.1.0
  │ └── replace-ext@1.0.0
  └─┬ vinyl-sourcemaps-apply@0.2.1
    └── source-map@0.5.7

$ du -ms .
57 .




terser is relatively smaller with 5 dependencies (6mb total).  i might look into forking it and merge its dependencies into a standalone-package


$ shNpmPackageDependencyTreeCreate terser

+ terser@3.16.1
added 5 packages from 38 contributors and audited 6 packages in 1.742s
found 0 vulnerabilities

[MODE_BUILD=npmPackageDependencyTree] - 2019-02-13T02:54:10.589Z - (shRun npm ls 2>&1)

/private/tmp/npmPackageDependencyTreeCreate
└─┬ terser@3.16.1
  ├── commander@2.17.1
  ├── source-map@0.6.1
  └─┬ source-map-support@0.5.10
    ├── buffer-from@1.1.1
    └── source-map@0.6.1 deduped

$ du -ms .
6 .



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

kai zhu
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:                     271,751 bytes (100.0%)
terser (es6):                  137,538 bytes ( 50.6%)
google-closure-compiler (es6):  89,845 bytes ( 33.1%)
uglifyjs-lite (es5):            88,681 bytes ( 32.6%)

$
$ npm install google-closure-compiler terser uglifyjs-lite
$ ./node_modules/.bin/google-closure-compiler jquery.js > jquery.min.google-closure-compiler.js 2>/dev/null
$ ./node_modules/.bin/terser jquery.js > jquery.min.terser.js 2>/dev/null
$ ./node_modules/.bin/uglifyjs-lite jquery.js > jquery.min.uglifyjs-lite.js 2>/dev/null
$ ls -lS
total 1184
-rw-r--r--   1 kaizhu  wheel  271751 Feb 12 23:40 jquery.js
-rw-r--r--   1 kaizhu  wheel  137538 Feb 12 23:40 jquery.min.terser.js
-rw-r--r--   1 kaizhu  wheel   89845 Feb 12 23:40 jquery.min.google-closure-compiler.js
-rw-r--r--   1 kaizhu  wheel   88681 Feb 12 23:40 jquery.min.uglifyjs-lite.js
-rw-r--r--   1 kaizhu  wheel   10563 Feb 12 22:59 package-lock.json
drwxr-xr-x  37 kaizhu  wheel    1258 Feb 12 23:40 node_modules


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

J Decker
In reply to this post by kai zhu


On Tue, Feb 12, 2019 at 7:07 PM kai zhu <[hidden email]> wrote:
npm google-closure-compiler handles transpilation and minifiction.
and it's just 2 deps, itself, and Java.

hmm, google-closure-compiler actually has 29 dependencies (57mb total)

I see.
I just have a copy of  npm\node_modules\google-closure-compiler/compiler.jar
didn't realize it had other deps   "dependencies": {    "chalk": "^1.0.0",     "vinyl": "^2.0.1",     "vinyl-sourcemaps-apply": "^0.2.0"  },

Which are used for grunt and gulp plugins, which I don't use.

 


$ shNpmPackageDependencyTreeCreate google-closure-compiler

+ google-closure-compiler@20190121.0.0
added 29 packages from 72 contributors and audited 34 packages in 2.04s
found 0 vulnerabilities

[MODE_BUILD=npmPackageDependencyTree] - 2019-02-13T02:53:32.614Z - (shRun npm ls 2>&1)

/private/tmp/npmPackageDependencyTreeCreate
└─┬ google-closure-compiler@20190121.0.0
  ├─┬ chalk@1.1.3
  │ ├── ansi-styles@2.2.1
  │ ├── escape-string-regexp@1.0.5
  │ ├─┬ has-ansi@2.0.0
  │ │ └── ansi-regex@2.1.1
  │ ├─┬ strip-ansi@3.0.1
  │ │ └── ansi-regex@2.1.1 deduped
  │ └── supports-color@2.0.0
  ├── google-closure-compiler-java@20190121.0.0
  ├── google-closure-compiler-js@20190121.0.0
  ├── UNMET OPTIONAL DEPENDENCY google-closure-compiler-linux@20190121.0.0
  ├── google-closure-compiler-osx@20190121.0.0
  ├── minimist@1.2.0
  ├─┬ vinyl@2.2.0
  │ ├── clone@2.1.2
  │ ├── clone-buffer@1.0.0
  │ ├── clone-stats@1.0.0
  │ ├─┬ cloneable-readable@1.1.2
  │ │ ├── inherits@2.0.3
  │ │ ├── process-nextick-args@2.0.0
  │ │ └─┬ readable-stream@2.3.6
  │ │   ├── core-util-is@1.0.2
  │ │   ├── inherits@2.0.3 deduped
  │ │   ├── isarray@1.0.0
  │ │   ├── process-nextick-args@2.0.0 deduped
  │ │   ├── safe-buffer@5.1.2
  │ │   ├─┬ string_decoder@1.1.1
  │ │   │ └── safe-buffer@5.1.2 deduped
  │ │   └── util-deprecate@1.0.2
  │ ├── remove-trailing-separator@1.1.0
  │ └── replace-ext@1.0.0
  └─┬ vinyl-sourcemaps-apply@0.2.1
    └── source-map@0.5.7

$ du -ms .
57 .




terser is relatively smaller with 5 dependencies (6mb total).  i might look into forking it and merge its dependencies into a standalone-package


$ shNpmPackageDependencyTreeCreate terser

+ terser@3.16.1
added 5 packages from 38 contributors and audited 6 packages in 1.742s
found 0 vulnerabilities

[MODE_BUILD=npmPackageDependencyTree] - 2019-02-13T02:54:10.589Z - (shRun npm ls 2>&1)

/private/tmp/npmPackageDependencyTreeCreate
└─┬ terser@3.16.1
  ├── commander@2.17.1
  ├── source-map@0.6.1
  └─┬ source-map-support@0.5.10
    ├── buffer-from@1.1.1
    └── source-map@0.6.1 deduped

$ du -ms .
6 .



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: add stage4 constraint - ease-of-minification

kai zhu
I just have a copy of  npm\node_modules\google-closure-compiler/compiler.jar

good to know.  also, the previous benchmark was misleading, because terser didn’t mangle by default [1]. with mangling, its performance is inline:

```shell

npm install google-closure-compiler terser uglifyjs-lite
npx google-closure-compiler jquery.js > jquery.min.google-closure-compiler.js 2>/dev/null
npx uglifyjs-lite jquery.js > jquery.min.uglifyjs-lite.js 2>/dev/null
npx terser jquery.js -m > jquery.min.terser-mangled.js
npx terser jquery.js -c -m > jquery.min.terser-compressed-mangled.js 2>/dev/null
npx terser jquery.js -c -m --mangle-props > jquery.min.terser-compressed-props-mangled.js 2>/dev/null
ls -lS jquery.*
  271751 Feb 14 13:12 jquery.js
   91350 Feb 14 13:24 jquery.min.terser-mangled.js
   89845 Feb 14 13:24 jquery.min.google-closure-compiler.js
   88681 Feb 14 13:24 jquery.min.uglifyjs-lite.js
   86478 Feb 14 13:24 jquery.min.terser-compressed-mangled.js
   79896 Feb 14 13:24 jquery.min.terser-compressed-props-mangled.js


```

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss