I'd contend that the reason HTML5 actually paid attention to video and vector graphics was that Flash made them popular. I don't want Flash (or equivalent) to die because I want to see even more innovation from them, all of which eventually makes its way to standards.
I love Flash, and the core problems people rant about boil down to crap Adobe can fix.
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.
Not to mention functionality - code the same thing in Flash and using Canvas and compare what is involved. Some things that are trivial in Flash/Flex are (as far as I can see) pretty difficult when using Canvas.
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.
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.
Give it time. The canvas element isn't even out of draft phases yet. How long has Flash been around?
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.
Nice. I haven't done much AS, and I'm really not too surprised. Since you've done both, I'll definitely keep your view in mind; many haven't. Is the main part of the ease due to the language / core API though, or ActionScript's libraries? Canvas has effectively no mature libraries as far as I can tell, though there are some impressive ones.
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)
Actually a lot of Flash apps are mainly code + assets now, that's certainly the way we make things.
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 briefly considered writing some kind of framework for Canvas that would emulate the Flex DisplayObject and related container classes together with some useful behaviors.
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.
It depends what side of it you're trying to do, just getting a tree structure of Sprite-like things working is actually quite easy - canvas' drawing transform stack is ideal for resolving the nested transforms for each shape. The trickier part is re-rendering the smallest region of canvas possible when you do change part of the display list.
Maybe I should post a link to my stuff when I get around to working on it some more!
It was the event handling side of things that I realized were going to be a fair bit of effort - all standard graphics stuff, but not things that I was particularly interested in writing at this moment in time.
Having said that, if you do have something along these lines I would love to hear about it.
1) I'll seriously disagree with you on this. Flash is likely much easier, because it's designed around doing this, but it's easily possible in Canvas too. Just maybe not currently. An OpenGL-like pipeline to help figure out what you clicked on, combined with JavaScript objects that can draw themselves, allows identical behavior. I don't know about interaction speed, can't comment on that. And I'm only using OpenGL as an example because I have some idea of how it works, there are other ways to detect what was clicked.
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.
Actually I think you just agreed with everything I was saying!
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.
Aaah, ok. I was keying in on the "There is no way of..." and "have to..." to mean you thought it was impossible, not that it just wasn't easy currently.
The problem with HTML5 is that it does not provide any better new features of multimedia, but an incomplete alternative to Flash. I would definitely choose HTML5 if I can make something that can not be done with Flash nor HTML4
HTML is doomed. Flash is way more powerful and installed on almost every computer in the world. Flash also runs almost the same on all browsers, even IE6, where many HTML sites break - another clear advantage...
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.
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.
37 comments
[ 1.8 ms ] story [ 83.0 ms ] threadhttp://news.ycombinator.com/item?id=1181452
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"?
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.
Flash VS HTML5 is a no brainer for any sane person.
I almost forgot, FU Adobe i use FreeBSD.
Good riddance.
Interactive graphics that work on the iPhone and iPad.
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?
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.