Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mobile Flash Fail: Weak Android Player Proves Jobs Right

blog.laptopmag.com

Post reply on HN
Print view View original

111–120 of 194 posts

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#111

Post by zmmmmm »

WilliamLP wrote: post #17
IdeaHamster wrote: post #4

I would give anything for someone to explain to me why the right move for Adobe wasn't to simply accept HTML5, pivot from Flash to making killer HTML5 authoring tools, and maybe even provide a way for people to take their existing Flash projects and repurpose them to HTML5? How would that have been worse then trying to wedge Flash where it doesn't belong?

The much glossed-over answer is that JavaScript and HTML just isn't a good environment for rich app development, for many reasons. One "elephant in the room" kind of issue is that JavaScript's object system is not acceptable to most programmers, and most programmers require classical OOP. Even prototype system fanatics probably would have to admit that the current state of JavaScript doesn't work very well, with its…

There are some problems with HTML/Javascript but I find it reasonably good as a developer. The problems with it are all about the lack of standardized apis to native OS functions - audio, video, microphone, etc. It always seems to lag about 5 years behind the most interesting apis (eg: now I would want accelerometer apis ...)

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#112

Post by ItarPeyo »

bruceboughton wrote: post #86
jcl wrote: post #74

Earlier quoted context omitted.

You are assuming that the only thing preventing Flash from working on mobile is that it hasn't been "optimized" enough -- that opening the source to Google and Apple will unlock performance otherwise unattainable by Adobe. But suppose Adobe's programmers are not completely incompetent? Perhaps Flash's execution model is genuinely unable to be optimized further. Or perhaps most Flash content in the wild runs at the li…

Rubbish! Most moderately advanced HTML5 demos run hideously, if at all, on mobile hardware. The difference will be if HTML5 can replace 80% of Flash uses in a performant manner. The video tag makes up a huge block of that 80%. The other 20% will always run like a dog on mobile hardware, no matter the technology.

Always?! Even on mobile hardware that will come in 5-10 years?

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#113

Post by illumin8 »

cookiecaper wrote: post #23

Adobe is seriously doing it all wrong. They have to open-source the Flash Player and everything around it now. They can keep the IDE proprietary if that floats their boat, it's just a premium authoring tool, but the only way to save Flash is to open-source like NOW. HTML5 is still young enough that an open Flash Player and standard and protocol (RTMP) would effectively kill it. Open-sourcing would open so many doors.…

This is a great idea, but I think Adobe might not want to open source it because they have sold Flash to content companies as a way to lock their streaming content down with DRM. Opening the specs and allowing anyone to play DRM content would let the "evil pirates" get their hands on all that sweet, sweet booty. By booty I mean streaming episodes of Hulu...

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#114

Post by [deleted] »

myth_drannon wrote: post #70
naturalized wrote: post #66

I actually doubt that Adobe has the competence to make high quality software, that would be required for mobile Flash (due to serious optimization that is required). There is probably not enough engineering culture in the company for that. I also think that a proper software company cannot be located in San Francisco itself, otherwise they tend to attract programmers that are too cool/have to many outside interests t…

Many of Adobe's engineers are based in Ottawa,Canada and India.

[deleted]

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#115

Post by illumin8 »

bruceboughton wrote: post #86
jcl wrote: post #74

Earlier quoted context omitted.

You are assuming that the only thing preventing Flash from working on mobile is that it hasn't been "optimized" enough -- that opening the source to Google and Apple will unlock performance otherwise unattainable by Adobe. But suppose Adobe's programmers are not completely incompetent? Perhaps Flash's execution model is genuinely unable to be optimized further. Or perhaps most Flash content in the wild runs at the li…

Rubbish! Most moderately advanced HTML5 demos run hideously, if at all, on mobile hardware. The difference will be if HTML5 can replace 80% of Flash uses in a performant manner. The video tag makes up a huge block of that 80%. The other 20% will always run like a dog on mobile hardware, no matter the technology.

Have you watched the Apple HTML5 demos on an iPad? It's actually revolutionary to see what they can do with the limited hardware. Being able to touch and drag a 3d model around at 30 fps without stuttering? I can't even do that on a lot of PCs with Flash.

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#116

Post by illumin8 »

rbranson wrote: post #49
borisk wrote: post #39

Earlier quoted context omitted.

Flash player gives Adobe a lot of power and keeps their not so good dev/design tooos safe from competition. From what I've seen the current strategy is to try to add features not available in HTML5, like P2P. That would allow youtube and company to roll out torrent-based players and save hugely on bandwidth.

I doubt P2P could be used reliably for video streaming. There's a quality of service component of video streaming that P2P solutions can't currently provide effectively in the context of embedded web video streaming. Besides, YouTube probably doesn't cost very much bandwidth-wise. Google has dozens of datacenters placed at or near key peering locations where they can negotiate very low or zero tariff interconnects wi…

Agreed. The main reason why it wouldn't work is that existing broadband deployments are not designed for P2P. Your neighborhood might have a gigabit of downstream bandwidth on fiber from the cable company but the upstream is limited to something like 100 megabits for the entire neighborhood. It sounds nice in theory to cut bandwidth costs, but somehow I don't think the cable companies are going to be too happy with you sharing their limited upstream with your traffic. They'd much rather deliver lots of streaming content downstream, which is what their network is designed for in the first place.

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#117

Post by joehn »

cookiecaper wrote: post #23

Adobe is seriously doing it all wrong. They have to open-source the Flash Player and everything around it now. They can keep the IDE proprietary if that floats their boat, it's just a premium authoring tool, but the only way to save Flash is to open-source like NOW. HTML5 is still young enough that an open Flash Player and standard and protocol (RTMP) would effectively kill it. Open-sourcing would open so many doors.…

adobe also sells access to the premium codecs in flash. youtube pays a nice chunk of change for it

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#118

Post by diego_moita »

CodeMage wrote: post #32
warfangle wrote: post #24

Earlier quoted context omitted.

"even 'fast' JS VMs are still rather slow" 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...

None of those comparisons really matter in this discussion, except Java, which is clearly out of the competition anyway. Why? Because unless you're suddenly running Ruby, Python, PHP, C or OCaml as a client-side script embedded in your browser, you're comparing apples to oranges. It would be interesting, though, if someone could point me (and everyone else) to a reasonable, credible comparison of HTML5+JS vs. Flash v…

I've been playing with Silverlight and am very well impressed.

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.

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#119

Post by diego_moita »

elblanco wrote: post #35
warfangle wrote: post #24

Earlier quoted context omitted.

"even 'fast' JS VMs are still rather slow" 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...

You forgot to compare to Actionscript which is the language that matters in this comparison. http://en.wikipedia.org/wiki/Actionscript Adobe's had a JIT Actionscript compiler for years and it's really quite fast.

> it's really quite fast.

Take a look at Silverlight. Its performance will surprise you, I am sure.

Re: Mobile Flash Fail: Weak Android Player Proves Jobs Right

#120

Post by dusklight »

Even if Jobs is right about the technical shortcomings of flash, that doesn't change the fundamental fact. It should be YOUR choice whether you want to run flash on your phone, not his. He has no obligation to provide help to get it working, but neither should he be actively preventing even the possibility of flash (or any other software) through legal and procedural means.
Post reply on HN