The reason Google and Facebook dominate the internet has little to do with technology and much to do with economics, namely scale economies and network effects.
> Yes, the modern browsers have taken us back at least 20 years when it comes to UI design.
I'll grant that CSS is a mess. What else?
> I can only use one hierarchy to denote the same object.
You can create multiple URLs that point to the same object.
And the network effects can only happen because there is a tight coupling between the data (contained and scrambled within the HTML page) and the presentation. Had data and presentation be decoupled, I could have combined network information from various providers and present it to me in one overview.
> I'll grant that CSS is a mess. What else?
Everything. The security model, the fact that the user has limited control over their identity (and it is not build into the protocols), the multi-threaded nightmare, no component standardization, very limited integration with low-level OS systems, the 'one-tab is one context' metaphor, the box-model, the misfit of page-to-interaction (and the history API), the non-existent voice interaction, the color-model, the DPI/pixels/ems transformations, the invisible local storage we barely manage, the resource utilisation, the lack of uniformity in the programming model, the peer-to-peer communication (WebRTC does not count, since it is not standardized and has quite some flaws), the lack of (easy) customization abilities (high-contrast websites), the limited math-rendering, the enourmous complexity... I could go on.
> You can create multiple URLs that point to the same object.
Yes, but they would not denote equivalence. I could use a redirect, but then one system needs to know the representation of the other. It would be fundamentally asymmetric.
Also, it would contradict the term Unique Resource Locator.
This one is interesting because Alan Kay is so expressly against it ("browsers shouldn't have features"). He thinks every object should just render itself as a bitmap.
Besides, browsers do have standard components. That's what the semantic HTML tags like <button /> are. The specific views vary between browsers. Is that a problem? Regardless, almost no site uses the standard stylings that do exist. They use a de facto standard like Bootstrap, or they build their own.
I agree with some of your other points, but I don't understand your lament of "enormous complexity" while you're advocating for more features.
I'm with you in principle. I think such a modular architecture based on standard interfaces between objects is exactly what we need, but I don't see how it precludes e.g. the dominance of Google. Google dominates because they have all the search data. People don't want non-Google results in their views. Non-Google results are worse.
wikipedia defines URL as "Uniform Resource Locator", and i don't think i've ever heard "unique" in there
- reverse index to resources
- Easier to move resources
- Cryptographic signatures on id’s
"What if "data" is a really bad idea?" -- Alan Kay (https://news.ycombinator.com/item?id=11945722)
I just don't see how he has ever pushed for the direction you're advocating. If anything, it's the opposite.
I think he's made his way into this thread, so I invite him to clarify!
In other words, you want to be able to walk into any library and use ISBN as the underlying identifiers, instead of the Dewey system, which is not broadly applicable. You might get the Dewey number from the ISBN and vice versa, but the ISBN resource assigned to a book resource is the fundamental linking pin.
So, when we link from an article, we want to be able to say: "it is this specific article I am linking to, you figure out how to get access to it." This will be much more durable than an ephemeral URL.
This is the fundamental reason the modern internet is centralizing to a couple of entities.
"This has to be one of the worst ideas since MS-DOS."
Yes, the modern browsers have taken us back at least 20 years when it comes to UI design, component based programming and distributed systems. The web is an endless stack of kludges, held together by duck-tape. I can back this up, in case you don't believe me.
But, we should ask ourselves how it became such a stack of kludges. And I think Alan hits the nail on the head.
"At the very least, every object should have a URL. I believe every object on the internet should have an IP. It represent much better what the actual abstracts are of the physical hardware to the bits. "
Beautiful insight. The URL does not scale from a systems perspective. In my designs, I see myself often using UUIDs and negotiation to transfer knowledge about entities. The URL (and RESTful communication) is an annoyance. It fixates the location to something arbitrary. I can only use one hierarchy to denote the same object. I cannot easily renegotiate how the same things are named in my systems. And, the worst: the type of the object is often included in the url. `https://foo.bar/person/123` fixes the type 'person' to the object 123.
URLs nowadays are an abomination. Most are not durable, contain excess information and suffer from projecting the information against an arbitrary axis.
Finally, all developers should at least once have implemented their own compiler. It is not a hard experience at all and can be done in around 100 hours by someone with a medium skill in programming using a good text-book. It gives a truly fundamental insight into systems design and should simply not be skipped.
W.r.t. tools: I assume any programmer worth his salt has build at least some of their tools! Perhaps I should start asking this at interviews. If you don't understand how your tools are built, how can you even begin thinking about building tools for others? And how can you understand, without attempting a crude build yourself? All the hard things are already done, the literature is there, the books are written.
So, anyways, you make a bold claim: "most of what he said was wrong." This is awfully vague, I am afraid. Lets make it a challenge. Except for him making predictions, I challenge you to come up with a couple of statements from Alan Kay, and we'll discuss it.