Skip to first unread message
Itzik Arzoni
Dec 19, 2015, 3:20:37 PM12/19/15
to Haxe
Hi guys.
Here's a short update about what happened after my presentation.
As you know, I've presented Haxe and it's abilities to the company's R&D forum, which was consisted from CTO's and R&D managers from all of the departments.
And it was a pretty good success. There are some good new.
Altho, sadly, in my department, the idea of using Haxe as a compiler to JavaScript or as a solution to their client requirement was pretty ridiculed. They know and understand the power of Haxe, as I presented it, but had so much bad experience with another "compile to JS" solution, that they don't even consider trying.
However, and this is big one: I was called to a meeting with one of the bigger departments R&D chief and he told me he is going to push OpenFL as a solution to their client requirements.
He told me he was very excited to see the presentation, because he tried and searched for different solutions, and this is exactly what he needs.
He want to try a POC of converting a Flash client to OpenFL, and push it as the next technology. He also want to speak to some Server developers to get them to try Haxe.
I will also present my perzi presentation in front of a bigger international audience, and this time I will pay a lot of attention to the video. So stay tuned.
Here's a short update about what happened after my presentation.
As you know, I've presented Haxe and it's abilities to the company's R&D forum, which was consisted from CTO's and R&D managers from all of the departments.
And it was a pretty good success. There are some good new.
Altho, sadly, in my department, the idea of using Haxe as a compiler to JavaScript or as a solution to their client requirement was pretty ridiculed. They know and understand the power of Haxe, as I presented it, but had so much bad experience with another "compile to JS" solution, that they don't even consider trying.
However, and this is big one: I was called to a meeting with one of the bigger departments R&D chief and he told me he is going to push OpenFL as a solution to their client requirements.
He told me he was very excited to see the presentation, because he tried and searched for different solutions, and this is exactly what he needs.
He want to try a POC of converting a Flash client to OpenFL, and push it as the next technology. He also want to speak to some Server developers to get them to try Haxe.
I will also present my perzi presentation in front of a bigger international audience, and this time I will pay a lot of attention to the video. So stay tuned.
Philippe Elsass
Dec 19, 2015, 3:55:34 PM12/19/15
to Haxe
Well I'm not sure that is such great news. And what other "compile to JS" thing did they try with such problems. I personally really minimise what Haxe JS is: if they would consider es6/babel or typescript, and/or spaghetti systems like webpack, then Haxe JS is nothing ridiculous or risky. It is even arguably much easier to learn for people with former AS3 or Java experience.
Openfl on the other hand is OK in the hands of a team with strong C++ experience. Like TiVo for instance. But AFAIK Prezi doesn't use openfl: last time they talked about it, it was Haxe JS in the browser, and classical native mobile apps with a Haxe JS core to process their presentation models.
Philippe
Stephane Le Dorze
Dec 19, 2015, 6:17:05 PM12/19/15
to Haxe
Hi Philippe,
About prezi usage of Haxe to process presentation models inside a native app, I would really appreciate if you could share any link / prezi that expose their experience going that path.
Itzik Arzoni
Dec 20, 2015, 2:22:16 AM12/20/15
to Haxe
Here's Co-Founder of Perzi talking about it in World Haxe Conference:
https://www.youtube.com/watch?v=ZS-8yknnbsU
https://www.youtube.com/watch?v=ZS-8yknnbsU
Message has been deleted
Itzik Arzoni
Dec 20, 2015, 2:39:07 AM12/20/15
to Haxe
Hi Phillipe, the bad experience they had was with Script Sharp. I don't know anything about it, but I know how frustrated they are developing with it (you know the paradox of legacy code), so now when deciding to refactor, they take no chances (other than using angular with typescript)...
I didn't say perzi was done with OpenFL, but it was made with Haxe. What he asked me was a solution that will allow him to make a skinnable platform using swf assets as skins and be exported to HTML5, and try to reuse as much code as possible from the current flash client. OpenFl answer these requests. I assume that after POC we will know better.
I didn't say perzi was done with OpenFL, but it was made with Haxe. What he asked me was a solution that will allow him to make a skinnable platform using swf assets as skins and be exported to HTML5, and try to reuse as much code as possible from the current flash client. OpenFl answer these requests. I assume that after POC we will know better.
Justin L Mills
Dec 20, 2015, 6:58:33 AM12/20/15
to haxe...@googlegroups.com
I think as long as they are using Angular 3 they will be ok! ;) if
not perhaps they should switch to Haxe and do without such crutches.
If your a Starwars fan you should consider Haxe the force and Typescript one of the tools of the Empire :)
On the Openfl choice, I think they should definitely look at the other haxe cross target solutions as well and aim where possible to make code not too dependant on any particular haxe cross target solution by keeping good separation of view/render and logic code so that they will be free to use the best emerging Haxe technologies where needed.
If your a Starwars fan you should consider Haxe the force and Typescript one of the tools of the Empire :)
On the Openfl choice, I think they should definitely look at the other haxe cross target solutions as well and aim where possible to make code not too dependant on any particular haxe cross target solution by keeping good separation of view/render and logic code so that they will be free to use the best emerging Haxe technologies where needed.
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.
Itzik Arzoni
Dec 20, 2015, 7:34:11 AM12/20/15
to Haxe
How would you consider porting a pretty big flash client to Haxe with as little as possible code rewrite, if not using NME or OpenFl?
Of course that if they will want to build it all from scratch, than of course making as much encapsulation as possible of the display is the right way. But if most of your code is written in flash, than a flash api is what you need, am I right?
Of course that if they will want to build it all from scratch, than of course making as much encapsulation as possible of the display is the right way. But if most of your code is written in flash, than a flash api is what you need, am I right?
Lars Doucet
Dec 20, 2015, 8:49:28 AM12/20/15
to Haxe
@Itzik Arzoni:
Pretty much; if all you want is cross-platform transpiling, than any Haxe framework will do. If you need the Flash API (and in particular, support for swf files), OpenFL and/or NME should be your first stop.
Flambe is not a bad alternative to consider, as it can do many flash-like things in HTML5, but it has a different pipeline for using vector art assets (convert them using FLUMP), and it does not have native targets.
Justin L Mills
Dec 20, 2015, 9:28:12 AM12/20/15
to haxe...@googlegroups.com
It's hard to say without seeing code base, but if you have stuff in
feathers, you probably should rewrite it anyway, my experiance is
that it's often inflexible and buggy, I have been moving a lot of
feathers components to custom renderTexture structure and using less
inheritance with flat displayobject structure using maybe nested
control structures only, certainly the first step is to stop
inheriting Sprite all the time and to move away from using
EventDispatcher, some form of macro signal is lightly to be far
lighter, and more and more global oldschool mouse/touch events seem
more reliable to use with starling than the built in ones that seem
to not work well without inheritance and that approach may well be
simpler to work like Kha for instance.
For the data layer, with haxe remoting or http://haxe.org/manual/std-Json-parsing.html both front end and backend you may find it much easier to throw away the loading code and perhaps some of the models for something simpler and more efficient, it's my experiance that when two languages are involved the interface between them is sometimes widly complex and seems to leave my brain aching and desparate when with pure haxe I could just remote the infomation fully structured without missing data and avoid many parsing mistakes.
So once you start moving your code to never inherit display objects, use signals or function communication - you will end up with a project that could be ported to NME, Luxe, Flambe or even Kha. Non flash apps are often more image / textfield based without the inheritance sprite, even looking at starling the basic stuff is just images and text, so it's about flattening your graphics rendering structures and only building abstract control structures instead that are not flash specifc, like using a single renderTexture to draw a scroller of pages of images/text, most targets like lime, snow, kha with have something like a rendertexture.
Once you have the code in a less Sprite centric structure and have removed large enterprise frameworks like robotlegs, that will be a pain to port and are probably just crutches, then you can start moving code to Haxe and compiling it as a swf/swc that is compiled within your as3 application.
Certainly it's viable to create projects that can run on multiple cross target Haxe solutions you only have to look at the work me and another haxe collegue have done on porting Daedalus from as3 to Haxe ( hxDaedalus ) with it now running on luxe, flambe, swing, canvas, openfl, nme, svg, and that was quite a vector drawing project, which kind of why yet to create a Kha version, as may need to think more triangles and more about the approaches in general. Certainly it's not ideal approach but you can build up toolsets that allow flexibility especially if you share them with community.
Anyway these are just suggested approaches based on my own work, I am still working on the management where I work to give Haxe a proper chance, they seem a bit more interested when I chatted to them at the christmas party, especially as we seem to have a developer for every target, half of them being expensive freelancers far better if we atleast modulized some of the ip into NME modules for the mobile targets and perhaps luxe or haxe js svg for js - or whatever haxe framework seems stable and efficient.
That's the great aspect about Haxe you don't have to commit fully, you can just create some modules that provide cross target functionality.
Best of luck with your exploration of Haxe.
Justin
For the data layer, with haxe remoting or http://haxe.org/manual/std-Json-parsing.html both front end and backend you may find it much easier to throw away the loading code and perhaps some of the models for something simpler and more efficient, it's my experiance that when two languages are involved the interface between them is sometimes widly complex and seems to leave my brain aching and desparate when with pure haxe I could just remote the infomation fully structured without missing data and avoid many parsing mistakes.
So once you start moving your code to never inherit display objects, use signals or function communication - you will end up with a project that could be ported to NME, Luxe, Flambe or even Kha. Non flash apps are often more image / textfield based without the inheritance sprite, even looking at starling the basic stuff is just images and text, so it's about flattening your graphics rendering structures and only building abstract control structures instead that are not flash specifc, like using a single renderTexture to draw a scroller of pages of images/text, most targets like lime, snow, kha with have something like a rendertexture.
Once you have the code in a less Sprite centric structure and have removed large enterprise frameworks like robotlegs, that will be a pain to port and are probably just crutches, then you can start moving code to Haxe and compiling it as a swf/swc that is compiled within your as3 application.
Certainly it's viable to create projects that can run on multiple cross target Haxe solutions you only have to look at the work me and another haxe collegue have done on porting Daedalus from as3 to Haxe ( hxDaedalus ) with it now running on luxe, flambe, swing, canvas, openfl, nme, svg, and that was quite a vector drawing project, which kind of why yet to create a Kha version, as may need to think more triangles and more about the approaches in general. Certainly it's not ideal approach but you can build up toolsets that allow flexibility especially if you share them with community.
Anyway these are just suggested approaches based on my own work, I am still working on the management where I work to give Haxe a proper chance, they seem a bit more interested when I chatted to them at the christmas party, especially as we seem to have a developer for every target, half of them being expensive freelancers far better if we atleast modulized some of the ip into NME modules for the mobile targets and perhaps luxe or haxe js svg for js - or whatever haxe framework seems stable and efficient.
That's the great aspect about Haxe you don't have to commit fully, you can just create some modules that provide cross target functionality.
Best of luck with your exploration of Haxe.
Justin
Itzik Arzoni
Dec 20, 2015, 2:36:33 PM12/20/15
to Haxe
So much information, tahnk you!!
On Sunday, 20 December 2015 16:28:12 UTC+2, JLM wrote:
It's hard to say without seeing code base, but if you have stuff in feathers, you probably should rewrite it anyway, my experiance is that it's often inflexible and buggy, I have been moving a lot of feathers components to custom renderTexture structure and using less inheritance with flat displayobject structure using maybe nested control structures only, certainly the first step is to stop inheriting Sprite all the time and to move away from using EventDispatcher, some form of macro signal is lightly to be far lighter, and more and more global oldschool mouse/touch events seem more reliable to use with starling than the built in ones that seem to not work well without inheritance and that approach may well be simpler to work like Kha for instance.
I understand the Sprite and display list is a big drain of CPU and resources. Event in Flash itself it is better to do everything flat based on TileSheet animation. I am a big fan of the Signals event method, are they implemented in Haxe using macros?
In any case, shouldn't this approach be saved for when optimizing? Than, after a "dumb" conversion from flash, it would be possible to optimize in Haxe.
In any case, shouldn't this approach be saved for when optimizing? Than, after a "dumb" conversion from flash, it would be possible to optimize in Haxe.
For the data layer, with haxe remoting or http://haxe.org/manual/std-Json-parsing.html both front end and backend you may find it much easier to throw away the loading code and perhaps some of the models for something simpler and more efficient, it's my experiance that when two languages are involved the interface between them is sometimes widly complex and seems to leave my brain aching and desparate when with pure haxe I could just remote the infomation fully structured without missing data and avoid many parsing mistakes.
Wait, Do you mean that even if the server is written in .net or php, Haxe can still be used to make only the remoting parts, and communicating with the client? If so, this is amazing, I didn't realize it!
So once you start moving your code to never inherit display objects, use signals or function communication - you will end up with a project that could be ported to NME, Luxe, Flambe or even Kha. Non flash apps are often more image / textfield based without the inheritance sprite, even looking at starling the basic stuff is just images and text, so it's about flattening your graphics rendering structures and only building abstract control structures instead that are not flash specifc, like using a single renderTexture to draw a scroller of pages of images/text, most targets like lime, snow, kha with have something like a rendertexture.
Once you have the code in a less Sprite centric structure and have removed large enterprise frameworks like robotlegs, that will be a pain to port and are probably just crutches, then you can start moving code to Haxe and compiling it as a swf/swc that is compiled within your as3 application.
This get back to the first paragraph: Do you think that rewriting the
client IN FLASH almost from scratch, than port it to Haxe, is the better approach than trying to somehow
translate it, and than optimize in Haxe? (After all, even if the display list is flat or
encapsulated, most of the other client does relay on flash api, because
it was initially written in Flash.)
Certainly it's viable to create projects that can run on multiple cross target Haxe solutions you only have to look at the work me and another haxe collegue have done on porting Daedalus from as3 to Haxe ( hxDaedalus ) with it now running on luxe, flambe, swing, canvas, openfl, nme, svg, and that was quite a vector drawing project, which kind of why yet to create a Kha version, as may need to think more triangles and more about the approaches in general. Certainly it's not ideal approach but you can build up toolsets that allow flexibility especially if you share them with community.
It's a nice library. I'll see how to integrate it with one of the future projects.
I would like to give back to the community libraries and things I've written (As long as it is usefull), but for this articular case, it is a matter of consulting the company's policy.
I would like to give back to the community libraries and things I've written (As long as it is usefull), but for this articular case, it is a matter of consulting the company's policy.
Anyway these are just suggested approaches based on my own work, I am still working on the management where I work to give Haxe a proper chance, they seem a bit more interested when I chatted to them at the christmas party, especially as we seem to have a developer for every target, half of them being expensive freelancers far better if we atleast modulized some of the ip into NME modules for the mobile targets and perhaps luxe or haxe js svg for js - or whatever haxe framework seems stable and efficient.
That's the great aspect about Haxe you don't have to commit fully, you can just create some modules that provide cross target functionality.
This approach sound really good, but this what scaries the most out of the man I've talked to: The possibility to have *Another* code base to maintain, written in Haxe.
Best of luck with your exploration of Haxe.
Justin
Thank you!!
Message has been deleted
Itzik Arzoni
Dec 20, 2015, 2:40:14 PM12/20/15
to Haxe
Thanks. Right now I need t convert a project written in Flash. So OpenFl seems the first choice.
Philippe Elsass
Dec 20, 2015, 5:48:20 PM12/20/15
to Haxe
So they have the pain of maintaining a ScriptSharp project - would be curious of the problems they have, but last time I checked, a few years ago, it was kind of like GWT: cross-compilation of C#/Java is a very heavy build process, with complicated JS-interop mechanisms. That's a pretty bad precedent though as they will feel burned by the promise of "reusable code" across platforms. However insist that Haxe is much closer to JS than C#/Java (you can show comparisons of generated code).
But again, I'd suggest you describe a bit more the kind of projet do you intend porting, and on what platform.
Be careful not to fall for the "sunk cost fallacy": it's not because you have a lot of Flash UIs that it is going to be better to emulate the Flash player. Maybe rewriting the views is a better decision if there will be a lot of changes to do in order to achieve the port. That said, the value of Haxe stays: it will be easy to reuse code with minor changes.
Philippe
PS:
- stick to JSON+typedefs if you don't want to frighten them too much with Haxe,
- Haxe signals, like msignal, aren't macro based, but they are strongly typed and work with all Haxe targets, so it's a good event mechanism (but without bubbling).
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.
--
Philippe
Reply all
Reply to author
Forward
0 new messages