Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ōryōki Web Browser

oryoki.io

Post reply on HN
Print view View original

81–90 of 181 posts

Re: Ōryōki Web Browser

#81

Post by overcast »

Touche wrote: post #72
overcast wrote: post #41

Earlier quoted context omitted.

Sure RAM is meant to be used, but not when the browser just consumes it forever, until it begins grinding to a halt. What could a browser POSSIBLY be doing with 4-500MB of RAM PER TAB? It's a huge problem, and extensions like The Great Suspender should not have to even exist.

Each tab is a separate process. A separating operating system, you could say. Would you complain that your OS needs that much RAM? I wouldn't.

Except we're not running an entire operating system in each tab. Everything starts fine, and then quickly consumes memory. How about we just stay fine? I've got entire operating systems running with less resources in VirtualBox.

Re: Ōryōki Web Browser

#82

Post by xlisx »

robobro wrote: post #17
jfe wrote: post #7

This project is solving the wrong problem. It's not the interfaces of web browsers that suck, it's the gigabytes of RAM they consume.

I agree completely. Taking buttons off of the GUI and using different hotkeys doesn't make a better web browser. You just end up with a browser for hipsters.

A lot of the hate here comes from the fact that there are people who are being creative, and you aren't. It's easy to shut people down...try to help them, instead. It's an experiment, made public. What's the purpose of shitting on it?

Re: Ōryōki Web Browser

#84

Post by fiddlerwoaroof »

coderdude wrote: post #56
vertex-four wrote: post #46

Earlier quoted context omitted.

All of those are WebKit-based, which was Chromium's rendering engine until recently. The rest of Chromium is primarily UI and network code, along with their sandboxing system and extensions - WebKit's "ports" have their own implementation of said network code tying into the framework that they're porting to (GTK+ or Qt, usually), and all three browsers you list use the WebKitGTK+ port. uzbl, the one I've used the mos…

Do you know of any independent rendering engines? That's something I'd truly be interested in seeing. It seems like a herculean task to undertake. Edit: Thanks very much for the links. This will be a lot of fun testing out. Just responding here to avoid triggering the anti-flamewar protection.

Not really maintained recently, but there is:

https://common-lisp.net/project/closure/

Re: Ōryōki Web Browser

#85

Post by brianwawok »

scrollaway wrote: post #47
brianwawok wrote: post #26

Earlier quoted context omitted.

Why would I not want my browser to use RAM? What else with my 16 or 32GB of ram am I going to do when I surf? I would happily give double the current gen ram for better performance.

Don't assume everybody uses their computer like you do and only runs one browser maximized on their only monitor connected to their powerhouse of a computer equipped with a last-gen CPU and 64 gigabytes of ram. For example, I sometimes play very resource-hungry games and like to have a youtube video on my second monitor while I play. But that's not possible on my gaming PC, so I have to youtube-dl the video first and…

That seems like exactly what you are doing. So you want to run a game and a youtube video and browse at the same time, while on a low end PC. Cool. A lot of people don't use their computer like that.

I can do all of that at the same time as is...

Re: Ōryōki Web Browser

#86

Post by quantumtremor »

Fogest wrote: post #50
quantumtremor wrote: post #18

For Firefox users, this can all be done with Firefox and custom browser CSS (Vimperator helps), which offers significantly more control (without having to rewrite the core code). Screenshots: http://imgur.com/a/qDGP2 CSS base (I've made a few modifications): http://twily.info/firefox/stylish/firefox-css#view

Do you own twily? That is an interesting file explorer style thing on the webpage.

No. I believe Twily used to be on /g/ frequently, maybe still is.

Re: Ōryōki Web Browser

#87

Post by vmorgulis »

coderdude wrote: post #56
vertex-four wrote: post #46

Earlier quoted context omitted.

All of those are WebKit-based, which was Chromium's rendering engine until recently. The rest of Chromium is primarily UI and network code, along with their sandboxing system and extensions - WebKit's "ports" have their own implementation of said network code tying into the framework that they're porting to (GTK+ or Qt, usually), and all three browsers you list use the WebKitGTK+ port. uzbl, the one I've used the mos…

Do you know of any independent rendering engines? That's something I'd truly be interested in seeing. It seems like a herculean task to undertake. Edit: Thanks very much for the links. This will be a lot of fun testing out. Just responding here to avoid triggering the anti-flamewar protection.

There is Cocktail written Haxe (can compile to C++):

https://github.com/silexlabs/Cocktail

Re: Ōryōki Web Browser

#88

Post by revelation »

riscy wrote: post #6

> small web browser [...] built on top of Chromium More accurately, a minimalist web browser UI for Chromium. There's nothing small about Chromium.

Even more accurately, it's a minimalist web browser UI for Electron which is an application UI for Chromium which is a fully-featured web browser UI.

These people don't deserve any more Moore improvements.

Re: Ōryōki Web Browser

#89

Post by zatkin »

aerovistae wrote: post #73
aplaice wrote: post #66

Earlier quoted context omitted.

For anyone interested, here are some web browsers that are actually lightweight (if not html5-compliant) and not webkit-based: http://www.dillo.org/ http://www.netsurf-browser.org/

For anyone interested, here are some web browsers that are very lightweight and don't bother with HTML at all: https://www.google.com/search?q=spiders&espv=2&biw=1439&bih=...

For anyone interested, I'm just gonna stick to Safari on my Mac and iOS.

Re: Ōryōki Web Browser

#90

Post by bfgeek »

andrewguenther wrote: post #59
amaks wrote: post #45

Earlier quoted context omitted.

Chromium doesn't use webkit, it uses Blink.

Blink is a fork of WebKit and is still largely the same.

Depends on what you are counting as the "same".

Edge put together a really great visualization of the API surface of all the browsers. - https://developer.microsoft.com/en-us/microsoft-edge/platfor... The API surface (and bug surface) is actually pretty different these days.

Internally Blink and WebKit are also diverging reasonably rapidly. As a specific example here is the project to re-architect how blink does it's painting: https://www.chromium.org/blink/slimming-paint

EDIT: spelling

Post reply on HN