1. 9
  1.  

  2. 2

    I only knew NeWS because of the pizza ordering story

    1. 5

      NeWS is incredibly relevant today because the web stack is trying really hard to reinvent it and (for once) actually learn from its mistakes. NeWS and Display PostScript had a lot of the same advantages and disadvantages. On the plus side:

      • You could write sandboxed code that ran on the display server, so even on a high-latency network you could respond to a button click by animating the button instantly (without a network round trip) and process the event in the background.
      • You had full access to a rich programming model for graphics, inherited directly from PostScript and so you could render anything that a high-end DTP package / printer could.
      • The lowest level of the toolkit had access to an incredibly rich text layout engine.
      • Your display and print output languages were the same (far less important today now that printing is relatively rare and even phones have enough RAM to ship a pre-rasterised image to a printer at 2400dpi).

      On the down side:

      • You had to write PostScript. By hand.

      NeXT’s frameworks on top of DPS basically gave up on a lot of this and lost out on the first positive point in exchange for losing the negative point. They didn’t care too much about remote display, so this wasn’t too much of a limitation. You could write Objective-C to construct NSBezierPath objects that were basically encapsulations of PostScript programs without flow control. There’s a name for PostScript without flow control: PDF[1]. This is why Apple’s Quartz is sometimes referred to as ‘Display PDF’, it keept the PostScript drawing model but removed all of the flow-control commands, leaving something that could be fairly trivially serialised as PDF.

      In the modern browser world, you can write JavaScript or wasm that is sandboxed and runs on the display server (browser) and can respond locally to events and perform asynchronous communication with the back end (via async HTTP requests or WebSockets) to hide latency. The drawing model for canvas tags is the drawing subset of PostScript but with the control flow exposed to JavaScript (you can bounce from wasm to JavaScript, but I expect that direct wasm bindings to canvas are near the top of the to-do list for the folks wanting to do rich web apps without JavaScript). No one needs to write PostScript directly.

      The current problem with the web stack here is that the text layout that you get via the DOM is not fully exposed into canvas. I’m expecting to see a future web browser where the only thing exposed to JavaScript is a top-level canvas and the whole DOM (from HTML parsing onwards) is implemented in JavaScript + canvas.

      [1] Only slightly facetious here: PDF is a document object model where the display objects are a subset of PostScript with the flow-control operations removed and only the rendering left in.

      1. 1

        NeWS is incredibly relevant today because the web stack is trying really hard to reinvent it and (for once) actually learn from its mistakes. NeWS and Display PostScript had a lot of the same advantages and disadvantages.

        If there is something to add it would be the distinction between ‘pages’ versus ‘frames’ – layouting, drawing and so on are very page oriented throughout the stack. The modern end of the stick ‘GPU command buffers as draw commands’ is animation oriented. In that sense the ‘draw commands to handles to composition’ model of SurfaceFlinger and onwards is reasonable, but with quite a few other issues.

        I’m expecting to see a future web browser where the only thing exposed to JavaScript is a top-level canvas and the whole DOM (from HTML parsing onwards) is implemented in JavaScript + canvas.

        I’m expecting one where the ‘HTML as document and not ELF for javascript’ is actually a separate translation stage that merges ‘visual/accessibility/layouting template’ preferences (CSS) with interaction model (WM or browser plugins) and spits out an intermediate representation designed to glue together animation oriented with page oriented in a mostly network friendly format. Ideally one that works recursively where the canvas of one process composes canvases from others without lossless transformations to pixels or worse.

        There are some lessons that JS in browser needs to learn from a post-mortem on FirefoxOS for the JS + Canvas path to not run into similar ‘the devil: synchronization’ motion to photon latency problems, in a similar vein as to how 50Hz/60Hz frame of mind breaks game development. This is one of the systemic issues for which the primitives are unreliable and even printers lacked a working approach to (recover from paper jam and so on).