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

Web Browser Engineering

browser.engineering

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Web Browser Engineering

#31

Post by chrishtr »

amelius wrote: post #2

Is this written by actual web browser engineers? If so, what fields did they specialize in?

Author here.

I'm the rendering lead for Chrome, and know quite a lot about how it works. I also recently wrote a series of articles about the new rendering architecture of Chromium, see here:

https://developer.chrome.com/blog/renderingng/

Pavel is a professor at the University of Utah and has extensively studied CSS from an academic point of view. He also has a lot of experience teaching the material and making it accessible to students.

Re: Web Browser Engineering

#32

Post by varispeed »

Many years ago, probably 20, I went on a task of implementing a web browser. I remember I gave up at rendering tables. I couldn't wrap my head around on how to properly size them. It has become extremely complex quickly to address edge cases and I eventually gave up when I couldn't understand what's going after having a two weeks break. Probably if I had money and was able to commit full time I could eventually get it, but I had to focus on commercial work and putting food on my table.

edit: it's a great article! But nothing on rendering tables :-)

Re: Web Browser Engineering

#33

Post by dmitriid »

fabrice_d wrote: post #30
dmitriid wrote: post #26

Earlier quoted context omitted.

"The total word count of the W3C specification catalogue is 114 million words at the time of writing. If you added the combined word counts of the C11, C++17, UEFI, USB 3.2, and POSIX specifications, all 8,754 published RFCs, and the combined word counts of everything on Wikipedia’s list of longest novels, you would be 12 million words short of the W3C specifications" https://drewdevault.com/2020/03/18/Reckless-limit…

It's well known that Drew Devault count is meaningless since it includes dupes, drafts, and unrelated specs. Still, the space to cover for a from scratch browser is huge. Flow didn't start "from scratch" recently, it's an evolution of a primarily SVG+CSS renderer for set top boxes. They also re-use Spidermonkey as their Javascript engine.

> It's well known that Drew Devault count is meaningless since it includes dupes, drafts, and unrelated specs.

It's not meaningless. Because in order to implement a browser, you have to figure out which of them are dupes, deprecated, drafts etc.

And even that won't help you. Because a huge amount of "deprecated" standards are in the browsers. A huge amount of stuff in the browsers is still at the "community draft" stage, and yes, you have to implement that, too.

Microsoft simply gave up, forked Chromium... And they still can't keep up: https://web-confluence.appspot.com/#!/confluence

Re: Web Browser Engineering

#34

Post by chrishtr »

tester756 wrote: post #23

I recommend this: https://www.html5rocks.com/en/tutorials/internals/howbrowser...

Author here.

That article, along with a number of other resources, are listed here:

https://browser.engineering/bibliography.html

In my view, a critical part of really learning how something as complicated as a browser works is by trying to build it yourself. That's why our book is oriented around building a browser as you go.

Re: Web Browser Engineering

#35

Post by pavpanchekha »

gnull wrote: post #29
pavpanchekha wrote: post #10

Earlier quoted context omitted.

Author here. I wrote up my answer here: http://browser.engineering/blog/why-python.html Basically: server-side JavaScript is just not as widely known as Python, and it'd be additionally confusing when our browser starts running JavaScript. And in-browser JavaScript is a bit too restricted (by things like the same-origin policy) to do the whole thing inside a browser.

Great blog design, btw! I love the way it displays footnotes (if you can call them that now) on page margins. Does it have RSS?

Yep! You can point your RSS reader at https://browser.engineering/rss.xml

Re: Web Browser Engineering

#37

Post by fabrice_d »

dmitriid wrote: post #33
fabrice_d wrote: post #30

Earlier quoted context omitted.

It's well known that Drew Devault count is meaningless since it includes dupes, drafts, and unrelated specs. Still, the space to cover for a from scratch browser is huge. Flow didn't start "from scratch" recently, it's an evolution of a primarily SVG+CSS renderer for set top boxes. They also re-use Spidermonkey as their Javascript engine.

> It's well known that Drew Devault count is meaningless since it includes dupes, drafts, and unrelated specs. It's not meaningless. Because in order to implement a browser, you have to figure out which of them are dupes, deprecated, drafts etc. And even that won't help you. Because a huge amount of "deprecated" standards are in the browsers. A huge amount of stuff in the browsers is still at the "community draft" st…

The Edge graph stops before they switched to chromium though...

Re: Web Browser Engineering

#38

Post by dmitriid »

fabrice_d wrote: post #37
dmitriid wrote: post #33

Earlier quoted context omitted.

> It's well known that Drew Devault count is meaningless since it includes dupes, drafts, and unrelated specs. It's not meaningless. Because in order to implement a browser, you have to figure out which of them are dupes, deprecated, drafts etc. And even that won't help you. Because a huge amount of "deprecated" standards are in the browsers. A huge amount of stuff in the browsers is still at the "community draft" st…

The Edge graph stops before they switched to chromium though...

Yes, that was my mistake. Doesn't make my words any less true.

Re: Web Browser Engineering

#39

Post by carapace »

jahewson wrote: post #22
baybal2 wrote: post #21

It's now nearly impossible to build a web browser from scratch because of runaway explosion of web browser features, and proprietary API extensions. W3C here is unfortunately a part to the problem. Standardisation is good, but letting google pour streams halfassedly written RFCs onto other browsermakers is not good. Non-enforcement of standards is also bad, and it's bad to extend W3C privileges to companies who thems…

Actually a from-scratch web browser is being built: https://www.fastcompany.com/90611677/flow-ekioh-web-browser-... Also you should take a look at the WHATWG because it’s far more relevant than the W3C nowadays.

Flow browser isn't FOSS.

> WHATWG [is] far more relevant than the W3C nowadays.

Which is arguably part of the problem.

Re: Web Browser Engineering

#40

Post by carapace »

fabrice_d wrote: post #30
dmitriid wrote: post #26

Earlier quoted context omitted.

"The total word count of the W3C specification catalogue is 114 million words at the time of writing. If you added the combined word counts of the C11, C++17, UEFI, USB 3.2, and POSIX specifications, all 8,754 published RFCs, and the combined word counts of everything on Wikipedia’s list of longest novels, you would be 12 million words short of the W3C specifications" https://drewdevault.com/2020/03/18/Reckless-limit…

It's well known that Drew Devault count is meaningless since it includes dupes, drafts, and unrelated specs. Still, the space to cover for a from scratch browser is huge. Flow didn't start "from scratch" recently, it's an evolution of a primarily SVG+CSS renderer for set top boxes. They also re-use Spidermonkey as their Javascript engine.

> it includes dupes, drafts, and unrelated specs.

Even if it's overblown by, say, three times, that's still over thirty million words.

Post reply on HN