The point about web apps being the successor tech is excellent. We’ve mostly moved on from the world where I run xcalc on that machine over there and display the result on this machine here. Smart widgets would have been nice, but who cares today? Oh, hi there, in browser calculator that doesn’t talk to a server! What’s funny is we’ve recreated the same tech with the same problems. JavaScript is no more preemptible than postscript was. “A script on this page is still running. Stop it?” Wow, such solution.
While JavaScript isn’t, a partial “solution” to that is coming in the form of WebAssembly, which will support true threads. Granted, we’ll still largely be in OS/2 land, where the event loop is single-threaded blocking, but that also applies to lots of other popular and successful toolkits (including both Swing and Cocoa, if memory serves).
I’m working on JS engine performance right now and I’d be overjoyed to see WebAssembly take over the world. In some places JS and the surrounding APIs seem almost deliberately designed to make optimization hard.
I thought that SunOS/Solaris had support, and that OPEN LOOK ran on NeWS. It seems like Wikipedia agrees, so maybe my memory is right, but I can’t actually find anything else backing that up. (For all the jokes about “citation needed”, there don’t seem to be any backing up the assertion in that Wikipedia article.)
The point about web apps being the successor tech is excellent. We’ve mostly moved on from the world where I run xcalc on that machine over there and display the result on this machine here. Smart widgets would have been nice, but who cares today? Oh, hi there, in browser calculator that doesn’t talk to a server! What’s funny is we’ve recreated the same tech with the same problems. JavaScript is no more preemptible than postscript was. “A script on this page is still running. Stop it?” Wow, such solution.
While JavaScript isn’t, a partial “solution” to that is coming in the form of WebAssembly, which will support true threads. Granted, we’ll still largely be in OS/2 land, where the event loop is single-threaded blocking, but that also applies to lots of other popular and successful toolkits (including both Swing and Cocoa, if memory serves).
I’m working on JS engine performance right now and I’d be overjoyed to see WebAssembly take over the world. In some places JS and the surrounding APIs seem almost deliberately designed to make optimization hard.
Background worker threads certainly help, but still no protection against infinite loops in onclick handlers. :(
It’s an interesting article. I remember when the NeWS versus X11 debate was raging.
One thing I found myself wondering from reading the article - did any operating systems running NeWS actually achieve wide adoption?
I saw that SGI’s 4Sight used NeWS. I forget, was that the predominant window manager by the time IRIX came around?
I thought that SunOS/Solaris had support, and that OPEN LOOK ran on NeWS. It seems like Wikipedia agrees, so maybe my memory is right, but I can’t actually find anything else backing that up. (For all the jokes about “citation needed”, there don’t seem to be any backing up the assertion in that Wikipedia article.)
Indeed. I think this is a great example of how crappy our “institutional memory” is as a field.
How are we supposed to learn from past mistakes if we keep forgetting everything we learn every few years when the next shiny paradigm comes along?
No, it was 4Dwm, a pretty bog-standard Motif derivative.
Ah, Motif. Don’t miss it a bit - had more than one tussle with all the incompatible libraries and their clones back in the day.