This is awesome. I've always wanted to know how the actual layout portion works (or at least, can work in a simple way). I think these kinds of resources are really valuable and people should be empowered to make bespoke-ish web renderers as the need arises.
Web Browser Engineering
41–50 of 64 posts
Re: Web Browser Engineering
#42As a front end developer, I am really happy to see resources like this. Developing for the browser is a real challenge. I think working with html / css /js has been a neglected skill for a long time - most software engineers look down on that type of work and its rarely covered in comp sci course work. Still, its good to see a lot of progress has been made, this book included. My only critique - why use python instea…
I agree, JS _the language_ would be a more "obvious" choice for this, since it is both generally much faster and more popular in web development. I assume they are using Python _the ecosystem_ here. It probably comes with packages better suited for rendering specifically? I don't think either is a super compelling choice anyways for this type of work. I think you want to use a systems language here. However Python is…
I think writing this in javascript would add some confusion, as people learning about this might have a hard time understanding exactly where the javascript is running.
Re: Web Browser Engineering
#43Earlier 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 includes dupes, drafts, and unrelated specs. Even if it's overblown by, say, three times, that's still over thirty million words.
Note that a large effort has been made to make specs more precise, to be easier to implement in an interoperable way.
That contributes to "word bloat", but it's not necessarily a bad thing. Picking the right metrics is not always that easy!
Re: Web Browser Engineering
#44Earlier quoted context omitted.
> it includes dupes, drafts, and unrelated specs. Even if it's overblown by, say, three times, that's still over thirty million words.
Note that a large effort has been made to make specs more precise, to be easier to implement in an interoperable way. That contributes to "word bloat", but it's not necessarily a bad thing. Picking the right metrics is not always that easy!
> Note that a large effort has been made to make specs more precise, to be easier to implement in an interoperable way
This is true for HTML5 which defined full browser behaviour, including things like improperly closed and improperly nested tags.
Many, many other specs? Not so much. Especially the crap that Chrome has been pumping out the past several years.
Re: Web Browser Engineering
#45Many 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 i…
> Many years ago, probably 20, I went on a task of implementing a web browser. I remember I gave up at rendering tables.
HTML 5 effort has cleaned up a lot of behaviors and specified how browser tags should behave. So it is, possibly, an approachable task now. Still daunting though.
Re: Web Browser Engineering
#46As a front end developer, I am really happy to see resources like this. Developing for the browser is a real challenge. I think working with html / css /js has been a neglected skill for a long time - most software engineers look down on that type of work and its rarely covered in comp sci course work. Still, its good to see a lot of progress has been made, this book included. My only critique - why use python instea…
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.
This looks fantastic! Really excited to see this. I'm looking forward to reading the updates as well. Cheers.
Re: Web Browser Engineering
#47I recommend this: https://www.html5rocks.com/en/tutorials/internals/howbrowser...
This also looks great. Might you or anyone else know where to find the accompanying video? I get "Sorry
This video does not exist." for the embedded video link.
Re: Web Browser Engineering
#48This video is good background for khtml/webkit on which chrome was based https://www.youtube.com/watch?v=Tldf1rT0Rn0
Re: Web Browser Engineering
#49Earlier quoted context omitted.
Which part of OSs do you expect not to be covered? There's IPC. There's memory management. There's process management. There's network management. There's security. There's device management. They all happen at a slightly higher layer, but they all exist similar to an OS. (I'm not sure if the higher layer makes it easier or harder to understand - but in terms of what you need to know, an OS class or three is definite…
> IPC, memory management, process management, network management. I imagine the non-trivial parts of these are done for the JS VM (correct me if I'm wrong), and therefore a VM design course would have more intersection with Browsers with respect to these disciplines than an OS course. > security This one is everywhere, it has no special connection to OSes. > They all happen at a slightly higher layer Slightly?! That'…
These are all part of the browser outside the VM too.
Multi-process architecture requires you to think deeply about IPC.
Memory management is all over the place - there isn't a browser without custom allocators, investment into GC, etc.
Process management -> see multi-process architecture.
Network management: Browsers need to handle a tremendous amount of network issues. I mean... that's what they do. Outside of the VM, too.
As for "security is everywhere" - the whole point of an OS (and a browser) is to make it possible for security to be everywhere. To provide the primitives that you can securely build on.
> Slightly?! That's an understatement of the week!
Not really, no. I've worked on embedded networking stacks, on full-fledged OSs, and on browsers. I stand by "slightly". Yes, granted, a browser doesn't get quite as bit-fiddly as a on-the-metal OS, but it's a matter of degrees, not quality.
Can you work on many areas of a browser without ever touching OS-like code? Absolutely. This particular book has a good chance of avoiding most, because it focuses on the rendering part.
But a browser, as a whole, provides an abstracted platform just like an OS. And it echoes many concepts, if in slightly different forms.
Re: Web Browser Engineering
#50As a front end developer, I am really happy to see resources like this. Developing for the browser is a real challenge. I think working with html / css /js has been a neglected skill for a long time - most software engineers look down on that type of work and its rarely covered in comp sci course work. Still, its good to see a lot of progress has been made, this book included. My only critique - why use python instea…
> Developing for the browser is a real challenge. I think working with html / css /js has been a neglected skill for a long time - most software engineers look down on that type of work and its rarely covered in comp sci course work.
IMHO, those are job skills and not comp sci topics. They shouldn't be part of a degree program (except the most superficial treatment required to get some ugly UI up that may be required for something else). You have your whole career to pick them up.