I'm a program manager on Mozilla's Shumway team. If you have any questions, please ask! :) The name "Shumway" is derived from "Gordon Shumway", the actual name of the TV character ALF: Flash -> Flash Gordon -> Gordon Shumway -> Shumway. :)
Shumway is written in TypeScript. It has an ActionScript interpreter and a JIT that generates JavaScript, compiled using eval(). The code is on GitHub:
Yes and no. Shumway is in a race to stay relevant as Flash fades from the web, but there will always be a long-tail of Flash content that would/will be lost when Adobe or browsers stop supporting the Flash plugin.
Even YouTube must continue to support Flash video for at least another year because many websites embedded Flash videos using YouTube's boilerplate embedding HTML with the Flash <object> tag. Google can't magically rewrite these third-party websites' HTML. :) Maybe YouTube can use some SWF that loads or redirects people to youtube.com? Or browsers could recognize YouTube's boilerplate embedding HTML and rewrite it with YouTube's HTML5 video.
This is indeed a major consideration: Flash will undoubtedly go away as a player, and if we don't want to lose all the legacy content with it as if it were stored on floppy disks, Shumway or something like it is the only solution.
Note that for a lot of content, it's not even required to use Shumway in the form of a browser extension or built-in system: it's perfectly possible to run SWFs with Shumway as a website-deployed player. E.g., the header on http://areweflashyet.com is deployed that way and works just fine in all modern browsers.
It's not gone from YT! It's certainly on its way out. But despite the announcement I still see Flash as default in Firefox and even in Chrome it sometimes falls back to Flash (happens to me when I start a video, put my laptop to sleep, and continue the video after resume).
It looks like the main change was enabling HTML5 for every video. I haven't had Flash enabled for a couple years – previously many videos (IIRC everything with ads) would display the missing plugin error page. Now it falls back to <video> but since they built it wrong, that only happens if Flash is completely unavailable — any sort of click-to-play will still result in using Flash.
Slight tangent: I've spent the past week experimenting with different kinds of bitmap caching achievable in the browser. Given that you understand both the browser and the way DisplayObjects implement bitmap caching in Flash, I was wondering if you got any clues on how to optimize DOM heavy pages? There are quite a few situations where momentarilly swapping out complex static DOM with a bitmap representation would decrease drawing calls. What I don't know is, to what extent are browsers smart about caching the renders, and when the overhead of caching by canvas would be smaller than default DOM rendering. However, I've had plenty of success in increasing performance, for instance, using canvas to resample images from original to DOM element size, so I'm optimistic about bitmap caching as well.
I'm on a friends tablet now, but I'm looking forward to digging through the implementation later. Keep up the good work!
I think letting the browser do this kind of caching for you is best in most cases. Developers have used tricks to force browsers to layerize content for many years, and browsers have become better at that over time. Nowadays, it should be fairly simple to isolate complex but unchanging content into its own layer that's cached and composited with the rest of the page instead of being rerendered for each page update.
In Shumway, we do almost all rendering in a Canvas element, so we haven't experimented all that much with DOM-heavy constructs.
As for your last question: I used to work with AS3 on a daily basis in a previous work-life, so I have extensive experience with it. Yes, there are some parts of the language that're very nice. I think that optional static typing is the best of all worlds, for example. The details of AS3's type system leave much to be desired, but the IDE support gained through static typing and the large set of bugs that're far easier to avoid are easily worth it.
Also, declarative classes are, in my opinion much easier to deal with than, e.g., the unstructured alternatives in JS. That's part of why we moved to TypeScript, and I'd argue that it vastly improved the quality of our codebase. I'm very much looking forward to classes in ES6.
Of course there are things that I don't miss about AS3 and regret having to deal with in Shumway. Namespaces are one, E4X the other. Both are good concepts in theory but hugely problematic in practice because of issues in the details.
That's not a portmanteau though is it? I thought a that was when you joined two words, eg hungry + angry = hangry. Maybe portmanteau has different variations that I'm unaware of - though I know I probably just sound like a pedant.
You're totally right, you're a pedant. JK, I was indeed confused, I don't know how to call a long chain of parallel associations like flash,fla -> flash gordon,alf -> gordon shumway -> shumway. Maybe it's a first.
It was probably a sequence of thoughts, but the flash gordon | alf relationship is parallel, they're unrelated above the convergence point that is shumway.
There was another open-source Flash Player clone called "Gordon" (i.e. Flash Gordon). The founder of Gordon, Tobias Schneider, joined Mozilla to work on Shumway, the successor to Gordon.
In part, the team just wanted to experiment with TypeScript. Also, the language is syntactically similar to AS3 so there is a close mapping from the AS3 library APIs to Shumway's TypeScript implementation.
Congratulations to the team on a promising start! There has been many attempts to implement free flash players, but none turned out to be usable in the real world. Maybe Mozilla has the perseverance to actually pull it off.
Search bugzilla & you should find open tickets. They shipped first for platforms with native support, understandably, but last time I checked the intention was to support everyone.
It's irritating that they're not just pushing all media through DirectShow, since that's the Windows native framework for doing it and it automatically supports whatever codecs are installed. Their excuse is that they don't have enough control over what codecs users install, which is a bit disappointing.
ffdshow has been able to play H.264 and a bunch of other codecs for a long time, and a not-insignificant number of users probably have that or some other codec that can...
Media codecs are a very common source of security holes, which is one of the main reasons for not indiscriminately using just any codec that might be installed on the system. I think most users value the decision to not unnecessarily expose them to these security holes.
Also, that wouldn't change anything about the current situation: we still can't rely on users having the right codecs installed. We're not saying that Linux and Windows XP won't be supported going forward. They most definitely will. As part of this first small step towards deployment, we opted for a conservative approach where we only enable Shumway in situations we have the maximum amount of control over. This will be broadened over time.
I understand that Prime Instant Video isn't supported (according to the announcement) because Amazon uses Silverlight for that. However, it is possible to switch to Flash as a sort of fallback (this is a required step for, say, streaming PIV to a Chromecast).
What would be required in order to get Shumway to actually play video from PIV (instead of Amazon simply demanding that the user installs Flash or Silverlight)?
The problem with PIV, as with a few other video services, is that it uses DRM. AS you're probably aware, there are some quite unfortunate laws around that which prevent anyone from just offering an alternative implementation of a DRM system. Hence, we can't even try. That's not to say that we won't ever be able to offer at least some support for services like this, there might well be ways to work out something clever.
Isn't EME supposed to address that? Or is that not adaptable to non-HTML5 video (even though this is, technically, HTML5+Javascript that happens to be able to play Flash animations)?
What's the easiest way to test shumway on arbitrary files? I'm running the latest nightly, but the amazon videos still use flash (tested by checking the right click menu). I've tried the extension in the past, but it never seemed to do anything.
Also, it would be nice if there was, say, a table of common flash APIs coloured by implementation status, for easy tracking of shumway completeness.
There are two easy ways to test Shumway on all SWF files: if you don't want to use Firefox Nightly, you can just install the extension from http://areweflashyet.com/ and should be all set. If you're using Firefox Nightly, you can simply visit about:config and change the shumway.swf.whitelist setting to "*". Note that you still need to have the Flash plugin installed for most sites to work, as I explained in another comment a few minutes ago.
Regarding the table of supported APIs: the problem with that is that we actually have most APIs implemented, but have compatibility bugs in some of them which break content. If we could easily list the broken APIs, then in most cases we could just as easily fix them. That said, there are some major API areas we don't yet support. Those are mostly related to newer and thus less-used capabilities, such as Flash's version of WebGL, called Stage3D, and a new text layout system called Text Layout Engine.
Eventually we hope to get to the point where we can play all SWF files and hence have Shumway be a complete drop-in replacement for the Flash plugin. Since implementing full support for all capabilities (and matching all quirks) of a two decades-old platform is a huge undertaking, we're not trying to get there in one big leap. Instead, we're gradually widening the set of supported content so we can get to something useful to end users sooner.
We're looking at tests and sometimes implementation details from the other open source projects, yes. E.g., we've used the SWFDec tests extensively in our work on the older AVM1 language runtime.
The Shumway interpreter and JIT work in other browsers, but the installable extension to replace the Flash plugin as the default SWF handler is currently Firefox-only. But pull requests are welcome! :)
You can try Shumway in other browsers without the extension at the project website:
Shumway is written in TypeScript. It has an ActionScript interpreter and a JIT that generates JavaScript, compiled using eval(). The code is on GitHub:
https://github.com/mozilla/shumway/