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

Comments

This is great!

[the roAm]

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

Re:This is great!

[sopssa]

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!

[TheRaven64]

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!

[datapharmer]

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!

[Anonymous Coward]

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!

[the roAm]

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!

[Jurily]

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

Re:This is great!

[Anonymous Coward]

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

JavaScript isn't Java!

Re:This is great!

[Anonymous Coward]

The actual rendering appears to be SVG in this case.

Re:This is great!

[the roAm]

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!

[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.

Re:This is great!

[Nadaka]

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!

[Anonymous Coward]

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!

[the roAm]

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

Re:This is great!

[Anonymous Coward]

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!

[slim]

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

Re:This is great!

[khellendros1984]

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!

[maxume]

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!

[JesseMcDonald]

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.

Re:This is great!

[ByOhTek]

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

Re:This is great!

[the roAm]

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!

[ByOhTek]

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!

[amicusNYCL]

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

Re:This is great!

[bluefoxlucid]

As long as it runs workit.swf

Re:This is great!

[Transfinite]

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!

[Ltap]

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!

[ubrgeek]

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!

[IGnatius T Foobar]

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!

[drachenstern]

ECMAScript and open graphics standards?

Or is that what Flash was originally slated to be?

Re:This is great!

[Ltap]

To work harder, you have to already be working.

Re:This is great!

[Ltap]

How does Java factor in to this?

Re:This is great!

[Transfinite]

that's why we invented WebWorkers: http://www.whatwg.org/specs/web-workers/current-work/

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!

[Anonymous Coward]

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!

[Anonymous Coward]

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

Re:This is great!

[Anonymous Coward]

I would love to do away with the flash player also, because my non-mac laptop fans do the same in Windows and Linux when lots of tabs are loading ads and a flash video.

HOWEVER, flash is a file format, not just a player. When you right-click on a flash video on pr0n sites and youtube, you'll see a menu with a little blurb showing either Adobe's ID string and configs, or some other video player's name. The browser's flash plugin just loads a site's custom wrapper. That object tends to have some sublicensed FLV loader or a standard Adobe one, which downloads the actual FLV file (that's what gets 'saved' to your hard drive for offline viewing apps that you can find out there). No matter what, Adobe's flash language can't be removed from the equation, even if you can remove the player.

The problem with the format is that you have to think of Microsoft's own DOC format.
1) Flash changes once a year, forcing you to upgrade to newer 'plugins' so you can view some videos. I think redtube.com or one of those top ones fails under Flash 9, which is preposterous. It's like forcing you to have get the latest KDE version so you can load a webpage where the only problem is that an idiot programmer used a new API instead of an old one.
2) supposing that any one 'non-adobe' system (say, Gnash) is used to load 90% of flash websites starting tomorrow, it can't blow away the original format from the creator. Microsoft and Adobe encourage some incompatibility with old releases to push people to newer software (indirectly driving up hardware sales.) The app would need to be updated in an endless cycle. Look at WINE.

In the end, it comes down to whether the future IT market decides that flash as a file format sucks, and wants it to go the way of the dodo and 1990's VRML. What ends up happening is that another similar or stronger player takes over. The problem with flash's dominance is that it gave us a multi-platform alternative to browser-specific plugins / video formats such as last Active-X and AVI or Quicktime were last decade. That was a good thing, if somewhat accidental, but it has caused us to give up performance and to put all our eggs in Adobe's basket ever since sites like youtube popped up.

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:This is great!

[TheRaven64]

Really? I thought most people used flash for games.

Re:This is great!

[Shining Celebi]

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.

Firefox 3.5 was released in June, with new Javascript improvements via Tracemonkey (a JIT compilation engine) that make it comparable with Chrome. I just tried out the demos and Firefox does not noticeable lag and it did not use more than 10% CPU, which is about the same as a normal Flash video for me.

Re:This is great!

[dave420]

When that's possible, sure! Until then everyone will keep using Flash, as it's released, wide-spread, fast, and works.

Re:This is great!

[Bill, Shooter of Bul]

Maybe that won't be so bad then. Javascript will mainly just interpret the binary flash file and represent it back to the browser as svg +javascript. It doesn't have to render each frame of the movie, it could just tells the browser the key frames and the general instructions of how to get from key frame to key frame. Not going to be as fast as flash, but it still has a chance of not being pear pc* slow.

For you younger folks or older folks with limited mental faculties, Pear pc was an emulator of a power pc based apple system that ran 25 times slower than the host computer. Somethings are technically possible, but practically useless. This doesn't look like one of them.

Re:This is great!

[Anonymusing]

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 geeks (i.e. Flash).

Fixed that for you.

Most people on the Internet think Flash is just part of it. And many of them (I'd guess most) actually like it.

Re:This is great!

[mweather]

It is possible, provided you use a standards compliant browser.

Re:This is great!

[Anonymous Coward]

No problem: "Signed, Ura Dick"

Re:This is great!

[Jurily]

So, everyone who doesn't accept the One True Internet gets written off as a geek? Fine, next time fix your own damn cupholder.

Re:This is great!

[tixxit]

I'd mod you up if I could. That said, don't some JIT VMs do both interpretation and compiling. Like, after a certain hunk of code has been hit 10 times, it compiles it. That would seem to be ideal for browsers as well. Hell, anything that improves that 5 seconds my browser is frozen for after loading a Slashdot page would be awesome.

Re:This is great!

[Razalhague]

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.

You know, the HTML5 standard isn't even complete yet.

Re:This is great!

[h4rm0ny]

Don't know why you got modded Offtopic when your point is a fine response to the GP. Java does have fine performance (for most purposes), but it suffers from start-up times getting the virtual machine up and running. People have a simple reaction to such programs. They start it, they find themselves waiting for it to get going, and they say: "This is sooooo slow." Doesn't much matter what happens after that. The impression is made.

Re:This is great!

[Anonymous Coward]

"keep using Flash, as it's released, wide-spread, fast, and works." [Citation Needed]

Re:This is great!

[Anonymusing]

My post was about market segments, since I was responding to one concerning a topic that marketers call "audience". Flash is not despised by "a large number of people". It is despised by a sizable number of technically-minded people. That's a big difference.

But hey, if you want to read some kind of insult into my comments, be my guest.

Re:This is great!

[Anonymous Coward]

java

Re:This is great!

[rve]

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.

And the boobies look pixelated!

Re:This is great!

[catmistake]

um... what functionalities of flash are you referring to? 99.99% of what flash is now used for is video. Any other method of displaying video would be better. If you are referring to that .001% of flash utilization that is used for something other than video, I don't think the GP was referring to that. I know... let's just use flash for whatever it's good for... and not use it for what it sucks at... then we'll all be happy.

Re:This is great!

[TheRaven64]

Yes, as I said, a lot of implementations use a hybrid of these. For example, I provide a Just Too Late (JTL) mode, which does static compilation in a low-priority background process so the next time you load a code bundle it just checks if the files have been modified since the last run, and if they haven't then it loads the library containing the statically compiled version. In this mode, you don't even need the JIT code loaded, so you save about 20MB of RAM the second time you run the program (important on handheld platforms), as well as the cost of running it.

Java VMs typically interpret bytecode by default but compile methods once they have been executed a few times. Some code, for example initialisation routines, only run once every time the program runs, so compiling them every time is a bad idea. Other code runs thousands of times per invocation. The idea behind Hotspot is to put more effort into compiling the 10% of the code that is running 90% of the time.

You can also do some nice tricks with JIT compilers like this. For example, if one method is often passed instances of a particular class, you can compile a specialised version of the method that inlines calls to methods in that class. Then you just need a small test to decide which version to run.

Tamarin, the VM Flash uses, is even more clever. It doesn't compile functions, it compiles traces. A trace is a sequence of basic blocks with one entry point and multiple exit points. This can weave through a variety of different function calls, so you effectively flatten the entire program then reconstruct functions based on how the code is used, rather than how it is written. This lets you avoid a lot of function call overheads and basically gives you a combination of inlining and function specialisation for free.

Re:This is great!

[hazydave]

Depends in the browser. Consider that applications in Palm's WebOS are usually written in Javascript. Which is why they've spent so much effort tweaking up Javascript speeds. As this is probably more interesting for mobile devices than PCs (which pretty much get Adobe plug-ins, if you want them), this is not a trivial issue.

And until the 1.4 release of WebOS, Apple actually had a faster Javascript engine on the iPhone 3GS than either Palm or Android (not huge, but faster). Given that, based on the closed nature of the iPhoneOS, there will NEVER be full Flash support from Apple (because, like the Commodore 64 emulator, it offers a way to add applications that you didn't buy from Apple), this might be rather significant to iPhonies as well.

Re:This is great!

[f0rk]

Im all for this idea. Some problems do still exist.

1. It's kind of future tech. The majority of all major browsers do support all this cool stuff. The minority that do NOT, still hogs most users.
2. What Adobe is selling is the Flash IDE. I hate it, but most flash "programmers" use it, and is quite unwilling to actually learn to program. JavaScript/Canvas do not have such an IDE.

When IE6, IE7 and IE8 is gone, then we can start thinking of actually use this stuff.
When there is a proper IDE for this stuff, we can start seeing the flash "programmers" migrating.

As an extra bonus, 3. Most people that do flash aint very open source-y in nature. Most bigger flash studios use obfuscators "to protect their product".

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:This is great!

[tepples]

Don't know why you got modded Offtopic when your point is a fine response to the GP

I'm guessing because it's not also a response to the article. Some Slashdot moderators either dislike digressions in general or are looking for some random excuse to bury either a given comment or five of a user's recent comments. If you're going to talk about Java, and the article talks about JavaScript and Adobe Flash, you need to somehow tie your comment in to JavaScript and Adobe Flash.

Re:This is great!

[Thinine]

WebKit has been using JIT compiled native code for over a year now, in addition to bytecode. Safari 4 actually ships with this JIT for the Intel architectures. I believe it has also been ported to ARM and MIPs.

Re:This is great!

[Anonymous Coward]

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

JavaScript won't be your bottleneck. DOM will be. Eventually you can run some things manually on a . That will work great for very simple Flash 5 files from 1998, but not for the sound synthesis, pixel shaders, bitmap filters of Flash 10 in 2010.

Re:This is great!

[promythyus]

He said *less* retarded...

Re:This is great!

[pohl]

...while the WebKit JavaScript VM is a bytecode interpreter.

The world has moved on since those days. Squirrelfish was a bytecode interpreter, yes...but Squirrelfish Extreme has been using JIT compilation since 2008. Note that Chrome also uses WebKit, and has been using a different Javascript VM called "V8", and it also compiles just-in-time. On the mozilla side of the fence, Tracemonkey also compiles just in time. The only laggard is IE.

I recon javascript will be used differently now that the runtimes are more capable. Your observation about how Javascript is used today only reflects the limited capabilities of yesterday's browsers. Flash can no longer be thought of as being uniquely optimized for long-running things. Those days are over.

Re:This is great!

[h4rr4r]

How about just posting the damn videos? All modern browsers will play video fine.

Re:This is great!

[catmistake]

mod parent up!!!

Re:This is great!

[Orlando]

Although I have big problems with the way a lot of people use Flash, I don't have problems with Flash itself.

Orlando...

Re:This is great!

[MillionthMonkey]

Most people use it for ads. Once I installed Flashblock I noticed ads everywhere disappearing and getting replaced with the Flashblock icon.

Re:This is great!

[drachenstern]

I think instead of saying "when IE+ are gone, then we can " you should say "when corporate designed proprietary browsers with no regard for open and established standards" because that ain't the only browser stinking up the works.

But I know what you mean.

As for the obfuscated code, I doubt we'll ever get away from that. Preventing reverse engineering is a pipedream, and middle management will never understand that.

As for proper IDEs, hrm, I think that most of us F/OSS guys suck at IDE design for graphical components, so it'll likely remain up to corps to produce the good IDEs. Maybe it's just me?

Re:This is great!

[icebraining]

Yes:

Sun's JRE features 2 virtual machines , one called Client and the other Server. The Client version is tuned for quick loading. It makes use of interpretation, compiling only often-run methods.

Re:This is great!

[largepox]

If the summary and title are any indication, how about HTML5/SVG and JavaScript?

Re:This is great!

[Anonymous Coward]

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

Like he said, clearly you aren't on a Mac. Flash on a Mac is easily 5 times slower than Flash on Win32. There''s horrid, and then there's WTF.

Re:This is great!

[Anonymous Coward]

Clearly you have never seen today's training courses, which are way more than just a video you have to sit through.

Re:This is great!

[fucket]

Yeah, they're some video and a set of radio buttons.

Maybe HTML 6 will make that possible.

Re:This is great!

[Unequivocal]

Reading slashdot causes my laptop fan to go b/c of all the gook javascript. Everytime I open an article in a new window the whole computer goes nuts and browser bogs down for about 10 seconds. Grumble. (This is latest version of FF on a reasonably new Toshiba laptop). It also happens on my thinkpad. Just me?

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!

[Unequivocal]

I thought it was only me! It's goofy that slashdot maxes out my cpu and freezed my browser every time I open an article in a new tab. You'd think for a geek website they'd figure this out.

Re:This is great!

[ShadowRangerRIT]

Do you have a citation on the "faster than .NET CLR" claim? My impression was that they were roughly equivalent; Java might be a tiny bit faster on identical code, but the CLR won in cases where CLR supported idioms were important (e.g. use of collections with primitives would cost Java time boxing and unboxing, while the CLR can use them in collections natively).

Re:This is great!

[ShadowRangerRIT]

For example, one search for a benchmarking comparison turns up this (sorry, Google wouldn't give a good direct link), which shows roughly equivalent performance.

Re:This is great!

[jmerlin]

Like Silverlight?

Re:This is great!

[Anonymous Coward]

Flash runs smooth, but it uses 100% CPU.

Re:This is great!

[Anonymous Coward]

Not true. Both V8 and JavaScriptCore do native JIT these days. As in, they go from javascript -> machine code.

Re:This is great!

[Anonymous Coward]

He said *less* retarded...

Re:This is great!

[amicusNYCL]

Some video and a set of radio buttons, huh? Educate thyself.

Re:This is great!

[amicusNYCL]

Good, tell that to Youtube and let me know how it works out.

Re:This is great!

[.tekrox]

Strike that down to just Windows please. Flash performance on OSX is still Abysmal;

Flash 10 Improved performance slightly - but only from being unable to use Youtube - to Youtube using 75% of 1 Core on a 2ghz Core2Duo...
iView (a Flash Based monster of a site - akin to BBC's iPlayer) just barely runs (90% 1 Core in Menu 70-85% during video playback) with Flash 10.1 on Snow Kitty 10.6.2

Re:This is great!

[BikeHelmet]

Flash tends to run very long-running things, like games which use a big chunk of CPU for several minutes at a time.

LOL! I haven't found a flash game yet that doesn't leak memory like crazy and slow down over time. On an Athlon XP, give any flash movie 30 mins and it'll be unplayable - even if the framerate started the same as on an Athlon II.

You got one thing right - flash applets are designed to run for several minutes!..

Javascript leaks less memory, and with a fast JIT compiler like V8, it's easy to avoid the 10-second function call timeout. After all, if something locks up a flash movie interpretted with javascript for 10 seconds, it's probably an endless loop. With the flash plugin that would turn into a browser crash, rather than just an unresponsive script whose window you have to close.

Re:This is great!

[spud603]

Yes, but once rendered, it should be pretty easy on the cpu. (on my computer it constantly hits at about 50% of one processor)
Interestingly, with Safari on Mac, if you zoom in or out it does a sort of recurrent zoom in or out, so maybe tiger image continually rerenders...

in any case very cool piece of software.

Re:This is great!

[quetzalblue]

> Educate Thyself

Sure would but it keeps asking me for a plugin .. ;-)

Dont other people boycott sites that use flash primarily for useless banners and such ? vote with your mouse !

BTW, that demo looks interesting, at least the part I could see without engaging the plugin, and is probably a great use for interactive animation but I sure would like to see something else than cra^H^H^Hflash.

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?

Re:This is great!

[OptimusPaul]

Actually quite a few, not quite a majority, of flash developers are quite willing to actually learn to program. Additionally the flash community is very open source friendly. While it used to be the case the obfuscators were regularly used, it's not very common anymore.

Re:This is great!

[Duggeek]

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.

Let's start with the obvious... TFA is a tech demo and not a product. That said, it's pretty ridiculous to think it's an all-out substitute for the Flash Player. It's not.

What's less obvious is the relationship with Flash. To me, it seems that this JS/SVG technique could easily supplant at least half the reasons why domos use Flash/SL/ML in the first place; animation and animated UI features. (slideshows, animated logos, *sigh* adverts too... the real basic stuff) This won't supplant Flash/ActionScript as a platform... not even close! What it will do is open-up webdev options to those who want splashy UI and pop-art without stuffing Adobe's (or M$'s) pockets.

Be excited already! This is a big step, not just for HTML5, but for open web tools as well. Even if it doesn't signal the end of Flash, at least it will make it much harder for SL/ML to justify their existence without addressing the AS/CF aspects of Flash head-on. While we're at it, maybe it will open some eyes at Adobe to not only design their products to be more accessible, but priced to match.

Re:This is great!

[Anonymous Coward]

How are you going to ditch all the Flash that is online? Write an SWF-eating worm?

Re:This is great!

[indi0144]

Inded, I don't know why it does not work in latest opera, Chrome is fine and I welcome this improvement and alternatives for Flash, just this way Adobe can make a better plug in.

But can gordon do stuff like the one featured in this index?

http://www.bestflashanimationsite.com/archive/
or
http://www.thefwa.com/

Remember, politics and technicalities does not matter for the clients. And for the developer the key is the time spent creating the site. Flash wins hands down there.

And when you client is in the computer of Aunt Mary he will call to inform you that "the site is down"

Code driven design will never be mainstream. Matter your own business: create "poetry with your code" and let graphic designers do their job or at least don't bitch because Joe Designer do not trow away Years of training, templates, licenses, techniques, resources and expertise because "is teh open source" the same as if I ask you to start coding by painting your C++ by hand with brushes and watercolors becaus it's artsy. whats next? Forget CMYK because we have invented the ubberopen PERL color mixer FULL RAINBOW color table?

---> code=!design <---

I'm not a graphic designer and I know a lot of them and they laugh by the mere mention of reinventing the wheel. Nuf said, This is really cool and I'm going to include a demo for this in the "lab" section of my site, my rant it's more about the drama some people put in such things like flash. Remember: every time you bash Flash the Silverlight team in Redmond wins a bonus ; )

Gordon haha just clever.

Re:This is great!

[Anonymous Coward]

Aww man you're ruining the circle jerk! GTFO!

Re:This is great!

[LostMyBeaver]

Bottlenext isn't the Javascript. It's the DOM model. Javascript compilers and interpreters in modern browsers (and Flash) are truly special. They are JIT compilers which very quickly are offering some of the best compiled code available. In addition, given that the code is compiled locally, they will soon start producing better code than even the Intel compiler on x86 since the code would be native to the local architecture accounting for everything from available instructions to the pipeline distance between cache misses to cache coherency mechanisms.

With all that, it won't make a hill of beans of difference since for EcmaScript to do anything of interest, it has to interact with the browser's internal representation of the web standards. Since branches of the DOM tree aren't directly addressable in that way and even simple changes to the tree can require reparsing a million objects or more to rerender the page in the browser, performance bottlenecks are now in the DOM model and not the language runtime.

If the DOM model of the browser itself were implemented in EcmaScript and the layout engine were as well, then it would theoretically be possible to remove all these bottlenecks. To do this, it would be necessary to do something like adopt ActionScript as opposed to EcmaScript across the browsers (for object orientation), port the entire engine of the browser to ActionScript and make a call interface for timing, graphics, fonts, windowing etc.. available as objects to the ActionScript engine.

It can be done and if nothing else, the project mentioned in this article show that there are people deranged enough to do this like that.

What makes browser companies so interesting (me being alumni of one of them) is that they are full of REALLY smart guys who have spent years making their browsers faster and faster and having had "cross-browser-maker barbeques" I've learned there's never any shortage of ideas to make them even faster.

5 years down the road, people will be talking about the performance of their H.265 CODECs written in EcmaScript 7 on different browsers.

Re:This is great!

[lena_10326]

The flash probably did not have a stop() in the final frame (the only frame if it's a vector graphic) so it's looping at 12fps continously redrawing. The flash author goofed up.

Re:This is great!

[Anonymous Coward]

It's often claimed that JIT compilers could produce better optimized code because they know more about the running program, but in practice, static compilers still produce far better code in just about every scenario, even without profiling.

Additionally your claim about bytecode speed seems awfully unrealistic...50% native speed? Or MORE? Perhaps for a programming language that is very poorly suited for native compilation, but generally...not even close.

Re:This is great!

[TheRaven64]

JITs can take advantage of run time invariants, which is a big win. On IA32, calls to shared library functions are significantly more expensive than direct calls. JIT'd code can take advantage of this by hard-coding the address of the library functions in the call instruction. These addresses won't change over the lifetime of the program run.

I'm not sure why you think static compilers produce better code. Perhaps you could give an example of a static compiler that produces better code than JIT'd code from the same source language. If you are claiming that a C static compiler tends to produce faster code than a Java JIT, for example, then you'd be mostly right but completely irrelevant. A C JIT (there's one using clang, for example) can produce much better code than statically-compiled C because it can do a lot more cross-module optimisation. For example, with the clang JIT you can compile all of your shared libraries to LLVM bytecode and then run link-time optimisations, inlining your functions into things like the C standard library qsort() (constant propagation + function specialisation + inlining passes).

50% of native for interpreted bytecode is not at all unreasonable. Bytecode instructions are a load, a jump, and then a sequence of native instructions. For dense bytecodes, where each bytecode instruction is more than two native instructions, you are executing native code more than 50% of the time. In most implementations, each bytecode instruction is ten or more native instructions, but suffers from worse register allocation (especially on x86, less so on SPARC, ARM, or any other architecture that doesn't completely suck) so you get a bit of overhead from that, plus the 10-20% overhead from the jump table, which gives something around, or a bit above, 50% native performance. Of course, it's possible to write a bytecode interpreter that is much slower, but I'm talking about something close to the state of the art, like Squeak.

Re:This is great!

[jakykong]

Javascript is a great invention, and as its speed improves, many arguments against its use are resolved. But, from what I can see, the two major ones (accessibility, and shrinking devices) that I see today are still quite valid, mostly independent of how efficient JavaScript can be.

Accessibility -- as more JavaScript is used, the site becomes ever more pointy-clicky and ever less static. To us mouse users, that's probably not a major issue. However, I know two people who can't use a mouse -- one of them is my father, who is paraplegic due to M.S., and relies on Dragon to use a computer at all. It's pitiful watching him struggle with flash- and javascript-heavy sites, because he simply can't tell the mouse to "go there" without most of a minute of effort. Granted, this isn't the majority of users. But it's an important enough minority that sites really should reconsider how much they depend on javascript. (Google's homepage is actually an example of how scripting can be used while leaving the site accessible. It adds flair to the homepage, and lets the menus function, but navigating the site by keyboard alone is still feasible.)

Mobility -- devices are getting smaller. We have iPhones and Netbooks today, which have small screens. Although they can run JavaScript, manipulating a site that builds a complex UI around it can be difficult (especially when it's a large page and things pop up all over the place). Even if the processing power weren't limited, the gaining popularity of these devices seems like a good incentive to keep scripting to a minimum.

I'm probably just a bit biased from the first reason above, but while I'm not against JavaScript, I don't think it's the way of the future -- flexible though it is, it's still got its fair share of problems, completely unrelated to its speed. Static, or at least mostly-static, pages don't have those associated problems.

Re:This is great!

[Acaeris]

erm, I hate to ask but what other browser are you referring to?

Safari's window code may be proprietary but it uses Webkit as it's rendering engine, which to my knowledge is not only open source but the most standard compliant at the moment. http://webkit.org/

Chrome also uses Webkit and Chromium is the open source version of it. http://code.google.com/chromium/

Gecko is the open source renderer for Firefox and most of the other browsers that appear on a website's stats.

Opera is the only proprietary browser other than IE and it's pushing standards just as much as Gecko and Webkit.

am I missing something?

Re:This is great!

[jakykong]

IDEs for code seem to be the only user interfaces F/OSS folks seem to know a lot about -- off the top of my head, there are Vim or Emacs (take your pick -- I like them both.), BlueFish, Eclipse, and on the more specific sides we have the Qt designer, IDLE, and I'm sure Dia fits in there somewhere.

The catch -- of course -- is that most of these UIs feel very logical, but not very intuitive. They're great once you get used to them; but I doubt the average Flash "programmer" will want to use Emacs any time soon. So I guess in the end, you're probably right. It's probably up to the corps to produce the popular, decent IDEs. ;)

Re:This is great!

[Tim C]

Well, I'm using Firefox 3.5.7 and the "blue" demo was not smooth for me at all, while in Chrome it was. I didn't bother checking the CPU utilisation, but performance was visually unchanged even when running them both at the same time.

Re:This is great!

[paimin]

Which format has reasonable compression, and can be assured to play on all major browsers on all currently popular versions of Windows, OS X, and Linux?

Re:This is great!

[t-n_dmkr]

SVG+JavaScript

Re:This is great!

[amicusNYCL]

Oh believe me, if there was a viable alternative we would be all over it. Not many people here have a love for Flash, we've been using it since the Flash 3/Flash 4 days and we've probably run into almost every bug at one time or another. We've lost a lot of productivity to the Flash IDE. But, as it is, Flash is basically the de-facto standard for producing online learning content, and our graphic folks are able to produce some pretty cool things with it.

Re:This is great!

[tepples]

OK, so what authoring tools are available for SVG+JavaScript, other than making it in Adobe Flash, running it through this, and seeing what doesn't break?

Re:This is great!

[drachenstern]

Well, are we only referring to browsers of the top 5 variety? What of Lynx, what of custom or inhouse rendering engines in poorly thought out attempts to replace the popular with a corporately sanctioned browser (it's possible, but no - I have no evidence of any others).

I think it's important that we focus on keeping ALL vendors in check, not just Microsoft and their particular product IE....

Re:This is great!

[morgauxo]

Isn't that the point, offer a way to move beyond Flash WITHOUT reinventing the wheel?

speed

[gbjbaanb]

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

[Jeffrey Baker]

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

[slim]

The language needs better ways of manipulating bits and bytes.

A hidden canvas element?

(I feel dirty now)

Re:speed

[n3umh]

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

Re:speed

[Neil Hodges]

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

Re:speed

[gbjbaanb]

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 :)

Re:speed

[TheRaven64]

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

[revlayle]

Weird, I am using the same exact build and having no problems whatsoever - maybe different based on the OS? (Win7 here)

Re:speed

[badkarmadayaccount]

Throw in hardware access and optional static typing and we have a new system/general purpose language.

Re:speed

[badkarmadayaccount]

What's wrong with that idea?

Flash: No thanks

[Anonymous Coward]

Better SVG authoring tools, yes please.

Now if they could

[mandark1967]

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

Re:Now if they could

[Infiniti2000]

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

Re:Now if they could

[SolitaryMan]

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

[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:Now if they could

[clang_jangle]

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

[yabos]

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.

Re:Now if they could

[Ltap]

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

[Anonymous Coward]

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

[Anonymous Coward]

That works, but be careful to delete *only* the cookies or you'll break some sites.

Re:Now if they could

[Danny Rathjens]

Why would disabling the caching ability make things faster? :)

Re:Now if they could

[Anonymous Coward]

No need to block the complete adobe dir. They are using lso.

http://en.wikipedia.org/wiki/Local_Shared_Object#File_locations

Cookie dir's should be chmodded to 000 to prevent updates as root changing this again to 755 or something like that.

Not sure how to do this on windows but maybe someone can tell the rest of the users.

Re:Now if they could

[Unequivocal]

I don't know but here's a theory: if you don't permit disk caching, perhaps the app chooses to cache more stuff in memory. That would speed things up at the cost of a fatter process.

Re:Now if they could

[Anonymous Coward]

If updates chmod dirs in your ~/, you're using the wrong OS! Unless you're referring to hostile sysadmins...

Re:Now if they could

[characterZer0]

Not that kind of caching. Caching downloaded objects so you do not have to download them again when you visit the page next week.

Re:Now if they could

[Anonymous Coward]

Taking away write permissions for my ~/.macromedia dir didn't work for me. Browser stuff with Firefox wasn't an issue but that stopped my Hulu Linux client. Apparently Hulu Desktop for Linux also relies on those damned Flash cookies and uses that same folder to store them. I'll just keep using that goofy online Adobe Flash utility to manage Flash for now.

Re:Now if they could

[Anonymous Coward]

Haven't tried in FF, but hulu works fine here in opera with write permissions removed from ~/.adobe and ~/.macromedia.

Checked out the demos on my iphone

[Anonymusing]

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

[Anonymous Coward]

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

[Sir_Lewk]

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

[khellendros1984]

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

[Anonymusing]

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.

Re:Checked out the demos on my iphone

[Anonymous Coward]

hey thanks for the PhoneGap info. i hadn't heard of it before and it's just in time for their beginner class this week.

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.

Re:Sort of a good idea

[goose-incarnated]

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)

Re:Sort of a good idea

[bersl2]

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.

And this is why we have things such as AdBlock (and variants) and NoScript. Presumably, if and when SVG and the HTML5 media tags start being used much more, there will be browser controls for whether the media should be run or ignored.

Re:Sort of a good idea

[drachenstern]

As an expert in ignoring things, I can vouch that it's easy to ignore things which you don't see. So my advice is to stop using the web and go outside more. That way you can ignore online advertisers, email and more! As for ignoring other people when you go outside, carry a bloody shovel over your shoulder and splash a little fresh blood on your clothes. Most people will go the other way.

Perhaps you wanted someone who was an expert in HTML5? I don't know those people, everyone seems to run away when they see my shovel...

Re:Sort of a good idea

[nschubach]

I would assume it should be trivial to overload the functions required to initialize this stuff as well.

Re:Sort of a good idea

[msimm]

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

??? Just use Noscript with javascript disabled by default (which you should be doing anyway). Then the advantage of a pure javascript solution is that not only do you avoid installing Flash (and the security issues associated with it) but you don't need to install another plugin to block the animation (because everyone uses noscript already...right?). ;-)

Re:Sort of a good idea

[nine-times]

It was a joke. (sort of)

The serious idea embedded in the joke is that, aside from playing video, I don't want to view any of the content that's currently being displayed in Flash. Video should be done with HTML5, and then Flash is completely useless. I like the idea of getting rid of the Flash plugin, but even more I like the idea of not seeing any of the content people use Flash to display.

Re:Sort of a good idea

[AVee]

I tend to agree that this is not where we should be going, but it may well be a part of how we get there. Flash isn't going to go away just like that, nor is HTML5 going to be all over the place all of a sudden. However, this may well ease the transition a bit.
Eventually Adobe will probably start spitting out HTML5 instead of .swf files, I'd guess they wouldn't mind not needing to maintain the player anymore.

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:Not SVG

[Jeffrey Baker]

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

[gehrehmee]

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

[Anonymous Coward]

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

[Anonymous Coward]

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.

Re:Not SVG

[maxume]

Because IE doesn't handle

application/xhtml+xml

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

Re:Not SVG

[Jeffrey Baker]

Tons of shit doesn't work in IE.

Re:Not SVG

[maxume]

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

[amicusNYCL]

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

[Ltap]

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

[maxume]

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

[Jeffrey Baker]

HTML5 includes XHTML5, so although it is true that XHTML2 is dead, it is also irrelevant.

http://www.whatwg.org/specs/web-apps/current-work/#the-xhtml-syntax

Re:Not SVG

[snadrus]

All Video happens in C code: HTML5, Flash, Silverlight, MS media embeds.
Firefox can't do h263 for HTML5. There's no chance of reimplementing h263 in Javascript with performance, so game over for this language choice producing a replacement.

Re:Not SVG

[Jeffrey Baker]

Which inclues an XML syntax. Any browser which supports HTML5 will also have XHTML5.

Re:Not SVG

[TheRaven64]

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.

No, but if your browser supports the video tag and you have the correct codecs installed then something like this can implement the Flash video APIs in terms of that.

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

You should use XHTML. Then you can mix HTML, MathML, and SVG in the same document, and have elements from all of them in the same DOM. The entire point of XHTML is to allow different XML formats to be used in the same document. Saying 'I want to do this without using the solution that was specifically designed for this exact problem' is a very strange thing to do. You have a long career in management ahead of you.

Re:Not SVG

[klecu]

HTML5 browsers will have built-in video decoding capability without the need for plugins, especially Flash which in my experience has been a terrible medium (as far as resource efficiency) to distribute video. It takes more CPU, more memory, and isn't as clear or as smooth as just playing h.232 video.

Re:Not SVG

[gehrehmee]

The thing is, if the requirement is "Render a video at this coordinate on the page, with this size", the javascript implementation could simply go "Hey, pass that off as an and let another plugin handle it." Firefox's HTML5 code is being set up to handle an external supplier, for the linux case, gstreamer, in which case Firefox should be able to do html5 video with whatever codecs the system has available.

Re:Not SVG

[nine-times]

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.

But why should they when your OS already has a perfectly good decoder? Using Flash for video playback was an ugly hack to begin with.

Re:Not SVG

[Nick Novitski]

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

...which supports XHTML syntax and the application/XHTML+XML mimetype. XHTML syntax is still quite alive and well, and usable by anyone who feels like using it, like myself (I find the rigor makes things easier to read and write). Perhaps you don't like its strictures, but luckily there's room for both of our syntactical preferences in the W3C tent.

Re:Not SVG

[Anonymous Coward]

Why shouldn't you use XHTML?

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

That sounds very much like the usual bullshit coming from "web-developers" who doesn't know the content/functionality of XHTML. If you think XHTML is HTML4 plus some extra slashes here and there and a different MIME-type, then go learn XHTML before you bitch about it.
A hint: The real difference between HTML4 and XHTML lies in the parts that Internet Explorer doesn't support.

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

HTML5 is almost as much XHTML as XHTML2 is XHTML. The difference in this area between the two is that HTML5 is both XHTML and (SGML-)HTML.

Re:Not SVG

[amicusNYCL]

I don't have anything against XHTML, I just don't see a benefit to using it versus HTML. I'll write structured markup either way.

Re:Not SVG

[amicusNYCL]

go learn XHTML before you bitch about it.
A hint: The real difference between HTML4 and XHTML lies in the parts that Internet Explorer doesn't support.

I know as much as I need to about XHTML, and I'm also not bitching about it ("There's no practical advantage to using XHTML over HTML." - that's not a complaint, it's a fact). If you think you have a good point, maybe you should make it instead of brushing it off. If your point is that XHTML is (in theory) well-formed XML, then describe how having well-formed XML is a benefit over using HTML for structuring a web page. I don't see any practical advantage to having a web page that you can also parse as XML. If I want a data feed I'll use XML. If I want a web page I'll use HTML.

Re:Not SVG

[BZ]

Note that the current HTML5 draft proposes parsing SVG in text/html. At least the html5 parser implementation in Gecko (currently trunk-only and not enabled by default yet) supports this.

Re:Not SVG

[$1uck]

Because it's nice when your web page is a data feed and your data feed is a web page? Do you need anymore reason than that? Once your web page can be parsed like XML, well it could be used in countless different ways. It can become a web service (and you don't need to use something ugly like SOAP).

Re:Not SVG

[Anonymous Coward]

Why shouldn't you use XHTML?

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

Being able to add SVG to the DOM isn't a practical advantage? Admittedly it's not something that everyone needs to do, but if you do want to do it, saying "you can't because you need XHTML and XHTML is bad because it doesn't have any advantages" seems like a somewhat circular argument.

Re:Not SVG

[Anonymous Coward]

The future is actually most likely XHTML5, or the XML dialect of HTML5. And there are practical advantages in that the Use of xhtml, such as being able to embed SVG, mathml, and more in it. The browser is able to be really strict about the document's validity, which may help you catch stupid mistakes early, you can use XSLT to easily transform an XHTML document that was well designed into other formats, etc.

Re:Not SVG

[SolitaryMan]

Why shouldn't you use XHTML?

Many reasons

The main one, however, is because there seem to be an agreement between all browser vendors that the future is HTML5. Nobody cares about XHTML any more.

Re:Not SVG

[horigath]

To summarize: you can't use SVG properly without XHTML, but there's no reason to use XHTML because it doesn't have any advantages over HTML.

Are you sure that this makes sense?

Re:Not SVG

[Anonymous Coward]

It seems to me that the OP stated the primary practical advantage of XHTML over HTML: The ability to have multiple different namespaces such as SVG and MathML. Secondary practical advantages that have real world usages are the ability to treat it as generic XML for efficient storage, parsing and transformation, and embedding it in other XML formats and protocols.

Also, XHTML2 was abandoned in favour of HTML5, simply because HTML5 was what the industry wanted. HTML5 is essentially a successor to both HTML4 and XHTML1; it has an XML serialisation (sometimes called XHTML 5) that you can embed other XML namespaces in, as well as a not-quite-SGML serialisation similar to HTML4. If anything, HTML5 is closer to an XHTML1 successor than it is a HTML4 successor, besides in name. All XHTML1 was in essence was an XML serialisation of HTML4 with deprecated tags removed.

XHTML 2 was going to be something rather different entirely and can essentially be ignored from now on unless it's revived one day.

Re:Not SVG

[AVee]

But if your browser properly supports the tag and H.232 it will probably be pretty easy to start that through javascript...

Re:Not SVG

[Smurf]

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.

What's H.232? As far as I could tell, apparently it refers to a standard for VoIP (although that may be H.323).

Maybe you are talking about H.264 or some other H.26x video standard?

Re:Not SVG

[Anonymous Coward]

Correct me if I'm wrong

You're wrong. SVG can be embedded in any HTML5 document. Microsoft hasn't announced SVG support in IE9 yet, but it's likely.

Re:Not SVG

[SolitaryMan]

yep, sorry, got confused by all those numbers and didn't bother to check, which one to use ;) I was talking about video codec.

Re:Not SVG

[Anonymous Coward]

Practical advantages of XML HTML vs SGML HTML:

• XML is easier to parse, on low memory and cpu devices like portable phones and what not this is quite useful
• Data can be scraped by general purpose XML tools without handling all the SGML idiosyncrasies, eg. pulling out the content of a page for display in a news reader
• The behaviour of the parser is more predictable and less likely to behave differently in different browsers
• You can apply XSLT to the page to reformat all your static pages without manual editing
• You can embed additional XML content into the page that isn't necessarily intended to be rendered directly. This cleanly integrates like native content such as dumping a database query into the page in XML form so that javascript can build it in to a table on the user end based on what options they select. And the obvious of embedding SVG, MathML and whatever else. Any XML schema, any can be embedded. This blurs the line between the human readable web and machine readable data by allowing them to be interchanged automatically.

XML is just plain technically superior; of course, that doesn't mean much in the real world since the current stuff "works" in the vague way that people without imagination define that word so there is a lack of interest in new approaches unless it is rammed in to them (It's the "change happens one funeral at a time" sort of deal).

Re:Not SVG

[Nick Novitski]

You see no benefits to using XHTML. I agree that many of its outlandish promises failed to materialize.

I see no drawbacks to using XHTML. I hope you agree that it is and will always be valid HTML5, which is The Future(tm).

Let us be as one mind and one people.

Re:Not SVG

[DaVince21]

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.

Dude, HTML5 video tag.

It won't be a quick transition.

[Interoperable]

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.

[gencha]

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.

[Ltap]

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

Re:It won't be a quick transition.

[revlayle]

even then if this took off, you know someone will make an extension to a browser that will convert embedded flash object html (or js even) with the Gordon wrapper on any given page

less than 100% is good

[f3r]

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

[omnichad]

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

[jellomizer]

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.

Re:Must be an iPhone user

[Fnkmaster]

Seems like the effort would be much better spent just porting Gnash to iPhone. It's been talked about for two and a half years now, but to the best of my knowledge, nobody's just done it.

Re:Must be an iPhone user

[omnichad]

Would only work on a jailbroken iPhone. And unless Safari for iPhone has some new ability to accept plugins you'll have to port Firefox or Webkit yourself while your at it. If you just want to run a SWF file standalone, then porting Gnash would let you do that. But that would be of limited use.

Re:Must be an iPhone user

[DaVince21]

It's also very nice for Linux users (for speed), and users of any platform which doesn't support Flash (or only very slowly)

Variable names

[gencha]

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

Re:Variable names

[Rockoon]

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.

Re:Variable names

[The End Of Days]

Generally it's a size optimization, and/or obfuscation. There are a few libraries that will run through .js files and do the replacement for you, so you can work with reasonable names in the dev source.

Re:Variable names

[Anonymous Coward]

Some of your points are obviously correct. I was speaking of the cases where someone uses a variable p or l and you can only find out what it is if you go to the start of the function. And I personally find that using "value" instead of "v" is very helpful. At least then it's not confused with "vector".

Re:Variable names

[gencha]

I doubt that's the case here. And if that was the goal there are far better JS compression techniques available.

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:OMGWTFPDF

[Anonymous Coward]

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

[ReinoutS]

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.

Re:OMGWTFPDF

[Paradigm_Complex]

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!

Re:OMGWTFPDF

[Jeffrey Baker]

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.

Re:OMGWTFPDF

[thePowerOfGrayskull]

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..

Re:OMGWTFPDF

[MrNemesis]

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.

Re:OMGWTFPDF

[snadrus]

What we need is URL handoff.
.PDF should hand the URL to the PDF viewer and be done with it. Someone who doesn't know what's going on will still get a seamless experience and have nothing to complain about.

Re:OMGWTFPDF

[shutdown -p now]

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.

It depends on the nature of the PDF. If it's a long windy document, then sure, I'll download it and read it separately. But, for example, a lot of C++0x papers are small (1-5 pages) PDFs, and when reading comp.std.c++, I have to view some random ones all the time. It doesn't make any sense to download them just for one view, and I never know when (and if) I'd need to view that one again. It's so much easier to just open the list, pick the paper I want, and have it open right there and then in the same window.

Re:OMGWTFPDF

[Darkman, Walkin Dude]

Yo, sup dawg, I herd you like Flash, so I put Flash in your Flash so you can read PDFs while you read PDFs.

Re:OMGWTFPDF

[AntiDragon]

Although I agree, it's a convenience thing. There's been times where I have to browse and view loads of different PDFs via online links and having to first download then open each one is a pain. Safer, certainly but a nice, non-adobe-full-of-exploits in-tab PDF viewer would be nice.

Re:OMGWTFPDF

[__aatdha9242]

It already exists. Use google chrome and the gPDF extension, and all pdf files are opened by google's own javascript based viewer. Also availible for firefox as well!

Re:OMGWTFPDF

[Anonymous Coward]

Like to see Grandma use that

Re:OMGWTFPDF

[omnichad]

The one thing it does to is progressive downloading. You can read the first page, while the rest of the document is still loading.

Re:OMGWTFPDF

[shutdown -p now]

I use Opera, but looking at that extension, it seems that it just rewrites PDF URLs to point to Google Docs PDF Viewer, so an equivalent UserJS script shouldn't be hard to do. Doesn't seem to support large PDFs (I guess it times out trying to download them), but then that wasn't the requirement. Otherwise it's pretty nifty. Thanks!

Re:OMGWTFPDF

[Fahrvergnuugen]

Preview.app begs to differ.

Re:OMGWTFPDF

[DiegoBravo]

> The real WTF is that you are trying to view a PDF in your browser in the first place.

For the same reason the browser allows for viewing JPG/GIF/etc?

The "scripting" added to PDF by Acrobat doesn't mean that PDF shouldn't be considered as just another graphic format.

Re:OMGWTFPDF

[hcdejong]

Huh? Just set .pdf to always open with Adobe Acrobat (or whatever) and there's no 'first download, then open': just click the link and it gets auto-downloaded and handed to Acrobat. With the added bonus that your keyboard works properly (e.g. the inability to use Ctrl-W to close a browser window containing a PDF drives me nuts).

Re:OMGWTFPDF

[BitZtream]

Or better still, we could just stop using PDFs on the web.

Better STILL would be to stop using PDFs and stick with a standard document format ... like I don't know ... H T M L.

Re:OMGWTFPDF

[Anonymous Coward]

Wake me when browsers support CSS's paper-size style and HTML's <PBR> tag for forms that need to be printed onto pages in a certain way.

Re:OMGWTFPDF

[Anonymous Coward]

PDF is a standard document format, and a pretty good one at that.

It is being misused, and Adobe promotes its misuse with their web-like "features" but that's an entirely different problem.

HTML, on the other hand, has always been a crappy document format. HTML5 is a decent attempt at improving it but as long as the standard reads "obsolete but all browsers should support it" instead of "tell the user the webmaster has tried to plant child porn into his computer and display WHOIS information", it has no real hope.

Re:OMGWTFPDF

[selven]

So if you're browsing and you want to look at some online pdf document, you should download it, open up the download directory, find the file and then open it up? I prefer my one click in-browser approach, thank you very much.

Re:OMGWTFPDF

[sapphire wyvern]

What's really annoying is when webpages do stupid tricks so that even when you've set .pdf to always open in an external app (eg Adobe Reader, Foxit Reader) it *still* opens as an embedded object in the browser. That irritates me so much.

Re:OMGWTFPDF

[jbn-o]

Handing off a URL to a PDF application could accomplish the same thing, no?

Re:OMGWTFPDF

[ReinoutS]

No, you should click it and have it opened automatically in your pdf reader. That doesn't take more than one click.

Re:OMGWTFPDF

[selven]

That's still a new window. In-browser PDFs are a new tab.

Re:OMGWTFPDF

[ReinoutS]

And a new pdf viewer window is exactly what you want in this case. (Unless your browser is your OS, of course...)

Re:OMGWTFPDF

[selven]

Why? I could understand if you're going to read the whole thing immediately and then go back to the internet, but most of the time flipping back and forth between the internet and the browser is what you're going to do a lot. Tabs are much easier to navigate than tabs + windows.

Re:OMGWTFPDF

[GWBasic]

And a new pdf viewer window is exactly what you want in this case. (Unless your browser is your OS, of course...)

No, I don't want to leave the browser. That's why it's called a "browser." You can browse lots of different kinds of files.

Re:OMGWTFPDF

[Anonymous Coward]

You kids crack me up. It was called a browser long before they even had contents other than HTML/text. And even then, for a long time the only embeddable contents were GIF and JPEG pictures. It's called a browser because you read a bit here, follow a link, read a bit there, etc. Now get out of my lawn!

Re:OMGWTFPDF

[badkarmadayaccount]

gpdf add-on

Re:OMGWTFPDF

[DaVince21]

I'd personally prefer evince to be ported to other platforms and a browser plugin for that to be created.

Get real

[Anonymous Coward]

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.

Re:Get real

[koiransuklaa]

This solution (if taken into the logical conclusion) would obviously use the codecs installed on the host via the browsers video functionality. This is how video on the web should have been done in the first place.

What is your problem with this?

Re:Get real

[DaVince21]

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.

You answered your own question here; this implementation could just use HTML5's video tag support to do all the decoding work. And in case you didn't know, these videos can be stretched and warped in any way necessary, too.

Hmm, if it is any better than Flash...

[Rokewaju]

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...

[the roAm]

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

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

[revlayle]

not yet, i am sure that there has been no significant optimizations in that technology yet, as the adoption rate is small.... if a popular web application ro framework came out that used SVG extensively, you can bet the big ones (except IE, maybe) would come out with ways to improve the efficiency and speed of SVG rendering

Too much fuss

[vagabond_gr]

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.

Re:Too much fuss

[Amouth]

and Gnash started by implementing v1 before v2.. just like adobe did.. give the guy a break - what he did was not an easy feat (if it was it would have already been done). why not give it some time or support - as far as i know Gnash isn't supported on an iPhone or many other devices. he found a nich and filled it - and from what i saw - i don't think it would be too hard to update it and find flash objects via DOM and run Gordon in place of flash (if flash isn't available).. meaning after some updates maybe it's just include this js file and non flash supporting browsers and devices can now view flash on your site if they have JavaScript. while i'm not a fan of flash at all - this is a good thing.. and i would love to see it progress farther.

Re:Too much fuss

[mad.frog]

Mod this guy up. While it's an impressive demo, saying "He implemented Flash in JavaScript" is severely misleading... he implemented a subset of Flash 1.0 (circa 1996 or so) in JavaScript. It's a nice demo and I'm guessing that it will be useful for some trivial things, but he has a long way to go to get to Flash 10...

I can't wait for the Firefox addon

[dunkelfalke]

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

[SargentDU]

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

Before you get all excited...

[Qubit]

...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.

Re:Before you get all excited...

[diegocg]

gnash needs to write and maintain a javascript VM and many other things. This project does not.

Also, it could use some of the gnash actionscript libraries...

Re:Before you get all excited...

[eigenstates]

"for, say, internet video sites to work."

And that is about it- no JS or SVG needed. The thing I think the demo is shooting for is the only thing people keep saying Flash does that HTML5 doesn't- the rendering of vectors in cutesy marketing pleasing animations. Evidently it does so pretty well.

And with the notion of Workers, it looks like HTML5 might be firing towards the AIR market as well.

Re:Before you get all excited...

[eigenstates]

Oh ffs, sorry.

<video src='{path}' ></video>

Re:Before you get all excited...

[BitZtream]

If you look at the changes to flash since the beginning, the format has't changed a lot over the years. Once you get the base down for v1, the rest is mostly trivial changes like adding support for new image formats or more efficient use of various tags by passing in new/more vars.

Why gnash doesn't have support for the recent formats is beyond me, the newer formats change less and less. Somewhere between 6-8, the only change was a single modification to an existing tag. Most of the time its just things like 'this tags now support 32bit color instead of 24 or 15'

I don't think it will change much

[Monkeedude1212]

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.

Re:I don't think it will change much

[drachenstern]

You must not be using Firefox... let me help you with that: http://getfirefox.com/

I've found that I can inject just about anything I want into the browser that I run on my machine, isn't this the point of a bookmarklet? For that matter isn't that how most browser add-on's work, including the existing flash player? They extend the page as sent from the server (which by it's nature is either textual or binary, but is in no way inherently feedback oriented).

As for using Flash to create the content... once upon a time only MSWord could read .doc, only Acrobat Reader would read .pdf, and only Windows could run PE .exe's. Funny how things change, eh? http://www.swftools.org/

flash should only be used for Audio & Video

[nan0]

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!!!
:D

Re:flash should only be used for Audio & Video

[Anonymous Coward]

When Javascript has a BlazeDS/AMF implementation, then you can say flash is ready to be deprecated.

If you don't know what those are, you shouldn't be in this discussion.

How long? How about 'probably never'

[Quarters]

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.

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.

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:How long? How about 'probably never'

[Quarters]

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

Except for the fact that you mentioned right above that statement the real issue...Flash (and Silverlight, et al.) would continue to exist. It doesn't matter if Firefox put it in by default because sites can still require Flash or Silverlight. Yes, Slashdot owners may not care for those but the vast majority of people don't care. If they can get video in their browser they don't concern themselves with the whys or the hows of how it got there. Against that apathy and along with the fact that Adobe and Microsoft will continue to push their solutions and offer engineering support, etc... this tech has a HUGE uphill battle.

Find me in five years and tell me how this is going. I've got my opinion as to what you will say at that time.

Doesn't support AS3

[Steve S]

According to the list of supported swf tags (http://wiki.github.com/tobeytailor/gordon/swf-tag-support-table ), 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.

Re:Doesn't support AS3

[lennier]

"It's a strongly typed language with real classes"

You say that like it's a compliment. But prototypes are the most interesting thing about Javascript, IMO.

Re:Doesn't support AS3

[Anonymous Coward]

So what do you use instead of Flash for the animations and tools that designers need? I've yet to find a decent alternative to Adobe Flash/PS/Illustrator/etc that can be used in the browser.

Re:Doesn't support AS3

[BitZtream]

DoABC means execute a precompiled script. I've been converting a BUNCH of flash to SVG recently and I've yet to come across a flash file that used precompiled script.

Second, 'ActionScript 3' is still JavaScript, it really isn't any different, and there is already code out there to execute it.

You should probably stop reading marketing garbage and read the file format specs a little closer.

Re:Ummm ...

[Transfinite]

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

Now seriously...

[LunarEffect]

I'm impressed! Flash has pretty much become an integral part of the web, yet you always had to download and install an extra plugin to be able to view flash content. Having an implementation of the flashplayer written in a language that can be executed by every major browser reguardless of the operating system is an incredibly useful thing to have.
And now with ever faster Processors and better implementations of JavaScript interpreters, I think its far from a bad thing to put more work into the hands of interpreted languages.

Which browser?

[Chousuke]

Which browser are you using? They're all very smooth on my macbook, using Firefox 3.6pre (daily build). CPU usage is around 10-20% (max being 200%. Dual core). Quite impressive.

I wonder if it is feasible for this to become a full-fledged flash reimplementation. As far as I understand, Actionscript is very close to Javascript anyway; if the Flash engine becomes integrated into browsers, there would be no need to load the Adobe plugin, and browser makers could ensure that Flash just works.

I guess it's better to hope that Javascript and SVG and such technologies eventually overthrow Flash, but I doubt that will happen very soon.

Re:Which browser?

[Anonymusing]

Which browser are you using?

I was using Safari on my iPhone.

On my desktop, the demos are fine.

Replacing flash/silverlight

[gmuslera]

A giant jump for a project, a very small step for the web. Even if you catch current status of current web video players, Adobe/Microsoft will make sure that their solutions are the "right one", adding things, making developer switch to now "essential" shiny features, or even by deals with all the big video providers in the web. You know, like how the most popular browser used in the places where security matters isn't exactly the most secure one.

Re:Replacing flash/silverlight

[badkarmadayaccount]

Microsoft? Deals? Google/Youtube?

Haha

[lewp]

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?

Gee, I dunno. How long will we have to support IE6?

Um,

[rickb928]

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

Until Adobe and Microsoft break them.

Rinse and repeat.

JavaScript audio?

[tepples]

ECMAScript and open graphics standards?

What about open sound standards? Can the <audio> element of the HTML DOM support playing multiple instances of one sound at once, or varying the playback rate or volume of audio, or synchronizing vector animation to the audio? The common uses of audio that I've seen in SWF objects on Newgrounds makes use of all of these Flash Player features.

Re:JavaScript audio?

[drachenstern]

well, it's my thought pattern that if ECMAScript allows for multiple animations on a page at one time, that surely it could handle playing back multiple audio streams at one time. It seems as though I recall that the primary problem with playing back multiple audio streams is not a ECMAScript problem, as much as an OS or hosting container problem. But I can't think of any system that won't allow that nowadays, I think I'm remembering something from way in the past...

But the question was "playing multiple at one time or in a coordinated fashion" ... ECMAScript runs faster than we can detect a single cycle, and it can spawn multiple threads, so I should think playing multiple audio or coordinating their playback should be easily possible with ECMAScript. Granted, that's not my field, and I don't write anything using so ... idk.

Re:JavaScript audio?

[tepples]

It seems as though I recall that the primary problem with playing back multiple audio streams is not a ECMAScript problem, as much as an OS or hosting container problem.

That's why I mentioned the HTML DOM. Is that what you meant by "hosting container"?

ECMAScript runs faster than we can detect a single cycle, and it can spawn multiple threads, so I should think playing multiple audio or coordinating their playback should be easily possible with ECMAScript.

Provided that the DOM exposes a rich enough API to let the script coordinate their playback. The last time I read HTML5's definition of the <audio> element, I couldn't find DOM elements that looked essential for use in JavaScript games. But it appears that "currentTime", "playbackRate", and "volume" appear to have been added since then.

Re:JavaScript audio?

[Anonymous Coward]

Can the element of the HTML DOM support playing multiple instances of one sound at once,

Trivial to do with multiple audio elements and scripting. If it doesn't work in a browser that's an implementation bug.

or varying the playback rate or volume of audio, or synchronizing vector animation to the audio?

Volume is already scriptable. For the rest, it will. There's an experimental Firefox 3.7 build out. It might land in Firefox 4. Getting an API into the HTML spec will take longer.

Re:JavaScript audio?

[Acaeris]

HTML5 hasn't been finished as a standard yet. Most notable, audio and video tags still need tweaking and at the moment there are two different standards for video codec :/

Re:JavaScript audio?

[paimin]

The answer to the first three is definitely yes, and I'm pretty sure the answer to the sync question is yes depending on what you mean. Do some googling.

Re:JavaScript audio?

[drachenstern]

That's why I mentioned the HTML DOM. Is that what you meant by "hosting container"?

Yes but it seemed you were implying that the javascript engine would be solely responsible, even after you mentioned the DOM. Control versus content, ya?

Provided that the DOM exposes a rich enough API to let the script coordinate their playback. The last time I read HTML5's definition of the <audio> element, I couldn't find DOM elements that looked essential for use in JavaScript games. But it appears that "currentTime", "playbackRate", and "volume" appear to have been added since then.

Yeah, that's the problem with evolving standards. Frankly I'm surprised at many of our modern computing standards, that the guys who designed them were able to look ahead sometimes 10 years and foresee difficulties that weren't obvious at the time. Imagine if the Romans had envisioned cheap and efficient gasoline engines and had built their empire for it, or even just the use of electricity for something like a telegraph (which I firmly believe they had the inkling of).

So do you think at the time of the ratification of HTML5 that it won't be possible to make a "Flash" player out of javascript?

Re:JavaScript audio?

[tepples]

One of the first when I investigate an "active content" technology is what kind of game can be implemented with it. For example, Tetris has always needed at least non-blocking input, a fairly reliable timer, and repainting existing screen elements. But due to more recent changes to the Tetris Guideline, it also requires audio support to play sound effects and the "Korobeiniki" song. Racing games need volume and pitch controls to play engine noise, and rhythm games need synchronization among audio, animation, and input.

Moonlight

[tepples]

The only significant part of Silverlight that's Windows-only is digital restrictions management on streaming video. Everything else is cloned in Moonlight.

Re:Moonlight

[rufus t firefly]

The only significant part of Silverlight that's Windows-only is digital restrictions management on streaming video. Everything else is cloned in Moonlight.

Unfortunately the highest profile use of Silverlight for most people I know is Netflix, which makes it useless on anything other than the officially blessed versions of Silverlight. I have been telling everyone to just get any of the cheap settop boxes that support it, but it doesn't change the argument that as long as Moonlight is "hobbled" in a way that keeps users from working with it for popular applications, it's something to be avoided rather than embraced.

Re:Moonlight

[Anonymous Coward]

Sure, if you don't count the fact that Moonlight seems to be constantly 1+ versions behind Silverlight. Not at all surprisingly, I might add.

Re:Moonlight

[tepples]

Sure, if you don't count the fact that Moonlight seems to be constantly 1+ versions behind Silverlight. Not at all surprisingly, I might add.

And IE is constantly behind Firefox, Opera, and Safari/Chrome. Why is it that Flash apps are less likely to require the absolute latest version of the player than Silverlight apps?

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.

slightly shorter

[farlukar]

HTML5/SVG next-generation browsers like Chrome, Firefox, Opera, Safari, Epiphany, and other Web-Kit based browsers

i.e. anything non-IE :)

Re:Ummm ...

[farlukar]

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

Well, IE is shit, but currently there isn't any browser that's fully standards-compliant.

You DON'T know what you are talking about!

[gbutler69]

"There's no practical advantage to using XHTML over HTML." - that's not a complaint, it's a fact

Here, I'm afraid to say, you show your ignorance (that is not an insult - I'm using "ignorance" in the way it was meant to be used, that is, "You are IGNORANT [i.e. are not aware] of the facts") of the purpose of XHTML. It is not just adding some extra slashes and having to close your tags. It has NOTHING to do with data. What it allows, is embedding of other WELL-DEFINED XML namespaces. For example: SVG, MathML, SMIL, etc.

OK, smart-ass

[gbutler69]

Where is the production version of IE that supports HTML 5 reasonably well? Oh, it doesn't exist does it?

Odd.

[gbutler69]

Your unconditional faith in entrenched players is astounding. Also, the ending question about completely supplanting doesn't mean what most people seem to think it means. The point isn't that Gordon can replace Flash using SVG/HTML5, it is that soon, it appears, that SVG/HTML5/JS will be able to replace all the funtionality of Flash. Gordon, or technology like it, will just allow legacy Flash content without requiring a Flash Plug-In.

I'm really amazed how short-sighted a lot of the comments on this are.

Re:Odd.

[rickb928]

Well, wait until Adobe changes the Flash spec sufficiently to break Gordon. Flash plug-ins will work fine, of course.

My faith is based on experience. I was a Novell guy originally. Microsoft wasn't done until Novell didn't run. Not just a catchy phrase, this was BAU in Redmond. Adobe knows this tactic. If they wish to kill Gordon, they only have to worry about getting caught. Doing it is reasonably trivial.

I'm looking forward to SVG/HTML5 to solve this, but it will take time for authoring tools to catch up.

Re:Odd.

[gbutler69]

What part of, "Gordon, or technology like it, can then be used for legacy Flash support," did you miss?

BTW, condolences on the whole Novell thing. I definitely recall how it was obvious that Win95/98 did everything in its power to break Novell and force any sane person to *have* to move to NT/AD.

Re:Odd.

[rickb928]

Well, if authors recompile (wrong term I know) their Flash, they won't be distributing 'legacy'.

If YouTube updates to current Flash embeds, they won't be 'legacy'

If just a few very popular sites update their Flash content, 'legacy' won't be good enough.

And Gordon will have to play catch-up.

Not a new strategy. So far, Adobe hasn't broken legacy. If HTML5 catches on, hopefully they will compete and not destroy.

Gordon needs to know when to get out of the way

[morgauxo]

I want to be excited and hopeful this will become a full alternative to installing Flash on my Linux desktop. But, are developer's really expected to break their sites on IE just so it will work on iPhones or non-IE machines which don't have Flash installed? Don't get me wrong I would very much love to see IE and Flash go away forever but until IE marketshare goes sub 10% or IE picks up SVG support AND it's user's actually install the update I don't see how this can work. Now, if Gordon detected IE or better yet, any browser lacking SVG support and passed the swf to Flash I could see this having a chance of being used somewhere.

I still don't think it will get too popular because if website developers gave two sh1ts about how Flash sucks resources or what a pain it is to run in Linux or the fact it doesn't run at all outside of Windows,Mac,Linux(BSD?) it wouldn't have reached the state it's in today where it shows up on almost as many pages as HTML.

I think you fail to have vision.

[gbutler69]

Not an insult, but, I think you're failing to see the Forest for the Trees. How about this, instead of sites needing to add Gordon (or something like it of the next-generation) to their site, if you could install an Add-On in Firefox (or other browsers) that was a Simple JS library that would replace Flash tags with SVG "Stages" and use Gordon to provide the conversion from SWF to SVG/JS/CSS/DOM/SMIL/etc. Think Greasmonkey and Gordon put together for example, but, in a better more integrated way.

Remember, this is just a prototype and proof-of-concept at this point, but, if with a little imagination, it presents a clear way forward.

Some reasons:

[Anonymous Coward]

I usually prefer to download them myself, but there are circumstances where it is advantageous to be able to view documents on websites in the browser. That way, you can use the address bar and browser toolbar like you normally would, without a new window popping up, possibly overlapping them, you can bookmark the document in case it's prone to change, you don't have to worry about storage, let it reside in your browser cache and get cleaned up automatically and for some formats you can start reading the first pages while the document is still downloading. In other words, for similar reasons you don't want to read your HTML files in an external viewer.
And there's also a software design argument to be made: the browser, that is to say the window and toolbar, should care about navigation, manage bookmarks, maintain the history and so on, but it shouldn't be its job to worry about what kind of content exactly is being displayed in the client area. Implementing a specific file format viewer is logically separate and therefore that part of the browser should be isolated and export an opaque interface to the rest of the browser. In turn the browser should just call methods on that interface and should be agnostic of whatever is actually behind the interface, be it HTML, an SVG drawing, a PDF and so on.

HTML 5 needs better authoring tools

[mangobrain]

I think this fairly conclusively proves that, when fully implemented, HTML 5 can do everything Flash can do - at least, all the useful bits. Yes, I know, this only supports old Flash versions and doesn't do audio or video, but we already know HTML 5 can do audio and video - what people never quite believed was that the various parts of HTML 5 could be combined to provide the same presentation quality and interactivity as Flash. (At least, that's the impression I always had.)

However, instead of translating Flash to HTML 5 (which is a very neat trick, I have to admit), how about producing rich authoring tools which output directly to HTML 5? Otherwise, people will just continue to create Flash, because it will continue to be easier than writing directly for the alternative.

Compare & contrast using Glade with writing GtkBuilder XML files by hand. I've tweaked Glade's output by hand before now, but I wouldn't like to start from scratch. Not quite an equivalent example, since the end result in both cases is interpreted in the same way at run-time, but you get the idea.

Does this work in Opera for anybody?

[omuls are tasty]

None of the examples work for me in Opera 10.10 under Linux. Anybody got it to work?

A little late

[design1066]

I saw this on reddit two weeks ago WTF slashdot!!!

Whats needed to kill flash, let me tell you ...

[BitZtream]

An editor that compares to the Flash Authoring tools.

Thats it.

There isn't anything special in Flash that can't be done with Batik or Opera's latest SVG implementations except sound and video, which you can handle in HTML5.

The only thing thats needed is a good authoring toolset so that graphics gimps can produce their warez without having to use notepad.

To hell with javascript

[Anonymous Coward]

When I can write a simple Javascript app, like say a form to submit a registration, and it will run the same on every browser (or even the 2-5 major versions) without hacks, then they can pry Flex/AS out of my hands. When something as fundamental as "onchange" works differently on Firefox, Chrome and IE, there's a big GD problem.

Let's just say, I won't be holding my breath on that one.

They can make all the runtime speed improvements they want, but when it takes me sometimes orders of magnitude longer to implement a JS driven app as it does a Flex app -- the choice is clear. Flex/AS has it's evils too, but at least it's a sane development environment.