5 ms·

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 scr

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.

mephju 14y ago
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 14y ago
  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.

mephju 14y ago

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 14y ago
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.