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 :) > > 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
