ЧТо будет с гуглом? Flash Platform Team

[flastar]

Как вам новость на http://flash-ripper.com?
Что вы думаите?
Что будет делать гугл?

[Molecula]

Гугл будет набирать команду безумных флешеров, которые будут 24 часа в сутки, 7 дей в неделю, писать код который обретет форму Флеш-Винды ОС-флеш будет суперской и не будет нифига контачить с каким либо Яху продуктом.

[miramax]

Как минимум один псих уже работает с гуглом в этом направлении... %)

[artcraft]

цитата из книжки "Rich Internet Applications with Adobe® Flex™ & Java™" про недостатки AJAX

AJAX Shortcomings
An ability to create flicker-free Web apps without buying more software is AJAX’s big appeal. You
may have heard the chant, “AJAX is free.” Here’s the simple translation: no commercial AJAX tool
is worth paying for. There are hundreds of libraries, toolkits, and control sets that give you the impression
that AJAX applications are cheap to develop and strategically safe since there’s no vendor
lock-in. Actually, there is vendor locking because you won’t manually write JavaScript code and will
have to pick an AJAX library of some vendor. Now think about it: starting from the ground up you
need a communication layer, messaging and remoting mechanisms, an HTTP sniffer, a library of
UI components with shared objects and event models, a visual IDE that understands these components
in design time, and a debugger that accommodates all this stuff. On top of that, there’s internationalization
support, accessibility for the disabled, and support for automated testing tools.
You really think you’re safe with mix-and-match from different vendors? If the answer is yes, you
must be working for a software company in the RIA business. Coming to reality; a long development
cycle; lack of free, quality GUI components; and the shortcomings listed below make AJAX
less appealing and, actually, the most expensive way of creating RIAs.
These are some of AJAX’s current drawbacks:
• JavaScript development tools are limited due to the dynamic nature of the language, and
debugging any DHTML/JavaScript mix is a pain. Yes, Google’s GWT can spare you from writing
JavaScript manually, but at the end of the day, it’s still JavaScript that has to be deployed in
production. When the system isn’t working and time is limited, what are you going to use to
debug it – the real page of Java mock-up?
• Tons of JavaScript source code has to go over the wire to the client to be interpreted by the
browser. We’re talking about business applications, not some proof-of-concept demo.
• Web browsers will happily display your application even if a piece of JavaScript didn’t arrive at
the client. You won’t know if a problem exists until you execute the particular use case.
• A simple right-click followed by the “View Source code” menu option would reveal your business
application code. Better yet, all this code resides as plain text in the browser cache on
disk. Because of this, you have to drop all the code comments and use obfuscators to protect
your code from being stolen.
• HTML rendering is slow: think of a data grid that contains 5,000 records. Where’s your mutual
fund report?
• Any data manipulation by JavaScript is inherently slow because JavaScript is an interpreted,
not a compiled language. We’re talking thousand of times slow.
• The code is more vulnerable to hacker attack, a fact that was proved recently by a worm that
stole a bunch of mail addresses from Yahoo address books.
• AJAX doesn’t support server push. The server-side application can’t publish the data directly
to the client. AJAX applications have to poll the data from the server at specified time intervals
without knowing if the data is there or not.
Dion Hinchcliffe, the editor-in-chief of AJAXWorld Magazine, listed some of the important things
every AJAX developer should know (see http://web2.wsj2.com/seven_things_ev...tware_project_
needs_to_know_about_AJAX.htm ):
• Browsers were never meant to handle AJAX.
• You won’t need as many Web Services as you think.
• AJAX is harder than traditional Web design and development.
• AJAX tooling and components are immature and there is no clear leader today.
• Good AJAX programmers are hard to find.
• It takes real work to make up for AJAX’s shortcomings.
• AJAX is only one element of a successful RIA strategy.
Hinchcliffe says, “The addition of RIA platforms such as Flex, OpenLaszlo, and WPF/E to a RIA
strategy is virtually required to properly exploit the range of capabilities you’ll want capable online
applications to have. This is particularly true around rich media support such as audio and video
– which AJAX is virtually incapable of – but even such mundane things as good printing support.
These are all things that the more sophisticated Flash-based RIA platforms really shine at and are
easier to program in to boot. AJAX will increasingly get a serious run for its money from these platforms,
particularly as they provide back-end server support for things like server-side push, formal
Web Services, enterprise environments, and more.”
Interestingly enough, the future of AJAX in the enterprise application space may not be as bleak as
it appears, and we’ll tell you why a little bit later in this chapter.
Finally, the browser’s golden days are almost over. All leading software vendors are looking beyond
the browser for the next Web application platform.
To summarize, if you’re developing a new enterprise RIA from scratch, AJAX may not be the way to
go. Choose a solid application development environment that offers a virtual machine at runtime
like Flex/Flash, Java, or WPF. Any of these environments is more productive than AJAX. If you already
have AJAX applications, you can nicely integrate new Flex RIAs in existing AJAX applications
using tools like FABridge from Adobe for communicating between AJAX and Flex.
During AJAX’s first year of life, every article or book on the subject mentioned Google Maps and
Gmail, and various type-ahead samples: you enter the first zip code digit in a text field, and it suggests
your possible choices based on your input without a page refresh. Today, you can read about a
number of AJAX applications, including ones that work with photo images loaded from the popular
flickr.com Web site. If you run into one of these samples, compare it with the slideshow application
in Chapter 13. This is probably the easiest way to see the difference between the rich and just a little
richer Internet applications.

[flastar]

Вглядитесь что написано на шапке яху-блога(слева), я ничего не понял.)

[Aziz Zaynutdinoff]

там же черным по-русски написано:

package com.yahoo.webapis.search
{
   import com.yahoo.webapis.ServiceBase;
   import com.yahoo.webapis.search.events.SearchFaultEvent;
   ...
   ...
}

С гуглом ничего такого страшного не произойдет. Они свой пирог есть умеют, так что не факт, что вишинка с пирога досталась Y!, ведь события ещё не получили пиковый оборот.

[Nirth]

Гугл в основном занимается АЯКСОМ, флэш использует только там где у него явные приемущества(видео например).

Мне это в гугле не сипотично но это их дело. раньше например у гугла был очень неплохой SOAP API для поиска, который можно было юзать как из флэшки так и из сервера, а сейчас только JS оставили.

[flastar]

Не, гугл по поиску рулезнее это точно, а вот с yahoo я сомневаюсь.