5 ms·
Looks like Debian is mostly on top of it: > To me the problem suggests that it is important from a security and > accountability perspective to 1) incl
by cbr 11y ago
Looks like Debian is mostly on top of it:
> To me the problem suggests that it is important from a security and
> accountability perspective to 1) include the human-readable source
> code of JavaScript in Debian packages, and 2) to compile the
> human-readable source code into a minified code (if required) during
> package builds, using a JS-minifier that is included in Debian.
> Thoughts?
This is anyway mandatory in Debian.
https://lists.debian.org/debian-devel/2015/08/msg00478.html https://lists.debian.org/debian-devel/2015/08/msg00478.html
- zamalek 11y ago> Looks like Debian is mostly on top of it I wonder... I'm assuming their concern surrounds stuff that is installed on-disk with the package manager. Is there any benefit at all to JS minification when the file:// protocol is in use? Marginal (if at all) improvements to parse time? Anything else? Or is "everyone doing it?"
- teamhappy 11y agoUglifyJS also evaluates constant expressions and that kind of thing. So you get a couple of basic optimizations.
- jon-wood 11y agoApt can be used to install web applications to be hosted from a Debian based server, so just because you're installing a package on a machine doesn't mean the files it installs won't be accessed remotely.
- nteon 11y agoV8 uses a function's length in characters, _including comments_, to make optimization decisions. By removing comments and shortening var identifiers internal to a function, I can imagine a number of functions dropping under that 600-char threshold. Would be great to measure.
- 0942v8653 11y agoSomeone in the last thread mentioned that you can actually configure this limit. So it may be slightly more accurate in the ratio when minified but probably not worth it.
- the8472 11y agothat seems like a terrible way to measure things. why not go by the number of some form of nodes after parsing? Parsing has to happen before optimization anyway.
- gmac 11y agoAgreed, this is awful. Presumably it means that adding comments can slow your code down, which I would otherwise have thought a completely laughable suggestion.
- laumars 11y agoThe problem with JIT compiled languages is compilation time is as critical as the performance of the compiled code. Using string length happens to be quicker than producing ASTs. So while it is a dirty hack, it generally offers greater performance more often than not.
- striking 11y agoNope. Parsing happens inline with execution, unless the function has less than 600 characters, where it'll be compiled down instantly. If it has any hotspots after that, they'll be JIT optimized. It is a terrible way, but you can't complain that it's a lot faster than rewriting V8 to count nodes.
- lukeschlather 11y agoA proper linter like JSLint or JSHint is preferable, but minifying is a basic syntax check. Obviously not the best way to do it, but it's a benefit.
- icebraining 11y agoFrom the discussion, it seems it's not really enforced or complied with strictly.
- tracker1 11y agoGiven the most used minifiers are probably uglify2 and closure compiler... uglify2 requiring a JS runtime (node/iojs) and closure requiring Java, this would be some overhead for said build systems... personally, nvm/iojs are pretty high on my installed items, but having it in default would likely slow adoption of progressing versions. Node has pretty much become the standard for dealing with client-side assets in projects.
- caf 11y agoThe build systems are already building and linking massive C++ cathedrals for other packages, I don't think that running uglify2 on nodejs is going to be a resource issue. More problematic is that nodejs isn't available on all Debian architectures, due to lack of V8.
- tracker1 11y agoI'm not saying it is... and TBH any system servicing web traffic with JS these days likely has node involved. I was just saying that it would be elevated to a core component, and might hinder adoption of newer releases, though it could improve it too. I'm mainly echoing concerns that were in play when Mono had been gaining a little traction, and as an example a few useful utilities were added to Ubuntu's release, bringing in a large runtime... in this case it's not quite as big, but node_modules can get a little big depending on what you're working on (much better with SSD).