I'd also like to suggest a little more work on the URL parsing (even though most users probably won't enter anything that will be misinterpreted). For example, if a protocol scheme other than https:// or http:// is used, the browser will probably still treat it specially somehow (even though browsers typically seem to support fewer of these than they used to!). It might be good to catch these other cases.
Show HN: An interactive guide to how browsers work
31–40 of 40 posts
Re: Show HN: An interactive guide to how browsers work
#32This doesn't account for all browsers, only Safari and Chrome. There isn't even a passing mention of separate search and address bars.
Re: Show HN: An interactive guide to how browsers work
#33This is pretty relelevant to a project I'm working on - a new web browser not based on Chromium or Firefox. Web browsers are extremely complex, requiring millions of lines of code in order to deal with a huge variety of Internet standards (and not just the basic ones such as HTML, JavaScript and CSS). A while ago I wanted to see how much of this AI could get done autonomously (or with a human in the loop), you can se…
If you're interested in Python web browsers, may I suggest you take a look at Grail?
Re: Show HN: An interactive guide to how browsers work
#34stupid question: what if we scrapped dns looksups completely and made all the computers actually work with human readable domain names instead?
Re: Show HN: An interactive guide to how browsers work
#35stupid question: what if we scrapped dns looksups completely and made all the computers actually work with human readable domain names instead?
i have an even stupider question, which is what if we scrapped ip addresses and just used ethernet addresses to route everything? just make the entire internet network be one big switch.
i think the guy who created tailscale wrote about something like this...
Re: Show HN: An interactive guide to how browsers work
#36Not all browsers had or have a DOM, and some didn’t until later versions. Early browsers without DOMs (with initial release date): WorldWideWeb (Nexus) (Dec 1990), Erwise (Apr 1992), ViolaWWW (May 1992), Lynx (1992), NCSA Mosaic 1.0 (Apr 1993), Netscape 1.0 (Dec 1994), and IE 1.0 (Aug 1995). Note: Lynx remains a non-DOM browser by design. AOL 1.0–2.0 (1994–1995) used the AOLPress engine which was static with no progr…
Thank you for the suggestion! Would be writing something like "DOM in the modern browsers" more correct then?
I wouldn't do anything to "correct" your guide - I think it is "correct" as is. This comment is great for its informational content but I'd consider it an addendum, not an erratum.
If you like it might be nice to include a section on historical and/or niche browsers that lack some of the elements this guide describes - like e.g. Dillo which is a modern browser that supports HTML4 & doesn't support Javascript. But your guide should (imho) centrally focus on the common expectation of how popular browsers work.
Re: Show HN: An interactive guide to how browsers work
#37Great project, thanks
What's your next steps, do you plan to add more details of the reflow process?
Re: Show HN: An interactive guide to how browsers work
#38nice work!
Re: Show HN: An interactive guide to how browsers work
#39Earlier quoted context omitted.
IANA maintains a list of TLDs in the root zone[0]. I presume browsers use this list, since it does cover all TLDs in >99% of situations. [0]: https://data.iana.org/TLD/tlds-alpha-by-domain.txt
Yes but local/corporate DNS servers can use any TLD they want...
Right, but browsers don't automatically recognize those, as far as I know. If you want to visit a site with a custom TLD I believe you have to prefix it with the protocol.
Re: Show HN: An interactive guide to how browsers work
#40I love the "mental model" approach here. Most guides I've seen either get bogged down in the minute details of TLS/Handshakes immediately or are way too high-level. The interactive packet visualization is a really nice touch to bridge that gap. Thanks for sharing!