If Adobe ever did stop developing / supporting the Flash plugin, it would be a complete disaster from the point of view of people like myself who think once something has a URL it should ideally stay accessible until the heat death of the universe.
The best way for Adobe to save Flash is by killing it
31–40 of 43 posts
Re: The best way for Adobe to save Flash is by killing it
#32If Adobe ever did stop developing / supporting the Flash plugin, it would be a complete disaster from the point of view of people like myself who think once something has a URL it should ideally stay accessible until the heat death of the universe.
The Flash resource would still be available. If you encode your resource in a proprietary format then that’s your choice :)
Re: The best way for Adobe to save Flash is by killing it
#33I think some people are forgetting that Flash is used for more than just serving up video and pop-under ads (though admittedly that would be its largest use). There are a lot of games that may not be possible to run on an HTML 5 canvas. Also, lost in this discussion is the fact that one of the more popular browsers doesn't support HTML 5 in its current version or possibly even its next. Does streaming video work unde…
Also, lost in this discussion is the fact that one of the more popular browsers doesn't support HTML 5 in its current version or possibly even its next.
Not natively, but http://excanvas.sourceforge.net/
Does streaming video work under HTML 5 specs?
Yes.
Re: The best way for Adobe to save Flash is by killing it
#34I think some people are forgetting that Flash is used for more than just serving up video and pop-under ads (though admittedly that would be its largest use). There are a lot of games that may not be possible to run on an HTML 5 canvas. Also, lost in this discussion is the fact that one of the more popular browsers doesn't support HTML 5 in its current version or possibly even its next. Does streaming video work unde…
Also, lost in this discussion is the fact that one of the more popular browsers doesn't support HTML 5 in its current version or possibly even its next. Not natively, but http://excanvas.sourceforge.net/ Does streaming video work under HTML 5 specs? Yes.
Does streaming video work under HTML 5 specs?
Yes.
Not within ogg/theora it doesn't because there's no way of signaling the correct amount of data to buffer as used in the buffering mechanisms of modern video codecs.
Re: The best way for Adobe to save Flash is by killing it
#35Earlier quoted context omitted.
The implementations may differ, but the main use-cases are the same. So it's like comparing an apple to an orange when you want to choose a healthy supplement to your diet ;)
> but the main use-cases are the same I beg to differ. Flash is by far the best stream-able vector animation engine.
You haven't contradicted my claim :-) ... meh, programmers.
In case you're thinking Javascript games aren't possible ...
http://www.hongkiat.com/blog/10-most-popular-iphone-web-game...
Re: The best way for Adobe to save Flash is by killing it
#36The reason that the Flash authoring tools work in a sane manner is because there is a single, consistent runtime that they target. There is a vast graveyard of tools that tried to wrap html and javascript so you could make reasonable GUI authoring tools. To my knowledge they were all plagued by consistency and performance problems, or placed severe limits on what you could author. This is less of a way forward than i…
Yes the existing tools are pretty awful... but they're generally made by small companies that don't know how to build tools, building on the current implementations of HTML, CSS, and Javascript. Has anyone given it a real shot, targeting the newest features of HTML5? Adobe on the other hand has built industry standard tools over and over again (Photoshop, Illustrator, etc). They've proven that they can export their a…
HTML5 isn't exactly old, nor is it complete, that's why no one has given it a 'real shot'. But honestly, walking down that path seems like an enormous headache with little reward.
CMS systems already solve the problem of "how do I make and update a website", with an order of magnitude less hassle for the developer, and much less hassle for the user.
Re: The best way for Adobe to save Flash is by killing it
#37So instead of adobe being the monopolistic developer of tools for the successful flash platform , adobe should compete with everybody else on developing tools to html5? This doesn't seem like a great business move, at least not before they tried everything they can to keep flash important.
Precisely. Adobe has two very important footholds on the web: Flash and Acrobat. The web authoring tool landscape is only aimed at developers, a relatively minuscule market. Why would they eat their own tail?
Re: The best way for Adobe to save Flash is by killing it
#38Earlier quoted context omitted.
Ever hear of Flex? It's whole purpose is GUI components. And it's free, as in free beer. Where exactly did you check? Really. Show us this "free" flash compiler that isn't so hot.
mxmlc, the free compiler from adobe, does not allow you to use the standard gui controls that their paid compiler does. yes, you can use flex, but there is certainly some kind of reason that adobe added that limitation to mxmlc. man, why do you people have to turn everything into a pissing match?
My team is using Flex SDK + Eclipse right now. What "standard GUI controls" are missing?
Re: The best way for Adobe to save Flash is by killing it
#39Earlier quoted context omitted.
Seriously? Did Adobe beat you guys up and take away your computer? Did they say "no no no mine?" Where is the "not open" you guys claim? Flex SDK + Eclipse == free Flash development. I swear HTML5 fanatics just make stuff up these days. You'll use Windows, Flickr, Google, and Hacker News - all privately owned systems. But god forbid Flash is bad because... why?
You're assuming everyone posting replies and that the author of the post are all HTML5 fanatics. Have you considered that many of us might have worked heavily in Flash/Flex for years designing website and applications, and that possibly the uprising against Flash mentioned here involves Linux Flash plugins seg faulting with no error messages, crazy Flex binding memory usage, general CPU overload and a horrible debug…
Sounds funny, but my only supporting fact is I wouldn't be here without Flash. I basically loath programming but I'm willing to do it because of Flash.
Sure there's CPU problems and there will always be more-optimized forms of code. But Flash has a timeline, which is something few here will understand or appreciate.
Plus it really is ubiquitous, unlike anything else. I'll take a small performance hit if it means I don't have to learn/write/test multiple languages and systems.
I'm not in this for the code. I'm in it for the UX.
Re: The best way for Adobe to save Flash is by killing it
#40Earlier quoted context omitted.
what parts of flash are not open? When flash opened those parts you mentioned? do their knowledge and control of the closed parts of flash enables them to build better tools? how big a lead did they have for their tools when they opened those parts of flash ? Are they still today the leader in flash tools so maybe it's not worthwhile for a competitor to enter? I really don't know flash in depth , but my guess is that…
"what parts of flash are not open?" The source code of the Adobe Flash plugin, if nothing else. Incidentally, that does bring to mind one possible Hail Mary that could work: Open source the Flash player(s). Whether the open source community could fix performance issues on Linux and OSX depends on a lot of things, but they could certainly fix some things that would make it less aggravating. (Since it's probably imposs…
If they open-sourced it, it would be difficult to standardize. With a major release every 12-18 months, it's already difficult to drive adoption (takes about 12 months to get > 90% user base per version).
I will agree - they might want to consider open sourcing the Linux version. I know nothing about Linux so I'm guessing it's related to trying to support the "anything-goes moving-target many-flavors-of Linux" issue.
OSX is another matter (blocked OSX APIs).