While <script type='application/x-go'> seems to provide initial convenience by including everything for a component in a single file, experience has also shown that it is usually not a good way to maintain Go code. Perhaps if amazing editor support existed the situation would be different, but in general having the markup in whatever.vugu and the Go code in whatever.go makes things a lot simpler and existing editor tooling (both for Vugu has regular HTML and Go as regular Go) tends to just work.
We should decide if we want to deprecate the script tag approach or otherwise advise against it some place in the documentation and/or examples.
This is exactly how I started making components. From the same reason. The only problem is that if I use some imported code inside html, I'm forced to use Githubissues.
Githubissues is a development platform for aggregating issues.
While
<script type='application/x-go'>
seems to provide initial convenience by including everything for a component in a single file, experience has also shown that it is usually not a good way to maintain Go code. Perhaps if amazing editor support existed the situation would be different, but in general having the markup in whatever.vugu and the Go code in whatever.go makes things a lot simpler and existing editor tooling (both for Vugu has regular HTML and Go as regular Go) tends to just work.We should decide if we want to deprecate the script tag approach or otherwise advise against it some place in the documentation and/or examples.