Please note To goal of the v1.0 release is to get vugu stable, updated to work with the current Go tool chain, to make vugu easier to use from a developer perspective - including both simpler tooling and better documentation.
We don't want to take major new features in this release. We can focus on these after the v1.0 release.
If there is something that you think is missing for the v1.0 release can you please give us your feedback in issue #246.
If we keep everything in Issue #246 then the complete discussion thread is available.
We'll update this issue based on that discussion.
Please consider this list a draft. @bradleypeabody and I have been discussing what we want to change via Slack. This list represents our current thoughts.
ToDo
[x] Build with go v1.21.4+. We intend to only support the two versions of Go that the Go team support going forward. Which Tinygo versions we support is still to be discussed.
[x] Upgrade Vugu dependencies.
[x] Upgrade TinyGo to v0.30 (the current version).
[x] Lint the vugu source code with golangci-lint. Note: we need to add a config for this into the repo.
[x] Document how to build a vugu application using only the standard Go tool chain.
[x] Document how to deploy a vugu application using nginx as a web server.
[x] Correct the auto-generated comment to match the standard Go form. PR #261
[X] Add _gen to generated file names. PR #261
[ ] Extend/Update the examples in the vugu-examples.
[ ] Move to a Taskfile based build process for the vugu-examples. And recommend this approach for all vugu projects.
[ ] Move to a Taskfile based build for vugu itself. This simplifies building and testing vugu locally. PR #263
[ ] Create a new vgutil tool to help simplify the Taskfile. This is largely used to generate a new index.htnml file from a Go template.
[ ] Depreciate the vgrun tool. The new Taskfile approach supersedes it.
[ ] Depreciate the devserver.go development server. The Taskfile approach uses an nginx in a container to serve the vugu application.
[ ] Depreciate the current Building and Distribution advice. The new documentation that shows how to deploy to an nginx server and the Taskfile approach both make this redundant.
[ ] Document (and show in the examples) how things like CSS processors or webpack builders can be called from the Taskfile rather than make then part of vugu itself.
[ ] Depreciate the "FullHTML" mode. The new Taskfile approach and the new vgutil command that generates the index.html file from a Go template make this redundant (as far as I can tell!).
[ ] Depreciate the simplehttp package? Note: We don't need this for production any more, but we may need it for testing. So this may move the simplehttp package to a test support package.
[ ] Possibly spit the test suite into three. One suite each that uses the standard Go compiler, a tinygo compiler installed locally, a tinygo compiler in a docker container. This would simplify testing of vugu.
[ ] Work out what happens to the vgform package. At the minute we plan to build the examples and use those to see if this package needs to be updated (if at all).
[ ] Fix any outstanding bugs :smile:
[ ] Update the vugu.org website so that the documentation is consistent with the new advice.
Examples
At the minute we are thinking of reworking the vugu examples as a tutorial series. The topics are likely to be:
A simple example that shows you how to build and deploy. This is likely to be variation on the existing simple example but reworked to show you how to use the new Taskfile approach.
A set of examples that show:
How to manipulate the DOM
How to create new components
How to wire components
How routing works
How to organise source code to split the Go source files (which contain the logic) from the .vugu files which contains the layout, and the CSS files that contain the presentation.
How to manage long running tasks e.g. HTTP fetch calls from vugu.
Maybe show how JS scripts can be integrated. This is likely to be limited to scripts that do not manipulate the DOM. Using an existing JS charting library would be a good example of what we might support.
How to integrate with other tooling e.g CSS minimisers or packers, by extending the Taskfile. Possibly based on Tailwind CSS (or Bootstrap CSS or both?)
A more complete and fully production ready example, possibly based the taco-store example.
An example that uses tinygo to demonstrate the different ways tinygo can be run to create the final Web Assembly.
If you can think of a topic that is not listed here or a common problem, can you please let us know? We can then add it to the documentation and as a worked example.
Building and Deploying with Go and Nginx
Just so folks are aware of this. There is a new Wiki page that documents how to build vugu applications using only the standard Go tool chain.The resulting Web Assembly is then deployed into a nginx web server running in a container.
This is still a draft document, so feedback from the community would be welcomed.
Moving to a Taskfile based build
@bradleypeabody and myself has been discussing this. We now have a prototype approach that seems to work, and makes building a vugu application a lot simpler.
Taskfile is written in Go so it is portable to Windows and MacOS (unlike a GNU Makefile). The steps in the build are then defined in a YAML file that Taskfile processes. This change will also allow us to depreciate the vgrun tool which is less code for us to maintain. So watch this space as this is likely to be rolled out incrementally starting with the examples.
At the minute we are using nginx as the web server, running inside a docker container to serve the vugu application, rather than the previous approach of an inbuilt web server. This is simpler as it means we do not need to maintain the existing internal web server code.
The approach is also easy to adapt if you needed to use an apache web server for example.
The new vgutil tool
Until now vugu has been generating a simple index.html that is sufficient to load your CSS stylesheet, fetch the Web Assembly file that is your vugu application and start executing it. vugu has also been serving this generated index.html file for you via its own web server.
We want to change this so that the index.html file is generated explicitly and saved on disk. It can then be served by any web server (all via the Taskfile). The new vgutil tool is how we want to do this.
vgutil will take some command line parameters and feed them into an Go template file that is then run though the Go template engine to produce a new index.html file for you. If you customise the Go template file the updates will be reflected in a newly generated index.html file.
Previously to do this you would have had to change the code of the devutil package to achieve the same result. And you'd still be using the internal web server in this case as well.
Thanks
Can we say thank you to @Lord-Y for his PR's that have updated the Go, TinyGo versions, the dependency updates and fixing the golang-ci linter errors. It has really helped @bradleypeabody and myself move things forward.
Updates
23/12/23: The _gen.go file name change and the auto-generation comment are now merges. See PR #261. Moving vugu to a Taskfile build is in progress. See PR #263 for the latest comments.
Background
With reference to Issue #246
This issue serves as the ToDo list for Vugu v1.0.
Please note To goal of the v1.0 release is to get
vugustable, updated to work with the current Go tool chain, to makevugueasier to use from a developer perspective - including both simpler tooling and better documentation.We don't want to take major new features in this release. We can focus on these after the v1.0 release.
If there is something that you think is missing for the v1.0 release can you please give us your feedback in issue #246. If we keep everything in Issue #246 then the complete discussion thread is available.
We'll update this issue based on that discussion.
Please consider this list a draft. @bradleypeabody and I have been discussing what we want to change via Slack. This list represents our current thoughts.
ToDo
Tinygoversions we support is still to be discussed.vugusource code with golangci-lint. Note: we need to add a config for this into the repo.vuguapplication using only the standard Go tool chain.vuguapplication usingnginxas a web server._gento generated file names. PR #261vugu-examples. And recommend this approach for allvuguprojects.vuguitself. This simplifies building and testingvugulocally. PR #263vgutiltool to help simplify theTaskfile. This is largely used to generate a newindex.htnmlfile from a Go template.vgruntool. The newTaskfileapproach supersedes it.devserver.godevelopment server. TheTaskfileapproach uses annginxin a container to serve thevuguapplication.nginxserver and theTaskfileapproach both make this redundant.Taskfilerather than make then part ofvuguitself.Taskfileapproach and the newvgutilcommand that generates theindex.htmlfile from a Go template make this redundant (as far as I can tell!).simplehttppackage? Note: We don't need this for production any more, but we may need it for testing. So this may move thesimplehttppackage to a test support package.tinygocompiler installed locally, atinygocompiler in a docker container. This would simplify testing ofvugu.vgformpackage. At the minute we plan to build the examples and use those to see if this package needs to be updated (if at all).Examples
At the minute we are thinking of reworking the
vuguexamples as a tutorial series. The topics are likely to be:Taskfileapproach..vugufiles which contains the layout, and the CSS files that contain the presentation.vugu.Taskfile. Possibly based on Tailwind CSS (or Bootstrap CSS or both?)tinygoto demonstrate the different waystinygocan be run to create the final Web Assembly.If you can think of a topic that is not listed here or a common problem, can you please let us know? We can then add it to the documentation and as a worked example.
Building and Deploying with Go and Nginx
Just so folks are aware of this. There is a new Wiki page that documents how to build
vuguapplications using only the standard Go tool chain.The resulting Web Assembly is then deployed into anginxweb server running in a container.This is still a draft document, so feedback from the community would be welcomed.
Moving to a
Taskfilebased build@bradleypeabody and myself has been discussing this. We now have a prototype approach that seems to work, and makes building a
vuguapplication a lot simpler.Taskfileis written in Go so it is portable to Windows and MacOS (unlike a GNU Makefile). The steps in the build are then defined in a YAML file thatTaskfileprocesses. This change will also allow us to depreciate thevgruntool which is less code for us to maintain. So watch this space as this is likely to be rolled out incrementally starting with the examples.At the minute we are using
nginxas the web server, running inside a docker container to serve thevuguapplication, rather than the previous approach of an inbuilt web server. This is simpler as it means we do not need to maintain the existing internal web server code.The approach is also easy to adapt if you needed to use an
apacheweb server for example.The new
vgutiltoolUntil now
vuguhas been generating a simpleindex.htmlthat is sufficient to load your CSS stylesheet, fetch the Web Assembly file that is yourvuguapplication and start executing it.vuguhas also been serving this generatedindex.htmlfile for you via its own web server.We want to change this so that the
index.htmlfile is generated explicitly and saved on disk. It can then be served by any web server (all via theTaskfile). The newvgutiltool is how we want to do this.vgutilwill take some command line parameters and feed them into an Go template file that is then run though the Go template engine to produce a newindex.htmlfile for you. If you customise the Go template file the updates will be reflected in a newly generatedindex.htmlfile.Previously to do this you would have had to change the code of the
devutilpackage to achieve the same result. And you'd still be using the internal web server in this case as well.Thanks
Can we say thank you to @Lord-Y for his PR's that have updated the Go, TinyGo versions, the dependency updates and fixing the
golang-cilinter errors. It has really helped @bradleypeabody and myself move things forward.Updates
23/12/23: The
_gen.gofile name change and the auto-generation comment are now merges. See PR #261. Movingvuguto aTaskfilebuild is in progress. See PR #263 for the latest comments.