A language like PostScript would have been a much better foundation for the web than HTML+CSS+JS.
Browser engines would be much simpler. The platform would have had rich design capabilities much earlier and easier. A simple Forth-style language would have been a much better compilation target for high-level app development languages than JS. And having programmability built in from the start would have forced browser developers to think about security models as an integral part of the platform.
Actually, the original web browser, WorldWideWeb (circa 92) could display postscript files. As browsers were created for other operating systems, support for all the media that a NeXT could display was lost... NeXT's GUI was unique in that it was built on Display PostScript...
This also tells us that Tim Berners-Lee was familiar with postscript and its power, but still decided to base the hypertext on a SGML-derived declarative document format without embedded rendering instructions.
I don't agree; it violates the principle of least power (Berners-Lee).
You would inhibit accessibility, including the transition the web made from desktop to mobile -- e.g. consider how <select> is rendered on a phone. The browser needs semantic knowledge of elements on the page; it can't just be code.
You may also inhibit web crawlers and search engines, which are essential to the popularity of the web. You can't write an infinite loop in HTML, but you can in PostScript.
It's also not clear to me that PostScript can handle responsive layouts better than CSS (and a sibling comment hints at that, e.g. adding JS to do layout). CSS handles this at great cost, but it's also a hard problem.
In other words, it's reasonable for the web to HAVE vector graphics, but it can't BE vector graphics. Just like it has WebAssembly, but it isn't WebAssembly (nor would have that been a good idea from the start).
I think Alan Kay would disagree with that (and I do too, having written a lot of responsive layout code in PostScript, including a user interface toolkit (The NeWS Toolkit), a hypermedia browser (HyperTIES), and a HyperCard-like PostScript extensible interface builder (HyperLook), and various apps (PizzaTool, SimCity, etc), all that handle window resizing, dynamic responsive layout, and high resolution printing).
See his answer to the question "Should web browsers have stuck to being document viewers?" (And the ensuing discussion.)
You have to log in to see the replies to his reply, which includes a discussion about JAM and NeWS and PostScript based browsers and rendering.
>Alan Kay, Still trying to learn how to think better
>Actually quite the opposite, if “document” means an imitation of old static text media (and later including pictures, and audio and video recordings).
>It was being willing to settle for an overly simple text format and formatting scheme — “for convenience” — that started the web media architecture off in entirely the wrong direction (including the too simple reference scheme c.f. Doug Engelbart and Ted Nelson). Circa early 90s, it had the look and feel of an atavistic hack. I expected that Netscape would fix this rather than just try to dominate what was there (I expected a better architecture both for “thinking about media in the age of computing” and also something not like “an app” but more like an operating system to deal with the actual systems requirements, demands, and scalings of the world-wide Internet-in-progress).
>It’s both surprisingly and dismayingly difficult to get people — especially computerists — to criticize the web and the web browsers — even more so perhaps today.
>This is despite the glaring fact that the interactive media provided by the web and browsers has always been a hefty and qualitative subset of the media on the very personal computers that run the web browsers.
>[...]
>This led to a “sad realization” that sending a data structure to a server is a terrible idea if the degrees of freedom needed on the sending side are large.
>And eventually, this led to a “happy realization”, that sending a program to a server is a very good idea if the degrees of freedom needed on the sending side are large.
>John Warnock and Martin Newell were experimenting with a simple flexible language that could express arbitrary resolution independent images — called “JAM” (for “John And Martin” — and it was realized that sending JAM programs — i.e. “real objects” to the printer was a much better idea than sending a data structure.
>This is because a universal interpreter can both be quite small and also can have more degrees of freedom than any data structure (that is not a program). The program has to be run in a protected address space in the printer computer, but it can be granted access to a bit-buffer, and whatever it does to it can then be printed out “blindly”.
>This provides a much better match up between a desktop publishing system (which will want to print on any of the printers available, and shouldn’t have to know about their resolutions and other properties), and a printer (which shouldn’t have to know anything about the app that made the document).
>“JAM” eventually became Postscript (but that’s another story).
>Key Point: “sending a program, not a data structure” is a very big idea (and also scales really well if some thought is put into just how the program is set up).
Anyway, as I recall, Kay is making essentially the exact same argument as the Adobe guy, and the way he said it in that talk (Programming and Scaling, thanks below) displays astonishing ignorance for such a brilliant guy.
If Kay is right, then he should just create a web that is based on a VM. And then he can see how far it goes. It will never go anywhere because it will be broken by design.
And I'll elaborate on that and say that Kay's designs are probably brilliant for small scales, but not for large scales and heterogeneous problems.
It's easier to design something for a small scale. You can get a more coherent result that feels nicer locally.
But the whole point of the web is large scale -- WORLD WIDE was in fact TBL's original vision (e.g. see original proposals linked below). That's a much more constrained and thus harder design problem.
Alan Kay is opposed to the "principle of least power" and instead believes the web should consist of turing-complete "objects" which manage their own rendering.
Basically he wants a web consisting purely of "black box" Java Applets rather than of web pages. I think this vision have failed multiple times for obvious reasons.
Repeating what I said in the original comment: the web should HAVE a VM; it shouldn't BE a VM.
The web is hyperlinked DATA that optionally leads you to CODE. The VM-centric design is mistaken and broken, and it's a moot point because it won't ever be deployed in at a large scale in practice.
Like Kay's other designs, it's OK for a small scale and clean slate, but not for a large scale.
Importantly, the web can have and has had MULTIPLE VMs -- Java (via NSAPI), Flash, JavaScript, WebAssembly, and I would say PDF since all browsers now have readers built-in. The design of languages for code is more difficult and ephemeral than the design of languages for data.
The web scales with TIME (decades), not just users (billions of people). Kay's designs don't scale in either direction.
Kays vision is like if we only had JavaScript drawing directly to the screen, and no HTML or any of the other web standards. In such a web we wouldn't have search engines, probably not even links.
The object oriented paradigm (with data and behavior encapsulated in black-box objects) works fine for software systems, but it absolutely fails for large decentralized communication systems. TBL understood that and instead based the web on declarative data formats, and eliminated the behavior to a few verbs (GET, POST etc.) with constrained semantics.
OOP is great when appropriate but it seems Kay doesn't recognize the limitations of the paradigm. Even Java have abandoned the strict object-dogmatism and embrace more data-oriented patterns.
Yes exactly; I think of the web as a modest and humble (and thus brilliant) extension of Unix. It adds simple networking and hyperlinks to hierarchical namespaces (and extends hierarchical names as URLs).
Those principles scale. GET/POST is basically the Unix/Plan 9 principle of read() / write() of declarative formats.
On a small scale you can avoid that and use more tightly coupled RPC (and maybe you should), and you can design more elaborate VMs.
On a large scale it all becomes REST (e.g. what do you talk to Github with, what does a Debian repo look like, etc.). It's less about the technical design and more about the social issues -- who owns each end of the wire? If you own both ends of the wire, you have a much different problem, but that's not the problem the web is solving.
When watching the Kay talk, I was struck that he seems to be lumping every "good" in software engineering under the term "object oriented". Virtual machines are objects. Servers are objects. Numbers should be objects. All abstraction is objects. It was not really a useful or enlightening way of thinking about the world.
At the very least, embedded PostScript should have been supported for scalable graphics from the beginning. We now have this "sort of" available with the HTML <canvas> element, which uses essentially PostScript primitives for drawing with JavaScript. However, this format is not amenable to easy automated processing within the language, because in contrast to PostScript, JavaScript is not a homoiconic language.
A useful compromise between simplicity, security and flexibility could have been Encapsulated PostScript (EPS), a subset of PostScript with certain restrictions.
While there is some software capable of using postscript as a serialization format (eg Xcircuit, I'm not sure how it does it but my guess is that the side affect of some of the functions is to create drawing elements) that would be way harder to work with. Think about all the problems Javascript creates, now imagine dealing with them is necessary just to extract the page content. No thank you, I've written simple HTML parsers/DOMs in ~300 LoC and that would be way harder with something turing complete.
Postscript instead of JS, maybe (I wrote some Postscript programs in the 90s). But we would still create pages in HTML because fixed positioning and unpredictable window sizes never mixed well: Java applets, Flash, ActiveX in the past, embedded PDFs today. They had and have their use cases but you don't create a web site with them or it will render very badly for too many of your users.
PostScript can certainly handle resizable windows (or "responsive" rendering as the kids are calling it these days).
See the heavily commented PizzaTool source code, which renders a color preview of your pizza in a resizable pizza shaped window (which you can spin) as well as faxing a hires black and white picture of the pizza with your order:
The Story of Sun Microsystems PizzaTool:
How I accidentally ordered my first pizza over the internet.
>Designing to Facilitate Browsing: A Look Back at the Hyperties Workstation Browser (1991)
>Abstract
>Since browsing hypertext can present a formidable cognitive challenge, user interface design plays a major role in determining acceptability. In the Unix workstation version of Hyperties, a research-oriented prototype, we focussed on design features that facilitate browsing. We first give a general overview of Hyperties and its markup language. Customizable documents can be generated by the conditional text feature that enables dynamic and selective display of text and graphics. In addition we present:
>an innovative solution to link identification: pop-out graphical buttons of arbitrary shape.
>application of pie menus to permit low cognitive load actions that reduce the distraction of common actions, such as page turning or window selection.
>multiple window selection strategies that reduce clutter and housekeeping effort. We preferred piles-of-tiles, in which standard-sized windows were arranged in a consistent pattern on the display and actions could be done rapidly, allowing users to concentrate on the contents.
>[... here's what the kids these days call "responsive layout", but implemented in the late 1980's for NeWS HyperTIES:]
>Figure 2 shows many HML features that allow authors to create visually appealing pages while maintaining a consistent database format. First, many commands (.style, .size, .para, etc.) control the formatting of text and its position on the screen. Second the HML is a full programming language, allowing the creation of nested blocks, with local variables and macros. Although variables created inside a block are usually local, it is possible to create and make changes to global variables. Blocks are very useful in creating structural formatting, e.g. section headings are tagged, rather than having explicit commands for larger font, boldface, and line spacing. In Figure 2 the macro .indent makes use of blocks to obtain the desired formatting. Blocks together with macros are very useful to create style files, a set of macro definitions that can be used in any article in the database. In Figure 2, chap_name, sec_title and indent could have been defined in a style file. The use of any of them in any article would then guarantee consistency throughout the database.
>Style files guarantee consistency, thereby reducing the burden for authors and browsers. Also thoughtful use of style files could give further cues to lessen disorientation, e.g. major articles would be in larger fonts, while secondary articles might be in smaller fonts.
>[...]
>Each selection of a highlighted link can set a variable. Predicates on these variables can be tested to decide on whether one string or another is displayed. This permits optional text to be suppressed, selection of national languages, Ted Nelson’s “stretch text”, an outliner, and other features. Figure 3 gives an example of conditional text for a software installation manual (in our example, “Magic Paint”). This software package can be installed either on a Macintosh or an IBM PC. It provides for different configurations on each machine, different floppy disk sizes, one or two floppies, and hard disk options. When this storyboard is interpreted, users should already have indicated what configuration they possess, thereby setting the proper variables. Suppose the user has a Macintosh with two floppy drives, then the variables .macintosh and .dual_floppy would be set to true while the other variables would be set to false. This will cause the storyboard interpreter to generate a screen with information relevant to this user’s task.
I disagree, I did some Postscript programming, and it was very much oriented around printing documents so I don't think it would be great for a DOM in a browser.
PostScript's native Array/Dictionary data structures are practically identical to JSON and JavaScript's polymorphic Array/Object (or Python's Array/Dict).
And NeWS PostScript uses "Magic Dictionaries" that look and feel like dictionaries, but are wrappers around built-in objects implemented in C, like canvases, processes, events, fonts, etc. Sort of like getters and setters that invoke native code. They make it much easier to extend PostScript and implement APIs without adding a lot of operators to the language.
And NeWS had an object oriented programming system called "class.ps", designed by Owen Densmore, that represented objects with dictionaries (and magic dictionaries too, with OpenWindows NeWS 2.0 but not the original NeWS 1.x). We used it to write all kinds of user interface toolkits, widgets, applications, and it worked very well.
See the Pizzatool source code for a well commented example:
Tom Stambaugh described how Smalltalk inspired Owen Densmore's PostScript object oriented system in NeWS.
A point he didn't mention is that PostScript is directly descendent from Interpress, which was developed at Xerox PARC and reincarnated as PostScript at Adobe by Chuck Geschke and John Warnock:
It seems to me that Forth is to stacks what LispLanguage is to lists. Forth demonstrated the advantages of a stack-centric paradigm in which each pushed or popped item could be evaluated as an expression or a primitive. Postscript reflects the application of that paradigm to the world of typography, 2-d graphics, and page layout. My own recollection is that Postscript's primary contribution was the use of splines to describe character glyphs, allowing them to be effectively rendered at virtually any resolution desired. If anything, Postscript owes more to TexLanguage and DonaldKnuth than to Forth. I view the stack-based language paradigm as a convenient afterthought rather than a central organizing principle.
I also think we should note the contribution that OwenDensmore, at Sun, made in demonstrating how to use Postscript dictionaries to create a dynamically-bound object-oriented runtime environment. This was the fundamental premise of the Sun window server that ultimately became the NetworkExtensibleWindowSystem. Owen and I discussed his "crazy" idea at a poolside table at the now-demolished Hyatt Palo Alto, on El Camino. I told him that it made sense to me, we scribbled furiously on napkins, and I helped him see how he might adopt some learnings from Smalltalk. It was one of those afternoons that could only have happened at that time in that place in that culture. -- TomStambaugh
I've extracted Owen Densmore's paper from the news.tape.tar (marked PD), "Object Oriented programming in NeWS", and uploaded it:
It would require some modification to run in other postscript environments, but not much, I think. It was developed after the 1st Edition Postscript manual but before the second, so it's considered a Level 1.5 Postscript environment. It uses dictionaries freely, but the << /Level-2 (syntax) >> had not yet been invented. So it uses a number of nonstandard operators for dictionary construct. These would need to be simulated or the routines rewritten to use Level 2 syntax. -- luserdroog
comp.lang.forth discussion on "Why is Postscript not Forth?":
Wouldn't that be slower? To this day, despite the continued efforts to improve the rendering speed, I hesitate a bit before opening PDF files due to their heaviness. In that alternative universe, would it be possible to optimize PS renderers to be on a par with HTML+CSS+JS renderers? I also guess such "webpages" would require more bandwidth because they need to include every font glyph used.
PDF files can be heavy or light, just like a webpage can be heavy or light. These days most PDF files are machine generated without much care for file size and you get their stereotypical heaviness. If you take a bad webpage generator (such as Word 2003) you get highly complex and redundant markups too.
Also PDFs can embed font glyphs. That doesn't mean they have to. Common fonts like Helvetica are even guaranteed to be available in any PDF viewer.
What, you can go to the 522’s page of a pdf and it will insta-appear. With web technology, you can’t even begin scrolling because layouting happens from top to bottom.
Of course there are some pdf’s that is so full of multilayered vector graphics that it may take a short while, but goddamn facebook starts up the fans in my laptop, so it is hardly fair comparison.
PostScript is like PDF, it assumes a canvas of fixed dimensions. This is fine if everyone has screens of the same dimensions or only prints to read on paper (and nobody have bad eyesight). But on the web there is a wide variety of viewport dimensions, so a PDF-like layout would either make text to small or require incessant scrolling back and forth and up and down.
CSS is more complex than PostScript because it tackles a much harder problem.
OK, since PS has an embedded programming language I guess you could program the layout to adapt to different viewport dimensions. This would force you to embed the complexity of CSS/browser layout engine in each page.
>PostScript is like PDF, it assumes a canvas of fixed dimensions.
Actually, the most important way PostScript is unlike PDF is that it's a Turing complete programming language, which is useful for implementing responsive layout.
>CSS is more complex than PostScript because it tackles a much harder problem.
No, CSS is more complex than PostScript because it was designed by a bickering committee and competing companies over a long period of time, and nailed onto the side on HTML as an afterthought of a shotgun wedding.
>This would force you to embed the complexity of CSS/browser layout engine in each page.
Or implement a shared library or user interface toolkit or browser platform or scriptable Hypercard-like environment that makes it easy to implement responsive layout. See my comments above about The NeWS Toolkit, HyperTIES, HyperLook, PizzaTool, etc.
> No, CSS is more complex than PostScript because it was designed by a bickering committee and competing companies over a long period of time, and nailed onto the side on HTML as an afterthought of a shotgun wedding.
That is not really an argument, that is just en emotional outpouring. I haven't seen anyone propose a simpler solution which solves the same real-world problems. But you can easily create a simpler solution if you ignore the problems of different device dimensions, accessibility etc.
Anyway, CSS itself is not the issue. Even before CSS, the browsers used a layout model which was adaptive to different viewport dimensions and text scalings. This layout model is formalized in CSS as "normal flow", but the model itself predates the CSS spec. CSS now allows you to override these defaults in various ways so you can create a layout with fixed dimensions. But by default it is adaptive.
In PostScript you need to explicitly write code to make the layout adaptive. If you want it to be as adaptive as HTML is by default, you will end up implementing something of similar complexity to a HTML rendering engine in each page (never mind issues with search engine indexing, accessibility and so on) - or you will bundle an adaptive rending library, in which case we are back to square one - a browser rending engine.
HTML + CSS may be "bad" and "ugly" but have the great advantage that it actually works in the real world. Ugly things that work is always going to beat elegant things that doesn't work.
A language like PostScript would have been a much better foundation for the web than HTML+CSS+JS.
Browser engines would be much simpler. The platform would have had rich design capabilities much earlier and easier. A simple Forth-style language would have been a much better compilation target for high-level app development languages than JS. And having programmability built in from the start would have forced browser developers to think about security models as an integral part of the platform.