As an aside, on the subject of writing a browser from scratch, I once had a meeting with my technical director (many jobs past) in which the proposed solution to some oddities in the Qt web browser widget of the day (this would have been around early 2010s, using Qt 4.8.x, I think) was for us to write our own. Apparently this was a basic, simple task that was commonly set in introductory programming textbooks, and should take me a half-day or so to get something basic running.
I pointed out that when Netscape decided to rewrite their browser, with all the knowledge they had of how browsers work, they spent three years doing it, and that was a decade and a half previously when the web was orders of magnitude more simple.
I sometimes wonder how out of context he was. Or I was? What did he think a browser was? Were we speaking at massive cross-purposes? Did he mean we should grab some other web engine and find a way to use that? Even so, a half-day to get something going? And just what introductory programming textbooks was he reading?
Where was I going with this? Somewhere along the lines of how "write a browser" clearly can mean massively different things to different people, or maybe that there can be an enormous gulf of context and understanding there somewhere. To this day, I still don't know. Never will.
There are essentially six pieces to a browser: a platform support library, a graphics rendering platform, a networking layer, the HTML/CSS rendering, the JS VM integration, and the browser shell on top of all of it.
Getting a first cut of really basic HTML rendering--essentially saying, here's a string that's X color and Y font, display it--is probably doable in a day if you have robust implementations of everything else. I have to imagine your director thought that doing HTML rendering was "all" you'd have to do. Of course, what makes building browsers especially hard is there is very tight integration between all of these different components, so that you have to maintain all of these pieces.
Perhaps he meant "write an app that uses an HTML rendering widget that also has the networking components built in"?
In the old days of Chrome you'd occasionally see WebKit engineers griping about how Chrome was taking all the credit for just repackaging WebKit. I remember wondering about this at some point and noticing the code was roughly 50-50 Chrome/WebKit in terms of size (which is a fraught measurement always but hopefully gives you the idea). To be sure the HTML-rendering part of a browser is a central piece of it, but the Chrome part included stuff like v8, the Windows port of WebKit, the network stack, the multiprocess architecture, all the browser widgetry like tabs, bookmarks, and the fancy URL bar, and so on. So I guess even for people who are close to this it's hard to say what making a browser entails.
I pointed out that when Netscape decided to rewrite their browser, with all the knowledge they had of how browsers work, they spent three years doing it, and that was a decade and a half previously when the web was orders of magnitude more simple.
I sometimes wonder how out of context he was. Or I was? What did he think a browser was? Were we speaking at massive cross-purposes? Did he mean we should grab some other web engine and find a way to use that? Even so, a half-day to get something going? And just what introductory programming textbooks was he reading?
Where was I going with this? Somewhere along the lines of how "write a browser" clearly can mean massively different things to different people, or maybe that there can be an enormous gulf of context and understanding there somewhere. To this day, I still don't know. Never will.