Adobe is seriously doing it all wrong. They have to open-source the Flash Player and everything around it now. They can keep the IDE proprietary if that floats their boat, it's just a premium authoring tool, but the only way to save Flash is to open-source like NOW. HTML5 is still young enough that an open Flash Player and standard and protocol (RTMP) would effectively kill it.
Open-sourcing would open so many doors. Apple could modify Flash until it worked on iOS properly, Google could modify until it worked on Android. The reason this hasn't happened so far is that Adobe is a bottleneck nobody wants to deal with; they just consider basically impossible to get Flash Player on mobile because Adobe doesn't have the structure or the talent to do it correctly, and there is no other option except to let Adobe do it. An open Flash would open many doors, awesome adaptations, deployments, and uses that we can't yet think up would come out of it, and all the while Adobe would keep selling its IDE (probably selling more, actually, because Flash will then do cool stuff that everyone wants).
I don't know why they don't do this. Flash Player is already basically free, all of the money from Flash comes from the IDE Adobe sells. Keep the IDE locked up if you want, Adobe, but every second you keep the Player locked up you are killing Flash that much more, and when nobody uses Flash nobody is going to buy your IDE.
I know there are free software Flash players out there, but it's not the same. It's like saying nobody needs cooperation from nvidia because of nouveau. While a noble effort with meaningful results, vendor support still gets you much, much farther ahead.
If Adobe knows what's good for them they will be opening the Flash Player as quickly as they possibly can. They are going to be very sorry that they didn't. They probably will eventually take this route as a last-ditch effort when Flash content has dipped like 80% and been replaced by HTML5/JS, but that will be too late. This is Adobe's last chance, they must open it now if they expect any kind of future from it.
Flash is too big for Adobe alone, and if they don't want the whole thing to crash and burn totally and have that revenue dry up, they need to open ASAP. This should be the number one priority at Adobe.
You are assuming that the only thing preventing Flash from working on mobile is that it hasn't been "optimized" enough -- that opening the source to Google and Apple will unlock performance otherwise unattainable by Adobe.
But suppose Adobe's programmers are not completely incompetent? Perhaps Flash's execution model is genuinely unable to be optimized further. Or perhaps most Flash content in the wild runs at the limits of desktop performance, and that compositing vector graphics and text on top of video while running multiple VMs embedded in a webpage is just too much for a memory- and CPU-constrained device.
In that case, open-sourcing Flash would have little effect. Even if we had an optimal mobile Flash player, we'd still need everyone to rewrite their Flash movies to run well on it. That's why HTML5 has the advantage here: HTML5 content is being freshly written and tested for mobile platforms.
Rubbish! Most moderately advanced HTML5 demos run hideously, if at all, on mobile hardware.
The difference will be if HTML5 can replace 80% of Flash uses in a performant manner. The video tag makes up a huge block of that 80%. The other 20% will always run like a dog on mobile hardware, no matter the technology.
Have you watched the Apple HTML5 demos on an iPad? It's actually revolutionary to see what they can do with the limited hardware. Being able to touch and drag a 3d model around at 30 fps without stuttering? I can't even do that on a lot of PCs with Flash.
Without examining the code it's hard to jump to conclusions, was the flash version really rendering the effect pixel by pixel as I'd imagine the HTML5 one is?
I've got a quad core Win7 box with 4gb of RAM and a video card that runs Fallout3 at max settings on my 23" monitor without even noticing.
Or So They Say only advanced frames in Firefox when I moved my mouse. It actually ran for me in Chrome, but was pixelated (2x?), and still laggy (I'm guessing <24fps)
While it's cooler than anything I've ever done with javascript, I was watching more impressive demos on a Pentium 75 over a decade ago.
HTML5/Javascript/etc. appear to have a long way to go, performance-wise, before they catch up to Flash. And by the time it catches up to Flash 10, where will Flash be?
I ran two three minute tests, one in Safari and the other Firefox on a 2.8GHz C2D w/ 4GB RAM and nothing else really open.
In Safari 5.0.1 your link didn't render a single frame in three minutes.
Firefox 4b3 did render, but the animation would not normally be watchable. The opening scene ran the best, probably around 15fps while during second and third scenes the galaxies would jump about an inch with each frame. I don't know what the fps were, but it was updating the screen less than one time per second with a single core maxed out.
Also, on launch, FF was using 76MB of RAM yet after the three minute test it was using 168MB of RAM.
So your link didn't function in one browser, used 2.8GHz of processing power and ~90MB of RAM in another yet was completely unwatchable.
Well, the demo is an amazing demonstration of HTML 5, and the limitations of HTML 5...if your browser can swing it. It runs pretty great in Chrome, not so great in FF and sucks everywhere else.
What if this were a Flash demo? Only be mildy interesting -- and that's only for the presentation itself. From a technology perspective it'd be ho-hum.
I think more important than that is that it's not even interactive. Interactivity with HTML 5 apps has light years to go compared with Flash even if browser vendors can lick the performance problem.
In other words, HTML 5 as a content delivery platform has a very long way to go...and as it is is certainly not anywhere near as a cross platform as Flash is. It's just not a swap out substitution for Flash yet and forces developers to produce software that's just simply not of the same quality as Flash is able to handle.
We're talking about Google, a company who wrote their own cleanroom Java implementation and reverse-engineered ActiveX to create a ChromeFrame implementation still compatible with anything that ever worked in IE. I think they could speed things up a bit.
ActionScript is just JS plus some extra sugar. JS implementations have gotten hundreds of times faster in the last three years, while Flash has gotten slower. Slap a modern JIT on there and we should get some improvement.
A lot of what goes on in SWF files is the art data (vector graphics, the 'movieclip' object, etc). Flash comes with a pretty extensive API for manipulating graphics and these objects, all which needs to be rewritten for mobile. There's a lot there, believe me.
Unfortunately, much of that content is what causes the problem. Using the artist tools (Flash CS3), you can generate content that simply fumes memory, without writing a single line of code. I'm not sure you can even fix those issues without re-authoring the art content.
What makes this worse is that anyone can embed one of these crappy SWFs in a webpage, causing the browser to fume memory too.
> reverse-engineered ActiveX to create a ChromeFrame
Can you elaborate?
> while Flash has gotten slower. Slap a modern JIT on there and we should get some improvement.
Adobe actually contributed to Tracemonkey's JIT as one of their effort towards ECMAScript engine unification, they even planned to write a engine for WSH Active Script, but failed. IMHO Flash is laggy because of the drawing part, but in this case HTML5 is also laggy as hell. Try set font to 100 in this demo:
> JS implementations have gotten hundreds of times faster in the last three years, while Flash has gotten slower.
I don't know about that. Flash may be proprietary, poor coding community, etc, but to suggest it is creeping down to JS performance is pretty outlandish.
Flash has two communities. One: Designers trying to do timeline animation with a mix of code snippets they've found. Two: Decent coders who implement the safest, best methods.
When Flash performance is subject, it tends to be Flash's poor design that gets the bad rap even though it tends to be the poor developer community at fault. In the same way, JS-based interactive content can also be coded poorly and perform poorly as a result.
Honestly, I've seen some pretty intense, balls-to-the-wall sites that I know would absolutely work at a crawl or snail's pace in JS, but work elegantly in Flash.
A full open-source file format would be a great move for Adobe.
ActionScript is not JS plus sugar. ActionScript 3.0 adds statically-typed variables and class-based inheritance. A good compiler can use these additional constraints to produce better code -- performing more like Java than JavaScript. It's possible that the VM is not the bottleneck here.
I don't think Flash's problem is speed. It could be sped up by 10x and I don't think it would significantly matter to its market position or future prospects.
Open-sourcing would open so many doors. Apple could modify Flash until it worked on iOS properly, Google could modify until it worked on Android.
If Adobe has spent years growing the Flash player code on the principle “make it work well on Windows, and then hack it as necessary to make it work tolerably on other platforms”, then even after it is open-sourced, developing a Linux- or iOS-compatible Flash player may be more than just a Simple Matter Of Programming.
Remember the long gap between Netscape open-sourcing its browser and Mozilla becoming a usable platform.
It's not necessarily that it'd be a simple matter or wouldn't require major architectural changes or whatever, it's just that it'd be much, much more _possible_. And I fully believe that there are many, many improvements that could be made that are just a simple matter of programming, even if running on mobile devices isn't among them. Not to mention a fully open-source Flash Player would make a great reference for aspiring free Flash players like Lightspark.
If Adobe stays on the path it's on, HTML5 will continue to mature faster and faster as the desperation for a legit Flash replacement grows. Adobe could stay in the loop without having to reinvent the wheel and reacquire a distrusting and skeptical customer base if they would just open Flash while they're ahead; people would continue to buy the Flash IDE in droves, but when HTML5 takes over, that installed base is not likely to wait on Adobe and they'll move on to a competing IDE. I believe that HTML5 is still young enough that it could be basically deposed by a truly open Flash.
>Remember the long gap between Netscape open-sourcing its browser and Mozilla becoming a usable platform.
Not sure this is the best comparison. Netscape open sourced Communicator 4.0, yes, but what we know as Mozilla was a total rewrite after they decided to scrap 5.0.
EDIT:
Unless your point is that the Flash codebase may be similarly bloated. :)
Not sure how much I agree. There seems to be an intermediate step in your reasoning that goes something like: "FOSS fixes everything". Sometimes it's true, sometimes it isn't.
Why would Apple spend a lot of money and man-hours to port Flash for the iOS? Is not like the lack of Flash seems to be bothering anyone much (in terms of units sold). And Google actually did help Adobe to port Flash to Android, and it seems (from this article) that the job is not that good.
Maybe Flash would need a massive internal change for it to reach the speed it deserves: sometimes it's better to simply start from scratch. Also it's still not obvious to me that Flash is the right technology for the mobile/touch-screen Web.
I don't think the point is "FOSS fixes everything".
I think the point in this case is, "go FOSS and you've got a shot. Stick with the status quo and your death is assured".
I think the poster has a point. Maintaining a monopoly on the tools to create media in a certain format isn't going to amount to much if everyone ditches the format. Flash is already becoming a four-letter word. I don't see what Adobe can do on their own to change the direction Flash is headed.
Why would mobile OS companies devote resources to improving Flash when they're already working on Canvas, WebGL etc... They'll still have to make Canvas as fast as they make Flash.
Flash was supposed to be canvas, but Macromedia/Adobe chose not to join the standards process, so browser makers just rolled their own. After all the effort on canvas, they'll just drop it all and replace it with Flash or work on both?
It just seems impractical. I don't think Google is interested in Flash beyond integrating it with NativeClient. Maybe they could improve it, they may have more engineering talent, but these are ultimately strategic decisions, not technical ones.
As far as other companies besides Google, MS and Apple, why would they commit themselves to Flash when Canvas is already open source, can be improved, etc..?
I think Adobe is screwed with their current plugin either way. Their path of piling on features, ensuring perfect integration with authoring tools seems more reasonable. That's where their focus should be. They won't lose much if they lose the plugin, it's not a big deal if they could do the same things the plugin does through JS eventually.
The plugin is just an insurance policy and if NativeClient becomes a standard they won't have to worry about penetration when they come up with a better plugin eventually.
I think this goes 180 degrees in the wrong direction.
Based on what I've heard, the real reason anyone uses flash anymore is because of the authoring tools, not the runtime.
Instead of open-sourcing the flash player, build a development/authoring tool for HTML5 of equal or higher quality than the Adobe tools and open-source that...then watch this debate become irrelevant a year from now...
I agree that an equivalent IDE for HTML5 would be huge for HTML5. I don't think HTML5 has a chance of mainstream adoption until it gets one and I hope it does get one. I don't necessarily want Flash to win out, or think HTML5 should suffer, I'm just saying that the only way Adobe will keep Flash alive is open-source.
This is a great idea, but I think Adobe might not want to open source it because they have sold Flash to content companies as a way to lock their streaming content down with DRM. Opening the specs and allowing anyone to play DRM content would let the "evil pirates" get their hands on all that sweet, sweet booty. By booty I mean streaming episodes of Hulu...
The benefit from preventing the death of the Flash format is greater than the benefit from not pissing media companies off, first of all. Secondly, as stated, the DRM components should be possible to open if they're properly implemented. There are many open implementations of PGP et al that are open and PGP hasn't lost anything from that.
If their DRM is hacky/not good, then yes, open-sourcing would probably be bad for that component. But DRM is a rather small part of the overall Flash ecosystem, and if they don't get the Player completely open, they are going to lose meaningful revenue from Flash completely relatively soon.
its already far far too late for adobe, if they had open sourced 10 years ago, there wouldnt be a html5 video and canvas, flash would be the standard.
open sourcing it now will help them stay relevant for longer but it will be a band aid, proprietary tools will be replaced by web standards on the internet thats more obvious now than it ever was. flash can innovate by raising the limit on what you can do, but there is a roof on that functionality the gap between it and where web standards are now is getting smaller and smaller.
I think the window is closing but if they can pull it off (a BIG if), they have a chance at being the only cross platform runtime that works across a majority of phone platforms (I'm assuming they will get on WP7, and that they get Air onto all the existing platforms that already support flash via updates). If they do, its hard for me to see how a lot of developers won't be doing Flash + iPhone versions of their apps first and only then native implementations. I'm not particularly looking forward to this, but it just seems obvious.
I may be wrong, but I think Adobe 10 years ago was pushing for things like html5 video and canvas... because Flash was Macromedia's. It was a case of: the enemy of my enemy is my friend. (They were also one of the first big companies to push SVG from what I remember).
heh not the first time I have made that mistake, when I say "they" I mean macromedia / whoever happened to be in charge of flash at the time of whatever incidence we are talking about.
But I am not sure Flash was really comparable to what it is today back in the days of Macromedia. Did we have Youtube and company back then? My gut feeling is that Adobe there went from "the enemy of my enemy is my friend" to "hey, wait a minute: we could actually BUY it, and CONTROL it".
Adobe bought Macromedia and suddenly Flash was great and amazing and they integrated it with the rest of the their portfolio.
The question I am trying to put is: back in the days of Macromedia, do you think they would have clanged on Flash on mobile like they life depended on it?
(this is not a rhetorical question, btw, I am really wondering: I didn't follow Adobe and Macromedia much in those days)
I only ever seen the flash progression in those times from peeking over the wall at the other side so people might be able to correct me, but I dont think the adobe acquisition did flash a whole lot of favours, it managed to get its 98% etc penetration well before adobe was ever around.
Back in those days flash vs html for plain websites was a serious debate, under adobe while video has got massively popular, flash has been further and further marginalised as a tool almost only for games, adverts and video.
I certainly couldnt see macromedia open sourcing flash any more than I could see adobe doing it without this pressure, if anything I think macromedia were even more aggressive with shutting down alternative players, at that time they were competing with html which broke in every browser, they wanted to make certain it was write once run everywhere.
To be honest I am entirely biased, but its always seemed obvious to me that open web standards will very very slowly replace virtually everything proprietary on the web. right now there is not one decent web publishing tool and I am pretty stunned that adobe havent stepped up to produce one yet (dreamweaver does not count, and neither does flash exporting canvas). Heres hoping whoever does makes sure it works on linux :)
Could an alternate approach be to take the route that Dalvik did?
There's also a research paper about having a remote proxy to deal with Flash on mobile devices; it's something like a VNC viewer, but for Flash. That wouldn't violate any patents now, would it?
Flash player gives Adobe a lot of power and keeps their not so good dev/design tooos safe from competition. From what I've seen the current strategy is to try to add features not available in HTML5, like P2P. That would allow youtube and company to roll out torrent-based players and save hugely on bandwidth.
Why couldn't you implement P2P in JavaScript? You'd have to work around browser sandboxing that prevents access to the disk, but you can do that by installing as an extension. I think a JS-based torrent client is reasonable.
"New features" is not a good answer; it might stave things off a bit longer, but the real problem in Flash is that Adobe is choking it to death and only really provides first-class support on Windows.
Only recently have they started taking even the Mac platform seriously, probably trying to prove to Apple that they should be included in the iOS devices. Support is still a complete mess on Linux (the basis of Android and countless other platforms and most new platforms, meaning that any day now a Linux-based platform could be the new hotness, supplanting the iPhone, and then we'll have to go through this whole song and dance again with Adobe pretending to take Linux seriously to try and trick people into letting Flash run on that platform with its 40% penetration), and their penguin.swf blog has nothing but excuses; sure, video on Linux may be less straightforward than video on Windows (because there is actual competition and you have to make a choice instead of taking whatever Microsoft decrees), but lots of people with far fewer resources have been able to deal with it, there's no reason Adobe can't.
That's the thing. Jobs says Flash has had its day because a few years ago Apple was the underdog that wasn't worth supporting. When Apple tried to work with Adobe, they were neglected and left to rot for "higher profile" projects. And now that Jobs and Apple have some real power, 10.1 magically gets filled with Mac-related fixes that should have been in at least half a decade earlier. And Jobs isn't buying it; in his mind, Adobe (correctly) is still the flippant and unresponsive bully who doesn't care about you until your market cap exceeds Microsoft's.
Nobody sane is going to hitch their star to Flash while Adobe lords over it. I understand, as do most of Adobe's recent customers, that Adobe is run by staunch old men who just don't get it, but someone really needs to help them get it, for the good of the web and the good of their company.
I doubt P2P could be used reliably for video streaming. There's a quality of service component of video streaming that P2P solutions can't currently provide effectively in the context of embedded web video streaming. Besides, YouTube probably doesn't cost very much bandwidth-wise. Google has dozens of datacenters placed at or near key peering locations where they can negotiate very low or zero tariff interconnects with major IP networks. At work on a Time-Warner fiber connection, I am 2 hops from Google's network.
Agreed. The main reason why it wouldn't work is that existing broadband deployments are not designed for P2P. Your neighborhood might have a gigabit of downstream bandwidth on fiber from the cable company but the upstream is limited to something like 100 megabits for the entire neighborhood. It sounds nice in theory to cut bandwidth costs, but somehow I don't think the cable companies are going to be too happy with you sharing their limited upstream with your traffic. They'd much rather deliver lots of streaming content downstream, which is what their network is designed for in the first place.
I hope that P2P finds more mainstream uses so that customers start demanding better upload speeds and Comcast et al are forced to oblige. The upload speeds are really a bummer in the US.
Octoshape has had some successful deployments recently, although I suspect they only offload some of the bandwidth from the CDN. Also, Google isn't the only game in town; P2P offers the promise that you could cheaply deliver video to large audiences without having to pay Akamai or give up control to Google.
Maybe I'm wrong on this, but I always thought that Adobe can't open source flash because of intellectual property conflicts. Or is that just an excuse?
Shelving the question of Adobe's strategy or competence for a moment, I think this review is indicative of Apple's competitive advantage.
Assuming Adobe had infinite time and resources, could they make Flash run well for all content on every mobile device? Of course not, they are hamstrung from legacy support as well as variances in hardware and software stacks they have to deal with. But just like Microsoft they are beholden to their legacy software and deploy base.
Meanwhile when Apple decides to go mobile they start from scratch. They design the hardware, the software, using open technologies where appropriate, but rolling their own closed-source secret sauce. Then they play hardball with Adobe and any other potential heavyweight partners because they own the entire product stack from design to retail. If some low-level tester finds a choppy video on a prototype iPhone, it takes about 5 minutes to escalate the issue to the people who can fix it directly. Meanwhile, if there are hardware problems with Flash, Adobe has to go talk to whoknowswhat podunk handset manufacturer and hope that they listen.
Looking at this way it's basically impossible for Adobe to craft a consumer experience like Apple. Microsoft has a similar problem. Pure SaaS helps with the legacy problem, thus making it possible for pure software companies like Google and Facebook to at least iterate quickly.
It's equally impossible for Apple to craft a consumer experience with as wide a reach as Adobe or Microsoft. Apple is not going to get more than 30% market share with their present strategy.
MS/Adobe are unlikely to fall below 60% (especially since this is not a zero-sum game.)
Whether Apple can achieve greater than 30% market share is debatable, not as equally impossible as it is for Adobe to ensure the level of compatibility and legacy support for Flash, and ultimately irrelevant.
Adobe can maintain at least 60% market share - on PC's (Mac + Windows). But they cannot achieve that on mobile devices.
You're ignoring the iPod, the iPhone and the iPad. I might agree that they can't hold onto the huge marketshare numbers they start with as the copycats move in and undercut them, but so what? Then they just go and revolutionize some other market.
I would give anything for someone to explain to me why the right move for Adobe wasn't to simply accept HTML5, pivot from Flash to making killer HTML5 authoring tools, and maybe even provide a way for people to take their existing Flash projects and repurpose them to HTML5?
How would that have been worse then trying to wedge Flash where it doesn't belong?
Migrating to open standards is the right thing for Adobe to do, but that's not how Adobe likes to do business.
Adobe is lazy. If there's a problem with their software, they'll blame it on somebody else, because talk is cheap. If that doesn't work, they'll wait until the last possible moment to actually put in the time and effort to improve their code. It's a pattern that is most evident with their Mac software:
CS5 (released April 2010) was the first version of the suite that was fully Mac OS X native. (Mac OS X was released March 2001). Prior to CS5, they were still using the Mac OS 9 GUI APIs, which, though they weren't officially totally deprecated until June 2007, were obviously always just a transitional compatibility environment. Even prior to the official deprecation of the Carbon UI APIs, Adobe had plenty of reasons to port to Cocoa. Number one was to provide a truly OS X native look-and-feel, which is pretty much impossible to emulate via Carbon.
Adobe's approach to dealing with Flash performance on OS X has been similar. When people complained that video playback was unreasonably slow (ie eating up 5x the CPU time that a standalone player would use), they blamed Apple for not providing them with direct low-level access to the video decoding hardware. When Apple called their bluff and gave them exactly what they asked for, Adobe released a flash player that used those APIs but wasn't noticeably faster for anybody, and introduced several new glitches that made it a step backwards for everybody who's Mac predates the NVidia 9400M chipset.
On the Windows side of things, Adobe's PDF reader has been such a long-standing resource hog that third-party PDF readers have garnered significant market share in spite of their lack of support for most of the recent advanced features of PDF. If Adobe would take better care of their PDF implementation, it would be good for the progress of the format overall.
Further back, Adobe kept their font format (PostScript Type 1) proprietary and expensive so long that Apple had to create TrueType, and Apple ended up licensing it to Microsoft. Several years later, Adobe abandoned Type 1 in favor of co-developing a TrueType-based successor (OpenType) that is finally re-unifying the font market.
Adobe seems to think they're playing it safe by being the last rat off each sinking ship, but one of these days, they'll be too slow.
CS5 (released April 2010) was the first version of the suite that was fully Mac OS X native. (Mac OS X was released March 2001).
By that standard, iTunes still isn't native. Apple always positioned Carbon as a fully supported and native framework. They even promised 64-bit Carbon support in Leopard before yanking the rug out right before it shipped, which no doubt rendered a lot of work by Adobe useless. I would have preferred it if Apple had officially deprecated Carbon many years ago. But instead they kept updating it and saying it was supported; there's no reason to blame Adobe for believing them.
Of course I agree there's plenty of reason to blame Adobe for Flash being a steaming pile on anything other than Windows.
Apple said Carbon was a fully supported framework because that's what their developers needed to hear in order to switch to OS X. In reality, even Adobe was smart enough to not use Carbon for any big new projects (Lightroom uses Cocoa on OS X). By the time Apple pulled the plug on 64-bit Carbon, it was clear that the only reasons for its continued existence were Microsoft Office and Adobe CS. Apple was well on their way to having a suitable replacement for Office, and their Pro Apps suite was missing only the hole that CS fills. Neither Microsoft nor Adobe was paying Apple to keep Carbon alive, and Adobe in particular was setting new records for unimportance to Apple because Apple was too busy taking over the consumer market with their Intel machines to really care much about pro tools. (Apple would have had to worry about Microsoft not following them to new APIs if not for the facts that Office doesn't need to go 64-bit, and Microsoft needs to keep Office on the Mac in order to prevent open file formats from catching on.) Adobe wouldn't let Carbon go quietly, so they forced Apple to play the bad guy in killing Carbon.
When Apple has moved on to a new technology, support for the legacy technology has generally lasted about 5 years. If they wanted the more demanding apps off of it, it made sense to close the door to 64 bit. Apple has put considerable effort into optimizing the OS. It didn't make sense to do that for legacy support. Apple certainly does care about pro apps, and has done many things that can/do enhance apps developed for current technology.
Photoshop showcased the Mac as a performance platform for some time Previous to OS X. I think they played hardball with Apple, trying to bully them into using costly Display Postscript licensing for OS X, and lost.
At one point Adobe engineers would interviewed by MacWeek magazine and talked about development. Sometimes managers forced them to do Windows code first because they hated it so much. They described it as working in a sewer. The Mac was far more advanced below the surface of the OS. Color matching support evolved far earlier. Simple things like anti-aliasing an image when scaling it had to be reinvented in every Windows app, but it was an included service of the Mac OS. Clearly the engineers loved Apple even pre OS X. It's too bad that Adobe trying to strong-arm control of a key technology in OS X placed some distance between the companies. The Mac market and In retrospect Apple did the right thing avoiding the proprietary lock. Going with more open standards, and sharing some things they develop has been good for most of us. (except those wanting proprietary lock in)
The sad story is that Apple could deprecate Carbon all they want, but if Adobe, Microsoft, Quark and friends kept using it, Apple would need to oblige. Apple had no power, and these companies were basically "too big to fail" so to speak.
It's also not the first time Apple got bitten by this problem (although to be honest given the number of massive changes they carried in the last 10 years or so, they kind of were asking for it ^_^).
> Adobe's PDF reader has been such a long-standing resource hog
It makes me feel old to remember a time when Adobe reader didn't suck.
The great PDF support in OSX is one of the things that's most jarring to lose when I use a Windows machine. It's incredible that you have to download a third-party utility just to view PDF files on Windows properly, and none of the options even comes close to Preview on the Mac. In fact, the only aspect of working with PDF files that does suck on the Mac is Adobe Acrobat itself.
I remember Acrobat Reader not sucking up to about version 5 (PDF 1.4, circa 2001). Perhaps not too coincidentally, this is about the level of feature support that most non-Adobe readers have.
Only twice in the past year have I encountered a PDF that didn't work in Preview.app. The first was a PDF of my own creation: I was using LaTeX Beamer as an alternative to PowerPoint, and I embedded a 3d model in the presentation. The other file was a two page brochure where the two pages were individual attachments to an otherwise content-less document. (This was stupid enough that I think we can probably blame it on authoring tools making it too easy to use the fancy features and too hard to do the right thing, ie. concatenating the two documents.)
Imho the moral with Adobe/Acrobat and other such cases (eg. Microsoft/IE) is that when a company starts piling up features on their winning horse to take over _other_ fields, they may very well win that battle, but in the long run they'll have such a bloated messy piece of software that they will lose the war.
There is also a certain irony in that Adobe and friends dragging their feet in supporting Cocoa and Apple's latest stuff, was one of the reason why Apple waited so long to drop Cocoa... and now is so allergic to devolve any control of their platform, including to Flash/Adobe. :)
(note: I am not saying this is the _only_ reason, and I am happy to accept there are other reasons. But this definitely didn't help).
Of course porting to Intel first, and to Cocoa later costs a lot of money and men-hours for what is no appreciable difference to the end user (unless they are geeks and therefore know what goes on under the hood). So I don't completely blame them for that: Apple seems to be in a transition every other year!
As for Flash GPU acceleration, the fact that Flash performed so much worse than VLC seemed to already show Adobe wasn't being completely honest. Surely if VLC can, a company like Adobe should have no problem!
HTML5 is cool but it's not the end-all. You have a whole set of new issues to deal with when you use HTML5. You have to worry about cross-browser compatibility and specific rendering bugs, whereas Flash authors don't. You have to rely on the slow JavaScript VMs included in even the fastest browsers (even the "fast" JS VMs are still rather slow), and then you have IE, which is still used by > 50% of internet users, of which much is IE 6 or 7, which are outdated and _extremely_ slow. You have audio synchronization issues. There is no ready-made IDE like Adobe's Flash IDE, meaning HTML5 development is much harder for many people. There are other issues too.
The fact is that HTML5 is not a reasonable general replacement for Flash. If you want your thing to work for most people, you are going to have to write in Flash anyway. Realistically, only a relative handful of people could run a HTML5/JavaScript program at Flash-equivalent speeds. And that assumes that you just want something in Flash that HTML5 could do; there's still RTMP and significant swaths of other stuff that Flash does and HTML5 doesn't.
This doesn't answer the question of why Adobe doesn't do that, it lists the things that Adobe could step up to do. Yes, we know there is no ready-made IDE like Adobe's Flash IDE: fixing this problem is something Adobe can do, by providing a ready made HTML5 IDE. Why isn't Adobe doing that and leading the charge? There are distinct problems with HTML5 replacing Flash, and Adobe is in a unique position to partner, consult, contract, and contribute to that. For example, if everyone else's javascript VMs are crap and Adobe's Flash interpreter (which is close to javascript, isn't it?) is awesome, then Adobe can help contribute rather than taking a beating from industry leaders (Jobs) and be part of the solution rather than be viewed as part of the problem.
I think the answer is a common one in free markets: cost.
Adobe would need to invest a _lot_ to make a good HTML5 IDE, and what would they get then? At best they'd be in the same situation as they were before just with HTML5 instead of Flash, and on top of that they would have lost control of the platform.
So the bean counters find this kind of proposition difficult to swallow. And if you say: but what if someone else did? Then they'll reply: well, then make sure Flash kills anything HTML5 related, and that's how they end up putting a lot of money to preserve the status quo, instead of using their baskets full of gold to make them run faster.
Compared to C, Java, OCaml, and so forth, perhaps.
Compared to Ruby, Python, and PHP - not so much. (take a look at the v8 entry. and this is from '09 - v8 has seen some performance improvements since then)
None of those comparisons really matter in this discussion, except Java, which is clearly out of the competition anyway. Why? Because unless you're suddenly running Ruby, Python, PHP, C or OCaml as a client-side script embedded in your browser, you're comparing apples to oranges.
It would be interesting, though, if someone could point me (and everyone else) to a reasonable, credible comparison of HTML5+JS vs. Flash vs. Silverlight.
I've been playing with Silverlight and am very well impressed.
It is much faster than Flash (my tests where the RSA encryption algorithm), has a way more comprehensive library (specially for data manipulation) and "looks" way more secure than Flash (please take this last one with a grain of salt).
Its acceptance is still lagging (I estimate something like 50%-60%), but growing fast. MS promised the new Windows 7 phone with Silverlight on it for September. It might increase acceptance.
From what I see HTML 5 adds a lot of interesting new gadgets and features (like websockets and video streaming). It is a great innovation, but is not for complex Rich Internet Applications.
I'd expect, for the next 5 years, Silverlight to become the platform of choice for RIA (mostly CRUD applications), HTML5 for video streaming and some simpler games and Flash critically sandwiched between both.
Are you insane? I've had to develop a CRUD application in Silverlight, and it was dauntingly slow in comparison to Ruby and Python frameworks, and the tooling is still behind the rest of the C# frameworks.
1) in most of your post you argue against the performance of VS2010 and how slow it is to edit XAML, not the performance of your Silverlight code/application. I take that it was as good as mine. And I think that this is what is being discussed here.
2) I agree that VS2010 is indeed much slower than previous versions, although I didn't experience something as terrible as you. But I am running it in a 3GHz quad-core with 4Gb of RAM, so...
3) Silverlight is a WEB client solution and that's the scope of this discussion and the post I answered. Correct me if I'm wrong, but I think frameworks like Django and Rails are server-side technologies and, as such, don't compare to Flash and HTML5, and are out of scope for this discussion, right?
Partially so. However much Silverlight might fill a niche for rich media, the fact is that 99% of the use cases will be for internal business applications, where it fails spectacularly. And in the case of ubiquitous media apps, it's simple: Siverlight is not nor will it ever be ubiquitous.
IMO the fact that Silverlight hasn't been canned is just another point that shows that MS doesn't get it. When they saw where HTML5 was going they should have jumped on board with both feet. It's too late to force everyone to use their OS at this point so they should have been focused on being compatible with everyone but simply running better.
Silverlight will get a bit bigger but it's never going to matter in the long term, any more than Java applets ever will.
The cynic in me thinks that MS thought that rather than spending energy to "get it" and maybe failing, they could back all horses and see who would win. They usual strategy (and Google's current m.o. sadly).
Why is java clearly out of the competition anyway?
I think this is a remnant from a time long gone, where applets were much worse than they are now. They have worse user experience than flash, but the difference isn't really that big anymore (e.g. http://www.pulpgames.net/milpa/).
AS3 is fast as the language, but developers can make too CPU intensive animations there too. Moreover AS2 in which a lot of ads are still made is awful slow. And you can't control which ads (and the quality of the implementation) will be served when you're on some site -- therefore on weaker processors most of the sites which present the flash ads are amazingly hard to use -- you just experience lockups all the time.
If you can show me how to make audiotool.com or even something like captainforever.com in HTML5 I think I'll begin to see where you're coming from, but there are plenty of things Flash does that HTML5 does not. To flip the switch from Flash 10 to HTML5 would be cutting off a lot of functionality.
Saying HTML5 should replace Flash is like saying HTML5 should replace JPGs.
Webcams? No, HTML5 will probably have support for that. "Advanced audio stuff"?! What do you mean? JavaScript (with HTML5) is a full programming language totally capable of "advanced audio stuff", whatever that means.
What do you mean Flash has DRM but HTML5 doesn't? And yes, I do consider DRM a bad thing.
The audio capabilities of HTML5 suck. They're not going to get better for a while, and in the time it takes them to catch up, Flash will have continued to build on their well established foundations.
Okay, looking at HTML5 drum machines via Google. Here. Here's an one, http://www.randomthink.net/labs/html5drums/ - it's got all the basic trimmings, but the playback has tempo fluctuations, and the whole thing is slow. And this is a drum machine running all by itself. Compare that to audiotool.com, and tell me that HTML5 can do what AudioTool does.
Keep in mind, I'm not trashing the efforts of the folks who made these, kudos to them! But compare that to something like this http://audiotool.com/app/dubtexno/1 -- HTML5 cannot do that. Sure, it will be able to in a few years. And surely, Flash will be able to do new things in a few years, too.
This doesn't even address the lack of a (for want of a better term) unified developing environment for HTML/JS/Canvas/Audio a la Flash CSwhatever.
What on earth are you talking about? You're comparing HTML5 today to Flash with their maturity? I would bloody well hope Flash is still faster.
The reason HTML5 is the future is it doesn't have the Adobe bottleneck. Is sound bad right now? Then browser makers can fix it. Is Flash a CPU hog? Wait until Adobe cares enough and has enough resources to fix it. Get it?
I don't think anyone is saying that. I think people are saying it's a better idea to invest in HTML5 today. And with that I would absolutely agree. Flash has jumped the shark.
I don't think it's fair to compare Flash 10.1 to a future revision of HTML5, because by that time Flash 11 will probably have more features that HTML5 doesn't.
"Media protected using the upcoming Adobe Flash Access 2.0 SDK can be played back securely in Flash Player 10.1 to support a wide range of business models, including video-on-demand, rental, and electronic sell-through, for streaming as well as download." http://kb2.adobe.com/cps/838/cpsid_83808.html (There's also RTMPE and SWF verification, but AFAIK those have already been broken.)
How do you synthesize/analyze audio on the waveform level with HTML5? AFAIK this is only possible with an alpha version of Firefox implementing an experimental API, not part of HTML5. Flash can do full waveform synthesis as of v10, audiotool wouldn't work without it. The only way I can imagine doing this is creating data: URI's for <audio> in Javascript containing raw OGG/WAV data, which is write-only, half-baked and seems impractical.
Adobe CS5 has some rudimentary HTML5 Canvas export capabilities, and from what I've heard, they plan to develop HTML5 as a fully-supported platform in future releases. http://www.youtube.com/watch?v=v69S22ZBBqA
The much glossed-over answer is that JavaScript and HTML just isn't a good environment for rich app development, for many reasons. One "elephant in the room" kind of issue is that JavaScript's object system is not acceptable to most programmers, and most programmers require classical OOP.
Even prototype system fanatics probably would have to admit that the current state of JavaScript doesn't work very well, with its warts like the "this" keyword behavior, and the tendency for all framework authors to role their own mutually incompatible systems.
Even Google seems to have backed off from this space recently - have you heard much mention of Chrome OS lately?
> Even Google seems to have backed off from this space recently - have you heard much mention of Chrome OS lately?
I hear about Chrome OS every single day, because I follow its development. Many hardware manufactures will be releasing Chrome OS netbooks in November / December of this year. Google doesn't generally hype things before they are available to consumers, so there's no reason to expect lots of Chrome OS discussion while it's still in development.
Google is still very hardcore about JavaScript/HTML5 development.
This is my biggest gripe about HTML5. They had the chance to really fix a lot of missteps but they made the (IMO) horrible mistake of using JavaScript as their "assembly language". Regardless of what anyone thinks about JavaScript, not everyone is going to want to program with it. Many of us will be programming in something else and compile to the base browser language.
What should have happened is that they just define a (high level) VM that we can all compile to. The browsers could have certain languages they compile to this VM language their self (e.g. JavaScribt, VBScript, etc.) and the rest of us compile to a binary file and point to that in our HTML page (e.g. <code type="vm" location="code/main.hvm"/>)
Oh dear... on paper great, but can you imagine how long it would have taken them to come to a standard? I think HTML5 is already a bit on the side of being a step too wide, but I guess we've been stuck in HTML4 (and related technologies) for so long that it was necessary. XHTML 2 was an awesome language, imho... just another case of too much meat on the fire, and so never reaching a conclusion.
Let's get a good HTML5 system now, and then we can think of adding additional scripting languages. The best is the enemy of the good. :)
>Oh dear... on paper great, but can you imagine how long it would have taken them to come to a standard?
I don't think it would have to take too long. One browser could do it and then the others could copy it. Further, the standard could be general until it's worked out more.
"The semantics of this can be tricky. At times it refers to the global object (in most places), the scope of the caller (in eval), a node in the DOM tree (when attached using an event handler HTML attribute), a newly created object (in a constructor), or some other object (if function was call()ed or apply()ed)."
The pragmatic answer is to limit its use except when absolutely required (as Google's guide suggests). The more problematic meta-problem, is that many people do think it's valuable and don't understand it and dig themselves into some subtle and insidious messes.
Avoiding something you don't understand might seem like a good idea when programming, but if it's a core part of the language you're using -- like 'this' in JavaScript -- trying to understand it and use it appropriately is actually a much better approach.
I've seen JS code that tries to avoid using 'this', and it often ends up a lot more complicated and tightly coupled than code which uses it appropriately.
The behaviour of 'this' in JavaScript is different to Java and other OO languages, but it isn't that complicated to understand.
There are some problems with HTML/Javascript but I find it reasonably good as a developer. The problems with it are all about the lack of standardized apis to native OS functions - audio, video, microphone, etc. It always seems to lag about 5 years behind the most interesting apis (eg: now I would want accelerometer apis ...)
They might be doing that in the background. I imagine that creating new tools from scratch (or heavily modifying existing ones) is a n time consuming process.
In the meantime, Flash is all they got to go on with.
Clearly they should be doing just that, if they're not already working towards that goal.
But I have rather low expectations. If Adobe's theoretical HTML5 tools are anything like Dreamweaver's WYSIWYG HTML editor or, worse, GoLive, they'll produce bloated, terrible code.
Even in current JavaScript engines, drawing with canvas is still pretty slow for the types Flash applications they'd like to promote. Maybe they'll port things in the future but it doesn't seem ready for prime-time now.
I have flash on my N1 too (froyo), but it's definitely noticeable when the webpage has flash on it -- even when it's a tiny flash ad somewhere. Scrolling the webpage becomes really choppy -- sometimes I wish I could disable all flash except for when it's used for video.
It does, but at the page level. If a page has seven flash elements, once you activate any of them it activates all of them (as the activation is of the plug-in rather than the instance). I suspect this was by design, as the thought would be "make compelling flash content and then we'll also get them with the flash ads".
uhm.. yes you can.. and i think that's the only thing to do when you want to have a decent webbrowsing and flash experience.
In the browser options you can disable plugins. You'll have to press the area of the plugin to make videos and games work, then. Disables all those flash ads, though.
This person's experience is completely the opposite of what I've seen on my own N1, though to be honest I don't watch many flash videos on my phone.
Strongbad episodes and casual flash games run perfectly.
The small amount of video I have tried seems fine - Youtube via the inline flash player (not launching the separate application) and flash player video porn.
The argument that Jobs was right because flash video sucks on a phone seems silly - weren't we suspecting that flash games were what Apple were trying to keep off their ecosystem?
Seems to me that there are really two points to be made here:
1) Flash as it is currently implemented is for the desktop.
2) Flash for mobile (10.1) should really be called FlashMobile 1.0 and will need a lot more time and development to give mobile users an optimal experience. This will also require Flash developers to code for mobile.
With regards to 1) It is extremely powerful and can create sites/services/applications/designs that cannot be viewed on a mobile device. This aspect does not negate its value. And with regards to 2) that's no different from many websites you visit in a mobile browser and they are not optimized. Just try visiting HN on an iphone. Brutal! But load it up through Google's mobilizer (http://google.com/gwt/x=) and it becomes actually manageable.
So now, who is to blame? Adobe? Nah. They just need more time to advance the mobile Flash code. The Developers? Nah. They just needed Adobe to come out with a decent mobile flash platform and now will need more time to optimize for it.
What is really to blame? Impatience. People see shiny "smart" phones and think they should do absolutely everything right out of the box just like their 17" laptop does. These things will come in time.
(ahem, that said, I've no issues with all the flash sites that work beautifully on my netbook... that cost half what an iPad does).
Have to strongly disagree here. Flash on my Nexus One works brilliantly. I use it to watch videos and play games frequently and without issue. It hasn’t crashed on me once. Flash is set to load on demand when I request it and otherwise it stays out of my way. In my opinion it proves Jobs dead wrong.
Is Flash the FUTURE of the web? Of course not. But it is the here and now. And by not having it available you will miss out on a lot of current content... and will for awhile yet.
Let's assume that you are just one case and not "the world". Sure, you could say the same about the original article, and I would totally agree with you.
But here it's the bottom line: if it works fine with 50% of the people, that's still not good for anyone who's not a geek (and maybe not for them either). Even 80% is not good enough. 95% is more like it, but probably it would still be too significant. I think you'd need something above 95% of cases to win your argument.
What I am trying to say, is that finding one guy for whom Flash doesn't work is a lot worse than how good it is to find one for whom it works.
I ran the "Man in Blue" tests: http://www.themaninblue.com/writing/perspective/2010/03/22/
on my N1 running Flash 10.1 in the default (webkit-based, I assume) browser and was surprised at how much faster Flash was than the HTML or canvas tests:
HTML: 6.5 fps
Canvas: 13.2 fps
SVG: blank page?
Flash: 25.3 fps
For reference, my eeePC 901 only managed 34 fps in the Flash demo (Chrome 6, Flash 10.1)
N1 running demo with 500 particles and shadows:
Canvas: 2.7 fps
Flash: 17.4 fps
"But much worse was that, even when these titles loaded, there was no way to control most of the action. Most games required keyboard or mouse actions I simply could not perform on my phone, even with its QWERTY slider. One shooter wanted me to hit the CTRL key to fire; another asked for the left mouse button."
Is this guy serious? He goes to play a game that was clearly built for a computer and blames Flash because it's not playable on his phone that doesn't have a keyboard?
Well, the usual argument of those crying about the lack of Flash on iPhone/iPod touch/iPad was that there are millions of Flash games which are unplayable. Nobody bothered to mention, what portion of those millions would actually work with touch interface.
a) his phone has a keyboard... it just doesn't have a full keyboard with CTRL key and everything;
b) _that_ is exactly his point. That most games, and most content was built on Flash with the "PC" as the target system. Quote: "Flash was designed for PCs using mice, not for touch screens using fingers." Hence even though Flash may have been ported to mobile phones now, most of its apps won't, because the developers were always thinking of Flash as running on a PC ('cause that's what it did).
That's like saying that after the java run time has been ported to your mobile phone that you can't run open office on it because it was designed for a desktop. Of course it won't work, it never was meant to. But now that it is available the authors of the software will start to receive feedback from their users and will be able to fix those issues. It starts with platform availability, up to that point you can't do much.
Remember that the original supporters of Flash argued that you needed to have Flash to support all those applications that are _already_ available. This shows that actually they are not that available after all, they need to be modified, and maybe heavily.
We are also not talking of small tweaks. If your program was created assuming a mouse pointer and a keyboard, the whole interface is wrong for a touchscreen. The amount of change to your code may very well be massive.
Well, I don't know about the content of this article, but I'm glad it alerted me to the availability of flash. I just installed it, and while it's not ideal, it's adequate for practicing Chinese on skritter, which is exciting.
We haven't optimized Skritter for Flash at all yet except to quickly scrunch down the layout. We just got a phone to play with, so we'll see how much better we can make it. I was blown away by the framerates one tester was getting--this is a Flash app that's too much for some netbooks, and here it is running fine on Android without any optimization.
The one thing that we'll have to figure out is how to improve the finger tracking, if we even can--its default state is too slow to start recognizing the strokes you're writing.
I can't speak to its video performance, but Flash 10.1 for mobile is even better than I expected for rich apps.
Do the videos need to be optimized for mobile because of API incompatibilities, or just to make up for dearer machine resources (CPU, RAM, network etc.) available on mobile? If the latter, wouldn't it presumably be just as possible to make HTML apps that don't work on mobile for the same reasons?
Ditto for the game control issue - if someone makes an game that's designed for keyboard control (or a site dependent on "hover"), it won't work well on mobile whether it's implemented in HTML, Flash, or whatever else, right?
Most phones only have hardware H.264 playback, but flash supports many other formats as well via software rendering. My bet is that it was forced to use software rendering on some videos.
Yes, that's the point. The author is saying that if you have to go through and convert your existing Flash content to work on a mobile device, why not go the full distance and convert it to HTML5?
But that's begging the question - there's still no reason to do that unless you already think Flash is a dead end, the future is HTML uber alles, etc. Which this guy apparently didn't, since at beginning of his article he writes, "I’m the last person on earth who wanted to believe Steve Jobs when he told Walt Mossberg at D8 that “Flash has had its day.” I took it as nothing more than showmanship ... " until he tried 10.1 on Android.
No, this guy thought that 10.1 on Android would mean that desktop content could be seamlessly consumed on a mobile device, thus invalidating most of Steve's complaints. I don't think that he believed that Flash was "better" than HTML5.
"So it will still work on IE" is going to be a pretty common response for that question for the foreseeable future. Right now when you go the HTML 5 right you still need to fall back to Flash.
For a VOD, streaming video, you don't just slap up one video file and be done with it.
You must have multiple versions of the same file, but encoded for the playback device's characteristics (fps, screensize, bandwidth).
It is not uncommon to have at least 3 encoded versions of a particular movie/video. (low, med., high quality)
Flash can perform a bandwidth test prior to playing a video, to determine which file to load. However, if there is only one file, it cannot transcode on the fly to a lower bitrate/resolution.
The author of the article stated it worked fine on certain sites, but others were choppy. So, it is not on the client side, it is on the server side.
In the US, we can assume the majority of streaming video network connectivity would fall under broadband (dsl, cable, fios), cellular (gprs, 3g), and wifi (802.11b,g,n).
Depending on how the device is connected, the encoded bitrate can make a huge difference.
*Caveat: This is using h.264 (not VP6), with a Baseline profile of 3.
If you encode at the baseline level 3, you can reuse your h.264 file to play on ipods/iphones at 640x480, but with iPad, you can push it to 720p, baseline 3.1
For a blog called "the geek's geek" it sure sounds like the guy needs some technical support because many others report a completely better experience.
Also, it's a fracking mobile phone you are holding in the palm of your hand and you want it to be as powerful as a desktop experience? Reality check!
If native optimized HTML5 video plays smoothly and Flash doesn't, nobody cares that it's not fair to compare the two. The "fracking mobile phone" point is irrelevant. Either Flash plays smoothly or it dies.
In this post however he seems to be comparing mobile-optimised HTML5 video against desktop standard Flash video. My netbook won't play HD native video but it will play optimised Flash - does this mean Flash is great on my netbook and native video must suck? Both of these are unfair comparisons. (Though I accept your point that users couldn't care less :)
No. Straw man. The point is, Flash video doesn't currently work on Android unless you re-encode it. If you're going to re-encode video, you're going to move to HTML5.
It's really this simple: Flash's bid for relevance on mobile phones is only going to work if they can make desktop Flash video work reliably.
They don't even need to make the games and stuff work properly. Stipulate that they fix that. They still fail if everyone shakes off the Flash video lockin.
Exactly. It's the "No porting necessary" bit that would be appealing and would let Flash swiftly be relevant on mobile. Little porting is fine too. But anything non trivial, like changing the user interface, puts Flash on mobile on much more equal footing with HTML5, which Flash should avoid.
> Also, it's a fracking mobile phone you are holding in the palm of your hand and you want it to be as powerful as a desktop experience? Reality check!
My iPhone 3G's processor is faster than one of my laptops (that I used on a daily basis, but recently retired it due to buying a new Starling Netbook). You're damn right it better perform just as well!
Your iPhone's processor may have a larger number representing its clock, but your laptop's processor is likely much faster.
You can't compare different CPU architectures by the number of hz. Desktop (=laptop in this case) processors are out-of-order power-sucking beasts compared to the power sipping CPU in your phone and other devices.
t1=time.time(); x=[i*i for i in xrange(1000000)]; time.time()-t1
On my 2.4GHz Core 2 Duo iMac, this runs in 0.47 seconds. On my Nexus One (using the Python executable from Scripting Layer for Android), it takes around 3.8 seconds. So the N1 is around an eighth of the speed of the iMac (ignoring the C2D's second core), which is actually pretty impressive.
Keep in mind that the N1 has a 1 GHz CPU, so the OP was correct in that you can't do an apples to apples comparison when different architectures are at play.
You are correct. But I did want to mention that I'm running an old iPhone...two generations old by now. I imagine that the newer iOS and Andriod phones are indeed comparable in speed to a decent but not top-of-the-line laptop.
I see nothing wrong with assuming that your phone should be able to handle laptop-like web media functions, such as watching video and playing audio or games.
It's not only the CPU that's the problem, but swap space too. While a laptop would have swap disk, as the OS would require one, an iPad/iPhone/iPod would not, and it's limited by the memory there is. As there can be N number of flash applications running on the same web pages, it could be that you need N "flash engines" running (I don't know that for a fact - just guessing here). And because it's hidden from the main browser, it can't control it. For example the browse might be able to do some kind of limit how much javascript memory/cycles are used, but can't do for plugin like adobe's.
Just punditry on my side, but I've also tried the jailroken frash on my iPad - and while it worked fine, I clearly saw that certain games are not playable - they were made for mouse with buttons, and just does not work with fingers.
Obviously this could be changed, but what Steve is afraid, is that people might perceive this as iPhone/iPad/iPod failure, rather than flash application one just expecting a mouse, and someone trying to emulate it with "fingers".
"Also, it's a fracking mobile phone you are holding in the palm of your hand and you want it to be as powerful as a desktop experience? Reality check!"
This would be more persuasive if there weren't non-Flash video and non-Flash games for comparison that don't have the same problems.
Some of my experience with adobe 10.1 has been mixed. Some of the games on Kongregate have been very usable and cnet tv played pretty smoothly. Going on the daily show's website and watching movies showed a horrible frame rate.
I am hoping the HTML 5 will do away with much of the need for using flash. Whether they use the VP8 or the MPEG codec, I don't care. They both seem to be up to the task.
Even if Jobs is right about the technical shortcomings of flash, that doesn't change the fundamental fact. It should be YOUR choice whether you want to run flash on your phone, not his. He has no obligation to provide help to get it working, but neither should he be actively preventing even the possibility of flash (or any other software) through legal and procedural means.
I can see the argument against Flash in a mobile browser. I've tried it on my N1, and have been less than impressed with how it handles zooming, panning, focus, etc.
However, that doesn't mean that porting Flash apps to mobile apps is a bad idea. Flex is still one of the best gui frameworks I've worked with, and I'd love to use it for mobile development. Just not inside the browser.
easiest way to kill flash - to offer it, but it should be slow, buggy and crash often. then everyone will think about flash as something bad and stop using it. So Android platform actually tries to kill flash =) Not just talking about is as jobs.
There is a large risk that people will decide that the terrible experience they have with browsing (a flash-heavy site) on Android phones is because of Android, and not because of Flash ads hanging their browser.
When you tell someone "flash just doesn't work on the iPhone, because flash is crap" it may not be true. But most people seem to be perfectly content with this experience, leading to a positive impression of the phone and industry-leading satisfaction.
`When I tried going to famous Flash game sites like Newgrounds or Addicting Games, I found that, as Steve Jobs said, “Flash was designed for PCs using mice, not for touch screens using fingers.”'
This is why we at Kongregate created our mobile-optimized site that features only mobile friendly games. Of course, you can still browse the full site if you like.
I have had more success than the author. It should be important to note that Flash on a mobile device is not going to be as easy to use as it is on a PC because the device is not as easy to use as a PC. I love having Flash on my phone as it allows me to see Flash enhanced navigation, mapping sites and the occasional game.
"After spending time playing with Flash Player 10.1 on the new Droid 2, the first Android 2.2 phone to come with the player pre-installed,"
FWIW the Droid Incredible launched long before and had it. I've used it, and it's not that bad for some stuff. It's better than no Flash player at all for things like viewing restaurant sites.
Said it before and I'll say it again: the only reason people wanted full desktop Flash on mobile devices was for the video. You can also s/video/porn if you're so inclined.
It's pretty telling that the first thing this guy tried out of the box was a bunch of video sites, not popcap or farmville.
Just curious, if you are Flash app developer, are you considering moving to HTML5? Is HTML5 and JavaScript mature enough for the job? Is there a tool/utility that helps convert/migrate Flash codes to HTML5/JavaScript?
I'm a Flex/Flash dev and I've looked at HTML5 a couple of times recently. The main product I work on is a web app similar to Adobe Illustrator for customizing print products. You can draw vector shapes etc fine with HTML5 (or SVG) but fonts is another matter because of legal issues. Yes there are some open source fonts now but they are not of the same quality plus we'd have to go back and change all our old designs to use the new fonts.
The big issue for me is development time. ActionScript is compiled, our app has close to 50 classes and uses dependency injection. Right now I can't imagine doing it with JS.
If you're looking for a tool to convert Flash to HTML 5 http://smokescreen.us/ looks promising.
If the problem is one of performance, then each generation of mobile phone should close the gap on reaching an acceptable level of performance for the Flash player. Moore's law may be Adobe's friend in this case.
flash is flash, and it allows some people to make awesome stuff. (samorost mmm)
I use it for business, and the technology earns me money. I am not alone.
it's curse that it got too popular, to a degree that there are lot of people who hate it.
I don't hate flash, I like it a lot.
I hate situations when flash is used for wrong reasons.
for me it fills like microsoft. still huge, but for me it's yesterdays technology.
if i think about a new project I do not want it to be based on flash
"This content is not optimized for a mobile device", which means the entire idea of using the flash based technology on a mobile device is deeply flawed.
I actually doubt that Adobe has the competence to make high quality software, that would be required for mobile Flash (due to serious optimization that is required).
There is probably not enough engineering culture in the company for that. I also think that a proper software company cannot be located in San Francisco itself, otherwise they tend to attract programmers that are too cool/have to many outside interests to write a high quality code.
"Too many outside interests to write high quality code"?
You need to get the chip off your shoulder and distinguish between genuine passion for hacking, and escapist basement dwelling. Outside interests refresh your mind and body and give you new inspiration.
Open-sourcing would open so many doors. Apple could modify Flash until it worked on iOS properly, Google could modify until it worked on Android. The reason this hasn't happened so far is that Adobe is a bottleneck nobody wants to deal with; they just consider basically impossible to get Flash Player on mobile because Adobe doesn't have the structure or the talent to do it correctly, and there is no other option except to let Adobe do it. An open Flash would open many doors, awesome adaptations, deployments, and uses that we can't yet think up would come out of it, and all the while Adobe would keep selling its IDE (probably selling more, actually, because Flash will then do cool stuff that everyone wants).
I don't know why they don't do this. Flash Player is already basically free, all of the money from Flash comes from the IDE Adobe sells. Keep the IDE locked up if you want, Adobe, but every second you keep the Player locked up you are killing Flash that much more, and when nobody uses Flash nobody is going to buy your IDE.
I know there are free software Flash players out there, but it's not the same. It's like saying nobody needs cooperation from nvidia because of nouveau. While a noble effort with meaningful results, vendor support still gets you much, much farther ahead.
If Adobe knows what's good for them they will be opening the Flash Player as quickly as they possibly can. They are going to be very sorry that they didn't. They probably will eventually take this route as a last-ditch effort when Flash content has dipped like 80% and been replaced by HTML5/JS, but that will be too late. This is Adobe's last chance, they must open it now if they expect any kind of future from it.
Flash is too big for Adobe alone, and if they don't want the whole thing to crash and burn totally and have that revenue dry up, they need to open ASAP. This should be the number one priority at Adobe.