DISCLAIMER!!!: THIS APP IS STILL IN ITS EARLY DEVELOPMENT AND HAS NOT BEEN AUDITED FOR SECURITY, SO USE AT YOUR OWN RISK!

TigerChat is a simple peer-to-peer/full-mesh chat app written in Go and transpiled to JavaScript via GopherJS. Every connection is inherently encrypted by WebRTC, and every peer must successfully perform a three-way cryptographic challenge-response handshake using Argon2 with each of the other peers in order to be authenticated with each other. However, while this provides reasonable security for fun chats amongst friends, it's not intended for the transmission of highly sensitive data.

If you are experiencing difficulties connecting to peers, TigerChat is also easily configurable for TURN in cases where your network may be preventing you from establishing peer-to-peer connections. However, while TURN may relay your traffic similarly to a proxy, it should be noted that using TURN does not make you anonymous. The point of TURN is to facilitate real-time communications in instances where peer-to-peer connections cannot be established, not to provide anonymity.

So, again, this is not intended to be a secure, anonymous chat app. It's just intended as a way to quickly and easily chat amongst friends.

If you don't already have access to a TURN server, you can sign up for ExpressTURN (https://www.expressturn.com) absloutely free, go to your dashboard, and you'll be presented with your TURN information which you can use to configure TigerChat for TURN. There are obviously a lot of different options out there for this, but I've found this to be the simplest for folks who are not too tech-savvy, as you can literally sign up and get your information for TURN access all in just a couple of minutes or less.

"But...why written in Go?!?!" Go is clearly a bit clunky when it comes to DOM manipulation. However, the advantages of being able to use Go to compile to native server-side apps (Go), to WASM (Go/TinyGo), and also transpile to JS (GopherJS) make it highly attractive for this portability and not having to context-switch when writing code for full-stack components which may be anywhere in that stack. This also means less of a learning curve and more efficiency with small teams all using the same language for everything.

"Okay... But why GopherJS, and not Go/TinyGo for WASM?!?!" While Go and the Go team feel WASM is "the future" and currently only officially support WASM, there's actually no current design goal by the W3C and friends to make WASM outright replace JS, as many people seem to think. On the contrary, most security professionals agree there are strong security risks for ever allowing WASM out of the current WASM sandbox. So, while WASM is certainly much better than JS at computationally-intensive tasks, it falls short when it comes to accessing anything outside of the sandbox, in which case it makes call-outs to the JS "glue code." In short, that means it's best to divide JS and WASM into separate and distinct functional roles in order to get the best peformance, where you have libraries built in WASM which peform computationally-intensive tasks, and then JS serving as the primary application logic which has direct access to the full unsandboxed JS API.

So, "the future" is actually JS and WASM working together, and it's not about just one or the other dominating the landscape. And in the case of TigerChat, since there's nothing computationally-intensive going on (other than the Argon2 computations, in which case the external Argon2 library loaded does also load a WASM module with it), TigerChat itself is transpiled entirely to JS and nothing compiled to WASM. There's simply no need to do so since it would actually take a performance hit if it was compiled to WASM, as it would just end up making call-outs to the JS "glue code" for the vast majority of its functionality, rather than being able to do anything directly by itself.

And then to further smooth out some of that clunkiness of interacting with the JS API in Go, the jsGo package has also been used in TigerChat in order to simplify DOM manipulation slightly, but also to simplify interacting with the native JS API in general to avoid using the Go standard library wherever possible. Avoiding the Go standard library avoids the inevitable bloat which comes with the multi-layered abstractions needed to support the Go standard library within the JS context. And while large file sizes continue to be hailed as a pain point, file sizes can be dramatically reduced by both avoiding the standard library and also using an optimizer, such as Terser. However, if you do use Terser, it's recommended NOT to use the -m/--minify argument with GopherJS so that Terser can work more efficiently at reducing the output more than GopherJS is currently capable of doing.

For additional notes on jsGo, please refer to its documentation:
https://github.com/ScriptTiger/jsGo

As an example of file size, the resulting TigerChat.min.js itself only amounts to around 80 KB, which is a reasonable size for such a simple app, and also considering about half of that is actualy the GopherJS Go runtime. However, TigerChat does call jsGo.LoadJS to load external JS libraries at run time and no external libraries are bundled together with TigerChat, also reducing the file size. But if you do want to bundle external libraries together with your GopherJS apps, GopherJS makes that easy too by automatically including any files in the project directory ending with .inc.js. And when doing that, it's recommended to NOT use external libraries which have already been minified if you intend to run Terser on the resulting bundle so that it can work more efficiently to reduce the size of the bundle as a whole.

For more ScriptTiger scripts and goodies, check out ScriptTiger's GitHub Pages website:
https://scripttiger.github.io/