If we would have a Go Web browser...

[Anssi Porttikivi]

...toolkit, we could build stand-alone GUI programs packing browser + server. It would not have to take standards too seriously. Does this make any sense?

[Larry Clapp]

On Friday, September 28, 2012 10:51:21 AM UTC-4, Anssi Porttikivi wrote:

It would not have to take standards too seriously. Does this make any sense?

 

No.  If it ignores standards, what's the point?

I've never written a browser or a gui toolkit, but I'm not convinced that a browser would be easier than a gui toolkit, or bindings to some existing toolkit.

If I want to write a web-app, I'll let my users pick their own favorite browser.

[Anssi Porttikivi]

I was notified about:

         https://github.com/mattn/go-webkit, requires: https://github.com/mattn/go-gtk

Some more motivation for my idea:

It looks like the major GUI paradigm for Go currently is Web. Of
course It is ok to run HTTP locally and use your favorite browser.
Going with a totally different GUI paradigm/stack automatically
would make your software a bit against the tide, and also prevent it
running also remotely, on server. And maybe integrate not so well with 

all the local window systems...

Sticking to HTTP/HTML/JavaScript might thus be nice and orthogonal:

- use all the zillion library things and know-how for Web work out there
- trust on one well-known major window-system/OS/hw binding interface,
like going with the Go Webkit above (or whatever emerges as the "best"
browser engine in Go), keeping it as portable as possible, and beautifully

integrated with all important local windows systems.

But packing both sides locally, you can:

- drop all code yout application does not need on the render/client side
- optimize cleverly for one back end, yours
- shortcircuit the communications path, for speed and better latency
(games etc.)
- provide optional extra functionality

[David Wright]

I am interested in client software too, and I think it's a great general purpose language, but libraries are going to be much stronger on the server than on the client for some time. You could always start on something simple with "encoding/xml" and a cross-platform toolkit like https://github.com/skelterjohn/go.wde to play around with, maybe write a help viewer.

If you were to try to build a full-featured web browser in a language other than C, I think you'd quickly find that you should have written it in C. That might not still be true in 5 years, but it's certainly true now.

David

[Kevin Gillette]

I'm not convinced of that. Certainly C is "the fastest" language suitable for such a task, but it's at the worst end of the spectrum for rapid prototyping and feature completion. Since that's all the web is these days, it takes a lot more effort to keep up with evolving standards, and you'll often see, for example, rather simple aspects of css3 spec that take years to get implemented, despite being conceptually/mechanically related to bits that browser already supports.

Pretty much since its inception, Go has been "fast enough" for writing all or part of a browser stack in, and at the very least, something like the ui toolkit, especially for the gtk family, will end up by far being the slowest/least efficient link in the chain. Even browsers that have been written in python, wrapped around webkit, did not have any problems with responsiveness.

[David Wright]

I guess if you only want to write an application that embeds a browser engine, that's something else. I could say I wrote a browser in Go in half an hour last month with my ObjC bindings. WebKit is great. But that's precisely my point, WebKit is (was?) written mostly in C. 

I've seen browsers written in C++ grow in complexity until they become unmanageable as software projects, you eventually have to settle on some subset of the language and police check-ins and that's really difficult to enforce in an open-source project. Mozilla finally pulled it off, but it's always leaked like the dickens. And I've seen a couple of browser engines written in Java fail for different reasons. JavaBeans due to neglect and poor performance, and Jazilla due to both and also a lack of original thinking. Apart from that, I believe emacs embeds a browser written in emacs lisp, but it's an emacs lisp web browser.

The other issue is that the first part of building a browser has always been assembling the myriad dependencies required to render a thousand different media types. It can be maddening, but if you're using C/C++, at least it's convenient that all of those libraries are written in C.

It's not just a question of Go being fast enough. Go is probably a better language for managing complexity than C (and C is certainly better than C++, which provides open invitations for all comers to add complexity). But Go needs lots of great libraries to be especially useful for writing client applications. We're all working on it; it will take a few years. 

David

[Mikael Gustavsson]

I think this would be a great thing to have:

- A simple go library for writing cross-platform desktop apps

- Using an embedded webkit for rendering and input (including SVG, webGL and all things HTML5)

- Write app logic in Go; no javascript required

[Joe Farro]

Anssi, I think this makes great sense. 

I'm a big fan of the approach of using a browser instance as the GUI layer for an app. This is not unusual, by any means, and may actually be the norm for iOS apps. I'm using this approach to write a browser based front end to the GDB. It's turning out to be quite involved, but I'm learning a lot and it's fun to work on. 

I think web browsers are great for using as your GUI. I see them as extremely mature, virtually ubiquitous, GUI toolkits that are incredibly expressive. Using something like webkit as your GUI layer also means there is a large, highly-trained labor pool available, most of which have a common understanding of practices and patterns for working in that space (not possible without standards, btw). Also, I think it's very tough to beat the text rendering capabilities of web browsers while remaining manageable (seems like a big deal, to me).

The expressiveness of browsers comes with a lot of complexity and among the many potential downsides is the fact that you will probably end up with a substantial amount of logic in JavaScript. And, where to draw the line of what to have in the browser vs in Go is very subjective. I find the fact I'm forced to make and stick with this decision helpful, though.

I should mention that I only have experience with Flash, Interface Builder for iOS apps, and general web stuff.

[Anssi Porttikivi]

I think it is perfectly ok to start with Webkit or any C libraries or any external code, as long as you can pack and distribute that easily with your application. You can then start adjusting the boundary between your Go part and external part, iteratively, version by version. You can also tweak Webkit to your needs/optimizations.

[Kevin Gillette]

I agree with your analysis here, provided the condition you mentioned that the landscape may change in a few years. I think most people who talk about "writing a browser" implicitly mean wrapping around a core set of web libs, like mozilla's or webkit. Aside from the GUI side, I don't think writing a reasonably featured browser is too terribly difficult from scratch, since by the time it is written, most of the tricky parts will have been phased out -- for example, since flash is being superseded by html5 sub-specs for almost all of its use cases, there's not much point in implementing npapi support (since none of the other plugins have enough of an overwhelming market share to make it worth the effort). After a couple years, you'll end up with either the sites that never had tricky bits in the first place, or were well enough maintained to keep up with the times. While there are many examples of deliberate invalid tag use, such as on Google's main search page (using font tags instead of css, to save bandwidth), I'm finding that the number of sites with invalid syntax (like improper tag nesting) is tapering off.  The common stuff, like image handling, is already pretty well supported by Go, and for many users, not having video or audio support (either deliberately left out, or "not yet implemented") would either go unnoticed, or would not necessarily be a deal-breaker.

Also, many people who want to write browsers either don't care about who uses it (they want to do it for their own use, or as a programming exercise), and/or are not targeting "full featured" use, but rather niche use of some kind, where refusal to render bad html is okay (or that bad-tag-stripped mode is an acceptable fallback, rather than bad-tag-quirks mode). Many of these browsers aren't even GUI browsers.

[David Wright]

Ah, but npapi and mp3 are super easy to implement when compared with something like MathML or SVG or, for Pete's sake, performant JavaScript. And don't forget you also need to have all of this evil cruft fully represented in the DOM. On the one hand modern browsers are marvels of engineering. On the other, they had to be, because everything was designed by committees, some of which were entirely comprised of people who would be intensely pleased to if their competitors were entirely incapable of building this ridiculously baroque and questionably useful thing they'd all met to describe.

Web browsers are amazing. Web standards are quite often absolutely laughable. I'm frankly astounded that the thing works as well as it does.

David

[⚛]

On Saturday, September 29, 2012 10:18:31 AM UTC+2, Kevin Gillette wrote:

for example, since flash is being superseded by html5 sub-specs

I do not expect Flash to go away.

The reason why Flash succeeded is that the original HTML specification didn't include universal computation. A non-negligible percentage of web pages needs such universality because there is need to have the free will to set the color of individual pixels and to freely react to user actions. The lowest level is: colors of individual pixels on the output and mouse/keyboard data on the input.

[Kevin Gillette]

On Saturday, September 29, 2012 2:37:58 AM UTC-6, David Wright wrote:

Ah, but npapi and mp3 are super easy to implement when compared with something like MathML or SVG or, for Pete's sake, performant JavaScript. And don't forget you also need to have all of this evil cruft fully represented in the DOM. On the one hand modern browsers are marvels of engineering. On the other, they had to be, because everything was designed by committees, some of which were entirely comprised of people who would be intensely pleased to if their competitors were entirely incapable of building this ridiculously baroque and questionably useful thing they'd all met to describe.

Web browsers are amazing. Web standards are quite often absolutely laughable. I'm frankly astounded that the thing works as well as it does

Yeah. On both parts. Well, speaking of the DOM, its API was a fundamental mistake on just about every level. Pity.

JS implementations are one of the things that really shouldn't be considered subproject. I'd presume to plug in something like V8 and be done with it. However, I'd like to have some middle-ground/infrastructure like a "go-libc", whereby without too much effort, cgo dependencies could compile without needing to link into anything non-exotic, even statically, aside from a shim into the go runtime. I agree that for small problems cgo is a good shim until common facilities get natively written in Go, but for big projects, like a web browser, it makes little sense to try to rewrite something as big as v8 or webkit, just to have it "pure". My own stance is that if I can statically compile it as mentioned above, and in the way that has been done for sqlite, for example (replacing all libc stuff with calls back into go), then it's pure enough.

As for stuff like webkit -- a lot of the brower ideas I want to do in a clean, consistent, non-hackish way are non-mainstream enough (and certainly not for the average user) that I'm not sure if webkit will produce a lot of friction, or make some things impossible based on design assumptions. I haven't looked into it enough, though. The best analogy I can make are all the programs that run on X11 that either assume the presence of non-standard "desktop environment" quirks that go above and beyond (or around) netwm, while utterly failing to work as expected on, e.g. tiling window managers.

Regarding flash: I'm not suggesting there will be some abrupt exodus of developers away from flash and toward html5 equivalents, but to my knowledge, the only thing that flash really provides that the combination of javascript and standards-compliant html5 browsers can't do is arbitrary audio manipulation/synthesis, and that was only added to flash in version 10, iirc. As for the other stuff:

Video: yes

Video Chat: yes, in standards process, some working examples.

Pixel manipulation: yes (canvas, or svg + javascript), even combinable with video.

3D stuff: (shockwave in this case): kinda -- webgl has security setbacks, but is eventually doable.

Prerecorded Audio: yes -- APIs are much saner in html5.

Microphone Input: yes.

Server-push: websockets

Low overhead messages: websockets

Input device handling: wrapping libraries like JQuery make this reasonably portable already.

Fullscreen: something is in standards process, iirc.

Font/typographic stuff: yes. Much cleaner, more capable with much less code than flash now (using css).

Background File Uploading: will probably be addressed at some point, if not already.

At any rate, many systems do not have flash installed anyway -- while much more available than, say, Java, it's much less so than JavaScript. I seem to recall that Adobe has been pushing a lot of sub-specs that make a lot of the "killer features" of flash obsolete. My understanding is that Adobe is considering flash to be a "phase out" product, instead focusing on developing editors for doing stuff in html5/javascript, which adobe proper (as opposed to flash through their acquisition of macromedia) is much more attuned to doing (for one thing, "editors" only need to support mac and windows, as far as they're concerned).

[Ziad Hatahet]

On Sat, Sep 29, 2012 at 12:24 AM, David Wright <d.wrig...@gmail.com> wrote:

I've seen browsers written in C++ grow in complexity until they become unmanageable as software projects, you eventually have to settle on some subset of the language and police check-ins and that's really difficult to enforce in an open-source project.

Google seem to have managed to pull it off (Chromium).

 

Mozilla finally pulled it off, but it's always leaked like the dickens.

That is not an issue with the language directly. In addition, C++11 has constructs to better manage memory use. 

Chrome, IE, Safari, and Opera all have major(?) components written in C++.

--

Ziad

[David Wright]

I don't hate C++. At all. I don't find it especially intimidating or especially interesting, and it's not always the best tool for the job.

My point is that C++ is not and has never been a language for casual users, it doesn't have the same source portability of C, and in practice it's more expensive or labor intensive to maintain a C++ codebase. Maybe the central problem is that it's so complex, major implementations have never done a very good job of tracking standards. I know that this is improving. But the number of man hours that have gone into thinking about simply how to parse the thing... there are other problems in computer science.

I'm aware that Google also uses a restricted C++, and uses it it pretty extensively, internally. And I'm sure that the Chromium people have made informed decisions about where and where not to use C++. But use of C++ in many desktop apps is pretty limited and was actually driven by Microsoft's APIs and tools. And many people just use C and compile it with a C++ compiler.

David

[Martin Angers]

This idea (or a very similar one) already has some traction in the node.js universe, with http://appjs.org/.

This is a cool approach to solve cross-platform desktop GUI apps. It's relatively easy to write a UI in HTML/CSS. It's certainly enough for some types of apps, at least. Native UI gives better integration, performance, etc. It's a similar tradeoff to the one in the mobile world (full native vs native frame with HTML5 core).