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

--

Search Discussions

  • Larry Clapp at Sep 28, 2012 at 3:54 pm

    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 at Sep 29, 2012 at 5:50 am
    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 at Sep 29, 2012 at 6:41 am
    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 at Sep 29, 2012 at 6:56 am
    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.
    On Saturday, September 29, 2012 12:41:52 AM UTC-6, David Wright wrote:

    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
    --
  • David Wright at Sep 29, 2012 at 7:24 am
    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
    On Saturday, September 29, 2012 2:56:19 AM UTC-4, Kevin Gillette wrote:

    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.
    --
  • Kevin Gillette at Sep 29, 2012 at 8:18 am
    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.
    On Saturday, September 29, 2012 1:24:46 AM UTC-6, David Wright wrote:

    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
    On Saturday, September 29, 2012 2:56:19 AM UTC-4, Kevin Gillette wrote:

    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 at Sep 29, 2012 at 8:38 am
    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 4:18:31 AM UTC-4, Kevin Gillette wrote:

    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.
    On Saturday, September 29, 2012 1:24:46 AM UTC-6, David Wright wrote:

    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
    On Saturday, September 29, 2012 2:56:19 AM UTC-4, Kevin Gillette wrote:

    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.
    --
  • Kevin Gillette at Sep 29, 2012 at 10:17 am

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

    --
  • ⚛ at Sep 29, 2012 at 9:20 am

    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.

    --
  • Ziad Hatahet at Oct 3, 2012 at 12:07 am

    On Sat, Sep 29, 2012 at 12:24 AM, David Wright 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 at Oct 3, 2012 at 1:32 am
    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

    On Tuesday, October 2, 2012 8:07:56 PM UTC-4, Ziad Hatahet wrote:



    On Sat, Sep 29, 2012 at 12:24 AM, David Wright <d.wrig...@gmail.com<javascript:>
    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
    --
  • Mikael Gustavsson at Sep 29, 2012 at 7:28 am
    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
    On Saturday, September 29, 2012 7:45:04 AM UTC+2, Anssi Porttikivi wrote:

    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
    --
  • Joe Farro at Sep 29, 2012 at 7:59 am
    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.
    On Saturday, September 29, 2012 3:28:44 AM UTC-4, Mikael Gustavsson wrote:

    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
    On Saturday, September 29, 2012 7:45:04 AM UTC+2, Anssi Porttikivi wrote:

    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
    --
  • Anssi Porttikivi at Sep 29, 2012 at 8:05 am
    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.

    --
  • Martin Angers at Oct 3, 2012 at 1:47 am
    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).

    Le vendredi 28 septembre 2012 10:51:21 UTC-4, Anssi Porttikivi a écrit :
    ...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?
    --
  • András Belicza at Feb 4, 2013 at 4:22 pm
    Hi!

    There is a new Go Web UI Toolkit (Gowut) which implements this and more.

    Gowut home page: https://sites.google.com/site/gowebuitoolkit/
    Gowut project site: http://code.google.com/p/gowut/
    Gowut documentation:
    https://sites.google.com/site/gowebuitoolkit/documentation

    Regards,
    András Belicza
    On Friday, September 28, 2012 4:51:21 PM UTC+2, Anssi Porttikivi wrote:

    ...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?
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 28, '12 at 2:51p
activeFeb 4, '13 at 4:22p
posts17
users10
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase