Adobe's roadmap continue to believe in flash player and AIR. ok. but not
at all for enterprise Apps.
first consequence is that any new capability like workers will be only
for the new VM we cant access with AS3 flex. (which was quite a big
surprise for me)
if tomorrow a great platform comes out, and is well suited for
enterprise apps, but not for gaming. flex is screwed for sure.
if tomorrow Adobe dont manage to make money on gaming, (don't forget
that in that area, theres already tools like Unity which are much more
advanced and widely used) they could decide to not continue to improve
AIR on mobile etc.
even if Adobe continue to port AIR on new devices, flex will only use an
old abandoned VM. Again its like if you were still trying to maintain an
AS2 framework in an AS3 world (its even worse).
And you pointed out the Adobe's roadmap for flash platform. But check
also their active work on HTML5 area. everyone is preapring itself for a
less plugins world, before a non plugin world. And the shift of Adobe
was quite a very early and brutal one. (which was a bad decision IMO,
but flex has to deal with it)
Do you really want flex to be totally dependant on Adobe's decisions?
even if Their strategy has nothing to do with apps?
Did not the last year afraid you enough?
The flex future is out of Adobe depency, and it has to be prepared as
soon as possible. even if we still have a few years before the
unevitable big shift happens.
Le 17/11/2012 17:20, Hordur Thordarson a écrit :
If we have a solution like Haxe, we can debug in a local native output, and use
the HTML/JS output only as a release.
That to me is a recipe for problems, test/debug on one runtime, deploy to
another one, you'll get situations where smth works in testing/debug but
doesn't or works differently in your release build. Not good.
but if you take the fact that the plugin word is getting to an end
I don't agree with that. Here's Adobe's roadmap on this:
"Adobe believes that the Flash runtimes are particularly and uniquely suited for two
primary use cases: creating and deploying rich, expressive games with console-quality
graphics and deploying premium video. This shift in focus for Flash does not mean that
existing content will no longer run, or that Flash cannot be used for content other than
gaming and premium video. However, it does mean that when prioritizing future development
and bug fixes, gaming and premium video use cases will take priority."
That to me says that Flash player/AIR aren't going away, quite the opposite in
fact as Flash player/AIR (for mobile) are core components of Adobe's new gaming
strategy for building a business on top of Flash.
but you don't get it anymore in the next flash builder versions, because of the
Adobe's strategy shift.
Do we know this for sure ? I've not read anything that tells me this. And
frankly, I can't see how Adobe is going to monetize Flash without top-notch dev
tools. Indeed, their roadmap says this:
"The Flash runtimes provide a number of key advantages and differentiators as a
gaming platform, including the following: .... World-class creative and developer tooling
including Adobe Flash Builder, Adobe Flash Professional, Adobe Photoshop, and Adobe
Illustrator".
But maybe I'm reading all this wrong or maybe I'm believing too much what I
think I'm reading or maybe the people here advocating a HTML/JS strategy for
Flex have been burned more by Adobe than I have.
On 17.11.2012, at 14:47, sébastien Paturel wrote:
Why? as we said it before, its only to get rid of Adobe's runtime for the long
term future of flex.
The last year should have convinced you thats its too dangerous to be so
dependant to Adobes decisions.
And no one wants to turn the AS3/MXML code to HTML/JS. its only an alternative
as a runtime. You would still use the same AS3, the same Flash builder.
If we have a solution like Haxe, we can debug in a local native output, and use
the HTML/JS output only as a release.
"Flash builder with a pretty nice, WYSIWYG GUI builder"
but you don't get it anymore in the next flash builder versions, because of the
Adobe's strategy shift.
"the code you run/debug will not be the actual code you wrote"
but if you take the fact that the plugin word is getting to an end, theres not
much choices left. and you have to rely on a new layer which will replace the
plugin.
"like the man said, if it ain't broke, don't fix it"
Again, the flex future is broken, and we have to fix it.
Le 17/11/2012 15:30, Hordur Thordarson a écrit :
if all says that HTML5 is not ready yet for RIA and enterprise apps that flex
can do very well, why the hell would we try to render flex on HTML5 engine for
My question exactly, why the heck, when we have the best cross-platform UI lib
out there with allready pretty darn good deployment options (from a
technical/ubiquity perspective), do we want to go and turn our AS3/MXML code
into HTML and JavaScript for running in the browser? If the only thing that is
gained by that is to get rid of the Adobe VM dependency then I say we're giving
up much more than we are getting.
I'm using Flex and deploying to Flash player / AIR specifically so I don't have
to deal with HTML/JS/CSS. And someone please correct me if I'm wrong, but
currently I have an excellent debugging experience for my Flex apps with
FlashBuilder and Flash player, I can set breakpoints, step through my code etc,
works like a charm. If Flex is rewritten and the decision is made to compile
to HTML/JS, as far as I can see, this experience has been downgraded
significantly because now I have to debug generated HTML/JS code, not my own
code. This is the problem with cross-compilation.
Also, what would the experience be on the dev tools side ? Currently we have
Flash builder with a pretty nice, WYSIWYG GUI builder and as I said, a pretty
nice compile-run-debug experience. If Flex is ported to Haxe or some other
language, we are back to square one as far as this is concerned. If Flex
sticks to AS3/MXML but then gets cross-compiled into HTML/JS, then as I said
above, the code you run/debug will not be the actual code you wrote. All sorts
of new problems will follow.
I'm really hoping I'm wrong and way to pessimistic about all this, and will
happily change my views on this if someone shows me some evidence that even
though Flex is rewritten and the Adobe dependency ditched, we will not loose
the nice dev experience that Flex has today.
I'm a Apple/Mac guy and have been since the days of the Apple II. I've been
programming for about as long. And as such, I've often had the problem that I
wanted to develop on my Mac but be able to deploy to Windows, or both. Out of
the countless number of frameworks and tools and programming languages that
I've tried through the years, nothing at all matches the Flex/Flash player/AIR
combo. Nothing, period. And I think we owe it to Flex to not just cut out
most of what makes it great just to get rid of the Adobe dependency. At the
very least, if a totally new Flex is started, possibly with another programming
language and deployment runtime, I would hope that there would also be an
ongoing lobbying effort concerned with showing Adobe what a great use of Flash
player and AIR the Flex framework is, because there is nothing seriously wrong
with the Flex platform as it is, and like the man said, if it ain't broke,
don't fix it :-)
On 17.11.2012, at 13:54, sébastien Paturel wrote:
i was in fact talking about enterprise app.
it is already quite rapidly heavy perf consuming.
if all says that HTML5 is not ready yet for RIA and enterprise apps that flex
can do very well, why the hell would we try to render flex on HTML5 engine for
native apps.
I was talking about 3D rendering, in a starling sens, as a background rendering
engine, not as application.
Le 17/11/2012 14:25, Nils Dupont a écrit :
It really depends on which kind of application you want to deploy. I was
more thinking of common "entreprise" oriented applications, e.g. a few
views, with a few lists and a few forms. For 3D rendering I agree that it
is not the best way to go.
2012/11/17 sébastien Paturel <sebpatu.f...@gmail.com>
Does not cordova only launch a web browser wrapped in an native app?
If so, its very bad result in terms of performances right?
in a native app environement, we can leverage from 3D rendering (the best
performances), but with cordova solution, we will use the lowest performant
renderer available, the HTML5 renderer.
it does not sound very promising to me, but maybe i'm wrong.
Le 17/11/2012 14:14, Nils Dupont a écrit :
Has anyone tried to make a bridge between Apache Flex and Apache Cordova?
I mean generating an Apache Cordova HTML5/JS application from a Flex
Mobile
MXML/AS3 application (at least for a subset of Flex Mobile components e.g.
views & transitions, lists, input controls, native APIs access, web
service
access, etc.)
Apache Cordova has the advantage to be able to target 7 different mobile
OS
and of course is open source.
For the UI controls, it is possible to use different librairies (JQuery
UI,
Twitter Bootstrap, etc.)
Maybe it is also an other way to consider in order to be able to deploy
Flex Mobile applications to mobile devices without
the use of Air runtime?
Nils
NB: Concerning desktop applications, Flash Player remains, in my opinion,
the best way to deploy cross-browser applications.
2012/11/17 Maxime Cowez <maxime.co...@gmail.com>
Are developers on this list still able to earn a living building new
Flex apps, or are you maintaining old ones?
I was actually hired 9 months ago by my current company to set up a new
Flex development branch, as they wanted a share of the market in that
area.
As such I am mainly creating new "enterprise" apps for government clients
so I can take full advantage of Spark and don't have to worry about
legacy
too much. From my experience in that short amount of time I can tell you
this: we started by creating small(-ish), fairly risc-free projects,
which
we could deliver with very good quality and on time even though on a
tight
deadline. Because of Flex's RAD (rapid application development)
possibilities we were able to use prototypes to discuss functionality
early
in the development process. All of which lead to very satisfied
customers,
of which some were known to be "clients from hell". Bigger orders are
rolling in as we speak.
I'd like to highlight one specific approach we took in selling Flex: a
customer wanted us specifically to use Dojo as a technology. We took the
risk to develop a small prototype in Flex and presented it to them. They
saw immediately that the UX was far superior to what they were used to.
And
we told them we could *perhaps* deliver the same with Dojo, but it would
cost them at least twice as much (which is a true estimate - not just for
selling purposes - and we had just proven by delivering the prototype in
no
time). They did not have to think very long about it...
We've been trying out various enterprise-level HMTL5/JS frameworks and
the
truth is, none of them comes even close to what Flex can do in terms of
stability, possibilities, performance and most importantly (for the
customer) development time. And yes I've included performance in that
list:
none of those enterprise-level frameworks have decent performance
compared
to Flex when presenting lots of data; I'm only speaking of classic
web-applications here.
@paul There's a team not far from my desk that's making a GIS application
with GWT: the project is a total mess and we're loosing money on it.
To sum it up: from my experience Flex as it is now still can be sold in
markets that are not too sensitive to buzzwords.
On Sat, Nov 17, 2012 at 9:34 AM, Paul Hastings <paul.hasti...@gmail.com
wrote:
Are developers on this list still able to earn a living building new
Flex
apps, or are you maintaining old ones?
in our neck of the woods flex is still kind of king for old school
GIS
applications (analytical/decision support/etc.) especially w/ESRI
backends.
mainly for desktops & some stripped down functionality for tablets--much
of
the processing is shared between client & backends.
while i'm sure there are some big/complex JS/JTML5 apps for this market
somewhere, haven't actually seen any.
