Hacker News Reader

Comment by mseepgood | Hacker News Reader

The creators of Go have cluster a.k.a. cloud computing in mind: http://www.youtube.com/watch?v=FTl0tl9BGdc And the predictions in this article are about PaaS / IaaS / orchestration, which have not a lot to do with GUI.

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.

View on HN

>just a web view anyways

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.

Agreed.

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 really wish all languages had an IDE that included an interface builder as nice as Visual Studio. Making a VB.NET program really is rapid application development, because in most cases you don't even need to write more than a dozen or so lines of code.

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.

> I find programming to be easy (relatively). I find interfaces to be almost insurmountably difficult.

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.

>I find interfaces to be almost insurmountably difficult.

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..

Full disclaimer: I haven't done much UI (outside of HTML/CSS/JS, that is)... I dabbled with Visual Basic and the associated tooling (WinForms, at the time) during my college courses.

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.

Idea: a Go HTML GUI toolkit designed to allow writing a GUI in real Go code without thinking about html, css, ajax, etc. It just abstracts that stuff away, providing a much more standardized/typical GUI programming experience, all the while running a web server and generating HTML on the fly.

I think developers will stay on traditional desktop systems, most likely a Linux since Apple and Microsoft target consumers(consuming videos, browsing the web or using only specific applications like Excel).

Developers need tools too so we shouldn't just abandon non-web technologies.

There's no reason why development tools couldn't be moved to the web. It's already happening with Github. And Github could include an IDE like Cloud9 one day.

I've been out of the OSX-space for a while. Are there a lot of apps using web views for their GUI? The only ones I can think of are Colloquy and Adium. Even then, they don't do the whole GUI as a web view, just the parts of the display that are theme-able.

> Are there a lot of apps using web views for their GUI?

No. [Edit: I'm talking about apps that use webviews make a native-looking app. Web apps don't qualify.]

All the apps developed for the web outnumber the apps in the app store.

Maybe I should have specified WebView rather than web view. IIRC, a WebView is a ready-to-go embed-able WebKit widget in the toolkit of OSX GUI developers.

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.

Reply on news.ycombinator.com