Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Open-Source JavaScript Flash Player (HTML5/SVG)

Soulskill posted more than 4 years ago | from the it's-called-gordon-get-it dept.

Graphics 300

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?"

Sorry! There are no comments related to the filter you selected.

eat my shorts slashdot !! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30820596)

Eat my shorts slashdot !!

This is great! (2, Funny)

the roAm (827323) | more than 4 years ago | (#30820616)

Wait, Javascript? Oh shit. I can feel the slow already.

Re:This is great! (4, Informative)

sopssa (1498795) | more than 4 years ago | (#30820632)

Welcome back to 2008. There was major improvement in javascript engines during 2009 in all other browsers than IE and Firefox. Chrome and Opera have incredibly fast javascript renderers and they're pushing it even more in next Opera version.

Re:This is great! (3, Interesting)

Zerth (26112) | more than 4 years ago | (#30820928)

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.

Re:This is great! (4, Informative)

the roAm (827323) | more than 4 years ago | (#30821208)

It's not odd, it's SVG. Rendering SVGs, especially ones with lots of lines and not a lot of solid shapes is quite CPU intensive.

Re:This is great! (5, Informative)

TheRaven64 (641858) | more than 4 years ago | (#30820678)

Why? Most of what a Flash applet does is run ActionScript, which is a dialect of JavaScript. The drawing in this will be done by the browser, rather than by a plugin, and the code will be run by the browser's JavaScript engine instead of the plugin's one. If anything, you'll see less memory usage because you'll only need one JavaScript VM instead of two.

Re:This is great! (2, Insightful)

the roAm (827323) | more than 4 years ago | (#30820768)

That's mostly true, but I'm somehow doubting JavaScript, as implemented in most rendering engines, will be able to do any of the higher-level Flash stuff with any semblance of grace or speed.

Re:This is great! (0)

Anonymous Coward | more than 4 years ago | (#30820858)

The actual rendering appears to be SVG in this case.

Re:This is great! (1, Funny)

the roAm (827323) | more than 4 years ago | (#30820962)

Oh wow, Captain Obvious! Can I have your autograph? I'm a big fan.

Re:This is great! (2, Insightful)

slim (1652) | more than 4 years ago | (#30821058)

I thought it was useful. I had assumed it was Canvas.

Re:This is great! (1, Funny)

Anonymous Coward | more than 4 years ago | (#30820946)

I have doubts Adobe's runtime can do any of the higher level Flash stuff with any semblance of grace or speed.

Yet it seems to do it well enough for most people.

Re:This is great! (0)

Anonymous Coward | more than 4 years ago | (#30820992)

Most people that run Windows or OS X. Adobe Flash's "Grace and speed" on Linux? Very funny. Flash windows update in squares and flicker.

Re:This is great! (2, Informative)

Transfinite (1684592) | more than 4 years ago | (#30821282)

Not true at all. Javascript engines are getting faster, a lot of effort, time and money is being put into making that so. Googles V8 engine for example. Also paired with the fact that HTML5 introduces a notion of concurrency into Javascript this is then even less of an issue. ~Unfortunately most people still think circa 1998 when talking about Javascript. Wrong. Javascript is key to the future of the web and not heavy inefficient server side solutions. Have a look at say node.js and see if you still think about Javascript circa 1998

Re:This is great! (4, Insightful)

Jurily (900488) | more than 4 years ago | (#30820798)

Couldn't we just ditch Flash and use something less retarded?

Re:This is great! (1)

amicusNYCL (1538833) | more than 4 years ago | (#30821246)

What do you suggest as a replacement for the functionality provided by Flash?

Re:This is great! (1)

drachenstern (160456) | more than 4 years ago | (#30821340)

ECMAScript and open graphics standards?

Or is that what Flash was originally slated to be?

Re:This is great! (2, Insightful)

Ltap (1572175) | more than 4 years ago | (#30821326)

The answer to your question relies on a proper definition of "we". "We", to you, means everyone who uses the Internet. However, "we", in reality, are a small minority of people who know what they are doing and what they are talking about.

It is similar to ipv6 - change can only happen at the level of big companies (or, in this case, video hosting sites like Youtube) who don't want to change for various reasons. HTML5 took forever to get here because it was designed to be easy to transfer to, but people have still ignored it the same way they have ignored web standards since their first conception. The only way to make people change is to make the HTML5 implementation easier than Flash implementation, which is difficult since so many people learn and are comfortable with Flash. Once HTML5 begins to have a little more impact and people (hopefully) learn it, we can all just move on, since nothing, as well all know, is easier than HTML.

Re:This is great! (1)

ubrgeek (679399) | more than 4 years ago | (#30821332)

Sure, in theory. But clients often see something they think is sexy on the Warner Bro.'s site for some new movie or a really cool sports game on ESPN and they want something similar. Then trying to get them to understand that their desire for something similar on their site requires using something despised by a large number of people (i.e. Flash). Then you're in a tight spot. Most times, my clients want the neat shinies they see, despite the fact that it actually goes against the first requirement they give me: We need to get X information out to the widest audience. That requirement at times becomes unreachable when the second bullet says, "And it needs to [do something that JQuery or whatever can't do.]

So yes, we can ditch it. As soon as the clients stop asking for it.

Re:This is great! (2, Insightful)

IGnatius T Foobar (4328) | more than 4 years ago | (#30821336)

Couldn't we just ditch Flash and use something less retarded?

Bite your tongue. If anything replaces Flash it will be Silverlight. Do you really want Microsoft controlling the non-HTML portion of the Web? Do you really want Microsoft turning the Web into a Windows-only experience? Because that's what's going to happen if Flash is supplanted. Be careful wht you wish for.

Re:This is great! (0)

Anonymous Coward | more than 4 years ago | (#30821456)

No, most of what a Flash applet does -- for values of "Flash applet" equal to what most people in the real world use Flash for -- is decode H.264/MP4 video. I mean, yeah, there are a few people that use it for crappy menus. And there are some clueless photographers who use it to let people with miniscule screens browse miniscule "full size" versions of their work. But really, in the real world, where real people are using the real Flash? YouTube.

Or, actually, RedTube or YouPorn or PornTube or whatever they call themselves now.

Re:This is great! (2, Insightful)

datapharmer (1099455) | more than 4 years ago | (#30820690)

Clearly you aren't on a mac. I can tell a website is running flash with my eyes closed on my mac because the fans turn on. Other than rendering large amounts of video, flash is the ONLY thing that causes my fans to come on with any sort of regularity. This is not a browser specific issue, it is a adobe wrote and anwful flash implementation for mac. I am all for a javascript replacement for flash if it gets rid of the adobe crapware. Adobe flash for mac might actually be worse than real media player was on pc in the 90s.

Re:This is great! (1)

maxume (22995) | more than 4 years ago | (#30821096)

The bigger problem is that the people developing flash content implement their own event loops without putting any sort of sleep statement in them, meaning that they check whether they should be doing something thousands of times between actually doing anything.

(I suppose this is sort of a flaw with flash, but it isn't real terrible that it allows the use of lots of resources)

Re:This is great! (2, Insightful)

ByOhTek (1181381) | more than 4 years ago | (#30821204)

Don't feel particularly special. Adobe flash is horrid on ANY platform it is made for. Not just Mac.

Re:This is great! (1, Informative)

Anonymous Coward | more than 4 years ago | (#30820762)

What makes it slow isn't the language it's the engine. JavaScript and Actionscript are both based off of ECMAScript. The difference is that Adobe/Macromedia has put a crap load of effort into optimizing their scripting engine.

The latest competitive point among today's browsers happens to be on the JavaScript side. Opera, Chrome, Safari, Firefox are all working hard to optimize their JS engines for top performance to do things exactly like this. Not sure where IE is in all this. Maybe with IE9 they'll work a little harder.

Re:This is great! (1)

ByOhTek (1181381) | more than 4 years ago | (#30821224)

IE is improving, and improving at a high rate.

Problem is, when you are light years behind the competition, a high rate of improvement still requires a long time for catch-up (if it ever happens, given that the competition are all moving targets themselves).

Re:This is great! (1)

Ltap (1572175) | more than 4 years ago | (#30821346)

To work harder, you have to already be working.

Re:This is great! (5, Interesting)

TheRaven64 (641858) | more than 4 years ago | (#30821434)

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! (0)

Anonymous Coward | more than 4 years ago | (#30820848)

Wait, Javascript? Oh shit. I can feel the slow already.

JavaScript isn't Java!

Re:This is great! (1)

the roAm (827323) | more than 4 years ago | (#30820926)

I never said it was. Java isn't even allowed on my systems. Mark my words, something using pretty much all of the higher-end features of HTML5 and SVG, as implemented through JavaScript, will be quite slow with any complex SWF. Also, Dromaeo -- go there and tell me that doing complex things with JavaScript isn't slow.

Re:This is great! (1)

khellendros1984 (792761) | more than 4 years ago | (#30821060)

I don't see why it would be slow, necessarily. A browser's javascript engine replaces the flash's actionscript, and browser rendering using svg vector graphics replaces the flash vector graphics. It's not a big change. "will be quite slow with any complex SWF" describes Flash pretty well.

Re:This is great! (1)

bluefoxlucid (723572) | more than 4 years ago | (#30821258)

As long as it runs workit.swf

Re:This is great! (0)

Anonymous Coward | more than 4 years ago | (#30821520)

Anyone, everyone, please show me ANY SVG vector content that runs faster in a browser than in Flash.

Re:This is great! (1)

Ltap (1572175) | more than 4 years ago | (#30821362)

How does Java factor in to this?

Re:This is great! (1, Insightful)

Nadaka (224565) | more than 4 years ago | (#30820940)

and java isn't slow. It currently runs about 2-3 times slower than c++ for nearly all applications, 2-3 times faster than .net CLR and about 10-20 times faster than scripting languages. In some case, though admittedly rare, java exceeds the performance of c++.

Re:This is great! (1, Insightful)

JesseMcDonald (536341) | more than 4 years ago | (#30821148)

For long-running, non-interactive applications, sure. As you say, in terms of raw performance Java is only 2-3 times slower than C++, which still makes it faster than CLR or most scripting languages. However, in the areas of start-up time and GUI performance Java's reputation for poor performance is well-deserved. This may not impact its usefulness for servers, but it makes all the difference in the world when it comes to desktop applications.

I don't think it will change much (1)

Monkeedude1212 (1560403) | more than 4 years ago | (#30821230)

I mean its great and all, it means that this new "flash" player will probably end up working across all the browsers eventually, and without the security vulnerabilities and downsides to the flash plugin.

But I think in the end - Flash is still going to be used to create the content. Adobe will put more effort into optimizing it, and then a lot of "regular" people will just end up prefering the flash plugin.

I mean Gordon is a server side installation, which means I personally can't start using it everywhere I go, the webmasters must do that. I don't see many of the sites I frequent that use flash (mostly for flash games) really implementing this unless it improves the quality of the game. It sounds like because its in its initial stages this SVG/HTML5 player doesn't quite stack up to Flash's current optimization. And if it does at one point, I see Adobe just optimizing flash even more, to keep it on top.

Obamacare croaked with Coakley! (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30820628)

A Dem can't even win in Massachusetts because Obamacare is so toxic.

speed (1)

gbjbaanb (229885) | more than 4 years ago | (#30820638)

So I guess the only thing holding it back is its performance (one assumes there are going to be fewer security and download/update issues :)

The blue demo seemed acceptable to me, but I wonder if it'd suffer as more stuff was added?

Still - top marks for that man, take the afternoon off.

Re:speed (1)

Jeffrey Baker (6191) | more than 4 years ago | (#30820750)

I would say that the main thing holding it back is the total lack of a high-performance way to address bytes in JavaScript. The state-of-the-art for decoding binary protocols in JS is to use charAt and charCode to grab a character at a certain offset in a string, which throws off a phenomenal amount of garbage to be collected and is tremendously slow as well.

The language needs better ways of manipulating bits and bytes.

Re:speed (2, Funny)

slim (1652) | more than 4 years ago | (#30820824)

The language needs better ways of manipulating bits and bytes.

A hidden canvas element?

(I feel dirty now)

Re:speed (1)

TheRaven64 (641858) | more than 4 years ago | (#30821502)

Why do they generate garbage? This was a solved problem in Smalltalk-76 (and Smalltalk copied it from Lisp), and I use the same solution in my Smalltalk compiler. Small integers are treated as immutable objects and are squeezed into a pointer (low bit set to 1, since all objects must be word-aligned and so always have their low bit set to 0), so you can store 31- or 63-bit integers without needing to allocate an object (or involve the GC). A trace VM can easily inline the charAt() method, so apart from the bounds checking (which static analysis can discard in a lot of cases), it can be very fast.

Re:speed (1)

n3umh (876572) | more than 4 years ago | (#30820892)

Blue starry one excellent in Chrome (, somewhat choppy in Firefox (3.5.7), consistent with sopssa's comments above... What are you using?

Re:speed (1)

Neil Hodges (960909) | more than 4 years ago | (#30821182)

For some reason, all of them cause the "Aw, snap" message in Chrome ( whenever I hover the mouse over them and move it around a little.

Re:speed (1)

gbjbaanb (229885) | more than 4 years ago | (#30821306)

I'm using FF 3.5, so its not so bad - I might try chrome in a few days (after the slashdotting) to see what its like there.

The answer about byte manipulation was an interesting one, as a C/C++ dev I take such things for granted, but "generating a lot of garbage" means there's a lot of string copying going on under the covers which I know is a tremendous hit on system resources. I'm hopeful that it'll be improved though - Google has too much at stake :)

Flash: No thanks (0)

Anonymous Coward | more than 4 years ago | (#30820644)

Better SVG authoring tools, yes please.

Now if they could (3, Funny)

mandark1967 (630856) | more than 4 years ago | (#30820652)

just duplicate the security vulnerabilities that Adobe provides us, we can finally put Adobe out of business!

Re:Now if they could (1)

Infiniti2000 (1720222) | more than 4 years ago | (#30820732)

Holy crap, it's written in Javascript, what more do you want?

Re:Now if they could (1)

SolitaryMan (538416) | more than 4 years ago | (#30820802)

Not as funny as it sounds: flash based cookies, which are not that easy to block and/or delete for the user, are used by all advertisers and other bastards, spying on you

Re:Now if they could (2, Interesting)

mandark1967 (630856) | more than 4 years ago | (#30820884)

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:Now if they could (5, Informative)

clang_jangle (975789) | more than 4 years ago | (#30821328)

flash based cookies, which are not that easy to block and/or delete for the user, are used by all advertisers and other bastards, spying on you

Trivial to defeat, at least in *.nix. Just remove all write permissions to the ~/.adobe and ~/.macromedia directories, after deleting all the cookies within. Buh-bye, flash cookies. Also makes flash work noticeably faster.

Re:Now if they could (1)

Ltap (1572175) | more than 4 years ago | (#30821400)

BetterPrivacy is your friend. It's actually interesting to open and close your browser once you use, say, a new site, and notice how many cookies some force-feed to you.

Re:Now if they could (0)

Anonymous Coward | more than 4 years ago | (#30821496)

I allow cookies for flash. I play a few flash games that use those to save states.

Not to worry; I use Noscript to block flash everywhere else.

Re:Now if they could (1)

yabos (719499) | more than 4 years ago | (#30821378)

The ironic part is most of the Acrobat reader vulnerabilities are accessible due to javascript. Disable javascript support in the reader and you are pretty safe from most of the exploits. I don't know if that holds true for the flash player though.

Checked out the demos on my iphone (4, Informative)

Anonymusing (1450747) | more than 4 years ago | (#30820708)

I checked out the posted demos [] on my iPhone. Although they were a tad sluggish (particularly the star fade-in on the first demo), frankly, it wasn't bad. Some of the sluggishness could have just been because the demos are getting Slashdotted.

Personally, I'm a little more interested in PhoneGap [] , which lets you use JavaScript to create iPhone apps (outside the browser).

Re:Checked out the demos on my iphone (0)

Anonymous Coward | more than 4 years ago | (#30820906)

Some are very sluggish on the iPhone. I can't see this being used for anything complex (let alone video). Also the 'buttons' did not work with my touch screen. This was using the iPhone 3G, perhaps the 3Gs would do better....

Re:Checked out the demos on my iphone (1)

khellendros1984 (792761) | more than 4 years ago | (#30821138)

The way flash works, and the way this would work for video, is to specify a few formats that are acceptable, and to implement those in the browser. It's binary code. The only real overhead to playing video in flash are the controls that get added. Otherwise, it's just a binary video decoder throwing up pixels into a buffer. It's not like they'd implement the video decoding in Javascript too....

Re:Checked out the demos on my iphone (2, Informative)

Sir_Lewk (967686) | more than 4 years ago | (#30821086)

Javascript runs on your hardware, not on whatever server it was hosted on. A site getting slashdotted will make a page more sluggish to load, but not run.

Re:Checked out the demos on my iphone (1)

Anonymusing (1450747) | more than 4 years ago | (#30821236)

I know this.

While JavaScript runs on the local box, Flash typically begins running as it downloads, so an animation may stutter if it is struggling with the download. I was assuming that this remained true with this JS interpreter, and surmised that some of the sluggishness could have been due to the SWF file downloading slowly; however, I could be wrong. The code might need to download the whole file before interpeting it.

Sort of a good idea (2, Interesting)

nine-times (778537) | more than 4 years ago | (#30820724)

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.

Re:Sort of a good idea (1)

goose-incarnated (1145029) | more than 4 years ago | (#30820860)

Presumably it would be trivial to block something well-specced (like video specific stuff in HTML5). Blocking flash blocks *all* flash, blocking video in HTML5 should be easier (no doubt an expert can chime in here and tell us both how easy it would be to ignore video in HTML5)

Not SVG (2, Interesting)

SolitaryMan (538416) | more than 4 years ago | (#30820730)

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:Not SVG (4, Insightful)

Jeffrey Baker (6191) | more than 4 years ago | (#30820792)

Why shouldn't you use XHTML? By the way, SVG made its way into HTML5 and it's much more useful than canvas so I think the reports of SVG's death are greatly exaggerated.

Re:Not SVG (0)

Anonymous Coward | more than 4 years ago | (#30820920)

He's just using the same old "tag soup" "[insert technology here] is dangerous" arguments people have been using for years now. It's bunk. There are plenty of companies using XHTML at the enterprise level safely and effectively regardless of the perceived limitations.

Re:Not SVG (1, Troll)

maxume (22995) | more than 4 years ago | (#30821214)

Because IE doesn't handle


, and you aren't using xhtml if you aren't using that Mime type.

Re:Not SVG (1)

Jeffrey Baker (6191) | more than 4 years ago | (#30821250)

Tons of shit doesn't work in IE.

Re:Not SVG (1)

maxume (22995) | more than 4 years ago | (#30821280)

Sure. For anyone with any sort of audience that uses IE, the features that you gain with xhtml instead of plain ol' html (probably) don't offset the pain in the ass that you incur.

Re:Not SVG (1)

Ltap (1572175) | more than 4 years ago | (#30821458)

I love the GGP's point that SVG is a failure because you need XHTML to use it. Why shouldn't you use XHTML? IE. I think we need to reach the point that whether or not something displays in IE should no longer be a concern to us, it's holding back web development and hurts everyone.

Re:Not SVG (1)

maxume (22995) | more than 4 years ago | (#30821522)

That's the biggest immediate reason not to use xhtml.

There are other ongoing reasons, like the movement of much of the web development community to html5.

Re:Not SVG (2, Informative)

amicusNYCL (1538833) | more than 4 years ago | (#30821322)

Why shouldn't you use XHTML?

1) There's no practical advantage to using XHTML over HTML.

2) There's no XHTML2. The future is HTML5.

Re:Not SVG (1)

gehrehmee (16338) | more than 4 years ago | (#30820916)

As someone rather new to flash, I'm not so sure how flash video works.

My assumption has always been that flash has support for h263 and other codecs coded into the plugin itself, so no one is writing flash actionscript to actually handle the codecs. If that's the case, the javascript flash implementation could likewise just pass the video decoding/rendering off to code in the browser designed to do that... unless I'm way off base, and people are actually writing actionscript for the video handling code, which I'd consider terribly distasteful.

Re:Not SVG (1)

King InuYasha (1159129) | more than 4 years ago | (#30821106)

You are normally right. However, it is possible to write codecs in ActionScript, but they are horribly slow. Flash includes a VP6, H.263, and H.264 codecs for video as well as a PCM and MP3 codec for audio within the plugin itself...

Re:Not SVG (0)

Anonymous Coward | more than 4 years ago | (#30821080)

The only reason here to not use XHTML would be that Internet Explorer doesn't support the relevant XHTML-functionality. The One big reason there's so little SVG-usage is IE's complete lack of support. Okey, now you can go ahead and focus on "different" browsers doing things "differently" and announcing SVG's failure.

It won't be a quick transition. (1)

Interoperable (1651953) | more than 4 years ago | (#30820834)

How long before HTML5/SVG next-generation browsers [...] completely supplant Flash and Silverlight/Moonlight?"

I can't offer any informed opinion on that, but I can say that Flash and Silverlight/Moonlight will go down kicking and screaming. Much like the IE6 optimized websites that will continue to use them for many years to come.

Re:It won't be a quick transition. (1)

gencha (1020671) | more than 4 years ago | (#30821064)

Oh come on. A guy implements a subset of SWF1.0 in JavaScript that only requires everyone to change how they embed .swf files in their site. This is huge. The web revolution is right around the corner I tell you.

Re:It won't be a quick transition. (1)

Ltap (1572175) | more than 4 years ago | (#30821478)

Did anything ever use Silverlight in the first place? I only recall stuff using Flash and that's it.

less than 100% is good (2, Informative)

f3r (1653221) | more than 4 years ago | (#30820912)

anything using less than 100% cpu in linux is better than Flash. Therefore there can in principle be nothing worse than Flash. Unbeatable, indeed a hard goal to achieve.

Must be an iPhone user (1)

omnichad (1198475) | more than 4 years ago | (#30820970)

For anybody else, this would just be a crazy waste of time. Wish Apple would just allow Flash on the iPod/iPhone

Re:Must be an iPhone user (1)

jellomizer (103300) | more than 4 years ago | (#30821500)

I agree. Apple is just making life difficult for its users. Espectially because the iPhone doesn't multi-task that means if you wanted just use 100% cpu sure it will drain your battery faster but it is not like you are slowing down other apps.

Variable names (1)

gencha (1020671) | more than 4 years ago | (#30820974)

What is it with these single letter variable names in the code? I thought we were past that.

Re:Variable names (1)

Rockoon (1252108) | more than 4 years ago | (#30821370)

Sometimes the specific single letter has standardized usage, such as i and j, x and y, and so forth.

Then there are cases where the best name for a variable is something like 'value', 'string', 'data', 'array', or 'pointer' where using those instead of a single character doesnt help anybody.

Library programmers are more familiar with using single letters, because many variables are often entirely abstract and simply dont have a concrete meaning. What should you call the input to a sort function? 'arrayToBeSorted', or simply 'a'?

I have not looked at the code in question, so maybe he/they are using single letter names obsessively or something.. but I know that when I'm programming, often times a single letter is just as descriptive as anything else.

OMGWTFPDF (5, Interesting)

shutdown -p now (807394) | more than 4 years ago | (#30820982)

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:OMGWTFPDF (4, Insightful)

Anonymous Coward | more than 4 years ago | (#30821186)

Even better, maybe someone could write a Flash PDF viewer, and then we could view our PDFs using this flash interpreter.

(Ohboy. The layers of cruft involved in that concept have just given me a cold shiver up my spine)

Re:OMGWTFPDF (4, Insightful)

ReinoutS (1919) | more than 4 years ago | (#30821192)

The real WTF is that you are trying to view a PDF in your browser in the first place. Try opening it with a real pdf viewer [] instead.


Jeffrey Baker (6191) | more than 4 years ago | (#30821348)

Exactly! I have a major "WTF?" moment every time I see people opening PDFs in their web browser. Drives me nuts. And Mac people are all up in arms because Chrome on Mac doesn't (or didn't -- it may be implemented now) open PDFs in a plug-in. To me, that's a feature, not a bug.


Paradigm_Complex (968558) | more than 4 years ago | (#30821206)

Why view the PDF in your browser? Download and open in a PDF viewer of your choice. Doing it this way won't kill your browser, honest!


thePowerOfGrayskull (905905) | more than 4 years ago | (#30821472)

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?

Hopefully you've disabled embedded PDF viewing a long time ago, given the potential security issues..


MrNemesis (587188) | more than 4 years ago | (#30821474)

I've never understood the logic of viewing PDF's inside the browser via plugin; I can understand it for flash or java, where they provide certain functionalities and integrate within the web page, but don't see why you'd want to use a PDF in-browser, which doesn't integrate with the rest of the site. Even worse is when the notoriously corpulent Acrobat plugin starts to load, your browser tends to either freeze (thanks IE6) or act like it's just snorted a gram of ketamine.

I intentionally disable PDF plugins everywhere; my own personal preference on windows is $browser_of_choice and SumatraPDF. It makes even Foxit look bloated (no vulns that I know of either whilst even foxit has had some), and has bitchin' fast rendering and startup. For people that mostly only read PDF documents it's an utter godsend.

Get real (1, Insightful)

Anonymous Coward | more than 4 years ago | (#30821022)

Er, um, do you recall the last time someone announced a ______ player written in some interpreted language?

It's always a thin shell of interpreted glop around some real codec.

You see JavaScript is about 10,000 times too slow to do the nitty-gritty video decoding.
So they always use a real existing codec to do the heavy lifting.

Since most of the security issues are in the codec parts, this is rarely a big improvement.

Hmm, if it is any better than Flash... (1)

Rokewaju (253296) | more than 4 years ago | (#30821038)

Thus far I am liking the sounds of this idea. If it can improve on the CPU side of things (Flash on Linux is such a royal pain in the old rear end), then I won't dread trying to watch a YouTube or other online video that insists on using a Flash player. However I will take a wait and see approach to see if this concept gets developed into something usable for PC users since this concept is being developed for the iPhone to get around Apple's "App Wall".

Re:Hmm, if it is any better than Flash... (1)

the roAm (827323) | more than 4 years ago | (#30821090)

Yes, because SVG rendering is SUPER FAST and EFFICIENT. Oh, wait.

Too much fuss (1)

vagabond_gr (762469) | more than 4 years ago | (#30821122)

The work that this guy did is amazing, no doubt. But the player supports SWF v1. The current version is 10!

Gnash already supports v7 and some features of v8/9 and is still not very usable.

Doing simple animations is one thing. Do you really expect to have a decent AS3 interpreter running in javascript? No question about video of course.

On the other hand this player could have some niche applications. If someone knows flash, needs some simple animations without violating standards and without messing with JS/SVG directly, they could use this. But as a general-purpose flash player? I don't think so.

I can't wait for the Firefox addon (1)

dunkelfalke (91624) | more than 4 years ago | (#30821130)

So I can finally switch to 64 bit firefox. And yes, I know that there is a Linux plugin available, but I don't use Linux at home.

Re:I can't wait for the Firefox addon (1)

SargentDU (1161355) | more than 4 years ago | (#30821178)

"but I don't use Linux at home." But you should! :)

Before you get all excited... (5, Informative)

Qubit (100461) | more than 4 years ago | (#30821220)

...according to the article his code only supports the SWF 1.0 format, and he's currently working on adding support for the SWF 2.0 file format.

Adobe Flash 1 and Flash 2 (which I'm going to guess might roughly line up with SWF 1.0 and 2.0), were released in 1996 and 1997, respectively. As in, over a decade ago.

Much larger, more long-term projects like Gnash [] have been working on completing a compliant Flash client for several years and still don't have support through Flash 8, 9, and 10. It's apparently a lot of work to support all of the different pieces of Flash, especially as it turns out that the SWF spec has been completely overhauled several times over the past decade, resulting in wide differences between things like ActionScript 1, 2, and 3.

So while I wish this effort all the best, it would require a lot of time/energy/talent to make this client have the coverage necessary for, say, internet video sites to work.

flash should only be used for Audio & Video (1)

nan0 (620897) | more than 4 years ago | (#30821248)

These days html/css/js can replicate most of the animation & navigation & effects that people use flash for, and in a more SEO friendly manner.

IMO the only convincing argument to use flash is for audio & video.

as this library doesn't cover multimedia...

it doesn't cover flash's only responsible use case... So it's clever - but useless.

not a criticism... keep it up!!!

How long? How about 'probably never' (4, Insightful)

Quarters (18322) | more than 4 years ago | (#30821266)

Ah yes, another stab at (this is a killer!). Those predictions never pan out. Specifically for this: * All existing websites would need to be retrofitted to host .swf (.flv?) movies differently * 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. * 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 * The vast majority of web users would have to care. So, yeah, no.

Doesn't support AS3 (3, Informative)

Steve S (35346) | more than 4 years ago | (#30821270)

According to the list of supported swf tags ( ), it does not support DoABC, which means that it does not support Actionscript3. So basically, it only supports the parts of flash that really annoy people: Animations. This won't let you play many neat flash games, or replace Flex, or play a movie designed for Flash9 (introduced in 2006) or later.

As an Actionscript hobbyist, I love the idea of an open source implementation of the player. But so far, none of the open source alternatives support the features I actually like: Actionscript3. It's a strongly typed language with real classes, and it's compiled to bytecode rather than interpreted (mostly). Javascript has come a long way, but it still sucks if you like strongly typed variables.

Keep trying, Tobias. And if you get that byte-level access, let the world know.

Ummm ... (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#30821338)

Anyone who leaves IE off of the list of next-gen browsers is a f***ing idiot. Why would I read a f***ing idiots article?

Re:Ummm ... (2, Insightful)

Transfinite (1684592) | more than 4 years ago | (#30821490)

Umm because IE is shit, lagging about 3 years behind the rest. They STILL have not managed to produce a *fully* standards compliant browser.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?