We can think of programming as a conversation between you (the programmer) and the machine (the compiler/transpiler). Because Go is a typed language, we can find many errors at compile/transpile time itself. This is a clear advantage to writing vanilla JavaScript where problems (caused by the lack of type checking) can lay hidden and surface at the most inopportune times. Compiler errors are the means by which the machine communicates to us that something is fundamentally wrong with our program, whether it's a mere syntactical issue or the inappropriate use of a type.

kick comes in very handy for displaying compiler errors, since it will show you errors from both the Go compiler and the GopherJS transpiler. The moment you introduce an error (that the compiler/transpiler can identify) and save your source file, you will see the error displayed in the terminal window where you have kick running.

For example, let's open up the client/client.go source file. In the run function, let's comment out the line where we set the ts variable to the TemplateSet object that we receive over the templateSetChannel:

//ts := <-templateSetChannel

We know that the ts variable will be used later to populate the TemplateSet field of the env object. Let's set the ts variable to the Boolean value of false by introducing the following code:

ts := false

The moment we save the client.go source file, kick will give us a kick (pun intended), about the error that we just introduced as shown in Figure A1:

The compiler error received shows us the exact line where the problem occurred, from which we can diagnose and rectify the issue. The lesson to be learned from this example is that it comes in very handy to have a terminal window running kick in the background while you are developing your Isomorphic Go web application. By doing so, you will be able to see compiler/transpiler errors the moment that you make them.