5 ms·

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 tow

by mephju 14y ago

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?

heja2009 14y ago
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 14y ago
  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.
andrewflnr 14y ago
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 14y ago
  It has been done several times with some degree of success: - Java Applets - Microsoft Silverlight - Adobe Flash
  - natural219 14y ago
    Premature, propietary, propietary.
    - TazeTSchnitzel 14y ago
      Them being proprietary had nothing to do with their success.
    - lutusp 14y ago
      > Premature, propietary, propietary. pro - what? s/propietary/proprietary/
    - cpeterso 14y ago
      Java applets were proprietary at the time. The Macromedia Flash Player predates Java applets.
electrograv 14y ago
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.
- 14y ago
Suan 14y ago
This thought has been in my head ever since I read this HN comment last night: http://news.ycombinator.com/item?id=5199006 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)
Millennium 14y ago
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.

by mephju 14y ago

heja2009 14y ago

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

andrewflnr 14y ago

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 14y ago
It has been done several times with some degree of success: - Java Applets - Microsoft Silverlight - Adobe Flash
- natural219 14y ago
  Premature, propietary, propietary.
  - TazeTSchnitzel 14y ago
    Them being proprietary had nothing to do with their success.
  - lutusp 14y ago
    > Premature, propietary, propietary. pro - what? s/propietary/proprietary/
  - cpeterso 14y ago
    Java applets were proprietary at the time. The Macromedia Flash Player predates Java applets.

electrograv 14y ago

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.

14y ago

Suan 14y ago

This thought has been in my head ever since I read this HN comment last night: http://news.ycombinator.com/item?id=5199006 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)

Millennium 14y ago

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.