flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "imagenesis@gmail.com" <imagene...@gmail.com>
Subject Re: bay area folks and flash
Date Tue, 17 Apr 2012 21:12:58 GMT
Objectively better from a development standpoint. *


On Tue, Apr 17, 2012 at 5:11 PM, imagenesis@gmail.com

> Javascript is not a better platform for applications or games. Look at
> EA's Command and Conquer online game. It's performance is horrible and it's
> just a turn based game.
> A lot of WEB developers have been forced to learn javascript because it's
> a standard and you're pigeonholed into it. They are screaming they want
> better UI frameworks and continued development because everyone knows how
> awful coding in mishmash of html/javascript is. There is a very vocal
> community of WEB designers who are screaming for a standardized Javascript
> display list framework. Give it about 5 years and they'll probably start
> screaming Javascript is dead and everyone should code for Native Client.
> Unless internet consumer's have a massive aversion to Flash games which I
> don't think they do, I don't understand why Adobe is second guessing
> itself. Convincing Flash developers, that Javascript is a *better*runtime isn't going
to work I don't think.
> Consumer internet application are not written in Flash. Flash is mainly
> used for games and internal applications with Flex. Saying Javascript is
> sometimes the better choice, it sounds like Javascript is a better choice
> for either games or internal RIAs. Neither of which is true. Yah,
> Javascript is the better choice if you're making a consumer internet
> applications where users don't want to load Flash for their social
> networking fix. At this point, there is no good free Javascript UI
> framework. There is Kendo UI, JQuery UI and Sencha. Only JQuery is free.
> None of them are as comprehensive as Flex. They don't have containers for
> one thing. Even if they were as comprehensive, there isn't any good reason
> to write something in Javascript. The necessary APIs for rich UI's are
> finite. These equivalent API's are found in Java Swing, Windows UI APIs,
> Linux UI APIs. The point is that they are finite, there aren't any magical
> new developments that Javascript will bring. UI APIs are stable. The Flex
> API is more or less complete. A Javascript equivalent will not be much
> better.
> Fundamentally the only scary part of Adobe's announcements is that they
> sound like:
> We'll try to monetize Flash
> If it doesn't work than we can't tell you what's going to happen. We can't
> tell you we'll open source it. We might just stop developing the API. We
> might take more aggressive steps to monetize it. We might end it
> permanently. I think this is what some flash developers are hearing. In
> reality though, Flash will obviously not be discontinued. Look at
> Shockwave, it has been in zombie mode for years.
> Then again, there is the "lure" of javascript. We all know, pretty soon,.
> a developer will release a great Javascript game that will make a ton of
> money and become super popular and than it might fuel momentum in
> Javascript. Okay I'll give you that.
> On Tue, Apr 17, 2012 at 4:29 PM, Mike Chambers <mchamber@adobe.com> wrote:
>> Yep. Agreed.
>> We had announced last year that we planned to monetize alchemy, and then
>> announced earlier this year that as part of that we would be removing the
>> domainMemory API.
>> Based on community feedback we changed those plans so that domainMemory
>> is still available (and officially supported), and that it would only be a
>> premium feature when used in conjunction with Stage3D.
>> mike chambers
>> mesh@adobe.com
>> On Apr 17, 2012, at 1:02 PM, Tink wrote:
>> >
>> > On 17 Apr 2012, at 20:37, Mike Chambers wrote:
>> >
>> >
>> > IMO if you want to gain back trust a credibility with developers you
>> still need to be clearer and more open about your plans. It should have
>> been made plain and clear that some of these new features would come at a
>> cost.
>> >
>> > Tink

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message