Hacker News Reader

Comment by cbr | Hacker News Reader

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

View on HN

> 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?"

UglifyJS also evaluates constant expressions and that kind of thing. So you get a couple of basic optimizations.

Apt 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.

V8 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.

Someone 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.

that 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.

Agreed, this is awful. Presumably it means that adding comments can slow your code down, which I would otherwise have thought a completely laughable suggestion.

The 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.

Nope. 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.

A 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.

Given 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.

The 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.

I'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).

From the discussion, it seems it's not really enforced or complied with strictly.

Reply on news.ycombinator.com