live code reloading (asset package based on vfsgen)

[emidoots]

I've long considered that running Vecty code as part of a Go webserver is a common use case, as opposed to a purely client-side application (which can be easily ran via gopherjs serve).

I think that an asset loading package which can provide the basics of:

• Perform live code recompiling (as gopherjs serve does), easily via a nearly one-liner call.
• Easily package the client-side JS code bundle into your Go server binary for serving in a production environment.
• Potentially enable packaging other smaller assets into the binary, too.

Would do us a world of wonders. I've prototyped this a while back mostly successfully at https://github.com/slimsag/vecty/tree/master/asset

Inspiration for this idea is drawn by a lot of fine work by @shurcooL around these projects:

• https://github.com/gopherjs/gopherpen
• https://github.com/shurcooL/vfsgen
• https://github.com/shurcooL/gopherjslib

The goal is to make starting a Vecty application backed by a Go server a super-simple process without any real involvement or understanding about what is going on behind the scenes (e.g. what vfsgen does, or how gopherjslib does things).

[ghost]

I've written a simple command line tool that I use to work on app engine development at https://github.com/xoviat/gaepher. It currently only works with GAE but I can make it work for other scenarios with some feedback.

[emidoots]

Something I've realized new users (and myself) hit into a lot is wondering whether or not what you are seeing in the browser is truly updated & recompiled code or some stale, maybe browser-cached version of the code.

I wonder if this could be solved by placing a 'revision' on the page that increments, or a color that changes or something.

[dmitshur]

Perhaps worth noting, something I want to find a chance to force myself to do is rewrite the vfsgen README significantly. Right now, it reads from lowest-level usage details at the top, to highest-level (most useful) at the bottom.

I want to flip that around, and make vfsgendev the main target of the README, and push vfsgen low-level usage down to the bottom, if at all. So the top of the README will start by saying, here's an optimal way to create a package for embedding assets in a project. It will provide example code and link to all the helpful relevant components.

The idea is to make it so people can jump into the "best practice" I've come to after years of research and iteration, without having to rediscover it from scratch themselves.

[johanbrandhorst]

@shurcooL Would love to see a blog post or something on these best practices - I only discovered vfsgen in the issue on go-bindata being abandoned.

[emidoots]

I've pushed my most up-to-date WIP for this at https://github.com/gopherjs/vecty/tree/sg/asset

There would still be a lot to do / figure out before we would merge such code, however. Mainly:

https://github.com/gopherjs/vecty/blob/9c461781e6bc27bade3cdd8c1e266c0d4d272f0a/asset/server.go#L4-L12

It's also lacking any integration of vfsgen / vfsgendev, i.e.:

Easily package the client-side JS code bundle into your Go server binary for serving in a production environment. Potentially enable packaging other smaller assets into the binary, too.

Which would probably require introducing ./cmd/vecty