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

So you want to build a browser engine

robert.ocallahan.org

Post reply on HN
Print view View original

41–50 of 134 posts

Re: So you want to build a browser engine

#41

Post by jwells89 »

shiomiru wrote: post #33

I'm writing one for fun: https://sr.ht/~bptato/chawan/ "Fixed-width text to a grid" makes things easier (sometimes), but I think it still qualifies. On the article itself; it might be better to start with more... basic things than the optimizations it talks about: * Cascading & layout must be cached and optimized - far from trivial. Layout is one of the hardest parts to get right at all, to make it fast as well is an…

> Much more low hanging fruit exists if you give up on writing a Chromium clone.

One idea that’s crossed my mind (may never get around to trying it) is writing an engine that completely ignores everything that’s not modern HTML5 and CSS3. That’s still a lot but it seems like it’d cut down on the scope significantly. This engine wouldn’t be very useful as a browser but it’d probably be enough for displaying bespoke web content in an app or something like that.

Re: So you want to build a browser engine

#42

Post by mkoubaa »

wizzwizz4 wrote: post #29
IshKebab wrote: post #27

Earlier quoted context omitted.

That's only because it was the "Chrome" (i.e. the dominant browser). Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up.

> Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up. That wasn't because they weren't up to the job. It's because Google was using Microsoft's playbook against them. https://news.ycombinator.com/item?id=18697824 > I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other bro…

I hate that they did it but I have a hard time sympathizing with Edge/MS

Re: So you want to build a browser engine

#43

Post by mepian »

amelius wrote: post #6

This makes writing a compiler or writing an OS kernel look like child's play.

A compiler by itself is surprisingly easy, especially if you read Abdulaziz Ghuloum's or Jeremy Siek's tutorials. Making it competitive with state-of-the-art compilers like Clang or HotSpot is difficult, but this is true for every kind of software.

Re: So you want to build a browser engine

#44

Post by xNeil »

chrstphrknwtn wrote: post #24
ramesh31 wrote: post #21

Earlier quoted context omitted.

>This makes writing a compiler or writing an OS kernel look like child's play. Indeed. The modern web browser is the single most advanced, complex, and highly developed piece of software that 99% of people will ever interact with, and we treat it as a given. Having a highly performant fully sandboxed VM that runs on every system imaginable in billions of devices used by nearly every human on earth is the single great…

> used by nearly every human on earth Roughly 60% of earth's population used the internet in 2023. So not quite nearly every human .

25% of the Earth's population is younger than 15. Assuming 20% of them use the internet, the TAM (not including the 3 out of 4, or 75%, seems like nearly ever human, I'd say (though it is a matter of opinion I guess.)

Re: So you want to build a browser engine

#45

Post by Buttons840 »

djbusby wrote: post #34

Seems a good place to mention https://sciter.com/ It's been on HN loads of times. A "browser" engine but very narrow scope. Works a treat for LOB type apps.

I was sad when the creator tried to raise enough funds to open-source Sciter and there wasn't much interest. If 1% of the people who complain about Electron had pledged something, we would have it as a good alternative today.

Re: So you want to build a browser engine

#46

Post by shiomiru »

roca wrote: post #39
shiomiru wrote: post #33

I'm writing one for fun: https://sr.ht/~bptato/chawan/ "Fixed-width text to a grid" makes things easier (sometimes), but I think it still qualifies. On the article itself; it might be better to start with more... basic things than the optimizations it talks about: * Cascading & layout must be cached and optimized - far from trivial. Layout is one of the hardest parts to get right at all, to make it fast as well is an…

I guess one of my points is that layout algorithms are not really part of the "most basic" decisions anymore. Replacing layout algorithms is actually a lot less disruptive to the engine architecture than switching to site isolation, say.

Fair; re-reading TFA, now I realize you explicitly instructed me to stop reading in the first paragraph :)

Trying to redeem myself with an on-topic question: isn't what you want more of a "refactoring of Blink" than "building a browser engine"? I would be surprised if a complete rewrite was really necessary for the features you want, since "saving state" already happens to some extent in all engines (even if it's just reloading from the cache) and I've seen reports about Gecko integrating multi-core cascade from Servo. What makes it hard to incrementally improve upon the current engines?

Re: So you want to build a browser engine

#47

Post by rice7th »

jsheard wrote: post #14
Paul-Craft wrote: post #8

Earlier quoted context omitted.

A browser engine is a compiler. Or, more properly, it's at least two compilers (HTML + CSS -- you can outsource JS to V8 or whatever).

The DOM stuff, JS, WASM, WebGL, WebGPU... at least five compilers, with JS and WASM needing two distinct frontends (baseline/optimizing) and at least two backends (x86/ARM), and WebGL and WebGPU needing three backends each (D3D/VK/Metal).

Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL? Also one could easily write a lot of frontends and a single massive centralised backend with multiple processor targets and optimisation profiles. Think about V8 which works for both JavaScript and WebAssembly. This would create a much simpler codebase and if you're going to use a parser generator it could very well be a breeze.

Re: So you want to build a browser engine

#48

Post by jsheard »

rice7th wrote: post #47
jsheard wrote: post #14

Earlier quoted context omitted.

The DOM stuff, JS, WASM, WebGL, WebGPU... at least five compilers, with JS and WASM needing two distinct frontends (baseline/optimizing) and at least two backends (x86/ARM), and WebGL and WebGPU needing three backends each (D3D/VK/Metal).

Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL? Also one could easily write a lot of frontends and a single massive centralised backend with multiple processor targets and optimisation profiles. Think about V8 which works for both JavaScript and WebAssembly. This would create a much simpler codebase and if you're going to use a parser generator it could very well be a breeze.

> Isn't webGL's GLSL directly delegated to the driver just like normal OpenGL?

Perhaps you could in an MVP implementation, but in practice no, none of the serious implementations do that by default. First because native OpenGL drivers are generally a mess, so browsers actually implement WebGL on top of DirectX, Vulkan or Metal wherever they can, and even when those aren't available the browsers still parse, validate and reconstitute the GLSL rather than passing it straight through to OpenGL as a layer of insulation against driver bugs. Chrome and Firefox do have hidden feature flags which bypass that behavior and call the native GL implementation directly, but you probably shouldn't enable those unless you're really into ShaderToy and want it to compile faster.

Re: So you want to build a browser engine

#49

Post by kernal »

wizzwizz4 wrote: post #29
IshKebab wrote: post #27

Earlier quoted context omitted.

That's only because it was the "Chrome" (i.e. the dominant browser). Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up.

> Look at what happened when Microsoft eventually tried to catch up with Chrome - they gave up. That wasn't because they weren't up to the job. It's because Google was using Microsoft's playbook against them. https://news.ycombinator.com/item?id=18697824 > I very recently worked on the Edge team, and one of the reasons we decided to end EdgeHTML was because Google kept making changes to its sites that broke other bro…

What a weak excuse. To blame an empty div for the demise of your browser engine just seems desperate.

Re: So you want to build a browser engine

#50

Post by ameliaquining »

giantrobot wrote: post #13
ZeroGravitas wrote: post #3

I was going to suggest: > initially try just being a faster, lighter or lower-power Electron or WebView. But he mentioned it himself, though maybe someone might want to try this with no intention to become a full browser. Can you skip any of the tricky security requirements if it'll be bundled into an app? Or is that just asking for trouble?

> Or is that just asking for trouble? The average Node project pulls in hundreds of dependencies. While you'd hope these would have some security vetting because of the Many Eyes theory, you have no fucking idea what your project is doing. Even a trivial Electron app is running a ridiculous amount of unreviewed third party code. Just one module able to exercise some local exploit in your engine because you didn't fix…

Aren't those dependencies trusted anyway? If they want to do something evil, they can just do it, they don't need to look for a zero-day in the engine they're running on.
Post reply on HN