> Tim Berners-Lee [inventor of the World Wide Web] and many others have called the design of the URL clumsy because we have host.domain— welcometothejungle.com—where it’s hierarchically going from lower to higher. And then we have the path component—/en/collections/behindthecode—which goes from higher to lower. We also use a mix of periods and slashes. So Berners-Lee proposed that domain/host/path—that is, com/welcometothejungle/en/collections/behindthecode—would be a better design. What are your feelings about that?
> I designed it this way for autocomplete. My vision at the time was that people would want to do autocomplete or they might want to just type part of the domain name and have it completed in a search list of the local environment. So it would not make sense to have the country code first. It had to be the least-significant part if you’re going to have any kind of reasonable search list or autocomplete. Imagine if we were to type “com.” and then wait for autocomplete. Out of 160 million choices, there would be a pretty long pull-down menu. So in the absence of any agreement or, in my view, cogent arguments about why the other way around made more sense, I did it that way.
I wonder if he considered that even under a domain/host/path format, an autocomplete could probably be designed to ignore the domain and search the host.
Eg, if you're searching for com/welcometothejungle/en/collections/behindthecode, just start typing "welcometothejungle" and autocomplete will find that substring and return the full URL.
Whats the issue with having the domain name, an essentially flat map from name to number, going from least general to most general, and a path, representing a file system tree, going from most general down its nodes to the most specific?
Is the argument they make up two parts of a url, and thus should behave the same way? Seems a bit superficial.
Yeah if your objective is differentiate between domain and file system path then that’s one way of doing it. That might help with parse-ability, especially if your protocol allows for an optional subdomain which may or not be there, so having a clear separation b/t domain and path might be useful. Hard to know without having been there when these decisions were being made.
So presumably nslookup -ls had some logic for finding the apex for a particular name, doing an AXFR and then filtering it to the the target name and below?
> Tim Berners-Lee [inventor of the World Wide Web] and many others have called the design of the URL clumsy because we have host.domain— welcometothejungle.com—where it’s hierarchically going from lower to higher. And then we have the path component—/en/collections/behindthecode—which goes from higher to lower. We also use a mix of periods and slashes. So Berners-Lee proposed that domain/host/path—that is, com/welcometothejungle/en/collections/behindthecode—would be a better design. What are your feelings about that?
> I designed it this way for autocomplete. My vision at the time was that people would want to do autocomplete or they might want to just type part of the domain name and have it completed in a search list of the local environment. So it would not make sense to have the country code first. It had to be the least-significant part if you’re going to have any kind of reasonable search list or autocomplete. Imagine if we were to type “com.” and then wait for autocomplete. Out of 160 million choices, there would be a pretty long pull-down menu. So in the absence of any agreement or, in my view, cogent arguments about why the other way around made more sense, I did it that way.
This guy is my hero.