Open-Source JavaScript Flash Player (HTML5/SVG)

gbutler69 writes "Someone has gone and done it. Tobias Schneider has created a Flash player written in JavaScript targeting SVG/HTML5-capable browsers. It's not a complete implementation yet, but it shows real promise. A few demos have been posted online. How long before HTML5/SVG next-generation browsers like Chrome, Firefox, Opera, Safari, Epiphany, and other Web-Kit based browsers completely supplant Flash and Silverlight/Moonlight?"

Sort of a good idea

[nine-times]

I'm not sure what to think. I love the idea of not needing to install Flash, but I also like being able to block annoying animations by not installing Flash.

I think overall, this isn't where things should head. It'd be much better if Flash were to simply work by exporting valid HTML5, CSS, and Javascript. Maybe there are some other advantages to the SWF format, but I'm not aware of them.

Not SVG

[SolitaryMan]

First of all, the main usage of Flash (for me) is video and I don't expect anyone to write h.232 codec using javascript and canvas anytime soon.

SVG has failed a long time ago. Correct me if I'm wrong, but there is no good way of putting it in the DOM unless you are using XHTML, which you shouldn't, and all other ways of getting it to the client are non-standard and handled differently by different browsers.

Re:Now if they could

[mandark1967]

I make it a point to verify, with each update of Flash, that my settings to automatically deny flash based cookies remain intact.

I hate the way you change configuration with Flash and would gladly do without it if something open-source could take its place.

I just hope the people working on this keep in mind that configurability and security are as important as performance.

Re:This is great!

[Zerth]

I dunno. The tiger demo(which appears to just display a picture of a tiger) maxes out 1 core in Chrome.

The animated stuff barely tickles it, though. Odd.

OMGWTFPDF

[shutdown -p now]

Great! Now, please, can someone write a PDF renderer in JS + HTML5 Canvas, so we can get rid of the browser killer plugin that is any PDF viewer out there?

Re:This is great!

[TheRaven64]

It's worth noting that Adobe and the browser makers optimise their VMs for different requirements. Flash tends to run very long-running things, like games which use a big chunk of CPU for several minutes at a time. JavaScript in a browser tends to do relatively simple things and uses a tiny bit of CPU. The main requirement for Flash is efficiency of generated code, while for JavaScript it's load time. The test suite that the WebKit team use runs in a couple of seconds on a decent computer, while a typical Flash game will often take at least 10 seconds to download all of the image and sound files that it needs. This gives the Flash VM a little while to spend compiling and executing the code.

There are, roughly speaking, four ways of implementing a programming language, although the boundaries between them are sometimes blurred. From slowest to fastest, these are:

1. Interpreting the AST (or even parse tree). Whenever you run a bit of code, you do a traversal of the tree and execute each node in turn. This is how JavaScript was implemented in browsers until a couple of years ago. It's very slow, because something like 'a = b' involves three AST nodes and so you need at least three function calls for a trivial assignment.
2. Compiling the AST to bytecode and interpreting the bytecode. Bytecodes are instruction sets for virtual stack machines where each opcode is one byte. You can implement them with a jump table, so the interpreter is fast (typically 50% native speed or more). A simple assignment would be a push value, push address and pop value at address bytecode instruction, which would expand to half a dozen or so native instructions. Significantly faster than interpreting an AST.
3. Just-in-time compiling to native code. Functions (or traces in something like Tamarin) are compiled to native code as they are needed, or after running them in an interpreter a few time and getting profiling information. This can produce the fastest code, because it can be tailored for that specific run of the program, but the cost of generating the code has to be added to the cost of running it every time that you run the program. Great for long-running programs, not so good for other things.
4. Statically compiling to native code. This produces good code. It doesn't have as much profiling information, but it also can spend longer optimising because the end user isn't waiting for the compiler to run, so it tends to be faster than JIT compilation in practice.

Tamarin, the VM in Flash, uses the JIT approach, while the WebKit JavaScript VM is a bytecode interpreter.

One of the hippyware projects that I maintain is a compilation infrastructure for dynamic languages, with an AST interpreter a JIT and a static compiler. On one of my test programs, running the JIT-compiled code took 0.023 seconds, but compiling it took over 2 seconds. In contrast, running it in the interpreter took about 0.9 seconds. Although the JIT-compiled code was significantly faster than the interpreted code, the total running time was faster. If you added a loop so that the test program ran twice, it was a bit faster in the JIT, and if you made it loop ten times it was significantly faster.

For most browsers, the JavaScript for a given page uses a fraction of a second of CPU time, so spending even one second generating optimised machine code from it is not productive. In contrast, Flash code can spend several CPU-minutes running, so if spending five seconds on optimisation makes it twice as fast then it's time well spent.

Re:This is great!

[NightLamp]

Can't we ditch JavaScript and _just_ use Flash - a nice blockable scripting engine that isn't integrated so deeply with HTML that disabling it breaks scores of sites with otherwise useful information?
If I want maximum battery life I block scripting, period. If I want fancy UI doo-dads and continuous browser-server communication I can enable Flash. What I don't want is great gobs of busted HTML when I don't want to run any kind of scripting engine. Just because you can doesn't mean you should, I'd like it if JavaScript became a "can't".

Re:How long? How about 'probably never'

[mounthood]

* All existing websites would need to be retrofitted to host .swf (.flv?) movies differently

No, just enough of the big sites like Youtube. If a Flash replacement isn't advanced enough to do this it won't get widely used, but most people don't care about the little sites.

* All popular browsers would need to embrace HTML5 video playback *Microsoft would have to emphasize this over their own product. * Adobe would have to emphasize this over their own product.

uh... do you think Flash would magically disappear if a competitor arrives?

* The marketing department being utilized for this tech (at this time that would be 'no one') would have to be better funded and more highly motivated than both the Microsoft and Adobe marketing departments

If Firefox included it by default, it would be in almost 1/4 of all browsers globally. Sites will pay attention to that.

* The vast majority of web users would have to care.

No, they just have to use a modern Free browser that includes a reasonable Flash replacement.

A Firefox embedded implementation would almost certainly allow users to switch to a different plug-in, like the canonical Adobe version. Change does happen; it's not impossible to replace Flash and there is no prerequisite for 100% compatibility.

Two use cases from Newgrounds

[tepples]

99.99% of what flash is now used for is video.

Does "video" in your comment refer to vector animations or just compressed pixels? And does it include video games? I see both vector animations and games on Newgrounds.

Re:This is great!

[amicusNYCL]

The main uses that come to mind are video, audio, and non-video animation. The company I work for makes online training courses which are all done in Flash, there's no suitable alternative to Flash in that context (unless you count Silverlight, which I don't).

Re:How long? How about 'probably never'

[Xtravar]

Assuming this project gets far enough (and I doubt it will), there could easily be a Firefox plugin that imports this Javascript whenever it sees typical embedded Flash. Also, pandering to iPhone users who don't have a Flash plugin would bring this project into the mainstream almost over night.

Re:This is great!

[ShadowRangerRIT]

IE8 came out in 2009, and from my understanding it massively improved JavaScript performance. Still not on par with the competition, but within an order of magnitude. FF 3.5 (with TraceMonkey) was released in 2009 as well, and had a similarly impressive boost to JS performance. Just because neither is quite at a Chrome level doesn't mean they aren't *much* faster than they used to be.

Re:This is great!

[tepples]

Not all videos are made of pixels gathered with a camera. JPEG is to MPEG as SVG is to what? Which vector animation codec works in both Firefox and Safari?