How would that have been worse then trying to wedge Flash where it doesn't belong?
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.
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.
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.)
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!
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 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.
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)
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 ^_^).
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.
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)
http://blog.gmarceau.qc.ca/2009/05/speed-size-and-dependabil...
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 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/).
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.
I made a blog post a few weeks ago on the matter: http://www.andresosinski.com.ar/blog_view_entry/?id=6
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?
Silverlight will get a bit bigger but it's never going to matter in the long term, any more than Java applets ever will.
http://www.readwriteweb.com/archives/does_html5_really_beat_...
http://en.wikipedia.org/wiki/Actionscript
Adobe's had a JIT Actionscript compiler for years and it's really quite fast.
Take a look at Silverlight. Its performance will surprise you, I am sure.
Some of the big sites I'm involved with are on track to hit 10% mobile use before the end of the year. And most of that is iOS.
The assumption that "most people" are windows desktop users is becoming less and less valid.
Saying HTML5 should replace Flash is like saying HTML5 should replace JPGs.
Really? Can you mention any specifics? I do not think there are any things that Flash can do that HTML5 cannot.
Have you seen Or So They Say? http://xplsv.com/prods/demos/xplsv_orsotheysay/
That doesn't mean Flash isn't overused. But its not useless either.
What do you mean Flash has DRM but HTML5 doesn't? And yes, I do consider DRM a bad thing.
Edit: Source for webcam comment: http://devworks.thinkdigit.com/Internet/Native-webcam-suppor...
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.
Here's another one - http://pattern86.com/sequencer-in-html5/ - also laggy, and it only consists of four channels.
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.
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?
"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.)
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?
Once you understand how scope works and how to force scope, and what exactly constitutes an object.. it makes quite a bit of sense.
"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.
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.
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.
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"/>)
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. :)
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.
In the meantime, Flash is all they got to go on with.
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.