Hacker News Reader

Comment by aquilaFiera | Hacker News Reader

WebAssembly isn't going to kill that notion; uglify already did. Nearly all codebases on big sites get run through a build process these days. The open web continues to live on through the open and free software movements.

View on HN

I'm apparently in the minority but I'm with the GP in that I've never been sure uglify and other minification was actually a great idea for this reason. The gains are marginal if you're using gzip compression (you are, right?); the loss of source readability is a big deal for the open nature.

Saying that the open web lives on through open/free software also seems dubious to me. Most SaaS don't have their offerings up on Github.

I wonder if we're about to discover yet again with the browser itself why the browser beat several cross-platform VMs.

As someone who has used uglify on occasion, sometimes you pull a trick and you don't want the competition to find out too easily. Make'm sweat for it.

And on the subject of Web Assembly, if asm.js is the inspiration, great thing will come for it, really a new era for the web. For example, things like that https://github.com/audiocogs/ogg.js, and to me that's just a tiny glimpse on what the possibilities will become.

> I've never been sure uglify and other minification was actually a great idea for this reason. The gains are marginal if you're using gzip

Smaller JS parses faster. gzip doesn't affect parse time.

I agree that the web is far from the full ideal of "open-by-design", but it's still the most significant platform providing it to some extent.

The problem of uglify can be mitigated if someone invented a binary format for JS that was interchangeable with the current text format. The format would reduce the code's size, while keeping it readable (you'd just have to run it through a binary-to-text decompressor).

I should also say that you can read uglified/obfuscated code. It just takes more patience. Example: if PS was written in JS and then obfuscated, how hard do you think it would be to find out how their color transformation algorithms are implemented?

You can't say the same thing for asm.js code though.

What's the difference between deobfuscating code, and decompiling it? Either way you end up with a weirdly-structured, canonicalized, symbolless mess.

The binary format that I mentioned/proposed would map one-to-one with a text format. They would be interchangeable. That means if you open a file in that binary format in a text editor (with the right plugin), you'd see almost exactly the original code. It's not decompilation. Only decompression.

I think you're confusing cost of parsing with cost of lexing. A 1:1 binary representation of JS (like HPACK is for HTTP headers) wouldn't decrease parsing time (the time it takes to turn a stream of recognized tokens into an AST) at all, which was the goal here.

Agreed, but the idea is still beneficial. If 1:1 binary representation for the data from the lexer doesn't yield much benefit, then a representation for the AST might.

And reading from that data could be much faster. And with a supposedly smaller file format, it probably wouldn't be so necessary for a minifier to rename symbols to single-letter ones to save a few more bytes.

[Edit: added the following paragraph]

This could yield a smaller file format (which is what people usually want from JS minifiers), without sacrificing the readability of the JS code.

Renaming symbols, and minification in general, is not really "necessary", it's just something people do to extract a few % more of performance. If they had that file format, they'd still have exactly the same reasons to rename symbols, so they'd still do it.

After all, if people cared about leaving their files readable, they'd just publish the non-minified version as well. Those who don't, won't avoid renaming either.

I agree that renaming symbols would still save a few more bytes, but I still think that with the right file format, symbol renaming and mangling would become an insignificant, unnecessary micro-optimization.

But that should only be tested in practice, so ... :)

This seems backwards. If I have JS source and the identifiers take up 10% of it, then symbol renaming and mangling can shrink my code size by something less than 10%.

If we shrink that other 90%, so that the formerly 10% is now 80%, renaming becomes more attractive.

This doesn't hold if people have a fixed problem with a fixed solution and fixed constraints... but problems and solutions grow.

> If we shrink that other 90%, so that the formerly 10% is now 80%, renaming becomes more attractive.

Convinced :)

I would say the same thing for asm.js. If you had enough time/patience you could still determine how some given logic worked in some sample asm.js code.

> if someone invented a binary format for JS that was interchangeable with the current text format

We already have gzip, although even with gzip minifying is useful, because gzip isn't content-aware. You can also enable source maps in production if you care about openness. The client doesn't have to fetch the maps/sources until developer tools is opened.

Well, gzip is general purpose. A binary format would be aware of JS' semantics and possibly yield much higher compression rates.

In fact, WASM's binary format is intended to be that way and apparently is yields more compression than using only gzip: https://github.com/WebAssembly/design/blob/master/BinaryEnco...

Reply on news.ycombinator.com