We use the GopherJS transpiler to convert a Go program into a JavaScript program. Figure 3.5 depicts a Go program that not only makes use of the functionality from the Go standard library but also uses the functionality from various JavaScript APIs using the equivalent GopherJS bindings package:
We use the gopherjs build command to transpile the Go program into its equivalent JavaScript representation. The produced JavaSript source code is not meant to be modified by humans. The JavaScript program has access to the underlying JavaScript runtime embedded in the web browser, along with access to common JavaScript APIs.
With regard to IGWEB, we have organized the front-end Go web application project code inside of the client folder. This allows us to neatly separate the front-end web application from the back-end web application.
Figure 3.6 depicts the client project folder containing numerous Go source files:
Upon running the GopherJS transpiler on the Go source files inside the client folder, by issuing the gopherjs build command, two output files are created. The first output file is the client.js file, which represents the equivalent JavaScript program. The second output file is the client.js.map file, which is a source map that's used for debugging purposes. This source map helps us when we are chasing down bugs using the web browser's console by providing us detailed information on produced errors.
The gopherjs build command is synonymous in behavior with its go build counterpart. The client project folder can contain any number of subfolders, which may also contain Go source files. When we execute the gopherjs build command, a single JavaScript source program is created along with a source map file. This is analogous to the single static binary file that gets created when issuing a go build command.
Code that is shared between the server and the client, outside of the client folder, may be shared by specifying the proper path to the shared package in the import statement. The shared folder will contain code that is to be shared across environments, such as models and templates.
We can include the GopherJS produced JavaScript source file as an external javascript source file in our web page using the <script> tag, as shown here:
<script type="text/javascript" src="/js/client.js"></script>
Keep in mind that when we issue a gopherjs build command, we are not just creating a JavaScript equivalent of the program we are writing, but we are also bringing along any packages from the standard library or third-party packages that our program relies on. So in addition to including our front-end Go program, GophjerJS also includes any dependent packages that our program is dependent on.
The ramification of this fact is that the produced JavaScript source code's file size will grow proportionately to the amount of dependencies we introduce in our Go program. The other ramification of this fact is that it doesn't make sense to include multiple GopherJS produced JavaScript files on the same same web page as depicted in Figure 3.7, since dependent packages (such as common packages from the standard library) will be included multiple times, unnecessarily bulking up our total script payload and offering no value in return:
A web page should therefore, at maximum, include only one GopherJS produced source file, as depicted in Figure 3.8:
