5 ms·
How does it compare to Google's closure compiler? It is considered by many best in class. It understands the code (uses Java based Rhino Javascript engine), whi
by frik 9y ago
How does it compare to Google's closure compiler? It is considered by many best in class. It understands the code (uses Java based Rhino Javascript engine), while most alternatives (UglifyJS & co) just monkey patch things. You can trust the Google's closure compiler output.
Edit: @jagthebeetle: have you tried "advanced mode"? (One should read the documentation before using it, it's really a game changer but requires one to read the docu first)
- jagthebeetle 9y agoThis was my immediate question. For want of a more rigorous test, the online closure compiler service (https://closure-compiler.appspot.com/home https://closure-compiler.appspot.com/home) failed to produce equivalent or shorter output for all but the first example.
- matt4077 9y agoClosure compiler optimizes code size, while this optimises code execution.
- bpicolo 9y agoI see that it claims that, but that's not entirely true. The closure compiler does a variety of perf optimizations as well (e.g. inlining). Closure is really a great compiler, it's just a shame it doesn't interact well (that is, at all) with the modern JS ecosystem.
- tadeegan 9y agoAs someone who works on Closure Compiler, this is one of my biggest gripes with the project. Things are getting better though! CC now supports node's module resolution algorithm. It works pretty well with Es6 imports but not so well with CommonJS (mostly because the exports are impossible to statically analyze). Within Google, CC is heading towards being a an optimizing backend for other less painful languages such as Typescript (tsickle) and the yet-to-be-released J2CL compiler. CC does pretty well with these examples (our debugger is not quite as flashy): https://closure-compiler-debugger.appspot.com/#input0%3D%252F%252F%2520From%2520Prepack.io%2520%2522Hello%2520World%2522%250Avar%2520s%253B%250A(function%2520()%2520%257B%250A%2520%2520function%2520hello()%2520%257B%2520return%2520'hello'%253B%2520%257D%250A%2520%2520function%2520world()%2520%257B%2520return%2520'world'%253B%2520%257D%250A%2520%2520s%2520%253D%2520hello()%2520%252B%2520'%2520'%2520%252B%2520world()%253B%250A%257D)()%253B%250A%250Aconsole.log(s)%253B%26input1%26conformanceConfig%26externs%26refasterjs-template%26includeDefaultExterns%3D1%26CHECK_SYMBOLS%3D1%26MISSING_PROPERTIES%3D1%26TRANSPILE%3D1%26CHECK_TYPES%3D1%26COMPUTE_FUNCTION_SIDE_EFFECTS%3D1%26FOLD_CONSTANTS%3D1%26DEAD_ASSIGNMENT_ELIMINATION%3D1%26INLINE_CONSTANTS%3D1%26INLINE_FUNCTIONS%3D1%26INLINE_VARIABLES%3D1%26FLOW_SENSITIVE_INLINE_VARIABLES%3D1%26INLINE_PROPERTIES%3D1%26REMOVE_DEAD_CODE%3D1%26EXTRACT_PROTOTYPE_MEMBER_DECLARATIONS%3D1%26REMOVE_UNUSED_PROTOTYPE_PROPERTIES%3D1%26REMOVE_UNUSED_VARIABLES%3D1%26COLLAPSE_VARIABLE_DECLARATIONS%3D1%26COLLAPSE_ANONYMOUS_FUNCTIONS%3D1%26COLLAPSE_PROPERTIES%3D1%26DEVIRTUALIZE_PROTOTYPE_METHODS%3D1%26REWRITE_FUNCTION_EXPRESSIONS%3D1%26DISAMBIGUATE_PROPERTIES%3D1%26AMBIGUATE_PROPERTIES%3D1%26PROPERTY_RENAMING%3D1%26OPTIMIZE_CALLS%3D1%26OPTIMIZE_PARAMETERS%3D1%26OPTIMIZE_RETURNS%3D1%26MOVE_FUNCTION_DECLARATIONS%3D1%26MARK_NO_SIDE_EFFECT_CALLS%3D1%26CROSS_MODULE_CODE_MOTION%3D1%26CROSS_MODULE_METHOD_MOTION%3D1%26CLOSURE_PASS%3D1%26PRETTY_PRINT%3D1 https://closure-compiler-debugger.appspot.com/#input0%3D%252...
- bpicolo 9y ago> CC is heading towards being a an optimizing backend for other less painful languages such as Typescript I actually considered musing about something like this in my post. Typescript support would be very interesting. Fwiw, the tooling support around the CC has been a problem historically. We relied on Plovr for a long time, but eventually it fell unmaintained, and there wasn't an alternative for a lot of the relevant parts (e.g. gathering source files you care about). Some important dev features also just didn't quite work as intended (sourcemaps) for a long time.