Flash vs HTML 5
nytimes.com
nytimes.com
Note that I really want to use Canvas - but at the moment when it comes to interactive graphical applications I don't think the two are currently directly comparable.
They’ll never be directly comparable. Canvas is a bitmap drawing field, Flash is a vector drawing field with enhancements. If you want to do vector stuff you’re probably better off using SVG.
Honestly, I think canvas will catch up to Flash in capabilities pretty quickly. And I'm holding out hope for OpenCL hooks for Javascript for this reason precisely. What's really needed now is a good editor like Flash's studio.
People are still largely doing everything by hand-coding things. Put Flash on that same level, and see how easy things are to do.
You're rather hardcore compared to most Flash developers I've run across, though. I'd wonder if most are just using whichever one has bigger / better tools. (not that this implies anything about the language, of course)
I've tried using canvas to replicate some things that we've made in Flash, and quickly ran into some problems:
1) There is no way of interacting with elements drawn to canvas, as it's just a flat image (as someone else mentioned in the comments here, canvas is just a way of drawing bitmaps). You could obviously write your code to deal with mouse and keyboard interaction, but it's even more overhead on something that is already quite slow, and even if you could interact with individual elements it brings me to the other thing...
2) Flash has everything in layers that can be updated independently, when it comes to canvas if you want to change something you have to redraw that section of the image entirely, something that isn't always practical which means you end up redrawing the whole canvas. Essentially Flash does the same thing, but as the compositing is handled by the plugin it is far faster than anything you can do in Javascript at the moment.
Also related to the above, the drawImage method that draws bitmap data to the canvas is painfully slow at the moment, so compositing using that is out of the question. If that can be optimised significantly it will certainly help.
Basically canvas is too low level to duplicate the kind of functionality Flash offers at the moment. Until manipulating the canvas and Javascript is optimised further it's not possible to layer in the interaction or flexibility of rendering that Flash has. I'm sure a framework offering this will happen one day, but it won't be any time soon.
I gave up when I realized how big a task this would be and that the result would probably be slow and almost surely superseded in some future release of Canvas.
Maybe I should post a link to my stuff when I get around to working on it some more!
Having said that, if you do have something along these lines I would love to hear about it.
Heck, if you wanted, you could literally duplicate OpenGL in its entirety in JS for Canvas. There's nothing preventing this, except lack of threading / parallel processing, though I admit it'd be ungodly slow.
2) Also primarily a problem currently, and likely due mostly to the lack of mature libraries to do just this. With compositing rules (source-over, source-atop, etc) and masks for objects, you can re-render only the displayed portion of any object on a Canvas as well.
Low level: well yeah, it's a thin layer over a bitmap surface. Libraries are needed to abstract away from that. It's kind of like saying that OpenGL isn't fast because it's core is low-level. That low-level feature-set Canvas has will be wrapped in libraries to make specific uses simpler, I guarantee it. Speed will come, especially as Canvas gains focus. It's still very new. Was Flash this fast/capable in pre-1.0 days? I have no idea if it'll catch up / surpass Flash, but it's far from its optimum right now.
I'm not calling for the death of Flash, and I seriously doubt it'll ever supersede Flash on everything, so Flash has it's uses and will continue to do so. Just pointing out that they're not on equal playing grounds in terms of development.
My point was canvas isn't quite there yet, not that it never will be, and also that I think the Flash-has-an-editor argument isn't the reason why canvas isn't ready yet.
As a side note, I'm already one of the people writing a library/framework to overcome the things I mentioned, the problem is I don't think it's going to be fast enough to do much with for a while.
Install base is a big factor to security.
I don't.
> In 5 years why should the web require a plugin to show video or vector graphics?
It shouldn't, but both your questions seem quite unrelated.
good point. But maybe Adobe should do more to embrace more on open standards than pushing a closed (swf) format.
HTML5 has some amazing possibilities ahead of it but none of that eradicates Flash's future. Fantasizing and circlejerking about that possibility is just retarded -plugins fill a void the W3C and browser vendors can't do themselves - and that is keeping up.
What are your needs in 5 years and what makes you think HTML5 is somehow perfectly anticipating them? How about 10 years? How about even one year from now?
Are you going to upgrade any software at all you use over the next 5 years? Or did they all get it perfect too?
I've lived in a world where I couldn't access online banking if I was using anything as exotic as Mozilla on Linux. Thankfully, the situation has improved a bit since those days, but I would never want to return to them. Note that today you don't have to stray very far from the mainstream before Adobe stops delivering their plugin. The web should be such that it can be used on innovative platforms without being at the mercy of one CEO who doesn't like another CEO that day, or thinks your FreeBSD or Plan 9 or Haiku are too marginal, or that your CPU instruction set insufficiently ubiquitous.
For the end user, what's the difference between "require a plugin" and "require a browser"?
First, it starts off talking about the iPad and how Flash may not be the CPU hog its made out to be. It then goes on to say that HTML5 is more efficient than Flash in Safari. The iPad runs Safari, in effect contradicting their previous argument about the iPad.
Next, they say that Apple could allow Adobe to make Flash faster, all they have to do is open up access to the hardware APIs. Who exactly wants a browser plugin to have low level access to the hardware APIs?
Seems kind of ridiculous to say that something else is at work here. Does Apple want to kill Flash? Probably, but even if they didn't want to, they've got plenty of reasons not to allow flash on the iPhone/iPad/etc.
Interactive graphics that work on the iPhone and iPad.
Flash VS HTML5 is a no brainer for any sane person.
I almost forgot, FU Adobe i use FreeBSD.
Good riddance.
Seriously, this argument is getting old. Chose the right technology for your purpose and use it wisely to prevent CPU spikes, security issues, etc. HTML makes strides forward and so does Flash. HTML is great for 90% of all needs, and Flash fills in the other 10% where you need some more flexibility, play audio, have multiple file-uploads, run it as an Air app on the desktop, etc.
What, HTML isn't installed on almost every computer in the world?