I empathize with your frustration, but you’re overlooking a whole lot of value that you claim are from “underwhelming” results.
Any standard with 100x less complexity would have probably 1e6x less utility. Like, it’s “easy” (hah!) to write a bespoke browser that connects to a system on a nonstandard port, requests (without headers!) a markdown document, renders it to the viewport, and allows scrolling and clicking on hyperlinks.
Heck, we’ll call it the Lobsters Transfer Protocol.
The client should just provide a viewport onto the rendered elements of the markdown document, with interactivity only insofar as clicking on links, scrolling the page, and zooming in. The client takes a starting address as a command-line argument airlobster -h <host> -p <port> -d <document path> --rev <optional server-recognizable digest for a particular historical revision of document> --depth <optional depth to resolve dependent documents, defaults to 1>. Client program flow looks roughly like:
Client program starts
Client parses arguments from command line
Client looks up IP for provided host
Client opens TCP connection to host on provided port
Client errors out if connection is rejected.
Specified document is pushed onto fetching queue
Client sends request in plain ASCII GET <document path> <optional digest>\n
Client receives length of document (8-byte unsigned integer, little-endian)
Client receives type of document (8-byte unsigned integer, little-endian)
Client receives byte array of document
Client errors out if byte array is incomplete or times out (say, 30 seconds from last byte if we’re still expecting the array?)
Client closes connection
Client decodes document based on type, puts result into {path, digest, content in renderable inermediate form} tuple stack (why stack? to make sure leaf deps are loaded first)–depth is decremented for use in dependent document resolution
Client renders the contents of the stack
Clicking on a hyperlink clears out the stack and queue, and starts the process again.
The server’s job is equally straightforward:
Accept connections on a port
Drop client unless given valid request string
Drop client if given valid request string but invalid document
Drop client if given valid request string and valid document but invalid digest
Write back length and type of document
Write document to connection
Close connection
Writing that should take about a month, let’s call it, if you are doing it in C (that’s fast enough and painful enough to discourage large overly-complex projects, no?).
And even with this stripped-down networked PDF reader, there are still problems in the spec. What prevents a server from shoving clients on a ride or telling them to allocate too much? How much is too much? What about alternative forms of the same document? Should a document also have a type in addition to its digest for identification? What if a type doesn’t exist for a specified revision?
And we haven’t even touched on the genuinely annoying parts, like rendering the bloody thing at all.
And all of this complexity is a toy compared to the usability most people expect from a browser.
~
Appendix:
Here are some tools that you might find helpful in such a journey:
http is probably the least complex and frustrating part of the whole stack, and the part I’d attack last.
If I did, it would be to create a “git” like content addressable network.
In terms of complexity on the browser end, http is pretty trivial. The bundle of complexity on that level is actually https…. and I’m not convinced of it’s utility. (I’m convinced that encryption and identification is needed, I’m not convinced https is the way to do it.)
It’s the html / css / dom / javascript stack on top of http that is the nightmare.
And most certainly I would not use C, but something like D or (maybe) Rust.
Certainly human language text rendering is insanely complex… but I’d argue it’s not worth the complexity cost it imposes to do it to perfection. You get 90% of the value with ye olde terminal fixed width fonts and 99% of the value with a relatively simplistic library.
The last 1% is just worth the complexity no matter how beautiful it looks. If you want typographic perfection, use a png.
And that’s with a fairly simple rendering of the language. Consider that the actual folks that use Urdu (around 159 million if wikipedia is to be believed) actually see something much richer.
I again don’t see the problem with HTML/CSS/DOM/JS. Like, what parts of the problem domain do you think they’re overkill for?
I again don’t see the problem with HTML/CSS/DOM/JS. Like, what parts of the problem domain do you think they’re overkill for?
I loved their original conceptual orthogonality of structure, content and presentation…
The pixel pushers hated it because they couldn’t pushed the pixels in the corner cases where they wanted to remove that orthogonality.
I’m sure the teachers of English (or Urdu) typography would hate that orthogonality… but I bet all languages will be pretty much equally readable if it was rigidly enforced.
In fact I’d argue your example .jpg has more to do with the traditionally high cost of paper news print than with conveying meaning. You could lay that page out much much more simply and still be readable in Urdu.
I loved the original immutability of the DOM… the need to make it mutable arose the failure of html to address the needs of composing the page from multiple sources.
Facebook’s React.js is the abomination that arose from vile abuse of a mutable DOM.
D3.js is beautiful and a treasure… until you peer under the hood at its hideous entrails…. and long for the wonderful clean faroff days of libplot.
If only the thought and effort that was dogpiled into the stack that D3.js abuses had been used to create a clean and powerful plotting API..
I again don’t see the problem with HTML/CSS/DOM/JS. Like, what parts of the problem domain do you think they’re overkill for?
CSS’s original intended usecases no longer exist. Hardly anyone reused the same original HTML with different stylesheets at the best of times; now that HTML is a presentation format rather than a semantic format there is no value in the HTML/CSS split. Likewise the DOM box model is overly complex because it was intended to support manual layout of a kind that people don’t do any more; every element can have margin/padding/border/… when really these should just be separate blocks. And really there are too many elements because there was this intention to have a common language for semantic markup that never really happened.
If I was writing this stuff from scratch, I would say:
Make the parsing more consistent. E.g. styles could be expressed with JSON or even full javascript.
Don’t parse invalid markup - perhaps even require markup to be sent in a protobuf-esque format so that only well-formed markup can be sent at all.
No CSS. All styling is inline. Offer selector-like functionality in the DOM API but only as a code API, don’t attempt to define a language for selector expressions.
Greatly reduced number of built-in elements. Maybe just <div> and <span> i.e. block and non-block elements.
Remove border/padding/… as first-class concepts. A box with a border is five boxes.
To make all this practical, standardise something like web components. Offer a standard library of components that replicate the functionality of existing tags and attributes.
Aw man. So often it feels like the wrong technology won. About 5 years ago I was working on a project that needed to have a transforming and zooming UI; VRML was an absolutely perfect fit, and the webapp in question was already IE-only. And then IE8 came out and removed the functionality entirely. Now I look at web VR and wish they’d kept the solution that existed and worked.
You are assuming the current complexity is needed for the current functionality, and that it isn’t caused by a windy path of legacy that with current knowledge you could avoid.
I think you are missing the point, the point is the browser has become a whole operating system by accident.
If you split out the awesome parts we have ended up with:
Standard way to display information across operating systems.
Sandboxing and convenient distribution of cross platform applications.
Secure communication with remote servers.
A universal linking/url system.
and remove lots of the legacy we used to get to this point:
complex js engines instead of just making a wasm like system from the start.
insecure defaults requiring things like OWASP guidelines to begin with.
many legacy and deprecated api’s.
… add your favourite problems …
And design things with all of our current knowledge we didn’t have previously, then we might have an equally capable, more secure and cheaper to maintain system.
The false assumption you have is that the complexity is necessary for the current functionality, and that is just incorrect.
Gopher has some nice features, but it doesn’t solve the problem. HTTP is not the hardest part by a long shot, and HTML+CSS+JS monsters can be delivered over gopher just fine :)
…but the pixel pushers have ruined it by layering on piles of crap.
The entire web stack is in dire need of refactoring.
Note: A “Pixel Pusher” is a person, typically managerial, who….
at the expense of meaningful content,
insists on the layout / font / alignment / color /…
be correct (to their personal weird definition of correct)
“to the pixel”.
The web should be removed from their hands and they should be shut in a dark room with only mspaint to play with.
But let’s not throw out the baby with the bathwater… there are some truly excellent things about the web.
Uniform Resource Locators. Excellent idea, and in many senses URN’s are a hint at an even better idea… (Somewhere between URN’s, Distributed Hash Tables, git and Tor is the concept of a content addressable web.
Sadly Fielding is credited for the definition of REST…. and then everything he says is watered down. His far greater contribution is the requirement that Anarchic Scalability must drive your design choices. Sadly this is treated with as much trepidation as a communist at a Republican Party convention.
The notion that structure, content and presentation are orthogonal concerns and hence require three different languages is truly great and empowering. And is probably the thing about the web that is most hated by the pixel pushers.
The importance of standards and interoperability. … however a standard that is not readily implementable is worse than no standard.
If I have a complaint about REST, it’s the “Code on Demand” part. It has been abused without limit to destroy everything else that is good about the web.
I suspect a massively simplified “BPF like” deliberately Turing Incomplete CoD would be a better design.
What would I throw out?
Straight out immediately would go the SGML / XML heritage. What a mistake that was.
There is very very little about JavaScript I like…. so out goes that as well.
Even if one removes the idiocy of wrangling incompatible browsers and the dire hideousness of monstrosities like bootstrap…. you can’t sanely write CSS without a CSS macro preprocessor facility.
HTTP isn’t necessarily the issue here, curl can handle that flawless for example, and every major language has some kind of a HTTP library. Web servers also exist in abundance.
But when it comes to HTML/CSS/JS - that’s where the mess begins. Partially revised standars, torn between backwards compatibility and incompatibility, between being so simple it’s lacking and being so complicated it’s overwhelming. Implementing a CSS layouting engine doesn’t only have to satisfy a standard and a reference implementation, but also all the quirks and ad hoc fixes major, old and long gone browsers came up with, to tackle the practical insufficiently of what some guys came up with.
HTML, a mark up language (implying it’s intended to stylize text, words, paragraphs, etc. - but not necessarily typeset it in every detail) is also cause and caused by this same problem. Due to it’s popularity, people want to use it everywhere, and due to it’s potential, it was hacked into actual fulfilling most of these wishes. And of course, if something is hacked, it probably wasn’t quite well designed. So it follows that the HTML that was one written about in some long forgotten RFC and the one a browser engine developer has to suffer with, are quite different. The former has has to only fulfill an ideal and and intention, the latter has to satisfy a history of compromises, hacks and other tricks on the border of keeping up with, breaking and inadvertently creating new standards.
I’ve been suggesting and thinking about this for a while now, that to fix this we can only use hindsight and humility, to create a simpler, more coherent, but still modern subset of HTML+CSS, that stays true to the intended use of the format, but recognizes the needs of it’s users and limits of it’s standards. Kind of like XHTML, but only less pedantic and based on convention, rather than fatal incompatibility. Idealy it would arise organically, but if necessary groups and individuals could offer suggestions to debate differences. Eventually, so I naively hope, browser developers would commit the radical act of adopting of of these subsets, and thereby creating greater incentive and legitimation to use them. But that’s only to be hoped for…
gopher doesn’t address application sandboxing and cross platform distribution of applications. There is no evidence to me gopher wouldn’t have feature crept in the same ways.
[…] At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way—and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.
– C.A.R. Hoare, “The Emperor’s Old Clothes”, Turing Award Lecture (1980)
He could have been speaking about (but isn’t) the incredible expense of maintaining a browser.
It’s my nature to prefer to pursue the utmost simplicity.
That’s because the web standards are insanely complicated.
Way way way more complexity than is actually needed, and the results are, ahh, underwhelming.
I would jump ship to a competing standard that reduced complexity by a factor 100x in an instant.
I empathize with your frustration, but you’re overlooking a whole lot of value that you claim are from “underwhelming” results.
Any standard with 100x less complexity would have probably 1e6x less utility. Like, it’s “easy” (hah!) to write a bespoke browser that connects to a system on a nonstandard port, requests (without headers!) a markdown document, renders it to the viewport, and allows scrolling and clicking on hyperlinks.
Heck, we’ll call it the Lobsters Transfer Protocol.
The client should just provide a viewport onto the rendered elements of the markdown document, with interactivity only insofar as clicking on links, scrolling the page, and zooming in. The client takes a starting address as a command-line argument
airlobster -h <host> -p <port> -d <document path> --rev <optional server-recognizable digest for a particular historical revision of document> --depth <optional depth to resolve dependent documents, defaults to 1>. Client program flow looks roughly like:GET <document path> <optional digest>\n{path, digest, content in renderable inermediate form}tuple stack (why stack? to make sure leaf deps are loaded first)–depth is decremented for use in dependent document resolutionThe server’s job is equally straightforward:
Writing that should take about a month, let’s call it, if you are doing it in C (that’s fast enough and painful enough to discourage large overly-complex projects, no?).
And even with this stripped-down networked PDF reader, there are still problems in the spec. What prevents a server from shoving clients on a ride or telling them to allocate too much? How much is too much? What about alternative forms of the same document? Should a document also have a type in addition to its digest for identification? What if a type doesn’t exist for a specified revision?
And we haven’t even touched on the genuinely annoying parts, like rendering the bloody thing at all.
And all of this complexity is a toy compared to the usability most people expect from a browser.
~
Appendix:
Here are some tools that you might find helpful in such a journey:
http is probably the least complex and frustrating part of the whole stack, and the part I’d attack last.
If I did, it would be to create a “git” like content addressable network.
In terms of complexity on the browser end, http is pretty trivial. The bundle of complexity on that level is actually https…. and I’m not convinced of it’s utility. (I’m convinced that encryption and identification is needed, I’m not convinced https is the way to do it.)
It’s the html / css / dom / javascript stack on top of http that is the nightmare.
And most certainly I would not use C, but something like D or (maybe) Rust.
Certainly human language text rendering is insanely complex… but I’d argue it’s not worth the complexity cost it imposes to do it to perfection. You get 90% of the value with ye olde terminal fixed width fonts and 99% of the value with a relatively simplistic library.
The last 1% is just worth the complexity no matter how beautiful it looks. If you want typographic perfection, use a png.
90% of the value can mean that 10% get no value.
And that’s with a fairly simple rendering of the language. Consider that the actual folks that use Urdu (around 159 million if wikipedia is to be believed) actually see something much richer.
I again don’t see the problem with HTML/CSS/DOM/JS. Like, what parts of the problem domain do you think they’re overkill for?
I loved their original conceptual orthogonality of structure, content and presentation…
The pixel pushers hated it because they couldn’t pushed the pixels in the corner cases where they wanted to remove that orthogonality.
I’m sure the teachers of English (or Urdu) typography would hate that orthogonality… but I bet all languages will be pretty much equally readable if it was rigidly enforced.
In fact I’d argue your example .jpg has more to do with the traditionally high cost of paper news print than with conveying meaning. You could lay that page out much much more simply and still be readable in Urdu.
I loved the original immutability of the DOM… the need to make it mutable arose the failure of html to address the needs of composing the page from multiple sources.
Facebook’s React.js is the abomination that arose from vile abuse of a mutable DOM.
D3.js is beautiful and a treasure… until you peer under the hood at its hideous entrails…. and long for the wonderful clean faroff days of libplot.
If only the thought and effort that was dogpiled into the stack that D3.js abuses had been used to create a clean and powerful plotting API..
CSS’s original intended usecases no longer exist. Hardly anyone reused the same original HTML with different stylesheets at the best of times; now that HTML is a presentation format rather than a semantic format there is no value in the HTML/CSS split. Likewise the DOM box model is overly complex because it was intended to support manual layout of a kind that people don’t do any more; every element can have margin/padding/border/… when really these should just be separate blocks. And really there are too many elements because there was this intention to have a common language for semantic markup that never really happened.
If I was writing this stuff from scratch, I would say:
<div>and<span>i.e. block and non-block elements.Why not JavaScript?
Aw man. So often it feels like the wrong technology won. About 5 years ago I was working on a project that needed to have a transforming and zooming UI; VRML was an absolutely perfect fit, and the webapp in question was already IE-only. And then IE8 came out and removed the functionality entirely. Now I look at web VR and wish they’d kept the solution that existed and worked.
Years ago, when I was a young and poor web developer, I did this very often, for fun and profit.
I’m not young anymore, but not even in my worst nightmare I saw the world you are describing here!
You are assuming the current complexity is needed for the current functionality, and that it isn’t caused by a windy path of legacy that with current knowledge you could avoid.
what part of the problem domain are they not overkill for?
I think you are missing the point, the point is the browser has become a whole operating system by accident.
If you split out the awesome parts we have ended up with:
and remove lots of the legacy we used to get to this point:
And design things with all of our current knowledge we didn’t have previously, then we might have an equally capable, more secure and cheaper to maintain system.
The false assumption you have is that the complexity is necessary for the current functionality, and that is just incorrect.
Well, there is, or rather was - gopher. There’s still Firefox addon that adds compatibility with gopher (I’m not sure whether it works in 57+).
Gopher has some nice features, but it doesn’t solve the problem. HTTP is not the hardest part by a long shot, and HTML+CSS+JS monsters can be delivered over gopher just fine :)
Don’t get me wrong…
There are excellent things about the web…..
…but the pixel pushers have ruined it by layering on piles of crap.
The entire web stack is in dire need of refactoring.
Note: A “Pixel Pusher” is a person, typically managerial, who….
The web should be removed from their hands and they should be shut in a dark room with only mspaint to play with.
But let’s not throw out the baby with the bathwater… there are some truly excellent things about the web.
If I have a complaint about REST, it’s the “Code on Demand” part. It has been abused without limit to destroy everything else that is good about the web.
I suspect a massively simplified “BPF like” deliberately Turing Incomplete CoD would be a better design.
What would I throw out?
Straight out immediately would go the SGML / XML heritage. What a mistake that was.
There is very very little about JavaScript I like…. so out goes that as well.
Even if one removes the idiocy of wrangling incompatible browsers and the dire hideousness of monstrosities like bootstrap…. you can’t sanely write CSS without a CSS macro preprocessor facility.
HTTP isn’t necessarily the issue here, curl can handle that flawless for example, and every major language has some kind of a HTTP library. Web servers also exist in abundance.
But when it comes to HTML/CSS/JS - that’s where the mess begins. Partially revised standars, torn between backwards compatibility and incompatibility, between being so simple it’s lacking and being so complicated it’s overwhelming. Implementing a CSS layouting engine doesn’t only have to satisfy a standard and a reference implementation, but also all the quirks and ad hoc fixes major, old and long gone browsers came up with, to tackle the practical insufficiently of what some guys came up with.
HTML, a mark up language (implying it’s intended to stylize text, words, paragraphs, etc. - but not necessarily typeset it in every detail) is also cause and caused by this same problem. Due to it’s popularity, people want to use it everywhere, and due to it’s potential, it was hacked into actual fulfilling most of these wishes. And of course, if something is hacked, it probably wasn’t quite well designed. So it follows that the HTML that was one written about in some long forgotten RFC and the one a browser engine developer has to suffer with, are quite different. The former has has to only fulfill an ideal and and intention, the latter has to satisfy a history of compromises, hacks and other tricks on the border of keeping up with, breaking and inadvertently creating new standards.
I’ve been suggesting and thinking about this for a while now, that to fix this we can only use hindsight and humility, to create a simpler, more coherent, but still modern subset of HTML+CSS, that stays true to the intended use of the format, but recognizes the needs of it’s users and limits of it’s standards. Kind of like XHTML, but only less pedantic and based on convention, rather than fatal incompatibility. Idealy it would arise organically, but if necessary groups and individuals could offer suggestions to debate differences. Eventually, so I naively hope, browser developers would commit the radical act of adopting of of these subsets, and thereby creating greater incentive and legitimation to use them. But that’s only to be hoped for…
is
gopher doesn’t address application sandboxing and cross platform distribution of applications. There is no evidence to me gopher wouldn’t have feature crept in the same ways.
Of all the things he mentioned, implementing web standards is certainly only a fraction of the cost - regardless of their complexity.
No, Mozilla needs all that overhead because of the complexity.
If you sliced away two full orders of magnitude of complexity, you wouldn’t need that cruft.
What would a PR person have to do apart from say, “It’s plain, simple, reliable, fast and it works”?
Any questions about “But does it have feature X?” can simply be answered with a “No, and it shouldn’t”
Where’s the PR department for curl?
tbf curl is rather complex for what most people use it for. though that’s probably due to pressure to accommodate the complexities of the web.
Related.
It’s not that “I could do that in a weekend”.
I know I can’t.
However, what I can be guided by is this…
He could have been speaking about (but isn’t) the incredible expense of maintaining a browser.
It’s my nature to prefer to pursue the utmost simplicity.