Unfortunately most of the real discussion will be lost in a flood of worthless HTML5 x Flash war discussions by overexcited zealots, but this is great news both for developers and users alike: not because of Flash integration itself (although it's good to have a plugin always updated), but because of the new browser plugin api being proposed. This is something that has been long overdue, and something that will benefit users as a whole in allowing a more tight control of what a plugin does, and how. Think of all the interface integration problems we currently have with plugins (any plugin), from performance problems (when a plugin can't have control over what kind of resources it actually has allocated), to input problems (should/can the plugin trap shortcuts and special keys, or the scroll bar?), to device control (who controls the volume of the sound used by the plugin?). Hopefully, these will all soon be a problem of the past, as Chrome (and others) adopt the new plugin API, and we can all move on to a more well-integrated web experience.
Again and again, we're seeing moves from Google that are far more pragmatic than those from other companies they're competing with (Apple and Mozilla most notably). By supporting h264 (the dominant video format) and Flash (by far the dominant general multimedia format on the web), they're positioning themselves to be the one-stop shop for everything web software wise. This can only end well for them.
Just so you know you can still remove flash from chrome if you want to, even though its "integrated". Just go to about:plugins and disable flash or any other plugins.
That's indeed cool. Also device change events -- that's something we've had problems for a long time... USB headphones have their own devices, so removing one in the middle of a Flash experience would kill sound (and sometimes the whole application) until it was restarted. Same with any other plugin, I'm assuming, although I haven't tested Unity/Silverlight/etc to see if they're constantly pooling the list of devices or what.
AFAIK sound wasn't part of NPAPI before and plugins had to use platform APIs, so any sound problems were Flash's fault alone. Even so, Flash is hardly the only program that behaves badly when hotplugging sound devices so you can't really fault them too much.
Speaking of Flash problems, another one I want fixed is keyboard focus handling; specifically how keyboard navigation between HTML and Flash is impossible and browser keyboard shortcuts won't work when Flash has focus. Also, finally killing the windowed/windowless mode distinction will also be great.
I haven't noticed, but I usually stick Firefox (for firebug). Using the Flash version of the animation test posted a few days ago: http://themaninblue.com/experiment/AnimationBenchmark/flash/ I get 27-29fps in Safari 4.04 and 48-50fps in Chrome 5.0 beta (maybe because it's the beta?). Firefox gets around 44fps. [older mac pro - dual dualcore 3GHz, 6GB, 10.6.2]
Emm, interesting result here on my machine (1st gen MacBook Unibody, 2.4GHz Core 2 duo, 4GB DDR3, running OS X 10.6.3):
- Safari 4 using system default Flash plugin: ~28 fps
- Chrome dev using system default Flash plugin: ~35 fps
- Firefox 3.6 using system default Flash plugin: ~46 fps
- Chrome dev using 10.1beta internal flash plugin: ~100 fps
Seems the performance improvement is pretty huge (in this test case).
It does seem that chrome's flash support is quite fast. I pull 75 fps in chrome and 65 fps on IE8 (windows 7 - Core2 Duo P9400); on my linux box, chrome's flash support definitely feels faster than in firefox.
I take that back; firefox's default plugin is significantly faster (on linux). At a much higher resolution (this test is very resolution dependent) on my Core 2 Duo 6600 running ubuntu 9.10, I get 25 fps in chrome and 30 in firefox.
This will be a great step toward fixing a bunch of the big problems with Flash (for instance, how flaky the mouse wheel is in Flex applications). We're building our product in Flex and this will hopefully help us a great deal.
It is pragmatic from Apple's perspective. They don't need it to support the most popular video content. They don't need it to sell their product. They don't want to depend on third-parties for anything they don't have to. So they omit it.
Google can't do the same with Chrome and Chrome OS, because their product is the browser. They need to support the web as-is or they stand to lose many more potential customers than Apple has over the iPhone's lack of Flash. They have no particular need or desire to omit it entirely, but it does have problems, so improving support for it is a wise choice.
Both companies have chosen the pragmatic solution for them.
From a developer's standpoint, though, I'm hoping there's a way to swap in the appropriate debug player. What would be even cooler would be if the new plugin API makes it easy to write an extension to allow swapping of plugin versions (a la Flash Switcher for FireFox).
If nothing else, it looks like they're making it easy to disable, so one could install the debug player manually, and switch between them by toggling the inbuilt-plugin enable in Chrome.
This makes a lot of sense. Since Chrome OS plans to have a readonly root partition, signed by them, they needed to tweek the plugin API a little bit to conform to their standards.
I hope the ClickToFlash chrome plugin still works. My mac runs a lot better since I have installed it: lower processor usage thus way more battery time.
If it does, it's because developers let it. If HTML5 is superior to Flash from a development standpoint, developers will still have the option of going that route with this. I believe that Google's announcement on this really only benefits end users: either way a developer goes, they're going to get a better result.
HTML5 is not superior to Flash from a development standpoint. Flash comes with a nice, integrated IDE that allows quick production of visuals and scripting. I think it'd be hard to make an argument that HTML5 development is equally assisted for most use cases.
The real question is whether developers hate Adobe/Flash/proprietary standards enough to keep promoting HTML5. I think they do for now, but unless someone comes out with a Flash-esque development environment soon, the fervor will eventually die out and people will settle for the path of least resistance, which is Flash.
You should try their IDE on a medium sized project (a Facebook.com/Odnoklassniki.ru game will do). It's no picnic.
Flash IDE has the bullet points, but TextMate/Vim/whatever can actually edit code. That is, there exist specialized workflows to solve problems Flash IDE is trying to solve, and they work better.
Adobe documentation is integrated into the IDE, but HTML5 documentation is far and wide abundant (and in my experience actually accurate and intelligible most of the time).
It's easy to whip up a quick project with Flash. But most of the life of software projects is spent in debugging and support. Good luck with that.
At the same time, browser tech will enjoy Firebug/Inspector/SpeedTracer, and specialized asset creation workflows, in many cases leading to a more professional looking (and working) result.
And yes, Adobe would do themselves good by getting on with browser tech tools, while they still have the chance.
It does not validate, but it does negate the whole "I'm forced to use Adobe stuff" point people like to spill around. That has been moot for a while and people continue to press on it.
HTML5 is not superior to Flash from a development standpoint.
daeken was saying if it is superior, then developers still have that option. They aren't choosing one or the other, as (say) Apple has with not supporting Flash at all on the iPhone/iPad platform. It's good news for everybody except the small contingent that specifically wants Flash to die out. It doesn't hurt people who choose HTML5 for other reasons (such as reaching iPhone users).
Flash comes with a nice, integrated IDE that allows
quick production of visuals and scripting. I think
it'd be hard to make an argument that HTML5 development
is equally assisted for most use cases.
It's not hard at all. I can write my HTML with any editor I like. I can see the source of any page I like. No need to buy Adobe tools or hunt for .fla.
Ugh. I hate this fallacy of composition. I think you know what he means, but it is easy to be the teacher's pet with a shiny apple of misinformation.
Making complex animations (not a sliding nav, for example) is not easy in HTML5+JS. Sorry, it isn't. We can have this argument forever, have yet to see someone produce the evidence of their accusations.
Flash IDE, with all of it's flaws, trumps any "HTML editor" for animation or UX complexity. Sorry, that's just the way it is. No "Visual jQuery" exists.
Making complex animations are not easy in Flash either. Unless Flash can draw thing for you, can it?
As for basic tweening, you do not need HTML and JS for that.
Now you can have CSS transforms, transitions and animation. Those are extremely easy to use and while they are not enough for really complex stuff they can and will replace most of the basic effect flash has been overused for.
It's extremely clear that you have not developed in Flash. Flash isn't an extension of the CSI interface, so no, it doesn't do anything "for you". Please, don't wax your "knowledge" as fact. You know exactly what I mean.
I do agree that Flash is used when it is not necessary.
However, on the flip of the same token there are those who would have you believe that you should use JS when Flash is a clearly better choice.
"teacher's pet with shiny apple of misinformation", "wax your knowledge", "flip side of the same token"... I think you have exceeded your daily quota of metaphormixing.
Right, writing normal HTML is easy. In this context, I'm referring to animations and other graphical niceties that Flash has historically been deployed to provide and which HTML5 addresses with its canvas elements. I mean that such things are easier to make with Flash's IDE, which comes with many drawing tools, the timeline, layers, etc., vs. HTML5 canvas which, as far as I know, has no serious development environment offering any of these things.
Even if it isn't so hard for a programmer to figure out how to duplicate things in HTML5 canvas, a large reason Flash has been able to spread so widely is because it appeals to designers and other visual producers, and is usable by them without much difficulty. To displace Flash, canvas will need to acquire a development environment that does the same.
While I also disagree with the previous comment somewhat, "No need to buy Adobe tools or hunt the .fla" is not an advantage of any other development platform; that's because the real tools used for Flash development (Flex SDK, the compiler, and asdocs/etc) are free. Indeed, the IDE is seldom used nowadays by many shops; it's not that there are "alternatives", but that there are better ways: I know I've been doing Flash for 10 years and my IDE of choice now is none other than Eclipse.
For all it's worth, you can create full Flash content with notepad, the official command-line compiler, and if you want graphics, some SVG editor or GIMP or whatever.
I can't imagine being able to complete an animated banner ad implemented in HTML5/JS (or Flex for that matter) in anywhere close to the time it would take within the Flash IDE. Using the Flash IDE, I can also apply JPEG compression to 24-bit PNGs (with alpha channels). I really wish there was a similar alternative for HTML. And as poor/buggy as the font support is in Flash, it's still far better than using a flattened image. The timeline, filter effects and third party tweening solutions also bring a lot to the table.
I'm not sure it changes anything. Everyone has Flash installed at this point. Chrome is a relatively small chunk of overall Internet usage either way. The big potential game changer is Adobe delivering a really good version of Mobile Flash that defies their detractor's expectations.
