Perhaps worse than the death of Flash was the death of Shockwave. I feel like so many Shockwave games I played back in the day are completely gone with no reference to them on the modern internet. Today, you can install some version of Flash on most operating systems, but I don't think there's any modern standalone Shockwave player and I could only get the plugin to work in Safari on macOS. Chrome and Firefox don't even run those types of plugins anymore.
There's one particular Shockwave game that I was recently able to recover from the depths of the Wayback Machine, which was a game from Disney for the Inspector Gadget movie; terrible film, but their website had this nifty little game that wasn't necessarily difficult but was addicting in that I wanted to see just how far I could go with it. For years I thought it was gone for good, and was glad to finally see it again after I lost it 15+ years ago.
I always liked it in part because I don't think I've seen a similar game. It's kind of like if you took the random shapes part of Tetris and added a "jigsaw puzzle" element.
When asking the difference between Shockwave and Flash, you'll often get the answer that they're two products that have nothing to do with each other. That is almost true, but not entirely true.
Director was originally meant for creating CD-ROM games. However, in the early 90's, it began finding a new home on the web. "Shockwave" was Macromedia's term which meant "compressed for the web." The first entry in the Shockwave line of products was Shockwave Director Player - so called because it could play Director Movies which had been compressed for the web. Because it was, at the time, the first and only product in the Shockwave line of products, Shockwave Director Player was often shortened to just "Shockwave."
Enter Flash. Again, Macromedia wanted Flash Movies to be able to be compressed so they could be downloaded quickly over the web - so they made the Shockwave Flash Player plugin, so called because it could play Flash Movies which had been compressed for the web. So there was Shockwave Director Player, to play compressed Director Movies, and Shockwave Flash Player, to play compressed Flash Movies.
The problem is, by this point, everyone already knew Shockwave Director Player as just "Shockwave." To those uninformed, it seemed that there was now both a Shockwave AND a Shockwave Flash. Shockwave Flash Player was more often referred to as just Flash, to avoid confusion with what was already being referred to as Shockwave.
So when we say Shockwave, we're referring to the first word in Shockwave Director Player, but when we say Flash, we're referring to the second word in Shockwave Flash Player...
Or at least, this was the case until Adobe acquired these names from Macromedia, at which point they just decided to rename the plugins to what they were being popularly referred to as. Now what was Shockwave Director Player is officially just called Shockwave, and what was Shockwave Flash Player is officially just called Flash. In order to further undo the confusion, SWF was changed to stand for Small Web Files instead of ShockWave Flash.
As for useless trivia, Director actually even predates it's main use of producing multimedia CD-ROMs. When it was still a MacroMind product, it was used for stuff like the "getting started" floppy disk for early Macs (the tutorial where you learned how to use a mouse by feeding fish and stuff)
Right, I suppose it's not fair to say it was originally meant for "creating CD-ROM games," that's an oversimplification. It's more like it was meant as a way to make applications without needing to learn a more advanced language like C++.
Wow, I think I was just over 13 years old when I got my hands on Macromedia Studio MX. I knew the difference between Shockwave and Flash, but I never knew why the authoring program for Flash was called Flash, and the one for "Shockwave" was called Director.
Shockwave and Flash are two distinct technologies to achieve essentially the same thing. At one point either Macromedia or Adobe conflated them by referring to Flash as "Shockwave Flash", but Shockwave was its own thing. Flash's scripting language was ActionScript and Shockwave had a language called Lingo.
In fact, I totally forgot about Lingo until just now. But it actually looks pretty cool:
https://get.adobe.com/shockwave/ is allegedly still a thing that exists and that you can install if you have Windows. It says it works on Windows 7 and 8, IE, and Firefox. My guess is that they haven't updated that, and it'll no longer work on Firefox since Quantum, but it's likely some flavor of IE will work with you there. And my guess is it'll work on Windows 10 with IE, since most things that work on 8 work fine on 10.
Actually, it's still being updated, but only on Windows. Director (the authoring tool used to create Shockwave Movies) was discontinued, but Shockwave was not.
Come and join the multitudes working in big corporate legacy application support, where the applications all have <100 users and are scheduled to be replaced imminently (and have been for the last 10 years).
Yes. Alternatively, you can use Pale Moon which is an actively maintained fork of Firefox that never got rid of NPAPI. Or, if you don't want to leave the comfort of your preferred browser, you can use the IETab extension.
Note that plugins do not work in Microsoft Edge. It has to be Internet Explorer. Edge didn't replace IE, you can still find IE by searching for Internet Explorer in the Windows 10 start menu.
Unfortunately, Java is a bit of an archival nightmare. Java Applets can do pretty much anything they want, they aren't consistent in that sense. Unlike Flash you can't just run them offline in a Projector, and the code structure of an applet is different from that of a normal Java app. This is on top of being unable to play Java games without getting a tonne of (well deserved) security warnings (unless you want to pay Oracle $100 per month for a signature.) Java in the browser was just a bad idea all around.
Because it gives the Java programmer too much power in an environment that should be safe. For example there are applets like AppEmbed that can run an EXE in the browser. That's just insane. Flash and Shockwave in contrast are limited in that sense, you are constrained to doing what you are able to accomplish with ActionScript or Lingo (or at least, that is intended to be the case.) Flash is insecure because it's buggy, Java is insecure because it's buggy AND because it's intended to work in ways you'd think are obviously insecure!
Applets, unless especially privileged by the user, run in a sandbox that prevent them from interacting with the local OS [1]. They certainly cannot run EXEs, again, unless the user consents.
In theory the Applet sandbox works really well. It's an extremely secure environment that's been deployed widely in the most demanding conditions -- think banks and governments. In practice the Applet security model encountered the following problems:
(1) Users are really, really dumb. They are happy to grant escalated privileges to the some 3D farming game they stumbled upon on the internet. Users will literally click on anything you tell them to. [2]
(2) Getting users to upgrade Java was terribly difficult. This meant when a real security flaw was discovered it might hang around for years and years and years. There was no mechanism to force users to upgrade Java or to actively disable Java installations proven insecure.
Maybe I'm confused because it's only relatively recently that I started again to take Java seriously, but isn't that precisely an example of a domain the Java security manager addresses? Again, I am well aware of the implementation bugs that have existed, and I don't know offhand if the security manager was part of Java's initial design or was added later, but I'm still confused as to why your ire's directed at the general concept of Java in the browser, rather than the specifically flawed implementations.
There's just no safe way to do what Java applets enabled (arbitrary code execution), because of the massive attack surface. It's one reason why NPAPI is dead.
Java applets never enabled arbitrary code execution. (Where do people even come up with this stuff?) Spend five minutes on Google and you can learn about the Applet sandbox which prevented Applets from doing most anything but draw to a section of the browser window and connect back to their origin server (not unlike Javascript).
Yeah, what do you think the applet is run on? The JVM. That's the attack surface. And securing that went so well that everybody uses Java applets everywhere and applets are allowed by default (hint: securing it is impossible and they're disabled by default because of it).
Unfortunately Javascript-infested websites are a bit of an archival nightmare. Javascript can do pretty much anything it wants, it isn't consistent in that sense. You can't run them offline.
Javascript in the browser is just a bad idea all around.
You can generally "Save As..." and they tend to work just fine. Like any code which has network access, they can be dependent on various resources. I sometimes run a downloaded file through an insecure chrome instance (--disable-web-security and a unique --user-data-dir) with a catch-all service-worker. That'd probably not work with applets as they make their requests outside the browser AFAIK.
Also the security sandbox of Javascript is one of the best, if not the best. So it cannot do anything it wants.
Not everything is a chat application. But even a chat application can and should partially work without an internet connection: Reading old messages and composing new ones can work offline.
That has nothing to do with Javascript. If you use canonical, cacheable URIs for your requests, my method above works fine.
In my day job, I'm working on a CRM and sales system that is 100% web based and does work offline and is even offline-first (I love you Germany, but your mobile network sucks).
There may be many other problems with it but offline is mostly a solved problem in the web world.
Quick experiment: In a new Firefox profile, I opened a couple of websites [1]. Then I went offline and tried to load them again. Every time I just got the default "server not found" page of Firefox.
"Offline" is no more solved "not hijacking scrolling", "linkable URLs" and "not re-inventing <a href> badly".
Did you try right clicking and choosing "Save as..."?
As I said before, it's a 5-minute thing to get started with service-workers. Web-sites can use that and then you don't even need to save. There is this great offline library, fellow developers! Use it! What other platform gives you such easy-to-use offline capabilities?
> As I said before, it's a 5-minute thing to get started with service-workers. Web-sites can use that and then you don't even need to save.
I don't care if websites can use that if they don't.
> You are dealing with a Turing-complete language here.
That's the fucking problem.
> What is the alternative you are supporting instead the current situation?
Using a proper application platform instead of a pile of hacks on top of the web. Without that pile of hacks, the web would actually be usable because publishers would not be able to break the UX.
There's one particular Shockwave game that I was recently able to recover from the depths of the Wayback Machine, which was a game from Disney for the Inspector Gadget movie; terrible film, but their website had this nifty little game that wasn't necessarily difficult but was addicting in that I wanted to see just how far I could go with it. For years I thought it was gone for good, and was glad to finally see it again after I lost it 15+ years ago.
Here it is in all its 1999 glory: https://web.archive.org/web/20031017000018/http://www.disney...
I always liked it in part because I don't think I've seen a similar game. It's kind of like if you took the random shapes part of Tetris and added a "jigsaw puzzle" element.