Go Template Preview (or gotemplate.io) is a small tool for Go developers.
It aids them in writing text and html templates.
Here's a detailed explanation of what Go Template Preview is.
TL;DR: it's a web-based tool to aid Go devs in writing templates.
Now this is the part that I never stop talking about!
My background is computer networking, so I'll do what we call a "packet trace".
First, you land on gotemplate.io. Let's assume you start using it right away.
template(t, d) which takes both your template and data as inputs, and returns the rendered text as output.
Now, if you know how, and try to inspect the
render function, you'll quickly be able to read it. But if you try to do the same with the
template one, you won't be able to read it anywhere on the site.
But why? If my browser is running the code, I should be able to read the code!
Well, a few years ago, this new browser technology was presented, called WebAssembly.
Coincidentally, one of the first languages that added WebAssembly support was Go.
This allows me to build Go Template Preview without rendering your templates myself.
There are no back-end services or APIs that render your templates remotely.
Your browser does it all!
This has its pros and cons:
However, it has a couple of cons:
So back to where we were.
When gotemplate.io finished loading in your browser, it started running the
template.wasm binary on the side, as a subprocess.
This Go binary then exported the
render() can call it. Once it has, it does a couple error handling chores and, if everything went well, it shows you the output.
This happens every time you press a key.
Well... I agree. But have you used it? It goes FAST!
I tried adding some few-millisecond delay between key press events and
template calls, but it only made the site feel slower, not faster, so I got rid of them.
Yeah... I know. But there's not much I can do. Go is heavy.
I tried TinyGo, but I need
reflect to decode your JSON data. It's in the works.
It was heavier in the beginning, because I was interacting with the DOM from Go itself, which required a library that grew the binary to about 21 MB.
In fact, if I were to write a "lessons learned" document, number one would be that Go won't make it into the browser unless binary size is heavily reduced. As much as I love Go, its use in the browser is currently limited to small, specific use cases like this site.
That said, with the performance Content Delivery Networks offer these days (see below) size is not as much of a concern as it used to be.
This is my favourite part.
Ever heard of Amazon? Well, I use their Simple Storage Service (S3 for short) for hosting the site. This gives me a simple, plain HTTP server to host the site.
I still need a couple of things though: TLS (to serve the site over HTTPS); and it'd be great to reduce the amount of bucket egress traffic since AWS is notoriously expensive.
Not only do they handle TLS certificates (for HTTPS) and caching (to reduce S3 egress volume), but they also put copies of the WebAssembly binary in servers all around the globe, and serve you the nearest copy every time you visit the site.
This is known as a Content Delivery Network (or CDN).
They also handle domain registration and DNS for gotemplate.io, too.
On top of that, gotemplate.io is on their Free plan, so they to all of that for free!
This is a nice segue to the next part of this document.
Well, Cloudflare manages most of the egress traffic at zero cost.
The S3 egress traffic is residual and negligible (I pay for it, but don't mind the bill).
So the site runs for pretty much nothing.