A brief history of Wade.Go

It has been over half a year since I started the development of Wade.Go (https://github.com/phaikawl/wade), my effort to create the next gen web development platform. It always bugged me that client-side code must be written in Javascript-family dynamic languages, leading to code that are hard to maintain. Wade.Go is a unique web framework written in and for Go that is client-centric. It's meant to be compiled to Javascript on browser with gopherjs and can render the same thing perfectly on server, set out to compete with the likes of AngularJS, ReactJS, etc. I want to make it real, the dream of being able to develop full websites in Go, both client and server side with the innovative client-centric approach.

There has been 3 iterations of Wade, each associates with new understandings, involves fundamental changes in the way Wade.Go works, and makes Wade.Go much much better. Iteration 4 is now in development, Wade.Go is still nowhere near ready to be released.

It has evolved from being completely reliant on Javascript in Iteration 1 (must be compiled to Javascript to do anything) and has no way to test itself, to a robustly go-test'ed system that could also run perfectly in native Go to render on server. It even supports writing "functional" client-side test in native Go that doesn't need a browser to run, just go test .

Iteration 3 tried to bring virtual DOM mechanisms learned from React.js family into play, and I thought it would achieve all the goals I had in mind about a big upgrade performance, but I was wrong, I made a big mistake in not carefully evaluating whether the end result could achieve good performance. It turned out, reflection became the new bottle neck, and Wade.Go was still slow, in another way.

At the end of Iteration 3, I came up with a new idea, a big change in templating that fits the virtual DOM mechanism and would solve everything, like it would become 100X better. I was excited, started working on it, but soon I realized that most of the work I put into Iteration 3, a huge refactor in months, is wasted, the core code must be rewritten. Iteration 3, being nearly finished, ended in regret and frustration.

But I have never thought of giving up. Iteration 4 has begun, I realized this is in fact an oppotunity for changing another big thing that should be changed.

Call for involvement

Although at various points there were some involvement, including code contribution, from interested people, I have been basically the only developer working on Wade.Go. I avoided spending time on stuff that are not real development, although it saves a bit of time in that sense, in the long run it's not good. Tremendous inspirations has come to me recently that made me realize this is the opportunity to make a transition, not later.

So I'm inviting enthusiastic gophers from anywhere in the world, may be you, to join the core developmentteam of Wade.Go Iteration 4, as long as you have the time, ability and are excited about the things Wade.Go is aiming for. I want to make a team of 3 or 5 people to develop it together. I know it will be difficult to get the ideas across in the beginning, but it's worth it, I want to spend serious efforts on this. Please send me an email to phaikawl[at]gmail.com if you want to join.

What's great about Wade.Go Iteration 4?

Wade.Go's current templating system has serious flaws and it also doesn't work well with virtual DOM mechanism. However doing something like Mithril.js (they write virtual DOM representation directly in Javascript) would be quite inconvenient with a language like Go, so we don't choose that path. Making something like React's JSX for Go is also a big NO.

So I came up with an idea, HTML markup for Wade.Go-based applications would still be written in valid HTML for convenience, but those HTML files are not served directly. Instead, a "template compiler" will compile the HTML files into Wade.Go's virtual DOM representation, which is vanilla Go code, subsequently compiled as part of the Go application. The virtual DOM will be used on all processing and rendering similar to React.js's mechanism. So what does it bring?

Safety : The template's data binding code, for example {{ len(Comments) }} , is put into real Go code and becomes something like func() interface{} { return len(Comments) } . So those mistakes like "undefined name", "invalid type" in template code no longer have to be detected at run time! They are all type-safe and compiled by Go's compiler, giving errors like app.go:102: invalid operation: Choice == 1 (mismatched types string and int) , no more ridiculous hidden errors in template!

: The template's data binding code, for example , is put into real Go code and becomes something like . So those mistakes like "undefined name", "invalid type" in template code no longer have to be detected at run time! They are all type-safe and compiled by Go's compiler, giving errors like , no more ridiculous hidden errors in template! Performance: No more run time overhead with templating, no more parsing of data binding expressions, no more need for reflection, Wade.Go would be blazing fast and achieve the desired performance.

What lies ahead?

Iteration 4 is a big undertaking that will bring amazing advancement. I'm excited about the future of Wade.Go, it could form a big ecosystem if catches on. Will it? That depends on how I, we, and may be you, develop it from now. It's been long process already, but the jouney has just begun, hopefully I will find suitable companions to develop it.

Thanks for reading this wall of text, if you have any feedbacks please tell me.