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

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.