indows 8...if I have to
learn a new OS, maybe I should just take the plunge and get an Apple.
Mark
-Original Message-
From: Kevin Newman [mailto:capta...@unfocus.com]
Sent: Thursday, November 22, 2012 2:46 PM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe
To be blunt,
To be blunt, if Flex doesn't measure up against those other frameworks,
it has no future - regardless of the language it's built on.
Kevin N.
On 11/21/2012 7:18 PM, Alex Harui wrote:
Because if I offer a solution that doesn't require porting your existing
code you might be willing to accept o
This has lots of sense. In fact talking with Nicolas Canesse, he point me
to that solution when talking about the main haxe problem that I see:
There's nothing like MXML in haxe.
2012/11/22 Alex Harui
>
> I hope to eliminate virtually all MXML codegen in Falcon. There is no
> reason for MXML to
On 11/21/12 4:45 PM, "sébastien Paturel" wrote:
> I'd like to be wrong, but i have serious doubts about the Cordova web
> view rendering performances
I will pass that on to the Cordova team.
>
> "multiple targets wouldn't have extra overhead in its abstractions"
> of course, but flex apps can
I'd like to be wrong, but i have serious doubts about the Cordova web
view rendering performances
"multiple targets wouldn't have extra overhead in its abstractions"
of course, but flex apps can have heavy UI work
"I'm not planning on transcompilation of MXML"
How you plan to use MXML?
Le 22
On 11/21/12 3:49 PM, "sébastien Paturel" wrote:
> If you consider Cordova only as short term answer, for POC achievement,
> thats ok for me.
Cordova will be around long-term if it proves viable for enough people.
> But its not viable as a final solution, because it would be giving up on
> grea
If you consider Cordova only as short term answer, for POC achievement,
thats ok for me.
But its not viable as a final solution, because it would be giving up on
great performances for native apps compared to native code usage directly.
We have to find out how much work it really is to create s
A component is an encapsulation of code, and its API is its contract. To
the extend that you can hide aspects of the target inside components and
fulfill those contracts, and to the extent that an application is an
assembly of components with some glue code, then yes.
For sure, you can't do ev
On 11/21/12 2:51 PM, "Daniel Wasilewski" wrote:
> Apology for feel instead of fill a gap ;)
>
> So once again, this is it, room of interpreters instead force people to
> learn Esperanto.
> the phrase 'For disposal of native speakers' could only attract more people.
> But the Flex itself as a
On 11/21/12 2:42 PM, "Daniel Wasilewski" wrote:
>>
> I am looking forward to it then, only one question remains, what about
> Java for Android and IOS targets?
> Do you have FalconAndroid and FalconIOS in mind?
It is not obvious to me why a FalconJava and FalconObjectiveC is not
possible, so
Apology for feel instead of fill a gap ;)
So once again, this is it, room of interpreters instead force people to
learn Esperanto.
the phrase 'For disposal of native speakers' could only attract more people.
But the Flex itself as a framework should fill that gap imho. Make it
more abstract, p
For me, AS3 is the key factor. If you make folks learn a new language, it
makes their set of choices much wider.
My goal is not to get rid of AS3, but preserve it as the one that you
can target multiple platforms natively.
by my analogy, I don't need an Esperanto, but room of Native tongue
On 21/11/12 23:29, "Alex Harui" wrote:
>>
>> I took a different approach. Instead of relying on generic compiler, my
>> goal is to implement a framework with a consistent set of rules, in
>> native languages and platforms.
>> Feel a gap in missing feature territory and encapsulate it in one plac
On 11/21/12 2:19 PM, "Daniel Wasilewski" wrote:
> There was a lot of talks here about approach to be taken to bring Flex
> to the next level.
> One of them was the fact that in order to target multiple platforms you
> need to have a descent compiler to convert AST into native language.
> That r
I am following this this discussion carefully as well as all what is
going on on Apache Flex from the very beginning.
Clearly if the future of Flex attached to Flash Player would be bright
this thread should not exist at all.
But is here, and there is a lot of concerns surrounding it. I have
r
On 11/21/12 1:59 PM, "Carlos Rovira" wrote:
> For me, in a full rewrite, the reason not to go AS3 is:
>
> * AS3 will be killed by its own evolution AS4
Not true. Apache Flex effectively owns it. The language doesn't have to
result in AVM2 ABC code. FalconJS will prove that.
> * AVM2 will b
Oh darn, hit Send too soon...
... re-architect the framework, was the intended ending.
On 21.11.2012, at 22:10, Hordur Thordarson wrote:
> This sounds like a very reasonable strategy to me, ie. continue supporting
> (as long as makes sense) the current AS3/Flash VM solution and concurrently
>
This sounds like a very reasonable strategy to me, ie. continue supporting (as
long as makes sense) the current AS3/Flash VM solution and concurrently work
towards a AS3 --> JS solution to remove the Adobe dependency and possibly
re-architect the.
On 21.11.2012, at 21:04, Alex Harui wrote:
> O
So in that case it'd either be using (or completing then using)
FalconJS, or Jangaroo (pulling it into Apache maybe - it's already under
Apache 2.0 license).
That doesn't sound terrible. That could even allow Apache to move AS3
(ApacheScript!) in a different direction over time from what Adobe
For that matter, Adobe Flash is not Apache either.
Just to add one more bullet point - existing AS3 code bases can still be
used if Flex is done in Haxe, as long as you target AVM2.
Kevin N.
On 11/21/12 4:59 PM, Carlos Rovira wrote:
Your point of "Haxe is not in Apache" is not a point for m
Hi Alex,
I'm strong advocate to make POCs in different directions so we could end
getting more knowledge that could end turning all efforts in a real next
generation framework. For that reason I think we'll end over the next year
with various groups targeting different points of views: AS3, Haxe a
On 11/21/12 12:53 PM, "Kevin Newman" wrote:
> But if we are to change languages, why not go with a language that,
> looks a lot like AS3 (and ports easy), addresses the language
> scalability issues of JavaScript (lack of classes, typing, a compiler,
> etc.), and can compile to JS as well as o
On 11/21/12 1:22 PM, Alex Harui wrote:
And, what isn't clear is how well AIR will run on that device,
if at all. There are so many devices it will be hard for AIR to keep
running well (in captive runtime of course) on all of them.
The exact same thing was true for desktop/laptops with Flash. I o
I'm probably not the standard Flex developer and my focus is very narrow at the
moment.
I agree with most of what's been said, but I have not seen my biggest concern
for the future addressed: TLF.
The lion share of my time is taken up right now by my w2p startup printui.com.
Reliable rendering
On 11/21/12 8:53 AM, "Kevin Newman" wrote:
> From what I see, the HTML5 everything push is ending - mostly because
> of performance issues on the native app side.
Here's my take: sometimes when you buy into the hype to early and the
technology isn't ready, you get burned, and then there is a
JavaScript is evolving with ECMAScript harmony 6, it's just incredibly
slow to standardize on the new stuff, and even slower before you can
really use most of it in practice.
But there are at least two attempts to build ES6 compilers that work
today. There's TypeScript (Microsoft), which adds
From what I see, the HTML5 everything push is ending - mostly because
of performance issues on the native app side. HTML5 is still taking over
for flash in the desktop/laptop web space for most things, though even
there, folks are starting to loudly express dissatisfaction with
platform fragmen
No, they want the Adobe AIR scenario, embeddable VM (JRE). And rumor has it
this allready exists for iOS and Android in an Oracle lab but was frozen
because of ...
:-) But since Adobe did this with AIR there is nothing technically that
prevents others from doing it.
But this is a Flex threa
@Hordur
"Since I use JavaEE for the backend for my apps, this would be a killer
scenario for me"
This is exactly why we create Flash4j.
For beeing able to write our Flex apps in ONE language(Java) instead of
ActionScriot/MXML/JS/CSS/HTML/Java.
2012/11/21 Carlos Rovira
> JavaFx looks prett
JavaFx looks pretty good. For people like us it'll solve much of the
problems since the platform gives you out-of-the-box, I'm referring to
maven driven projects, AOP, Annotations on steroids, and so on...JavaFX 2
revisions look so good and seems they copy lots of things from the Flex
world (@FXSki
Exactly. And talking about reality, reality is also that HTML will never be
everything to everybody, a one-size-fits-all solution, simply because there are
no such solutions, requirements are very different depending on what you are
building. For myself, I'll check out JavaFX before being stuc
On 21.11.2012, at 10:35, sébastien Paturel wrote:
> its more JS that need some improvements than HTML5. The dream solution i'd
> love to see happen would be to see JS evolve to something very close to what
> AS3 is. (AS3 is ECMAScript and is supposed to be the future of JS)
All the effort on JS
>HTML5 is not mature enough to compete with flash player right now, but we
have to think about future, and it will improve quite quick with all the
hype around it.
And even if you prefer flash player, there is our dreams, and there is
reallity. And reallity is that Adobe is pushing HTML5 for web an
PhoneGap is for sure a good solution for some developers allthough some of the
apps they feature on their website are really just shells around existing web
sites. I have the Wikipedia app on my phone and it is written with PhoneGap.
It works, but is quite slow for what is really a very simple
its more JS that need some improvements than HTML5. The dream solution
i'd love to see happen would be to see JS evolve to something very close
to what AS3 is. (AS3 is ECMAScript and is supposed to be the future of JS)
HTML5 is not mature enough to compete with flash player right now, but
we h
Now not every company build apps at the scale of FaceBook.
For most of the case HTML5 mobile apps + PhoneGap(Cordova) are pretty good.
2012/11/21 Hordur Thordarson
> On 20.11.2012, at 22:14, Kevin Newman wrote:
>
> > Mark Zuckerberg also said very publicly that Facebook "burned" (his
> word) 2
On 20.11.2012, at 22:14, Kevin Newman wrote:
> Mark Zuckerberg also said very publicly that Facebook "burned" (his word) 2
> years of development with HTML5, "We burned two years. That's really painful.
> Probably we will look back saying that is one of the *biggest mistakes* if
> not *the bigg
Mark Zuckerberg also said very publicly that Facebook "burned" (his
word) 2 years of development with HTML5, "We burned two years. That's
really painful. Probably we will look back saying that is one of the
*biggest mistakes* if not *the biggest strategic mistake* that we made."
It was less of
Hi Kevin,
all depends of how things evolve but I must say that my propossal (and my
contribution if someday get materialized in code) about Haxe is base the
API in current Flex 4.x as a starting point (a draft), but modeling and
changing it as project evolve. This project is for fun, at least in i
The main problem is bigger than that. Adobe through it's marketing has
told everyone that Flash is for Games. They have been actively working
against the idea that Flash is about ubiquity (they could pick that up
again, AIR fills the gap, but I don't see any signs they will).
That story is bas
HaXe really is more similar to AS3 than many here seem to think (it's
more of a superset than a subset - though there are some missing
features like namespace). Would Flex really need to start from scratch
when porting to HaXe? Could some level of automation be utilized
(there's an unfinished t
which also costs money.
It's leveraging what's already there.
-Mark
-Original Message-
From: omup...@gmail.com [mailto:omup...@gmail.com] On Behalf Of Om
Sent: Friday, November 16, 2012 17:24
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe
On Fri, Nov 16, 201
p0-(f(x)/f'(x)) Newton's Method Here
>
> neko.Lib.println("p1 = " + p1);
> p0=p1; //switch variables for next iteration
> x0=p1; //switch variables for next iteration
>
> }
> }
> }
>
> -Original Message-
> From: Nicholas Kwiatkowski [mailto:nicho...
Just some notes on Starling:
* Starling is written in AS3, so that'd need to be ported to HaXe along
with everything else (unless you just use it for the Flash target).
* Native Apps: Starling uses Stage3D, which NME doesn't (yet) support
(afaik, and I did just look somewhat recently). I supp
I'd like to have some doubts on that but I haven't, let's wait for the
anouncement.
-Message d'origine-
From: Gordon Smith
Sent: Monday, November 19, 2012 1:55 AM
To: flex-dev@incubator.apache.org
Subject: RE: Flex 5 in haxe
My guess is that once V12 makes it
My guess is that once V12 makes its debut, V11 feature addition will drop off
dramatically.
- Gordon
-Original Message-
From: sébastien Paturel [mailto:sebpatu.f...@gmail.com]
Sent: Saturday, November 17, 2012 8:58 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe
ok
/ p1=p0-(f(x)/f'(x)) Newton's Method Here
neko.Lib.println("p1 = " + p1);
p0=p1; //switch variables for next iteration
x0=p1; //switch variables for next iteration
}
}
}
-Original Message-
From: Nicholas Kwiatkowski [mailto:nicho...@spoon.as]
Sent: Friday, November
Regarding the guys who wait for Alex to share his thoughts. I dont want to
speak for him but I think that he shared some of his vision in the thread
about FalconJS and the slide presentation. And I think that he stated that
he needs help from the community to create something that makes sense and
c
I'm not saying the future of Flex shouldn't be planned, it should. I am
however hoping that the current, very funcitional solution isn't just dismissed
asap because it might not be future proof. Most of the stuff we are discussing
here isn't much more future proof than the Adobe route with the
> thats good news. but how long can we count on AS3 VM updates before any
new feature will only be for VMNext?
Only Adobe can answer that. But do we need these yet unannounced features?
I agree it would be nice to decouple Flex framework from the Flash Player
long term, short term I'd rather focu
On 11/17/2012 12:31 PM, sébastien Paturel wrote:
yes unity can output swf now.
but they had their own plugin before stage3D.
And unity will compete with Adobe on the tooling part which is where
Adobe wants to make money.
I don't believe that is a complete understanding.
Not all of Adobe's
Nope, haven't used Catalyst and have only done minor project maintainance in
Flash Pro and that is not my thing, working with timelines and such.
Design view isn't gone yet and even if it does go away next year or smth it
won't stop working all of a sudden in the then current Flash Builder.
And
On 17.11.2012, at 16:39, sébastien Paturel wrote:
> 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 bi
again thats true only today and still for a little few years from now,
just because HTML5 is not fully ready yet.
i really don't understand your optimism about flash runtimes, when even
Adobe made a big shift to HTML5, and narrowed flash runtimes to a
specific area.
i personnaly was still opti
I'm not willing to bet on plugin architecture or that Firefox won't solve
their video encoder issues sometime soon. And I am not willing to ride on
the coat tails o the gaming industry either. Have you seen the hits Zynga
is taking on their stock? Games are a dime a dozen and so are the platforms
t
Yeah well Firefox is in a hole re the Flash plugin because they need it for
video playback (H264) which btw is driving a lot of web usage these days.
I haven't been following the dev of the Chrome pepper stuff so I can't comment
on that. I do use Flash in Chrome a lot though and haven't had any
yes unity can output swf now.
but they had their own plugin before stage3D.
And unity will compete with Adobe on the tooling part which is where
Adobe wants to make money.
Le 17/11/2012 18:28, Jeffry Houser a écrit :
On 11/17/2012 11:39 AM, sébastien Paturel wrote:
if tomorrow Adobe dont manag
On 11/17/2012 11:39 AM, sébastien Paturel wrote:
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)
And can outputs a SWF [which at the moment is ideal for desktop
browser
Thats dangerous bet...
and even if " current Flex deployment scenario is viable for many more
years" it may be true, but for how long? 5 years? and next? given the
big task it is to change this dependency, it has to be prepared right
now, and can't wait the end of that ultimatum...
don't you t
And they may well do just that, I obviously have no control over that. I am
just taking at face value what they say their current strategy is and adding to
that my reading of the browser/mobile landscape, the future of browser plugins,
etc, and adding all that up my conclusion is that the curre
ok sorry for the bad assumption.
thats good news. but how long can we count on AS3 VM updates before any
new feature will only be for VMNext?
Le 17/11/2012 17:52, Justin Mclean a écrit :
Hi,
Adobe's roadmap continue to believe in flash player and AIR. ok. but not at all
for enterprise Apps
Hi,
> 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.
Web workers are in Flash Player 11.4 (ie existing AS3 VM) which we
and were you using Catalyst also?
Knowing that Adobe will drop the design view, and flash catalyst don't
make you think much less confident about their roadmap and the place of
flex in it?
Le 17/11/2012 17:44, Hordur Thordarson a écrit :
Well, this will always be different for everyone. I p
Hi,
yes i totally agree.
thats why the haxe way seems better for now. And thats why i still don't
see any satisfying way to keep flex in AS3 for its long term future.
Justin, you did not answer "what is the essence of flex" for you? :)
Le 17/11/2012 17:41, Justin Mclean a écrit :
Hi,
can f
Well, this will always be different for everyone. I personally don't like
IntelliJ, do like FlashBuilder/Eclipse (use Eclipse for all my Java dev as
well) and I use the design view in every single Flex app I've written so far
and don't see that changing. For instance, the design view allows me
Hi,
> can flex outputed to HTML/JS perform as good as flex outputed to flash
> runtimes?
Well as we can't do that yet it's an unknown. However from what I've seen of
the Falcon JS compiler the answer is that ActionScript running in flash runtime
is much faster. However it's not just a mater of
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,
On 17.11.2012, at 14:53, Nils Dupont wrote:
> @Hordur
> If we are all participating to this discussion on this mailing list, I
> think it is because we all love Flex framework! :)
Yep, you've got me there Nils, I'm totally a sucker for Flex :-)
> But we can't escape the pressure of customers com
On Saturday, November 17, 2012, Hordur Thordarson wrote:
> >
> 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.
>
>
Bingo!
Also, Adobe can s
On 11/17/2012 11:20 AM, Hordur Thordarson wrote:
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, many are afraid that Adobe ma
> 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 different
On 11/17/12 5:14 AM, "Nils Dupont" wrote:
> Has anyone tried to make a bridge between Apache Flex and Apache Cordova?
I'm currently trying to see how well FalconJS output works with Cordova.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
for 1 - check haxe and nme, its made for cross platform from the ground
up, so yes. but im not expert/
for 2- if we would not be doomed to re write it, i would be the first to
be happy. but when Alex is the first to call for a rewrite because a
rearchitecturing is too difficult to get enough mod
"I think that Haxe is such a "all use cases" solution when AS3 + Cordova is
not (unless someone proves the contrary)."
Of course not, it is what I said a few times in this discussion.
I don't know Haxe, another time, and I have nothing against the perspective
of using this technology.
But just 2 qu
maybe there was a misunderstanding here justin.
i was talking about HTML5 performances, not Flex.
so my question is:
can flex outputed to HTML/JS perform as good as flex outputed to flash
runtimes?
maybe i could ask it another way: can the next flex (re written)
outputed to HTML/JS perform as g
Hi Carlos,
By the way thank you for the initiative :)
Yes i agree that theres a point about simple use cases against complex
app use cases.
But if we must consider different solution for every target, it will be
much more difficult to achieve and maintain, compared to a global
solution which ca
HI,
> but you don't get it anymore in the next flash builder versions, because of
> the Adobe's strategy shift.
Incorrect Adobe are Releasing Flash Build 4.8 (currently in beta) [1] and there
are other IDEs eg IntelliJ that you can use. Both support Apche Flex.
Thanks,
Justin
1. http://labs.ad
On Sat, Nov 17, 2012 at 3:30 PM, Hordur Thordarson wrote:
> 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
Hi,
> What i read here and there is that the performances are poor.
Don't believe everything you read. Performance is good for most use cases. Can
you write 60 fps full 3d games will millions of polygons on the screen at once
in Flex? Probably not but then that's not what it's for. There were so
@Hordur
If we are all participating to this discussion on this mailing list, I
think it is because we all love Flex framework! :)
But we can't escape the pressure of customers coming to us with the
recurring question: Why Flex and not HTML5?
This question is easy to answer / to argument concerning
we are not talking about exploying to mobile browsers but about using
HTML5 engine for native apps like Cordova does.
And again, thats not what the industry is doing TODAY. but tomorrow, we
can except that the same shift that we observed on Desktop will happen
on Mobiles, and see the apps going
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
While I understand the desire to deploy mobile apps to mobile browsers, I would
just point out again that this is not what the industry is doing, and there are
reasons for that.
The reasons are that in the mobile browser you can't get the same performance,
the same UI experience and the same
What i read here and there is that the performances are poor.
if a proof of concept shows that Cordova can make intensive apps runing
on HTML5, fine. but i just doubt it.
Le 17/11/2012 15:10, Nils Dupont a écrit :
When you say HTML5 is not ready yet for entreprise RIA, I agree with you
for des
> 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
When you say HTML5 is not ready yet for entreprise RIA, I agree with you
for desktop applications (it is what I added in nota bene) because of
current browser fragmentation (there are still companies using IE7...), but
in the mobile world, browsers are far in advance concerning HTML5/JS. And
it app
Hi Sebastien,
I have use cases where I would need something tiny to be deployed to the
browser. We have huge products based on Flex/JEE, and our interface can do
lots of things. But our product could be in mobile browsers integrated in
diferent webs. We cannot do this right now without targeting H
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
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
> Does not cordova on
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
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 servic
> 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 "
On 17.11.2012, at 03:32, Jeffry Houser wrote:
> On 11/16/2012 10:25 PM, Hordur Xtest2 Imap wrote:
>> Also, when Steve J started his crusade against Flash on the iPhone, part of
>> the argument was HTML5 is so good you can do anything with that, that you
>> can do in Flash. Fast forward a few yea
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 stripp
project,
hopefully it will someday be Flex again however.
-Original Message-
From: Justin Mclean
Sent: Saturday, November 17, 2012 8:35 AM
To: flex-dev@incubator.apache.org
Subject: Re: Flex 5 in haxe
Hii Gorgon,
Are developers on this list still able to earn a living building new
Hii Gorgon,
> Are developers on this list still able to earn a living building new Flex
> apps, or are you maintaining old ones?
Yes. Doing a bit of both.
Justin
On 11/16/12 6:23 PM, "jude" wrote:
> That is my point in staying with what we have. The Flex SDK has had some
> constraints on it that made it what it is today. I'm not against starting a
> new or full rewrite but I would say let's get this project going on the
> current code base first. Let's
On 11/16/2012 10:25 PM, Hordur Xtest2 Imap wrote:
Also, when Steve J started his crusade against Flash on the iPhone, part of the
argument was HTML5 is so good you can do anything with that, that you can do in
Flash. Fast forward a few years and the reality is almost all mobile apps are
native
Well I dont agree with this.
If we narrow down the discussion a bit and just talk about Flex apps in the
browser, then as far as I know there are only two usable ways of running apps
there, via Flash player or as HTML/JS. One way depends on Adobe technology and
the other on the implementation o
On Fri, Nov 16, 2012 at 4:13 PM, Alex Harui wrote:
> Keep in mind that I'm the biggest proponent of the full re-write. We may
> still find a few performance mistakes in the current code (like the Chart
> styles init that just got fixed), but really, some very smart people have
> spent a lot of t
1 - 100 of 159 matches
Mail list logo
