GopherJS – A compiler from Go to JavaScript

Re:GopherJS – A compiler from Go to JavaScript by Cyranix on Tuesday October 14, 2014 @04:51PM (#8455734)

Can anyone speak to the trade-off in file size, for non-trivial codebases? There is a stated design goal of "small size of generated code", but the default snippet in the playground introduces quite a large amount of boilerplate. Is the penalty on file size fairly front-loaded or does the generated code scale horribly?

[ Parent | on HN ]

Re:GopherJS – A compiler from Go to JavaScript by nknighthb on Tuesday October 14, 2014 @05:48PM (#8456023)

Annoyingly but predictably, I don't really have any nontrivial code of my own around that doesn't violate any of the (entirely reasonable, except for x509) constraints.

GopherJS happily compiles itself, however. The raw source code looks to be about 250KB. The native binary ends up 7.7MB, and the unminified js is 3MB. A pass through UglifyJS with default options reduces that to 1.7MB (I have not tested the result):

    ~/gocode/bin$ ls -lh *gopher*
    -rwxr-xr-x  1 nknight  staff   7.7M Oct 14 14:02 gopherjs
    -rw-r--r--  1 nknight  staff   3.0M Oct 14 14:32 gopherjs.js
    -rw-r--r--  1 nknight  staff   233K Oct 14 14:32 gopherjs.js.map
    -rw-r--r--  1 nknight  staff   1.7M Oct 14 14:41 min-gopherjs.js
    ~/gocode/bin$

Edit: Oh, and the playground example minifies to 300KB:

    ~/gjstest/playground$ ls -lh
    total 1784
    -rw-r--r--  1 nknight  staff   194B Oct 14 14:05 main.go
    -rw-r--r--  1 nknight  staff   536K Oct 14 14:53 main.js
    -rw-r--r--  1 nknight  staff    42K Oct 14 14:53 main.js.map
    -rw-r--r--  1 nknight  staff   300K Oct 14 14:54 min-main.js
    ~/gjstest/playground$

[ Parent | on HN ]

Re:GopherJS – A compiler from Go to JavaScript by nulltype on Tuesday October 14, 2014 @07:28PM (#8456411)

What about after gzip?

[ Parent | on HN ]

Re:GopherJS – A compiler from Go to JavaScript by nknighthb on Tuesday October 14, 2014 @08:27PM (#8456620)

About what you'd expect, the playground sample drops to 75KB, and the compiler to 424KB. (Also the native binary gzips to 2MB.)

[ Parent | on HN ]

Re:GopherJS – A compiler from Go to JavaScript by shurcooL on Tuesday October 14, 2014 @08:37PM (#8456645)

Very nice finding!

[ Parent | on HN ]

Re:GopherJS – A compiler from Go to JavaScript by shurcooL on Tuesday October 14, 2014 @05:06PM (#8455817)

The thing is that if you want to compile a single fmt.Println("Hello") line, that will produce a large output because of what's needed to support it, including dealing with Go/JS types like bytes, runes, slices, standard library ("fmt" and things it imports), etc.

That part is constant. Once you write more code, the generated output will grow very gracefully as expected.

The output is quite large (order of 1~2 MB), even when minified, so it might not work well yet for user facing sites with huge traffic. That could be an ongoing improvement effort for GopherJS to benefit from. However, for smaller sites or offline utilities it works absolutely great.

[ Parent | on HN ]

Re:GopherJS – A compiler from Go to JavaScript by bitg on Tuesday October 14, 2014 @07:29PM (#8456417)

The original output is very large but when gzipped it's surprisingly small. For example an app in my framework that gopherjs produces is like 1.2MB minified, but the gzipped one is just over 200kb, so no problem.

[ Parent | on HN ]

Re:GopherJS – A compiler from Go to JavaScript by cromwellian on Wednesday October 15, 2014 @02:56AM (#8457432)

Download size isn't the only issue. Larger scripts are slower to parse and startup, slow down debugging tools, inhibit JS VM optimizations and use up more heap in general.

This may not matter on desktop intranets, but it will matter on the mobile web.

[ Parent | on HN ]