Live data from Hacker News

Web Browser Engineering (2021)

browser.engineering

11–20 of 138 posts

Re: Web Browser Engineering (2021)

#11
This looks awesome. About 15 years ago, I started working on a headless browser and maintained it for several years. It used SpiderMonkey as the js interpreter and had a custom DOM implementation. It ran all the modern js from the time, AJAX, etc. Later, I added a custom Flash runtime. It basically did everything but draw to the screen. That project was a lot of fun.

I'm definitely interested in going through this book.

Re: Web Browser Engineering (2021)

#12
post #10

Earlier quoted context omitted.

[flagged]

With all due respect, this feels better suited as a journal entry rather than a comment on a HN thread.

Perhaps, but it would have been of little use as a question there.

Once you acquire enough of a feeling for a foreign language that not every bit of your skill in it comes from somebody telling you that a particular thing is said in a particular way, you are doomed to live with a constant suspicion that your feeling is somehow off in a way you don’t recognize. Usually it can be suppressed and ignored, but sometimes it can’t, and occasionally it has to become a question. (I expect this is a fairly common experience.) This was one of those.

Re: Web Browser Engineering (2021)

#13
post #11

This looks awesome. About 15 years ago, I started working on a headless browser and maintained it for several years. It used SpiderMonkey as the js interpreter and had a custom DOM implementation. It ran all the modern js from the time, AJAX, etc. Later, I added a custom Flash runtime. It basically did everything but draw to the screen. That project was a lot of fun. I'm definitely interested in going through this bo…

Umm, if you wanted/want to draw to the screen, what library will you use?

Re: Web Browser Engineering (2021)

#14
post #9

It is so exciting to see material like this being made! Browsers seem like mysterious, undecipherable black boxes, which is very likely how G wants them to be perceived, but that is cracking by seeing the efforts/results of such projects like ladybird and others! I hope to one day be able to jump in and contribute to break that moat! And this books looks like an amazing start!

> I hope to one day be able to jump in and contribute to break that moat!

The moat isn't caused by a lack of non-chrome browser engines, it's because so few people use a non-chrome browser engine. Firefox already exists - it's just that ~no-one uses it and for websites that don't work with it those users have learnt to just open up chrome.

I'd love for the moat to be broken, and contributing to a browser engine like ladybird would be fun - but it doesn't contribute to breaking the moat. I'd love to know what would.

Re: Web Browser Engineering (2021)

#15
post #11

This looks awesome. About 15 years ago, I started working on a headless browser and maintained it for several years. It used SpiderMonkey as the js interpreter and had a custom DOM implementation. It ran all the modern js from the time, AJAX, etc. Later, I added a custom Flash runtime. It basically did everything but draw to the screen. That project was a lot of fun. I'm definitely interested in going through this bo…

Umm, if you wanted/want to draw to the screen, what library will you use?

I believe Chrome uses Skia

Re: Web Browser Engineering (2021)

#16
post #5

The author's post explaining why Python was chosen: https://browserbook.substack.com/p/why-python Apparently some of it now runs in the browser ("in the book itself") by compiling Python to JS? https://browserbook.substack.com/p/compiling-python-to-js

writing it in python makes me actually want to read the book, in fact i definitely will give it a read. if it was done in rust or go id probably skip it, and c++ is just too hard to look at for a fun project. will come back after reading and hopefully have something more meaningful to say about it.

Re: Web Browser Engineering (2021)

#17

Earlier quoted context omitted.

Umm, if you wanted/want to draw to the screen, what library will you use?

I believe Chrome uses Skia

Yes [4].

> [1] The library is used as of 2023 in Google Chrome, ChromeOS, ChromiumOS, Mozilla Firefox, Mozilla Thunderbird, Android, Firefox OS, Flutter,[5] Avalonia (from Alpha 4), LibreOffice (from version 7.0) and RAD Studio[6](since version 12.0).

> [2] Changes to the Skia repository will be rolled into Chromium by the AutoRoll bot several times per day.

> [3] It serves as the graphics engine for Google Chrome and ChromeOS, Android, Flutter, and many other products.

[1]: https://en.wikipedia.org/wiki/Skia_Graphics_Engine

[2]: https://skia.org/docs/dev/chrome/

[3]: https://skia.org/

[4]: https://github.com/chromium/chromium/tree/main/skia

Re: Web Browser Engineering (2021)

#18
post #14
post #9

It is so exciting to see material like this being made! Browsers seem like mysterious, undecipherable black boxes, which is very likely how G wants them to be perceived, but that is cracking by seeing the efforts/results of such projects like ladybird and others! I hope to one day be able to jump in and contribute to break that moat! And this books looks like an amazing start!

> I hope to one day be able to jump in and contribute to break that moat! The moat isn't caused by a lack of non-chrome browser engines, it's because so few people use a non-chrome browser engine. Firefox already exists - it's just that ~no-one uses it and for websites that don't work with it those users have learnt to just open up chrome. I'd love for the moat to be broken, and contributing to a browser engine like…

I'm one of those ~nobodies. Firefox is actually quite good these days, I use it at home and at work, 100% of the time - i.e. no Chrome or Safari fallback needed.

If anyone's looking for a reason to try a switch again, consider this your sign.

Post reply on HN