[electrograv]

I've thought about this a lot myself.

The language issue ultimately leads you to conclude that we need a browser with a built-in VM, rather than a built-in scripting language. It makes so much more sense, as a clean and elegant solution.

"I know! I'll make my own new browser with an embedded VM and newer cleaner APIs, and revolutionize the web! It'll be amazing, allowing native-like performance from the browser. WebGL will finally achieve performance feasible for high quality games, the need for full native apps would be tremendously diminished, etc. etc."

JVM is a well known example of a cross-platform VM, which tried to enter the browser via Applets. I think Java Applets failed because they were slow, ugly, clunky, and usually looked horrible and disturbed the web experience. Kind of like flash ads, but worse.

Microsoft Silverlight is kind of similar, but using the CLI rather than the JVM. As a plugin, it still wasn't seamless. And it had cross platform compatibility issues (not a fault of the CLI though).

The GUI issue (bloated DOM, hacky HTML/CSS) leads me to conclude that we need a new API stack for rendering GUIs that satisfies both web and application use cases without massively sacrificing memory and performance like the DOM seems to excel at.

But here's the thing:

Creating a new browser with a new VM and new GUI stack, all from scratch, is almost an insane undertaking. Sure, it's one I could almost see myself trying (being a perfectionist ADHD OCD coder) as a hobby, but I know better than that if I want to actually ship anything.

Ideally, I'd like to see some day a kind of "Mono Browser" - a browser that basically runs CLI code "scripts" in an otherwise traditional HTML/CSS stack for backwards compatibility. But the primary feature would be a new GUI stack completely disjoint from HTML/CSS for people who want to create blazingly fast and native-like snappy UIs.

It's fairly critical though to expose this new GUI stack, because otherwise it's just CLI-scripting-in-the-browser. CLI in a regular browser would be great IMO, but not a significant enough change for end-users to upgrade to the browser. Moreover, such a API stack would be extremely useful for cross-platform developers even of native apps. It would essentially compete with web-based cross platform frameworks like PhoneGap, and native ones like QT (though QT IMO is ugly and old fashioned vs web rendering).

So a great deal of work lies ahead in creating this GUI stack. This is something I'm kind of intermittently working on in my spare time. Unfortunately I'm usually kept quite busy on research work towards a PHD, but now and then I make a little progress. But if you know of others working on something similar, feel free to point me in that direction to collaborate.

[ux-app]

I've also been thinking about the same sorts of things lately.

Mostly I've been thinking about the GUI issue on the web. CSS and the DOM are just not up to the task of creating a responsive app GUI. The incredibly complex set of nested CSS rules that need to be calculated and applied for each reflow is a nightmare.

I personally think the DOM is a fine way to define an app structure. GUIs are after all containers and components which map nicely to nodes in a tree.

CSS is great for presentation (colors, font styles etc). One of its strengths is its simplicity and its cascading nature.

What we need is a sane constraints-based layout model. This is standard fare for native apps (eg: iOS autolayout).

Imagine being able to specify:

  Block_A sits at the top of the window.
  Block_B is anchored to the bottom edge of Block_A.
  Block_C is inside of Block_B and is anchored to the left edge.
  etc..

A complex layout can be defined in a handful of rules which even JS can solve for.

Solvers for these types of optimization problems have been around for 20+ years. There's even a nice one written in JS eg:

  http://www.badros.com/greg/cassowary/js/quaddemo.html

[nsm]

I've often wondered about replacing HTML/CSS/JS with QtQuick and QML. Thoughts?

[ux-app]

I don't have any experience with Qt&QML, though I've heard lots of good things about it.

I don't think a wholesale replacement of HTML/CSS is feasible though. There's just too much inertia behind the incumbents, not to mention that HTML/CSS is very good for the document centric web which applies to 90%+ of the existing web.

More flexible CSS layout modes such as display:flex are quite usable and go some of the way to addressing app-style layouts, however movement on these standards is slow and doesn't go far enough IMO.

[mephju]

Great to hear someone is looking into this even though it's only a side project!

But I am not sure the GUI engine would really take THAT long. How long did the Android guys need for their GUI solution?. It would be interesting to know that.

And no, I actually don't know people working on projects like this :)

[electrograv]

Yeah it's not an impossibly complex task, which is why I'm working on it, one step at a time. But it's much more involved than it sounds at first.

Of course a simple "widget" library is relatively easy to make, provided you already have powerful drawing and text functions. Then you realize, integrating text entry and copy paste consistent with the operating system gets much more tricky if you're making all your own widgets from scratch. More complex rich markup is even harder though... getting text to flow around correctly while achieving the layout you want at the same time. I think CSS does a fairly good job here, but I think we can do better.

A lot of the work before you even get to this stage though lies in good cross platform drawing and text rendering. OpenGL support is a 'must', of course. Then, 2D and vector graphics need to be implemented. OpenVG is supposed to provide this, but is useless as a cross platform solution, because it's only supported on a handful of mobile only systems. So I'd either have to implement all of OpenVG through OpenGL (and I certainly don't look forward to implementing the mess that is SVG) to get HW acceleration, or make my own VG library.

But that doesn't even solve text rendering. Text rendering western fonts is relatively easy, but it gets much more complex when you need to support unicode cursive fonts like Arabic with HW acceleration consistently. Fortunately the actual shape generation is already solved in the GNU world, but caching fonts efficiently on the GPU and with smooth antialiasing is another matter. It would be nice to just use the operating systems text renderer, but not only would the results be inconsistent across platforms, but I don't think it's possible to do this on an OpenGL framebuffer on all platforms.

So once I have HW cached text rendering, and vector graphics, only then can I even start thinking about building a widget library on top of it.

So it's much more complex than it initially sounds when you have to essentially reinvent the entirety of what the OS GUI API should provide. And if you can't settle for lowest-common-denominator functionality provided by all OSes, then reinventing the wheel is your only remaining option.

I know how to do all this, it's just a lot of work. If I was working on it full time it would go fairly quickly, but it doesn't seem to be a very profitable task so that's not feasible right now.