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

61–70 of 134 posts

Re: So you want to build a browser engine

#61

Post by crazygringo »

CoolestBeans wrote: post #60
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.

But that's exactly my point.

This article appears to be entirely about an implementation from scratch.

It makes very clear that it is not about forking Chromium.

But even Google was smart enough not to start from scratch.

So again, I don't know who the intended audience for this article is. It's advice on something no sane person or organization would ever do.

Re: So you want to build a browser engine

#62

Post by pankajdoharey »

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…

The underlying baked assumption is chromium as a rendering engine is better than Safari. How is chromium rendering engine better than safari ? Quality wise they both are same Safari actually consumes way less memory.

Re: So you want to build a browser engine

#63

Post by praisewhitey »

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…

IE/Edge was behind the competition at standards adoption since IE7. Just look at the history of Acid3, HTML5Test or Caniuse.

https://en.wikipedia.org/wiki/Acid3

https://html5test.co/results/desktop.html

https://caniuse.com/ciu/comparison

Re: So you want to build a browser engine

#64

Post by pizlonator »

I’m not sure that performance needs to constrain web engine design the way it traditionally has. The world has changed since the browser perf war started.

Just try disabling the JIT in a modern browser and you’ll find your UX is not really any worse.

HW has gotten faster than when the current browser perf wars kicked off. So it might be that to have a meaningfully useful browser engine alternative, perf won’t be the top concern. Compatibility will though, just because of the sheer number of features a modern browser engine supports.

And if you don’t have JIT, then it’s not clear if Spectre is even a meaningful concern.

Re: So you want to build a browser engine

#65

Post by checker659 »

Paul-Craft wrote: post #8
amelius wrote: post #6

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

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

There are at least two garbage collectors in there as well.

Re: So you want to build a browser engine

#66

Post by sneak »

Buttons840 wrote: post #45
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.

Open sourcing software to which you hold copyright doesn’t cost anything.

Re: So you want to build a browser engine

#67

Post by esprehn »

skilled wrote: post #9

Who is this post intended for? Nobody builds their own browser engines. And I mean nobody. I didn’t get the feeling that he wrote this for pet projects either. Andreas over at Ladybird is probably the only one (and Servo?) who is really doing it the way that this post describes. Still, the last couple of paragraphs made me think that this is more of a reflection of his own time over at Mozilla: could have / would hav…

For general web browsing it's true there's basically just Gecko, WebKit and Blink that are broadly used and compatible with the whole ecosystem.

There's a fair number of other engines though like Sciter, Flow, Cobalt and Servo.

Re: So you want to build a browser engine

#68

Post by esprehn »

Engine diversity is really important for the ecosystem and continued innovation. While building something competitive with the big three engines is a monumental task there's still a lot of value in building alternative engines to try new ideas even if getting "the whole web" implemented is basically impossible.

For example:

- Servo vs Blink vs Cobalt do selector matching and style resolution very differently.

- WebKit has a selector JIT, no one else does though.

- WebKit and Blink do layout super differently (with LayoutNG shipped).

- Firefox's html parser is written in Java and converted to C++ at build time.

The big value in folks trying to write new engines is finding these alternate paths. We can't depend on the big three for all the innovation.

That's what's great about Ladybird. Sure it'll need a lot of sophisticated sandbox improvements to get us to a big four situation, but it's more likely its value will be in finding another road the other engines didn't travel across the huge universe of specs, content and features.

Post reply on HN