Thanks I totally missed that, when did that get posted? Flash has a very important place still, and that is a great illustration of it. There was a lot of content being created in Flash that was beautiful. The video renderings just aren't the same. Old Metallicops was great, the Star Wars rap, good times..
I remember learning a lot of Flash and ActionScript using decompliers; you could see the code, assets, all sorts of fun stuff almost like view source in the web browser. Can't do that in video, thankfully we can in HTML5 but inspection of code isn't straight forward for more intense games yet.
With access to the source, it should be possible to export them to HTML5 using Adobe's flash authoring tools. I've never tried it though, and I don't know how good the HTML5 versions would be.
Edit: huh, it kinda runs with Mozilla's Flash-runtime replacement, Shumway. Another few rounds of bugfixes and we might not need any Adobe code to play these files just as they are.
The problem with most current Flash-to-HTML5 conversions is that they only barely support ActionScript, if at all. So anything meaningfully interactive (like minigames) is pretty much out.
Shumway makes it sound like "we got this" (which then discourages someone like me--someone who has a ton of knowledge of compiler design and a lot of background specifically with JavaScript-based language but almost no interest in duplicating effort, someone who would normally see this call to action and go "oh, I'll add this to my todo list"--from even spending much time researching the current space). Are you saying Shumway only "barely" supports ActionScript?
There are several such projects - swfdec, lightspark, gnash, etc. From what I've seen of them, they all underestimated the amount of effort. Most of them just petered out. So if you're going for it, I would worry less about duplicating effort and more about setting realistic goals for the project.
I wonder if we could wrap them in an OpenFL app exported to HTML5. OpenFL can render SWF content; as for the triggers for the interactive bits that might require access to the original source, alternatively it could be reproduced, it's usually just a matter of "click here to go to scene X" and the hidden scenes themselves would be extant already.
I did this for Strongbad emails years ago using some off-the-shelf flash to mp4 converter but a number of the videos had issues because they were interactive (and not just at the end but sometimes in the middle). I got the majority of them (at the time) converted so I could watch them on my iPod video. This was before I went full-on-data-hoarder and so I deleted them forever ago. Recently I tried to do it again and have all the swfs downloaded but haven't found a great way to mass convert them so I can put them in Plex (media server). If anyone has a good way to do it on linux via the command line I'd be very interested.
Shumway can be used as a runtime for those movies - the site owner just to need fallback to its HTML player. It plays common ActionScript 1/2/3 usages well.
Amazon is switching to JavaScript animated ads to support all devices. This isn't anything against Flash, this is a business decision to reach more eyeballs.
Flash is fast. JavaScript/HTML5/WebGL/etc are just recently getting close to the performance we had in Flash 10+ years ago. Flash is perceived to be slow because it was used to make obtrusive advertising, like JavaScript is used now.
The evil dictator has been replaced, with much fanfare, by a new evil dictator!
Flash's speed on desktops is not the main strike against it, although it was actually quite bad for many things (the 3d stuff worked better for it because it bypassed its aging 2d rendering engine which no-one left at Adobe understood or could fix). Flash's speed on mobile was abysmal and Adobe tried and failed to fix it for years (after Steve Jobs' famously pointed all this stuff out).
The fact that Flash would store user information separately from the browser in such a way as to circumvent security and privacy models, and did so for years after Macromedia (i.e. pre-Adobe-merger) knew about it, and that Flash had and has as many vulnerabilities as any two operating systems is simply icing on the cake.
Here's a discussion -- also from 2010 -- of Flash's abysmal 2d performance (which entailed fixing an example created explicitly to show how awesome Flash was):
Bear in mind, this is Flash's nearly 20-year-old/mature rendering engine optimized to only do minimal screen updates against a five minute hack using a canvas.
And, finally, you need Javascript anyway. Flash actually needs Javascript to even load properly (thanks to the stupid Eolas lawsuit), so it's a case of giving up one evil dictator while keeping a not-nearly-so-evil-and-much-more-useful dictator.
The hatred for flash from me is simple. On osx, almost ALL of my browser crashes had flash on the stack at the time things went belly up.
That, plus flashes uncanny ability to peg a process at 100% for seemingly just moving images about made me not a huge fan. This doesn't mean javascript isn't getting as bad or worse now that things are moving to there, but at least the javascript engines aren't as horrible as the flash runtime was. But if these javascript ads start burning cpu and draining energy from my laptop battery there will be a whole lot more sites getting added to my local firewall rules.
I didn't notice any drastic difference between the two operating systems in that regard. I had to test educational software written in Flash on a range of computer systems years ago. Adobe has always supported Apple/Windows evenly, so I'm surprised you would experience a difference.
Oh yes, the security was a huge problem. I absolutely do not want to go back to the land of Flash for many reasons.
Haha! The dictator reference is specifically in regards to intrusive CPU/battery-wasting Javascript ads. Which, I expect to see many more of if I ever disable adblock.
Edit: I just checked out your article and the referenced one. Chris Black responded to your issue with his code in the follow up article:
> 98% of the code optimizations from the last demo completely missed the point of purposefully redrawing the whole screen to compare performance. They were still good submissions, just not for the context of this comparison.
How does he justify erasing the background twice each update? Bear in mind each erase is the single slowest operation in the loop, and if you scale up the complexity of an animation it will become increasingly irrelevant.
Devs can keep their current flash workflows but export to non-flash targets, specifically native C++ (supports mac/win/linux, iOS/Android) and HTML5 (with canvas, DOM, or WebGL rendering). They can also use SWF-based vector animation assets, and even integrate with the Flash CC player. And it's all open source.
Flash has been "dying" for years, but if we really want it to bite the dust, we need to give people a better way to make their content that doesn't depend on a plugin.
I prefer to keep flash because it is easily blocked.
I find most flash to obnoxious/intrusive/distracting. I disable flash be default, and only enable the items I'm interested in. Also page loads are reduced, one less attack vector.
Agreed. I work for a business that provides fairly heavy RIAs, which we custom build based on customer needs on (typically) very short time frames. The applications are used by thousands of different users on massively varied combinations of OS and browser, and the flash+flex stack is the only way we can develop robust apps to the required deadlines. It's a shame but it's the way it is currently.
> 1. Tons of existing flash content people want to access
I'm not sure about that. For most of the time, there was not even a flash player for my operating system of choice and I did not miss much. Now I still have to click to enable flash content and that only happens about once a week.
> 2. Give current flash devs a reasonable alternative
HTML5 + JS are actually pretty powerful if one ignores the cruft that has been built up over the years (i.e.: stick to standards only, ignore the 90% outdated advice given in places like stackoverflow).
Earlier this year I was redoing a flash-only site for friends in HTML5 and JS: I am not a frontend guy at all, I did develop on firefox only, I stuck to html/js/css standards without any 3rd party library and when, after about 30h of development time, we tested across platforms it just worked.
> Flash has been "dying" for years, but if we really want it to bite the dust, we need to give people a better way to make their content that doesn't depend on a plugin.
Do we? Maybe people should reconsider whether their content really requires flash. The technology is there, flash devs will just have to move on and learn something new.
I've successfully used haxe + openfl in a school project and I'm happy to say I got 100%.
There are a few issues with the project but those are due to the project being my first video game.
I think more open-source Flash players would be the best. The problems stem from Adobe's implementation, not the SWF format itself; I think the latter is actually very well designed for its intended use cases, and if anything, attempts to replace it with HTML5/SVG/CSS/JS introduce even more inefficiency.
Media players: browsers don't have native support for H.264 over HLS or RTMP, and MPEG-Dash seems native to Chrome only. If the browsers could accept these natively, this would certainly speed flash's demise. Until then, what are the alternatives?
> Tons of existing flash content people want to access
Plus some existing flash content people need to access, such as Flex apps developed for internal use by businesses that have no intention of shelling out the cash to replace them.
The market is the people who hire those devs (ie, bank websites, video streaming sites, etc, etc, etc) and they are currently saying: "we still need flash for some things, so we're not ready to kill flash just yet."
Give THEM a reasonable alternative, and flash will go away.
In the short term, OpenFL lets you export as flash, so you can use the existing solutions for now, and in the long term, you can build whatever else you need into your native or HTML5 solution. So as soon as these features come online in HTML5 or Native, you can just switch over without having to rewrite your codebase.
TiVo is already using Haxe/OpenFL in their set top boxes and I'm sure they've worked out some video streaming solution:
Amazon is not doing this with the intention of "killing" flash.
They do this because flash ads are now no longer seen by a large enough group of users which makes them bad advertising vehicles.
Maybe at some point the Prime Music people will decide that a large enough group of users are no longer able to use their service, but that is a totally different decision with different motivations.
I've been wanting to update my existing Flash games (I've released 7 games) to something more modern, like HTML5+JS or (maybe) Unity, but I don't want to spend a ton of time learning a new stack and getting things working, as I really don't have the free time I used to.
A few of the games have heavy use of graphics and animation also, that I don't really want to have to recreate manually. I've worked on games made with Unity and Cocos2d(ios) since then, but I'm really hoping there's some shortcut I'm not aware of.
There's a ton of JS frameworks out there and it's hard to evaluate which would be worth the time and effort.
Plus I really don't want to have to do this again in the future, so hopefully this can be something I do once and I'm good for the forseeable future (which is why I'm leaning towards HTML5 + JS). Some cross-platform capabilities would be nice too.
That's as close as you get to keeping your existing workflow and maintaining your assets. It's really close IMHO and works well. Also there's some scripts that can translate As3->Haxe and take care of 95% of the work of porting the code, and then OpenFL has the same API as flash does so your API calls are all the same.
Alternatively FLUMP can be used if you just want to export assets and use a totally different framework:
http://threerings.github.io/flump/
Great! Now I'll no longer see these "Click to Play" placeholders instead of the intrusive animated ads. I'll finally be able to experience the intrusive animated ads the way they were meant to be seen.
I'm actually torn on this, because the fact is that Flash can do things that you realistically can't do any other way. In my case, I've written a couple of video conferencing apps that need web-web and web-Android connectivity, and Flash/AIR is still definitely the easiest way to do that sort of thing. WebRTC has promise, but it requires a reasonably recent browser (and not Safari), and until very recently it didn't work in WebViews on the Android side.
I tried to uninstall Flash, but my bank (Citi) uses it for their one-time credit card # applet. And, I miss a lot of videos on the internets, but I can live without those. The bank thing, I cannot. (Yeah, I complained and was told moving away is "in the works.")
I'm actually a bit conflicted about this. The nice thing about Flash-based media is that one can disable JavaScript (thus increasing one's privacy) and then enable Flash only to view a particular video (e.g. on Amazon Play); with JavaScript and HTML5, one generally has to enable JavaScript for the entire domain rather than a single video on a single page.
Why would one want to disable JavaScript in the first place? Privacy & security: why enable a site to execute random code on one's own machine when all one wants to do is read some content?
> Flash has had vulerabilities and executes arbitrary code as well... What's the difference?
It sure has! But it's nice to expose oneself to vulnerabilities only when absolutely necessary (e.g. to view a single video), rather than for every page currently loaded for a site.
> Why would one want to disable JavaScript in the first place? Privacy & security: why enable a site to execute random code on one's own machine when all one wants to do is read some content?
There are many reasons. Another is this: on most webpages (i.e. places you go to read text and maybe images and some videos; as opposed to web applications), JavaScript is an unnecessary waste of processing power, that only makes it harder for you to read in peace. It doesn't add value for user, so there's no reason to have it running in your browser.
I'm a flash dev in my 30s, never made as much money as I am making now. Flash is not dead, it's changing, it moved to embedded devices and has blazing performance results. As usual, a decade ahead of where the web is at. http://labs.adobe.com/downloads/air.html Haters gotta hate! (-__-)
My understanding is that Chrome for Flash uses Pepper (a NaCl extension) for its plugin support so its not a vector for attack. You can always turn it off from chrome:plugins.
I have Flash enabled all the time. No probs here. Smooth and efficient. I have no agenda or need to kill it.
So much viral hate. Plugins have a right to exist. You gonna declare war on all plugins or just Flash? HTML doesn't necessarily run its full suite of tricks on all browsers and platforms. And my iPad3 often slows to a crawl because of bloated well-known websites. Browser memory maxes out and I can't even switch tabs without full page reloading. Inefficiency follows poor technical design no matter what technology is used.
Is javascript next because of those trendy promo pops where they think you're leaving? Kill everything that sux, or whatever technology it comes from. Kill it all and dance on its grave like there's no tomorrow.
Tomorrow we'll retreat to our native apps with virtual coins and account validation. We'll share our contact lists without knowing that we did, and we won't be blocking ads because we can't.
Tried the Youtube HTML player once. That was one hell of a rough and buggy experience. Switched back to Flash.
Clicked a link to youtube in iOS Safari more than once, and got auto-switched to the youtube app rather than the video play in Safari. I don't know what or who to hate about that, I'm just tired.
Flash is a closed source binary plugin with a long history of security vulnerabilities that Adobe was slow to patch. For the most part, JavaScript engines are open source, don't have a history of security vulnerabilities (to the same severity), and are typically patched quickly.
You can't compare counts of published vulnerabilities when organizations have vastly different standards of publication. Open source projects (e.g. Firefox, chromium) publish everything, even internally found flaws. Closed-source projects tend to publish only those reported by external reporters, not ones they found internally. At least one hopes they are also fixing lots of internal bugs! They might not be, in which case a low vulnerability count could actually mean they've got lots of unfixed vulnerabilities.
What about attacks found in the wild? Flash takes the cake there, although that may in part mean its ubiquity makes it a useful target.
In any case you can't use Flash to browse the web. You are already taking on the risk of whatever vulnerabilities lurk in your chosen browser; using Flash is adding vulnerability risk on top.
