On Tue, Feb 28, 2012 at 06:24, Arnoud Bos <arn...@artim-interactive.nl>
wrote:
>
> On 27-02-2012, at 21:11, Niel Drummond wrote:
>
> > Hello list,
> >
> > There are some fair points made in this thread.
> >
> > Why waste resources on a HTML/js target when flex is far too far behind
> > equivalent javascript frameworks? There are some arguments against this
> > though: cross-compiling brings about new ways of using existing
> > methodologies, new ways of using existing tools, and a body of existing
> > knowledge that would otherwise simply go to waste. Javascript is not
> known
> > for type safety, rigorous testing methodology, large-scale applications
> > produced by large development teams, so many developers switching to this
> > runtime will simply have to adapt to a development mindset geared towards
> > the quality and productivity metrics of the runtime.
>
> Yup that's why we want to keep our beloved Flex alive. I guess most of us
> don't want to go back in time to program directly in an inferior language.
> Having different target for flex would be great. I guess we all agree on
> that.
> The viability of realizing this worries me. I have a feeling many
> people here would rather first focus on improving the current SDK, keeping
> the clients
> happy (And dream about a cross compiling one :)
>
>
Agreed 100%. Can count on me to help on that. We studied lots of other
options, but we always come back to Flex.
*Rafael Santos - CEO at Specta *(*Tecnologia nas Nuvens*)
*Tel*: +55-21-2236-7723 / 3173-7223
*Mobile*: +55-21-9432-9266
Twitter: @rafaelspecta <http://twitter.com/rafaelspecta>
rsantos at spectacompany.com.br
http://www.spectati.com.br
>
> > The "point" of cross-compiling to javascript, is to have a premium
> > framework with premium tools producing premium products on a runtime
> > otherwise known for flakier variants. If you take the attitude of "who
> > cares, flash is here now, when js arrives I will move to xyz framework",
> > this seems like passing an opportunity to leapfrog the competition, and a
> > lack of experience in the javascript industry.
>
> That is definitely an opportunity. haxenme is a great example of a solid
> move in that direction.
>
> But I'm still not sure if Haxe is the answer. And the reason is not
> purely from a technical point of view. I believe haxe is very capable.
> Point is that
> Flex has a rich enterprise ecosystem. Tools like FlexPMD, Sonar,
> FlexFormatter, maven(?),
> premium support in Intellij (i know haxe is coming) are not easily
> replaced. Furthermore there are many code examples (tour the flex for
> example),
> Spring integration, many Java Backend solutions, top notch frameworks like
> Parsley, SpringActionscript, Swiz, there is much documentation available,
> books on advanced topics. etc... Switching to Haxe means leaving
> those behind too (or porting them of course...). The question is if our
> clients
> would be willing to change and leave those behind.
>
> On the other hand it's also doubtful if all of those enterprise tools will
> evolve
> with the future changes of actionscript and the runtimes as the focus for
> Adobe
> will be on gaming and video. I wish i knew. Times are uncertain.
>
> I do see however that Haxe is growing and that the number of libraries
> is growing fast. Personally i am going to invest time in Haxe.
> But i'm not sure if the enterprise will. They move slowly.
>
> > As already pointed out, those of us who don't see the flash player as a
> > viable runtime for future proofing, will probably spend little time
> > improving the flash parts of flex, so it's no use arguing where the brunt
> > of the open source work should go. People will decide for themselves if
> > they want to take part in flex, depending on the direction the
> development
> > takes it.
>
> > I think the more relevant question is: if a branch of the flex code
> occurs,
> > that goes into an alternative js/HTML compiler, who is going to be
> backing
> > it with sweat and coding ? Will it be a part of the official repo, or an
> > outcast ? What compiler will it use ? Any other question is beating
> around
> > the bush.
> >
> > I personally don't think haxe has a syntax that is different from
> > actionscript (it is based on AS3 and is a subset).
>
> I'm just learning Haxe (and like it a lot) but i think categorizing haxe
> as a
> subset of actionscript does not give enough credit to it. Although Haxe
> lacks
> support for e4x and namespaces (do we really need those?), it has many
> features not available in actionscript: using, macro's, inlining, real
> generics, native enums,
> native iterators, type inference to name a few.
>
> > The learning curve for
> > actionscript developers is trivial, it is a small step compared to
> learning
> > javascript, C++ or scala.
>
> true, i started learning scala but Haxe is way more actionscript like. It
> feels natural
> to me as an actionscript dev. And it's very consistent.
>
> > Citing this as a reason against haxe, is really
> > an argument against change of technology in general, staying with the AVM
> > runtime, and hoping against a slow and meaningless extinction.
>
> Yes it's a bit risky road as Adobe took some unexpected steps and cannot
> guarantee
> it wont do that again. But on the other hand Adobe is investing heavily in
> faster actionscript
> in the runtimes which directly benefits us. Falcon will have a mutithreaded
> architecture and as most computers come with a quad core now it will
> probably very fast.
> Let's hope they follow the new roadmap and not do the same as they did
> with the one that was presented to me at Adobe max a few months ago.
>
> I still would not want to rule out Haxe as a viable option for a "Flex
> Next" but i have
> the feeling there are not enough people here having the same feeling.
> Focus seems on
> maintaining the current SDK and improving it. Seems like a good idea to me.
> Without maintaining / maintaining flex 4.x it will be dead soon.
>
> But I guess it could be an idea to port a smaller UI framework to Haxe
> first. Maybe reflex is a
> nice option. It's a smaller flex like framework made by Ben Stucki.
> Translating the classes
> with as3hx could be a start. Then we also could see what problems one
> would encounter
> porting a flex like framework to haxe. If porting works we could see how
> that performs with both
> haxe(nme) js/html5 and swf output. The framework supports lists and
> itemrenderers
> so making some complex UI with that could at least give a clue of what we
> are dealing with.
> Of course there would be still MANY challenges ahead, (like MXML
> compilation)
> but at least we would have something concrete to talk about.
>
> I'm still very busy with a big project for a month. After that i have time
> to dig into this. Could be a nice feasibility study and a way to further
> learn haxe.
> Not sure what i'm getting myself into but it looks like a nice experiment
> to me :-)
>
>
> >
> > - Niel
> >
> > On Mon, Feb 27, 2012 at 6:38 PM, Maciek Sakrejda <m.sakre...@gmail.com
> >wrote:
> >
> >>> Of course, if we talk about dumping all Flex display code, maybe this
> >>> is no longer a Flex framework project but an independent
> >>> ActionScript-to-JS cross-compiler (which may or may not support some
> >>> subset of the Flex framework).
> >>
> >> Also, the haXe solution being discussed may be more reasonable in this
> >> context...
> >>
>
> Met vriendelijke groet,
>
> Arnoud Bos
> Artim interactive
> T +31 6 246 40 216
> E arn...@artim-interactive.nl
>
>
>
>
