3 ms·

Is it still even doable for a single person to write a new rendering engine from scratch? I'm getting the impression that right now it's all about Webkit, Gecko

by d33 10y ago

Is it still even doable for a single person to write a new rendering engine from scratch? I'm getting the impression that right now it's all about Webkit, Gecko and IE and given how complex things got, I imagine that it would cost an enormous sum of money to write something that, say, can display top 10 Alexa web pages. Things just got too complex. Perhaps it would be better to have some effort in documenting Webkit code so that more hackers could actually read it and hack on it?

zeta0134 10y ago
It shouldn't be too much for a single person to take on if they're truly dedicated to the task. A small team is still probably more ideal, but the browser isn't overly complex, it simply has a lot of capability that it can pull off with its feature set. All of a browsers moving parts are designed to be quite generic, which allows quite complex interactions to arise out of a small handful of simpler components. Things used to be a lot harder 5 years ago, but the renewed focus on standards means that many smaller browsers can focus on just that, and ignore a lot of the weird quirks found in major browsers safely. (The death of Internet Explorer is finally bringing about the necessary changes in websites that have clung to its quirks mode so blindly for so many years.) I think starting with a manually written parser is a necessary first step if you're writing a web browser. It's tempting to want to pull in Webkit or V8 or Gecko or Chakra, but if you're writing a web browser, you need to understand what these tools are actually doing for you before you use them. Writing your own versions, even if that's time consuming, will teach you why these other frameworks have become so popular, and educate you about their shortcomings so you can hopefully code around those too. If you do it write, and your codebase is appropriately modular, it should be straightforward to modify the project down the road to use a different parser, or even an entirely different DOM tree implementation.

by d33 10y ago

zeta0134 10y ago

It shouldn't be too much for a single person to take on if they're truly dedicated to the task. A small team is still probably more ideal, but the browser isn't overly complex, it simply has a lot of capability that it can pull off with its feature set. All of a browsers moving parts are designed to be quite generic, which allows quite complex interactions to arise out of a small handful of simpler components. Things used to be a lot harder 5 years ago, but the renewed focus on standards means that many smaller browsers can focus on just that, and ignore a lot of the weird quirks found in major browsers safely. (The death of Internet Explorer is finally bringing about the necessary changes in websites that have clung to its quirks mode so blindly for so many years.) I think starting with a manually written parser is a necessary first step if you're writing a web browser. It's tempting to want to pull in Webkit or V8 or Gecko or Chakra, but if you're writing a web browser, you need to understand what these tools are actually doing for you before you use them. Writing your own versions, even if that's time consuming, will teach you why these other frameworks have become so popular, and educate you about their shortcomings so you can hopefully code around those too. If you do it write, and your codebase is appropriately modular, it should be straightforward to modify the project down the road to use a different parser, or even an entirely different DOM tree implementation.