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

51–60 of 134 posts

Re: So you want to build a browser engine

#51

Post by rice7th »

jsheard wrote: post #48
rice7th wrote: post #47

Earlier quoted context omitted.

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…

Wow that was something I wasn't expecting. Well I guess it does kinda make sense that running untrusted code on a gpu wouldn't be the best idea, however I seriously thought that browsers just passed their glsl directly to the GPU. Also since linux doesn't have its own graphics API I am afraid that WebGL support would introduce a lot of complexity, since you can definitely pass via OpenGL but Vulkan could be also an option.

Thank you for the tip!

Re: So you want to build a browser engine

#52

Post by jsheard »

rice7th wrote: post #51
jsheard wrote: post #48

Earlier quoted context omitted.

> 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…

Wow that was something I wasn't expecting. Well I guess it does kinda make sense that running untrusted code on a gpu wouldn't be the best idea, however I seriously thought that browsers just passed their glsl directly to the GPU. Also since linux doesn't have its own graphics API I am afraid that WebGL support would introduce a lot of complexity, since you can definitely pass via OpenGL but Vulkan could be also an o…

https://github.com/google/angle

ANGLE is the de-facto standard library that all of the big browsers use to implement WebGL on top of other graphics APIs, if you want to read up on it.

Re: So you want to build a browser engine

#53

Post by wizzwizz4 »

kernal wrote: post #49
wizzwizz4 wrote: post #29

Earlier quoted context omitted.

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

There will always be a case that kicks you out of the fast path, but shouldn't (or a case where you take the fast path incorrectly, resulting in incorrect behaviour). This is a corollary of Rice's theorem.

Re: So you want to build a browser engine

#54

Post by ameliaquining »

roca wrote: post #35
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?

I think sooner or later you're going to want to load lower-trust content --- IFRAMEs of third-party Web content, or sandboxed extensions, or something like that. Building your entire architecture on the assumption you'll never have to do that is very risky.

You could use the system webview for embedded third-party web content while using your own framework for trusted content.

Re: So you want to build a browser engine

#55

Post by giantrobot »

ameliaquining wrote: post #50
giantrobot wrote: post #13

Earlier quoted context omitted.

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

The LCE doesn't need to be in the engine, the engine just needs to lack protections for the code to run something locally. As for Node dependencies being trusted, they are trusted but that's largely unearned trust.

Re: So you want to build a browser engine

#56

Post by rice7th »

jsheard wrote: post #52
rice7th wrote: post #51

Earlier quoted context omitted.

Wow that was something I wasn't expecting. Well I guess it does kinda make sense that running untrusted code on a gpu wouldn't be the best idea, however I seriously thought that browsers just passed their glsl directly to the GPU. Also since linux doesn't have its own graphics API I am afraid that WebGL support would introduce a lot of complexity, since you can definitely pass via OpenGL but Vulkan could be also an o…

https://github.com/google/angle ANGLE is the de-facto standard library that all of the big browsers use to implement WebGL on top of other graphics APIs, if you want to read up on it.

Thank you, I'll definitely take a look at it.

Re: So you want to build a browser engine

#58

Post by kevingadd »

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…

YouTube did this to Firefox too - for a while they were serving a special degraded version of YT to Firefox users (polyfilled web components, instead of native web components or their classic non-web-components version) even though they had versions that would perform better. "Oops".

If you used user-agent tricks you could get them to serve a good version.

Re: So you want to build a browser engine

#59

Post by pavpanchekha »

jwells89 wrote: post #41
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 we…

It's not really clear what this even means. HTML5 and CSS3 aren't new versions of HTML and CSS that obsolete the prior stuff; they are extensions to what already existed.

So, for example, as far as I know, every web browser uses the HTML5 parsing algorithm for parsing HTML. This algorithm is very complicated, because it describes what parse tree to produce for any possible document. There's not, like, a separate HTML4 parsing algorithm; the HTML5 parsing algorithm replicates a lot of the complexities of pre-HTML5 parsing, but standardized.

Similarly, in CSS 2 the biggest complexities are things like floats, inline layout, margin collapsing, and stacking contexts. (My PhD was most of a standards-compliant CSS 2.1 layout engine.) There's not a CSS inline layout algorithm (the thing that puts words into lines) other than the CSS 2 one, though CSS 3 does add a lot more features.

In other words: the browser doesn't have a separate code path to handle old content. Instead, CSS 3 contains layout algorithms that extend CSS 2 but they don't replace them.[1] Similarly HTML 5. There are obsolete features you could probably dump (obsolete image formats, obsolete codecs) or rarely-used features (eval, document.write) or edge cases that probably don't matter that much (margin collapsing) or features where maybe your user base doesn't need it (writing direction? floats?) but this is really not so different from what the article talks about: a WebView/Electron replacement, where you commit to supporting a known universe of pages instead of the whole web.

[1] Granted some features like floats have become a lot less necessary, since a lot of their use cases can now be replaced by flex-box.

Re: So you want to build a browser engine

#60

Post by CoolestBeans »

crazygringo wrote: post #40

> So You Want To Build A Browser Engine The only correct answer is, "don't". I mean, if you want to build a toy browser engine for a CS class or fun or something, then sure. But the idea that "you want to build an engine that’s competitive with Chromium" is, quite simply, nonsensical. If you want your own browser engine, you're going to fork Chromium or Gecko (Firefox). I mean, even Microsoft gave up on maintaining i…

Even Chromium started with WebKit which itself was a fork. This doesn't mean you shouldn't be interested in browser dev but you also don't have to do a totally clean sheet implementation.
Post reply on HN