Hacker News Reader

Comment by AriaMinaei | Hacker News Reader

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.

View on HN

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