Hacker News Reader

Comment by mbebenita | Hacker News Reader

In the case of Shumway, building everything on top of the web stack made it impossible to resume much of the previous work. It also turns out that if you want to build a Flash replacement, you have to reverse engineer 15 years of development on a poorly documented closed source system. If you're not bug for bug compatible you won't have a working Flash player, which is probably what stumbled a lot of projects in the past.

View on HN

Have JS APIs implemented by browsers developed enough so that Flash's feature set is now possible to mock? I know in the past it would've been a real challenge to imitate the Flash Microphone and Camera APIs, and Flash had a real advantage in other areas like Clipboard APIs.

I haven't worked with AS3 for the past few years so my memory of the APIs is fading, but overall, they were for the most part well-structured and programmer-friendly. A complete Shumway would be really neat.

For the most part, yes. Some things are hard to emulate, Weak References, E4X which is still wildly used, AS3 Namespaces, and all the graphics APIs. Flash just has a very different rendering model that doesn't easily map to Canvas.

The hardest part about Flash is understanding how timeline animations interact with AS code: events, object construction order, for all versions of Flash. Shumway supports all SWF versions and the the three programming languages that are supported by the Flash player: AS1, AS2 and AS3.

It's not just "advanced" things like camera access that browsers fail to replicate for the standard web platform. AFAIK no browser even correctly supports something as simple as non-"Normal" blending modes for SVG.

And I'm saying this as a fairly staunch flash hater.

A lot of these things we're supposed to be using to replace flash with HTML5 are simply not there reliably or sometimes even at all. SVG is a particularly glaring example of something which is woefully under-implemented.

Reply on news.ycombinator.com