Recent versions of Chrome, Firefox and Microsft Edge support WebAssembly and have been tested with basic Vugu functionality.

Any browser that supports WebAssembly and is targetable by the Go compiler should work. Mobile browser support is not yet well tested but moving forward the Vugu project is intended to support mobile to the extent that WebAssembly is.

Vugu files (.vugu) do not generally contain any JS at all, only Go code.

That said, access from a WebAssembly program to the Document Object Model does require calls to JavaScript methods. There is a small JavaScript file used internally by Vugu during the render process which is automatically embedded in each Vugu app. Also, Go's WebAssembly support currently requires wasm_exec.js to be loaded, another small file that provides some needed support and integration for the Go runtime.

But everything else is just Go code running as WebAssembly. For example when a handler for a click is registered, Vugu will call the appropriate addEventListener method on the DOM. And when the event is fired, the relevant data is collected up about the event on the JS side and a call is then made into your Go Wasm program with the event info. Everthing else is Go from there: Vugu receives the event and makes the appropriate call to your code.

Vugu now supports, in addition to the default Go compiler, compilation with TinyGo. This significantly reduces the size of WebAssembly executables and often produces .wasm files measured in hundreds of kilobytes.

Using the default Go compiler, the binaries can be big, yes. However, they gzip better than one might expect for a binary. The average browser download of compressed content for a reasonably-sized program is several megabytes. For some use cases this is completely workable, others it's a problem. Future improvements in size can be expected as the WebAssembly spec and Go's support for it both evolve.

So far performance has been pretty good, but more testing is needed with larger applications.

For now, everything is experimental.

Vugu uses Go Modules which helps give developers expectations on API compatibility. No release date is set for Vugu 1.0, so if you need some guarantee of API stability you can lock to a specific development version.

A major refactor was done between Vugu v0.1.0 and v0.2.0, which among other things, involved a shift from dynamically registered components to component references being expressed statically so they are resolved at Go compile time. This was a major breaking change but was necessary to handle some fundamental issues that came up with the initial prototype for this project. While major breaking changes are unfortunate, the goal is to get those out of the way early, so stability improves moving forward. It is expected that the scope of the changes will continue to narrow and be more involved with adding features rather than rewriting things.

WebAssembly support in Go itself is also currently experimental and breaking changes may arrive with each new release. We'll do our best to update Vugu following Go releases as quickly as possible.

Once WebAssembly is no longer experimental in Go, and more mature in general, Vugu 1.0 will probably be released at that time.

Short answer: Because templates do not provide type safety or other compile-time checks.

This was a major decision in Vugu's overall design and was not made lightly. There are certainly arguments in favor of using templates, such as the fact that some expressions are shorter to represent and easier to understand. Templates also can be evaluated at runtime and do not require a Go compiler.

This is contrasted by the fact that one of the major drawbacks to building a large user interface in JS is the lack of type safety and other compile-time checks. The TypeScript people invented a whole new language to address the problem. The larger the code base, the more you need types and a compiler. Modern UIs can be very sophisticated and Vugu intends to support complex projects well. To do that, we need to leverage the Go compiler, which means that templates have Go expressions in them, not template code.

That said, it is not impossible that html/template support will be added to Vugu as an additional feature in the future.

The intention is to provide feature parity with Vue/React/Angular.

A lot of the basic functionality for markup, components and DOM events is already working well.

Some features don't translate well (like data binding), but still, the idea is that by the time we get to 1.0 "pretty much anything you can do in Vue, React or Angular, you can do in Vugu".

You'll also need to use go generate with vugugen to convert your your .vugu files to .go before building. But otherwise, yes, no special build tools are required.

However, for convenience, there is a development webserver (implements the standard http.Handler) which can be used to rapidly prototype new projects and takes care of building your project to a .wasm file on the fly and serving it to the browser.

Read more in the Build and Dist section.

One of the core ideas behind Vugu is that it is fundamentally a library, rather than a framework. The distinction being that with a framework, it calls your code. With a library, you call it. It is considered vital to the success of this project that we use existing Go tools and not try to unnecessarily wrap things or obscure the regular tools that Go developers are used to. At the end of the day, Vugu programs are just regular Go programs - with a main function and you call some methods in the Vugu library. Keeping that idea in place as the project evolves is a core concept behind Vugu.