Shorten sintax for some common keywords like "function" and "return"

💡 Ideas
1

The idea is to introduce a shorter sintax for some common keywords like "function" and "return", eg.:

// 29 Bytes
function foo(){
  return 'bar';
}

become:

// 22 Bytes
func foo(){
  ret 'bar';
}

the target is to reduce the size of .js and speed up the download of such file, since those keywords are repeated many times in .js files.

The only issue here would be backwards compatibility with older browser, without possibility to use polyfill to bypass such incompatibility.

Any feedback on this idea?

1 Like
2

The size to compare is the zipped size of the minified code, not the uncompressed unminified size.

3

of course, but there would still be a difference between the two files.

4

In a file with only one form of these two, even if there were thousands of functions, i suspect the max savings would be the bytes of “toin” - in a file that had mixed, though, it would be larger.

That’s not much savings compared to the massive cost of adding new syntax to the language.

2 Likes
5

To elaberate a bit on the zip format, here is a grossy oversimplification of how this would work.

If I have a JavaScript file that looks like this:

function foo() { ... }
function bar() { ... }
function baz() { ... }
...

The zip format will effectively find-and-replace every function with a unique, unused symbol, like :slightly_smiling_face:, then put a map at the top that explains what each symbol means. So, the compressed version will look like this:

-- START_MAPPING --
🙂="function "
-- END_MAPPING --
🙂foo() { ... }
🙂bar() { ... }
🙂baz() { ... }
...

So, using func instead of function everywhere will only save you the bytes "tion", as @ljharb mentioned, since the only thing that'll change is that :slightly_smiling_face: means "func " instead of "function ".

Now, this isn't really how the zip format works, I'm sure this explanation is full of lies and what-not, especially since I don't know all of the details of their algorithm, but that should give the basic idea of it and why such a change wouldn't save many bytes. (I did do a quick lookup to verify this, and found that it actually supports multiple different compression alogirhtms, so the details would vary depending on which one was chosen. But the above explanation still shows off a common compression strategy that I'm sure gets used in one way or another by the different possible compression algorithms within the zip format)

2 Likes
6

Nah you got that approximately right. The actual details of LZW compression (used in ZIP) are just about how to construct the dictionary efficiently and then the down-and-dirty binary encoding details, but your explanation is correct at a high level.

1 Like
7

Actually, functions can be shortened using arrow syntax (usually). The moments when devs actually require "classic" fns instead of arrows, are because of the this value, and those are rarer. However, generators must be defined using the function keyword, there's no arrow syntax for generators.

BTW, I suggest a shorter name like fn.

And remember, these aliases will become reserved words, so any variables named like that (in old code) will cause syntax errors