[mephju]

This is a real question and no trolling:

Why is nobody building a second kind of browser, one which is not based on html and css. A browser which is geared towards app execution and development. A browser which can run apps which can be programmed in a way that is similar to programming Android apps. Where I can for example have a footer without doing some css hacks. DNS and most of our backends could still be reused but the client stuff would have to be written again. Delivering apps and linking between them like the web does is awesome. Building sophisticated apps is not awesome but on Android and iOS it is. Why not take the best of both worlds...now....not in 10 years when some standards might agree on something. Just think about how very important the web is. Everyone is using it. The whole world largely depends on it, but it's increasingly not up to the task. And why do web developers seem to be so satisfied with the state of the technology which drives the web. Oh, you think css is great because you can code a hack for putting a footer on the bottom of the page even when there is no content in the attention area? What? It's so strange.

Why has nobody ever tried to create such a browser?

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

[Suan]

This thought has been in my head ever since I read this HN comment last night: http://news.ycombinator.com/item?id=5199006

To everyone saying that this has been tried and failed with Java Applets / Silverlight / Flash: what those technologies did was try to shoehorn app-like environments into the browser, which of course annoyed users because it broke all kinds of expectations when compared to visiting regular HTML pages.

What I (and I think, the OP) have in mind is an actual 2nd "browser". A different standalone app. I envision something where "webapp" authors can post manifests at URL endpoints which define the UI and behavior (not unlike styling in Android), and this 2nd browser will "render" the webapp using native widgets and controls. This brings with it a number of things:

  - OMG! The basic keyboard shortcuts all my other native apps have are now available, instead of some poorly hacked-together javascript-detected version
  - Rich user interaction with the app and the controls is now a first-class citizen - no more weird highlighting of the entire page, or unexpected popping-up and disappearing of elements on misclicks
  - Right click can actually be used, without hacks!
  - Opening a new "window" with a new app actually creates an OS-level window with the icon and name being the webapp's favicon - furthering the notion that you're actually using an app and not visiting a website.
  - It still retains the main advantages of the web - it's cross-platform and ubiquitous (and users don't have to go through the hassle of explicitly installing and updating native apps)
  - I'm sure developing highly interactive webapps for this platform would be a lot simpler, more fundamentally sound, and more enjoyable than the huge hack that is HTML5/AJAX now
  - etc etc

It would really surprise me if nobody has thought through this idea in more detail than me, or if there isn't someone out there working on something like this already...

(EDIT: formatting)

[andrewflnr]

It would have to be huge piece of software, and nobody would use it. That is, it would be very difficult to get adoption. That said, some of us are thinking about it.

It seems like this ought to have made it onto PG's list of frighteningly ambitious ideas.

[TazeTSchnitzel]

It has been done several times with some degree of success:

- Java Applets

- Microsoft Silverlight

- Adobe Flash

[natural219]

Premature, propietary, propietary.

[cpeterso]

Java applets were proprietary at the time. The Macromedia Flash Player predates Java applets.

[TazeTSchnitzel]

Them being proprietary had nothing to do with their success.

[lutusp]

> Premature, propietary, propietary.

pro - what?

s/propietary/proprietary/

[heja2009]

Not 100% sure what you mean, but wasn't Java ME a portable solution, a platform geared towards app execution and development? And in a limited sense it even succeeded... Not sure I want a 2nd iteration though.

[mephju]

Java ME doesn't have any of the advantages of the web. Like links or being searchable and so on. It's just another app environment. I am talking about combining the advantages of the web (which is not css/html) with those of successful app development platforms.

[Millennium]

Your way has been tried, by not one but two companies. Their browsers were called IE4 and NS4, and the blame for the Web "not being up to the task" is pretty much entirely theirs.