This. Go makes it fantastically simple to go from 0-to-web-server.
There were a few projects I wanted to write in Go, but avoided because of needing a GUI.
Then I remembered: I can just bolt a web-page onto my app, and I get a GUI for free [assuming knowledge of HTML/CSS/JS].
Even better: that GUI will work on any computer with a modern web-browser, including my phones. If you stick to standards, it should even be a reasonably consistent UX across the newer browsers.
---
While I would still _like_ to see a good UI toolkit for Go, I really think it's less of a necessity than most would have you believe.
I'm playing with the idea of a Cairo/Postscript type library with X, Win32, Quartz backends in Golang which would be a good foundation for such a thing.
I have got precisely nowhere apart from trying to connect to an X server unsuccessfully though :)
I find programming to be easy (relatively). I find interfaces to be almost insurmountably difficult. That's the only reason I stick exclusively to command-line programs.
Odd. Here's my 5 min explanation of how GUI programming works:
You have a bunch of objects that are responsible for generating events and painting themselves to the screen. They exist in hierarchies. You have objects that coordinate the transitions between different display states by swapping out different hierarchies (view FSMs, really.) You communicate with your domain backend thread/process through some kind of command channel. When your domain models change, they publish some events that go back through that channel to notify your display hierarchies so they can update themselves. Everything is async and through message passing.
The difficulties can be in a) setting up your hierarchy of display objects and b) getting your event routing / updating to happen in a clean way. Oh yea, and c) handling partially-complete domain models in the ui ;)
Cocoa/CocoaTouch and Flex are both quite nice environments for gui programming. I haven't used MFC, winforms or xaml/winrt..
Of everything you describe, I think the area I struggled most with was:
>getting your event routing / updating to happen in a __clean__ way.
I was a naive and young programmer, so I'll withhold any criticisms towards WinForms, but the event routing was a _mess_ by the end of that project.
That's a personality type (mine too). Probably best to bite the bullet with HTML/CSS. I think non-web interface builders are a thing of the past. Which is too bad, because CSS is a monster to master.
Developers need tools too so we shouldn't just abandon non-web technologies.
No. [Edit: I'm talking about apps that use webviews make a native-looking app. Web apps don't qualify.]
Colloquy represents the chatroom text as a stream of XML, which it uses XSLT themes to translate into HTML, which is displayed in a WebView. I'm sure Adium does something similar.
"Using HTML/CSS/JS as the new GUI medium" doesn't limit itself to just running stuff in a traditional browser. I was under the assumption that we were talking about making HTML/CSS/JS the new GUI layer, even for native apps.
Implementing a top-class GUI toolkit that is not just a binding to an existing one would be at least half a decade of work. And when it's done all GUIs will be rendered by web views anyway. The web is the presentation layer of the future. Classic desktop widget sets like QtGui or Swing will fit nowhere, because all the consumer operating systems like iOS, OS X, Android and Windows 8+ will have highly custom user interface paradigms, which won't be mappable to each other by some cross-platform thing.