add stage4 constraint - ease-of-minification
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"?
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.
So effectively, you're arguing that stagnant tools should hold back evolution of the language, even when non-stagnant alternatives exist?
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?
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.
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. www.npmjs.com/package/google-closure-compiler
It also does source amalgamation without transpiling; and seems to be kept up to date
npm google-closure-compiler handles transpilation and minifiction. and it's just 2 deps, itself, and Java. www.npmjs.com/package/google-closure-compiler, www.npmjs.com/package/google-closure-compiler
hmm, google-closure-compiler actually has 29 dependencies (57mb total)
$ shNpmPackageDependencyTreeCreate google-closure-compiler
- google-closure-compiler at 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 at 20190121.0.0 ├─┬ chalk at 1.1.3 │ ├── ansi-styles at 2.2.1 │ ├── escape-string-regexp at 1.0.5 │ ├─┬ has-ansi at 2.0.0 │ │ └── ansi-regex at 2.1.1 │ ├─┬ strip-ansi at 3.0.1 │ │ └── ansi-regex at 2.1.1 deduped │ └── supports-color at 2.0.0 ├── google-closure-compiler-java at 20190121.0.0 ├── google-closure-compiler-js at 20190121.0.0 ├── UNMET OPTIONAL DEPENDENCY google-closure-compiler-linux at 20190121.0.0 ├── google-closure-compiler-osx at 20190121.0.0 ├── minimist at 1.2.0 ├─┬ vinyl at 2.2.0 │ ├── clone at 2.1.2 │ ├── clone-buffer at 1.0.0 │ ├── clone-stats at 1.0.0 │ ├─┬ cloneable-readable at 1.1.2 │ │ ├── inherits at 2.0.3 │ │ ├── process-nextick-args at 2.0.0 │ │ └─┬ readable-stream at 2.3.6 │ │ ├── core-util-is at 1.0.2 │ │ ├── inherits at 2.0.3 deduped │ │ ├── isarray at 1.0.0 │ │ ├── process-nextick-args at 2.0.0 deduped │ │ ├── safe-buffer at 5.1.2 │ │ ├─┬ string_decoder at 1.1.1 │ │ │ └── safe-buffer at 5.1.2 deduped │ │ └── util-deprecate at 1.0.2 │ ├── remove-trailing-separator at 1.1.0 │ └── replace-ext at 1.0.0 └─┬ vinyl-sourcemaps-apply at 0.2.1 └── source-map at 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 at 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 at 3.16.1 ├── commander at 2.17.1 ├── source-map at 0.6.1 └─┬ source-map-support at 0.5.10 ├── buffer-from at 1.1.1 └── source-map at 0.6.1 deduped
$ du -ms . 6 .
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 $ curl -s -O ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.js $ ./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 $
On Tue, Feb 12, 2019 at 7:07 PM kai zhu <kaizhu256 at gmail.com> wrote:
npm google-closure-compiler handles transpilation and minifiction. and it's just 2 deps, itself, and Java. www.npmjs.com/package/google-closure-compiler
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.
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:
npm install google-closure-compiler terser uglifyjs-lite
curl -O https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.js <https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.js>
npx google-closure-compiler jquery.js > jquery.min.google <http://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 <http://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
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.