Have you ever used a hypertext environment built around PostScript? I worked with one for a few years in the early 90s (HyperNeWS).

While this was very powerful and hugely entertaining from a geek perspective it was never going to be suitable for a wider audience - primarily due to the nature of PostScript itself. Don't get me wrong, I really liked PostScript as a programming language, but you have to admit that it isn't something that most people would be happy working with.

I use postscript all the time--as an automatically generated result of my LaTeX files. A decent set of LaTeX macros would let you make basic text+hyperlinks postscript web pages without too much trouble, I'd think.

True.

However, if you wanted scripted behavior in your generated documents then things could get interesting.

Just as people who know only plain HTML or use crappy site builders end up with simple static pages, those who do not wish to learn Postscript would only be able to make static pages. However, more advanced users would obviously learn Postscript and write their own dynamic behaviour, ala Javascript.

PDF basically has the necessary features to do that already. Nothing actually stops you.

(Before you say "Ewww, PDF", recall PDF is basically Postscript, and most of the reasons you would say "Ewww, PDF" would still apply. I did say "most", there are some exceptions. Now, if you want to say, "Ewww, Adobe", I'm right there with you.)

At the rendering level Postscript and PDF are similar, but Postscript is a complete language. You could send semantically structured content and do appropriate layout on the client device all from inside Postscript.

You'd probably want to write in some other language or tool and use Postscript as an object language, like in the day of printers.

The huge difference is that the evolution of the media would be in the hands of the content creators, not the browser writers/choosers.

I would try this fork of the multiverse.

The Postscript rendering has to be sandboxed, running in a secure, limited context.

At least, that's what NeXT had to do with their Display Postscript. Prior to that it was possible to email someone a postscript file which the WindowServer would try to render for display in the mail window. One such file that went around would, when you clicked on the email, grab all your windows, spin them around the screen, and throw them off.

That's harmless, but Display Postscript included file operations...

Sandboxing would be required.

Delegating an area of display would also need to be part of the security model to support things like third party ads.

Ah, the details…

Yeah, thank god we now have operating systems which can't be harmed by email attachments... oh wait.

Any further explanation? I think for most people with websites, postscript would be an absolutely terrible choice: the barrier to entry is simply too high.

(Note: I think PostScript, and stack-based languages generally, can be great fun, but really not for the average “guy making a site about his dog” sort of user)

I am not as sure it would be such a horrible choice. Most people don't hand code their site and a Postscript derivative would have probably got decent support from Illustrator and the DTP crowd. It would have probably been easier for the normal user because writing software to create the pages would have been quite a bit easier. It would have spawned a lot more software instead of the user-unfriendly "use a text editor" culture we have now. Also, having an actual display model that was well understood by the creative crowd would have been pretty nice.

> postscript would be an absolutely terrible choice: the barrier to entry is simply too high.

You say that like it's a bad thing.

Port 83 is free as far as I can see, I'm game. HPTP?

Or Content-type: text/hyper-postscript?

It would be cool to try something like this, but I also wonder if the web is "it". With all this talk about net neutrality, it sometimes gets lost that the cool thing was being able to invent a new service on a new port. Would the web have been here if the net port restricted like it does today in the days of gopher?

If you were going to do this.... I would probably go with something more persistent in a protocol (more X windows than http). Flip the axis (0,0 top left) and ... well a lot of things from display postscript ... might be fun,

> With all this talk about net neutrality, it sometimes gets lost that the cool thing was being able to invent a new service on a new port.

But we can do that just as easily today.

> Would the web have been here if the net port restricted like it does today in the days of gopher?

There are very little port restrictions. The only ones that I am aware of that are routinely enforced are http and mail servers running on end-user lines and mail server other than the ISP ones connected from those lines.

Anything else is fair game.

> f you were going to do this.... I would probably go with something more persistent in a protocol (more X windows than http). Flip the axis (0,0 top left) and ... well a lot of things from display postscript ... might be fun,

Display postscript is a very impressive language, it takes some getting used to though.

But it is a lot more flexible and orthogonal than HTML will every be.