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

71–80 of 134 posts

Re: So you want to build a browser engine

#71

Post by matheusmoreira »

esprehn wrote: post #68

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

Diversity alone is great but not quite enough. The alternative browsers need to actually see significant usage. Otherwise the developers and corporations will go "this browser has 99% market share so I can just ignore the others", giving the dominant browser makers enormous leverage over the others.

Re: So you want to build a browser engine

#72

Post by lopis »

sneak wrote: post #66
Buttons840 wrote: post #45

Earlier quoted context omitted.

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.

False. This is very naive. If this was true, we wouldn't get the regular posts on HN about OSS drama, and how some people gave up OSS. Opening source up is more than showing us the source.

Re: So you want to build a browser engine

#73

Post by roca »

shiomiru wrote: post #46
roca wrote: post #39

Earlier quoted context omitted.

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

Indeed you can incrementally improve existing engines, and certainly that's what you would try to do if you wanted one of those specific features. But I didn't write the post because I want those features, I wrote it in the hope that it might be helpful to people who are already planning to write a competitive browser engine from scratch.

Yes, for almost every conceivable features you'd be much better off adding it to an existing engine. Maybe you won't get buy-in from the core maintainers, so you'll have to maintain an out-of-tree branch, but that's still going to be much less work than doing your own engine.

Re: So you want to build a browser engine

#74

Post by roca »

pankajdoharey wrote: post #62
jwells89 wrote: post #41

Earlier quoted context omitted.

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

I could be wrong but AFAIK Safari still doesn't have site isolation, so security-wise it's considerably weaker.

Re: So you want to build a browser engine

#75

Post by roca »

pizlonator wrote: post #64

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…

Those are interesting points, but disabling the JIT doesn't really change anything unless it means you can forgo site isolation, and that would be a very risky bet.

It may be that disabling the JIT is fine for users most of the time. However, that is also a tough call --- so easy for your competitors to beat you up with benchmarks, and there will be real use-cases (e.g. emulators) where it matters to some users.

And of course there's a lot more to perf than just the JIT. I barely mentioned JIT in my blog post.

Re: So you want to build a browser engine

#76

Post by roca »

crazygringo wrote: post #61
CoolestBeans wrote: post #60

Earlier quoted context omitted.

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.

And yet a few people are doing it. So yeah, it's advice to insane people.

Re: So you want to build a browser engine

#77

Post by weinzierl »

esprehn wrote: post #68

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

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

This is surprising. Is it really true in the sense that the code that parses the HTML in a regular Firefox install was autoconverted when it was built?

Re: So you want to build a browser engine

#78

Post by cxr »

pavpanchekha wrote: post #59
jwells89 wrote: post #41

Earlier quoted context omitted.

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

It's a semi-noob illusion that focusing only on modern standards and practices would surely result in a leaner implementation. This goes all the way back to the big push for web standards in 1998—e.g. you can find Slashdot Q&As from the early 2000s where people bring up the idea of how much smaller the browser could be without quirks mode and IE compatibility and then get corrected about how much of the code base this stuff actually takes up.

Re: So you want to build a browser engine

#79

Post by coldtea »

roca wrote: post #75
pizlonator wrote: post #64

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…

Those are interesting points, but disabling the JIT doesn't really change anything unless it means you can forgo site isolation, and that would be a very risky bet. It may be that disabling the JIT is fine for users most of the time. However, that is also a tough call --- so easy for your competitors to beat you up with benchmarks, and there will be real use-cases (e.g. emulators) where it matters to some users. And…

>and there will be real use-cases (e.g. emulators)

Those are so niche as a concern, that might as well not take into account at all when doing a new browser engine.

Re: So you want to build a browser engine

#80

Post by reubenmorais »

weinzierl wrote: post #77
esprehn wrote: post #68

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

"- Firefox's html parser is written in Java and converted to C++ at build time." This is surprising. Is it really true in the sense that the code that parses the HTML in a regular Firefox install was autoconverted when it was built?

Yep: https://searchfox.org/mozilla-central/source/parser/html/jav...

And more info: https://about.validator.nu/htmlparser/

Post reply on HN