Hacker News Reader

Comment by Animats | Hacker News Reader

"This will fetch a 92MB framework containing a binary distribution of the Chromium content module".

Go needed a GUI, but this?

Actually I think the standardization of HTML5/CSS3/JS as the UI framework is preferable to the extreme fragmentation that exists in the "native" UI space

I think there's opportunity in packaging this as a system installed & independently updated dynamically linked library much like WebView is updated on Android KitKat onwards. Eg. a single "system" Chromium component that's installed centrally & used by multiple programs much like Microsoft Runtime DLLs on Windows.

Slowly but surely, the web will re-invent the DLL hell from 2 decades ago

Not only that, but it will also re-invent the WinSXS hell in different ways. We now have modules, but also loaders in all sorts and flavors, we have AMD style, we have the noConflict style, and in the end, the web will probably re-invent snappy apps and flat image packages. Webpages will load an entire in-browser browser of a specific version required to use the page, and we'll all have come full circle. I bet we're gonna see in-browser virtualisation, because just sandboxing and containerization isn't enough.

This is a bit of a stretch. No one seriously writes AMD today and the support of it is solely for backward compatibility due to how trivial it is to support it. CommonJS won that battle when tools like Webpack & Browserify came into existence. ES6 Modules will replace CommonJS once loaders for both the web and node actually make it into existence. Even still, Webpack 2 and Rollup both support ES6 & CommonJS side-by-side.

Instead of potential inconsistency and performance deviations, standardizing on HTML guarantees abysmal performance and subpar user experience.

actually today, I think for most applications, a HTML based UI is good enough performance wise and certainly provides much higher scope for design creativity and flexibility over native framework widgets and views.

The performance improvement has basically come from the massive market that web is and consequently Google, FF and MS optimizing their JS and rendering engines (plus Moore's law)

> good enough

I find that this phrase irks me quite a lot these days. Feels like it's at every corner of software development waiting to pounce and ensure thoroughly mediocre results.

There's something to be said about, "don't let the perfect be the enemy of the good" but at the same time, "good enough", especially when it comes to UI speed/responsiveness and UX quality, feels like a massive cop out. Isn't there a middle ground somewhere that doesn't call for such huge concessions?

The point is that it's not a huge concession, it's what most people are using all day every day anyway.

>Actually I think the standardization of HTML5/CSS3/JS as the UI framework is preferable to the extreme fragmentation that exists in the "native" UI space

We've already solved fragmentation in the native UI space, with GUI toolkits like GTK and Qt. If someone extended those to mobile devices, then we'd have something a lot less terrible than HTML5/CSS/JS, which performed a lot better.

Like Qt Quick?

I was thinking something more like GTK and GLADE, or Qt and Qt Creator. Qt Quick looks like it's kind of halfway between what I'd consider a GUI toolkit and a drawing library.

Why? Disk space is plentiful and costs peanuts, and is becoming cheaper by the day. What's there to gain from having shared libraries other than that it's psychologically satisfying? Having been a Linux user for 12 years, I feel like it's of very limited benefit and has lots of drawbacks. Is there something I am not understanding?

My / has reached 200GB now? And that's despite /home being seperate.

That's the issue.

With this, my / will reach terabytes.

There's two things why not: cheap isn't free, and "elegancy principle": Don't build shitty hacks, build software that's easy to maintain, as minimal as possible, and will be used for decades.

Security.

The same reason security libraries are distributed independently so that they can be automatically updated without the program using them being re-compiled & re-released. On the Android platform, Chromium WebView updates far more frequently than the apps that depend on it & includes security patches on update.

>Disk space is plentiful and costs peanuts

RAM in not as plentiful, nor are level-3, level-2 and level-1 cache. having a second copy or almost-copy of a library can increase utilization of any of them.

Agreed. It would be nice if the Google guys could do something like Qt with Go, but more Go-ish and in pure Go so you can still easily cross-compile. I'd even settle for a faked native look using OpenGL.

How big are the Qt binaries?

For a simple app which just has a QML based UI and some networking, we are talking roughly 23MB of DLLs on Win 64.

    5.3M Qt5Core.dll
    5.6M Qt5Gui.dll
    820K Qt5Network.dll
    3.2M Qt5Qml.dll
    2.9M Qt5Quick.dll
    307K Qt5Svg.dll
    5.3M Qt5Widgets.dll

(It still might be possible to strip out Gui and Widgets though.)

I know there are OpenGL packages for Go, but I don't think they are really "pure Go" (in the sense of not linking to any C libraries at all). At least not under X11.

Unlike all the other X11 extensions, the GLX "protocol specification" doesn't define a network protocol. It defines C functions bolted on to Xlib for setting up GL contexts. In many use cases, there probably is no network at all -- just direct rendering.

I don't know what the situation is on other platforms, but I guess it is similar: OpenGL is exposed as some C-based library.

Qt is moving to an HTML+JS based toolkit too with Qt Quick.

That's false.

- QtQuick is "the standard library for writing QML applications." [1], providing: Models, Layouts, GraphicalEffects, States, etc. Conveniences and building blocks to build GUIs with QML.

- QML itself is a declarative language totally different from HTML. Bindings are done with JS (by the way, a specific, custom implementation of it), yes, but there's no HTML anywhere.

- Qt also provides the WebEngine module [2], which is an in-house packaging of Chromium. If you use this instead of QML to build your GUI, then yes you're in almost-vanilla "HTML+JS" land. But this is not QtQuick.

[1] http://doc.qt.io/qt-5/qtquick-index.html

[2] http://doc.qt.io/qt-5/qtwebengine-index.html

Trying to shoehorn a UI description in a procedural language is always going to be awkward.

But we could have a compilable document language with DOM-like bindings and an event loop in Go. It's a lot harder to implement than HTML + JS, though, which already provide that for free.

Go has a cross-platform GUI framework that was used to make this mobile app : https://play.google.com/store/apps/details?id=org.golang.ivy

It's based on OpenGL ES.

Which cross platform GUI framework you are writing about?

Ivy was made with GO mobile which is a collection of bindings for android/ios only.

At least it doesn't seem like the Plan9 fanboy section of the Go adopters would be inclined to use this.

Reply on news.ycombinator.com