3 ms·

I'd think about it like this :- 1) Write socket code to retrieve the page from a server 2) Get it to draw the text in a window. 3) Write code to look for tag

by jbb555 10y ago

I'd think about it like this :- 1) Write socket code to retrieve the page from a server 2) Get it to draw the text in a window. 3) Write code to look for tags and start diving up the retrieved file into a proper DOM tree. Perhaps start by creating an object for each paragraph. Then maybe look for <b> tags, then <div> tags 4) Change the rendering code to draw the screen for the data structure you created above. 5) Iterate a lot. Add support for parsing more and more tags into the data model. Start adding annotations for various attributes. 6) Start improving the layout code. Draw things in <b> tags in bold. Draw things in <div> tags under each other and <span> tags separately. 7) Add limited CSS support. Allow just width and height and border sections. make the code read the css file and attach the attributes to the correct sections of the DOM document you are creating. 8) Improve the layout code to look at the width and height tags on each element, and where tags are nested to propogate the width and height information up and down the tree as needed. Draw borders if the css tells you to. Look at font weight etc. 9) Iterate. Add one feature at a time. Repeat for a year until you have an browser that can render basic pages. 10) Iterate some more. Read specs. Rewrite your document to DOM tree parse a number of times perhaps using a more formal grammar. You'll probably be on about year 8 by now. 11) Add javascript support... :P Perhaps my point is though that this seems something where its very easy to start small, just render the text of a page, and incrementally add features and improve the layout. It will take a long time though as there are so many features to add.

kens 10y ago
The above list is a good start. I'd add: 2a) make clicking on links work, and 3a) display images. Those two features will make it much more fun. "How to make a browser" is something I've thought about for a while, ever since someone suggested it as an interview question. (I think it would be an awful question.) It really depends on what you're trying to do. If you want to understand how browsers work and build a toy browser, follow jbb555's list. If you want to display web pages, use WebKit. If you want to build a real, commercial-scale browser, I recommend a large team, since there are a lot of components, each of which is insanely complex. (Everything from CSS support to security to plugins to JavaScript to bookmarks to a debugger to all the new network protocols.) One more thing to add to jbb555's list: 0) "telnet news.ycombinator.com 80, GET /" - playing around from the command line can give you a good introduction to what really happens when you access a web page. (Edit: HN returns an error page for a plain GET. google.com returns insane code. apple.com looks like a better place to start.)
- jbb555 10y ago
  Yeah, it wasn't intended to be a well thought out list. It was meant to be "just start and iterate" but a little more specific :)
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.
asimuvPR 10y ago
Pretty much this. - Write the networking code to retrieve data from servers. I'd start with GET requests to keep it simple. This part is not that bad and its actually pretty fun. Doing it in Python is very simple and straightforward. - Write browser GUI because its a native application. This depends on what language you use for the task. If Python, you can get away with tkinter (flame suit on) for a very simple prototype. I believe tkinter is single threaded and that may turn out to be an issue (don't remember). - Write a simple rendering engine to display the text. No need to do this inside of the GUI code because the output can be read through the console. You are pretty much reading the raw html and extracting the bits you want. - Plug in the rendering engine into a GUI widget. Since this is a (assumed) read-only browser, you can get away with a simple textbox of sorts. Anything else will require a custom widget. At this point you have a very minimal browser. Adding CSS, javascript, etc requires that you include a pipeline to route data through the proper channels before it reaches the GUI. This is where the bulk of the work goes. Bring beer. :)

by jbb555 10y ago

kens 10y ago

The above list is a good start. I'd add: 2a) make clicking on links work, and 3a) display images. Those two features will make it much more fun. "How to make a browser" is something I've thought about for a while, ever since someone suggested it as an interview question. (I think it would be an awful question.) It really depends on what you're trying to do. If you want to understand how browsers work and build a toy browser, follow jbb555's list. If you want to display web pages, use WebKit. If you want to build a real, commercial-scale browser, I recommend a large team, since there are a lot of components, each of which is insanely complex. (Everything from CSS support to security to plugins to JavaScript to bookmarks to a debugger to all the new network protocols.) One more thing to add to jbb555's list: 0) "telnet news.ycombinator.com 80, GET /" - playing around from the command line can give you a good introduction to what really happens when you access a web page. (Edit: HN returns an error page for a plain GET. google.com returns insane code. apple.com looks like a better place to start.)

jbb555 10y ago
Yeah, it wasn't intended to be a well thought out list. It was meant to be "just start and iterate" but a little more specific :)

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.

asimuvPR 10y ago

Pretty much this. - Write the networking code to retrieve data from servers. I'd start with GET requests to keep it simple. This part is not that bad and its actually pretty fun. Doing it in Python is very simple and straightforward. - Write browser GUI because its a native application. This depends on what language you use for the task. If Python, you can get away with tkinter (flame suit on) for a very simple prototype. I believe tkinter is single threaded and that may turn out to be an issue (don't remember). - Write a simple rendering engine to display the text. No need to do this inside of the GUI code because the output can be read through the console. You are pretty much reading the raw html and extracting the bits you want. - Plug in the rendering engine into a GUI widget. Since this is a (assumed) read-only browser, you can get away with a simple textbox of sorts. Anything else will require a custom widget. At this point you have a very minimal browser. Adding CSS, javascript, etc requires that you include a pipeline to route data through the proper channels before it reaches the GUI. This is where the bulk of the work goes. Bring beer. :)