evaluate future direction after Go 1.16 changes

[dmitshur]

vfsgen was created to fill in a gap in the ability to embed files in Go programs, and uses net/http.FileSystem as the central filesystem interface.

Go 1.16 will add //go:embed and io/fs.FS.

This issue is to determine whether a vfsgen v2 should be made that makes use of the new Go 1.16 features, or if there isn't a need for vfsgen v2 because the Go 1.16 features on their own are sufficient for use cases that vfsgen is used for.

What's clear is that vfsgen v0 (the current version) should be v1 and its API should not change.

[silverwind]

go:embed does not feature compression, which is very important for both binary size and asset delivery performance to browsers where the compressed byte stream can be sent out as-is to supporting clients. That alone is why vfsgen is still very useful.

In gitea, we had some discussion on whether to move to go:embed and the conclusion is that it's just not worth to switch unless the compression topic is resolved and that would mean pre-compressing files before generating the embed, complicating the build process.

Now it would be totally awesome of vfsgen could do brotli encoding (#71) because as it stands today, 96.6% of browsers can accept brotli content so it would be the primary asset delivery method as brotli can save around ~20% size compared to gzip, so it's ideal for both binary size and asset delivery performance. As for brotli encoding in pure go, maybe this library is suitable.