You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by sébastien Paturel <se...@gmail.com> on 2012/11/16 13:49:37 UTC
[POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
After several discussions about the difficulty to break UIComponent for
example, and the whole re-architecturing of flex SDK issue.
I'd like to launch this poll to see if there's a consensus about it.
So in your opinion flex SDk:
1- Need a complete re write
2- Can be re architectured from the current code base
Thanks
RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code
base be re-architecture?
Posted by Antonio Ortiz <ze...@hotmail.com>.
Option 2 ... +1 this time, the next we NEED a complete re write
> -----Original Message-----
> From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
> Sent: Friday, November 16, 2012 7:50
> To: flex-dev@incubator.apache.org
> Subject: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
>
> After several discussions about the difficulty to break UIComponent for
> example, and the whole re-architecturing of flex SDK issue.
> I'd like to launch this poll to see if there's a consensus about it.
>
> So in your opinion flex SDk:
>
> 1- Need a complete re write
> 2- Can be re architectured from the current code base
>
> Thanks
>
RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
As an extra complication, I would hope that whatever the end state is, it supports client certificates from the OS's certificate store to make SSL connections. Currently browser based apps and Air apps can do this easily.
-Mark
-----Original Message-----
From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
Sent: Friday, November 16, 2012 9:38
To: flex-dev@incubator.apache.org
Subject: Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
If you find the magic solution fine :)
But let me doubt of such a magic solution, when i see that Adobe did
tried this path. When FalconJS is only prototype and far to be
efficient. When Haxe made some changes to AS3 especially to be able to
compile efficiently to many targets.
Le 16/11/2012 15:07, Kessler CTR Mark J a écrit :
> I would say it's possible given how it's compiled. So having a robust compiler or different compilers for different target environments could be possible.
>
> -----Original Message-----
> From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
> Sent: Friday, November 16, 2012 8:54
> To: flex-dev@incubator.apache.org
> Subject: Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
>
> "Having more deployed targets based on what we have currently"
> But is it possible? thats the question...
>
> Le 16/11/2012 14:50, Kessler CTR Mark J a écrit :
>> Option 2 ... +1
>>
>> I would think the community is already based around the current framework. Having more deployed targets based on what we have currently sounds like a way to broaden our target audience.
>>
>> How about we continue to correct and fix the current Flex framework. Could we start a new namespace that we could use to build up a partial new framework for a future transition to? It just feels like rewriting everything from scratch would take a long time and would basically be a separate project.
>>
>> I'm also envisioning the amount of work the developers using Flex will have to go through to convert to a completely new framework.
>>
>> -Mark
>>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architecture?
Posted by sébastien Paturel <se...@gmail.com>.
If you find the magic solution fine :)
But let me doubt of such a magic solution, when i see that Adobe did
tried this path. When FalconJS is only prototype and far to be
efficient. When Haxe made some changes to AS3 especially to be able to
compile efficiently to many targets.
Le 16/11/2012 15:07, Kessler CTR Mark J a écrit :
> I would say it's possible given how it's compiled. So having a robust compiler or different compilers for different target environments could be possible.
>
> -----Original Message-----
> From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
> Sent: Friday, November 16, 2012 8:54
> To: flex-dev@incubator.apache.org
> Subject: Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
>
> "Having more deployed targets based on what we have currently"
> But is it possible? thats the question...
>
> Le 16/11/2012 14:50, Kessler CTR Mark J a écrit :
>> Option 2 ... +1
>>
>> I would think the community is already based around the current framework. Having more deployed targets based on what we have currently sounds like a way to broaden our target audience.
>>
>> How about we continue to correct and fix the current Flex framework. Could we start a new namespace that we could use to build up a partial new framework for a future transition to? It just feels like rewriting everything from scratch would take a long time and would basically be a separate project.
>>
>> I'm also envisioning the amount of work the developers using Flex will have to go through to convert to a completely new framework.
>>
>> -Mark
>>
RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
Posted by Ian Appleby <Ia...@bcs.org>.
To be clear, would the intention here to be a limited subset for
multi-platform, with everything maintained for swf legacy?
Perhaps dumping mx and keeping spark, or some subtler equiv? Or to have mx
as an additional module only available on swf?
- Ian
-----Original Message-----
From: Kessler CTR Mark J [mailto:mark.kessler.ctr@usmc.mil]
Sent: 16 November 2012 14:07
To: flex-dev@incubator.apache.org
Subject: RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code
base be re-architecture?
I would say it's possible given how it's compiled. So having a robust
compiler or different compilers for different target environments could be
possible.
-----Original Message-----
From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
Sent: Friday, November 16, 2012 8:54
To: flex-dev@incubator.apache.org
Subject: Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code
base be re-architecture?
"Having more deployed targets based on what we have currently"
But is it possible? thats the question...
Le 16/11/2012 14:50, Kessler CTR Mark J a écrit :
> Option 2 ... +1
>
> I would think the community is already based around the current
framework. Having more deployed targets based on what we have currently
sounds like a way to broaden our target audience.
>
> How about we continue to correct and fix the current Flex framework.
Could we start a new namespace that we could use to build up a partial new
framework for a future transition to? It just feels like rewriting
everything from scratch would take a long time and would basically be a
separate project.
>
> I'm also envisioning the amount of work the developers using Flex will
have to go through to convert to a completely new framework.
>
> -Mark
>
RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
I would say it's possible given how it's compiled. So having a robust compiler or different compilers for different target environments could be possible.
-----Original Message-----
From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
Sent: Friday, November 16, 2012 8:54
To: flex-dev@incubator.apache.org
Subject: Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
"Having more deployed targets based on what we have currently"
But is it possible? thats the question...
Le 16/11/2012 14:50, Kessler CTR Mark J a écrit :
> Option 2 ... +1
>
> I would think the community is already based around the current framework. Having more deployed targets based on what we have currently sounds like a way to broaden our target audience.
>
> How about we continue to correct and fix the current Flex framework. Could we start a new namespace that we could use to build up a partial new framework for a future transition to? It just feels like rewriting everything from scratch would take a long time and would basically be a separate project.
>
> I'm also envisioning the amount of work the developers using Flex will have to go through to convert to a completely new framework.
>
> -Mark
>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architecture?
Posted by sébastien Paturel <se...@gmail.com>.
"Having more deployed targets based on what we have currently"
But is it possible? thats the question...
Le 16/11/2012 14:50, Kessler CTR Mark J a écrit :
> Option 2 ... +1
>
> I would think the community is already based around the current framework. Having more deployed targets based on what we have currently sounds like a way to broaden our target audience.
>
> How about we continue to correct and fix the current Flex framework. Could we start a new namespace that we could use to build up a partial new framework for a future transition to? It just feels like rewriting everything from scratch would take a long time and would basically be a separate project.
>
> I'm also envisioning the amount of work the developers using Flex will have to go through to convert to a completely new framework.
>
> -Mark
>
> -----Original Message-----
> From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
> Sent: Friday, November 16, 2012 7:50
> To: flex-dev@incubator.apache.org
> Subject: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
>
> After several discussions about the difficulty to break UIComponent for
> example, and the whole re-architecturing of flex SDK issue.
> I'd like to launch this poll to see if there's a consensus about it.
>
> So in your opinion flex SDk:
>
> 1- Need a complete re write
> 2- Can be re architectured from the current code base
>
> Thanks
>
RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Option 2 ... +1
I would think the community is already based around the current framework. Having more deployed targets based on what we have currently sounds like a way to broaden our target audience.
How about we continue to correct and fix the current Flex framework. Could we start a new namespace that we could use to build up a partial new framework for a future transition to? It just feels like rewriting everything from scratch would take a long time and would basically be a separate project.
I'm also envisioning the amount of work the developers using Flex will have to go through to convert to a completely new framework.
-Mark
-----Original Message-----
From: sébastien Paturel [mailto:sebpatu.flex@gmail.com]
Sent: Friday, November 16, 2012 7:50
To: flex-dev@incubator.apache.org
Subject: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
After several discussions about the difficulty to break UIComponent for
example, and the whole re-architecturing of flex SDK issue.
I'd like to launch this poll to see if there's a consensus about it.
So in your opinion flex SDk:
1- Need a complete re write
2- Can be re architectured from the current code base
Thanks
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by Stefan Horochovec <st...@gmail.com>.
Well.
As I said in a previous email, without knowing properly how will the AS4
and especially the AVMNext, I think is hard to guess that the best option
is this moment. The unique concrete information we have is an email from
Thibault warning about using Stage3D instead of DisplayObject.
When we talk about the future of a framework, just use it as information
for a decision such as this strikes me as inconsistent. However, if it is
necessary to rewrite the SDK, compiler, etc.. re-structuring the
architecture of the SDK can be quite interesting.
Regards
Stefan Horochovec
2012/11/16 sébastien Paturel <se...@gmail.com>
> After several discussions about the difficulty to break UIComponent for
> example, and the whole re-architecturing of flex SDK issue.
> I'd like to launch this poll to see if there's a consensus about it.
>
> So in your opinion flex SDk:
>
> 1- Need a complete re write
> 2- Can be re architectured from the current code base
>
> Thanks
>
>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
On Fri, Nov 16, 2012 at 11:57 AM, Hordur Thordarson <ho...@lausn.is> wrote:
>
> There are only two visible deployment options going forward, Adobe's VM or
> HTML. Both have plusses and minuses and my view is that HTML has many more
> minuses, at least currently, and I just don't see that changing in the near
> future. When the browser vendors can't even agree on basic things like
> video playback, sound playback, socket support and more, I don't see HTML
> becoming a replacement for Flash player/AIR. It is more likely that Flash
> player/Air tech dies and we'll be left with only HTML. At which point I'll
> find myself another career ;-)
>
>
How do you figure that? I see that as two options, only if you consider
the browser as an output. When you consider that a majority of Flex
applications are now targeting AIR as a way to get to native execution on
mobile, tablet, television and the desktop there is a lot more you can
target...
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Posted by Hordur Thordarson <ho...@lausn.is>.
On 16.11.2012, at 16:30, sébastien Paturel wrote:
> "I agree that the strategy should be maintain and enhance the current framework while planning/preparing for the future."
> Yes and talking about a complete rewrite has to be figured out quite early if we want to be ready when we need.
Sure, agreed.
>
> "usable solution to that problem so I can easily deploy to an app for Android/iOS with the same code base"
> Yes for now and maybe 5 years max if we're lucky. But after that? even during this 5 years timeframe, any new device, tv or whatever will use HTML5 for sure, but will they embed flash player or AIR?
> If we don't think of the future without Adobe runtimes right now, flex will be stuck to the current targets, and will be totally dependant to Adobes strategy with gaming. it seems quite dangerous for me.
There are only two visible deployment options going forward, Adobe's VM or HTML. Both have plusses and minuses and my view is that HTML has many more minuses, at least currently, and I just don't see that changing in the near future. When the browser vendors can't even agree on basic things like video playback, sound playback, socket support and more, I don't see HTML becoming a replacement for Flash player/AIR. It is more likely that Flash player/Air tech dies and we'll be left with only HTML. At which point I'll find myself another career ;-)
>
> "simply because HTML5 still has years to go before it can support the data-rich apps that Flex in Flash player/AIR excels at"
> Yes, and what you do when HTML5 is ready? flex will have no future because its too late to start something.
> We don't need to target HTML5 in the mobile browser with flex today OK. we target natives app OK, but threw AIR runtime, and flex is totally dependant to what Adobe will decide to do, but knowing that Adobe don't care about the future of Flex anymore, and is pushing a lot the HTML5 tools.
> and even without talking about HTML5, flex also need to target native apps without AIR dependency.
> Look, flex already can't target linux anymore because of Adobe decisions... Haxe can for example.
Yep, to bad Linux isn't supported any more. But business reality is however that supporting Windows, Mac and mobile, and doing so well, is more important. And Adobe's stuff does that better than anything else right now in my view.
>
> Le 16/11/2012 17:10, Hordur Thordarson a écrit :
>
>
>> Well, I got the feeling that some users on this list were advocating a total rewrite asap rather than maintaining and improving the current codebase. A new Flex framework, built in Haxe or some other language than AS3/MXML is a totally new framework that will have no support for the current codebase, which means I'm either stuck with the current technology or I have to rewrite all my stuff and unfortunately rewrites just-for-the-fun-of-it are hard to sell to clients.
>>
>> I agree that the strategy should be maintain and enhance the current framework while planning/preparing for the future.
>>
>> Yes, unfortunately Steve Jobs managed to kill Flash in mobile browsers (ok, other things contributed as well :-), so I can't deploy to Flash player in mobile browsers, but AIR is a perfectly usable solution to that problem so I can easily deploy to an app for Android/iOS with the same code base.
>>
>>> "writing yet another Gui framework on top of HTML/JS/CSS"
>>> Noone is proposing such a thing.
>>> Flex needs to be cross platform and with OOP language.
>> I didn't mean that a new Flex would be written IN Html/Js/Css. But some see the solution to the Adobe VM dependency being to deploy to Html/Js/Css, generated by Haxe or some other tool. I don't, not because there is anything wrong with Haxe or whatever other tool would be used, but simply because HTML5 still has years to go before it can support the data-rich apps that Flex in Flash player/AIR excels at, and that can't be fixed at the compiler level because in the end you just get Html/Js/Css that the browser executes, with all the plusses and minuses that come with that technology stack.
>>
>>> But the question is: does keeping AS3 make it possible to target OTHER runtimes like HTML5, or any other new in the future?
>> I guess the answer to that is probably no.
>> Another question though would be do you want to target HTML5 as a runtime ? I certainly don't for now at least and many small miracles have to happen in the HTML/browser world for that to change for me. Keep in mind that most mobile development development today fex is via native apps. This is because the HTML5 browser apps can't compete either on the development side or on the execution/functionality side.
>>
>>> "Which means that there is plenty of time to wait for other, better deployment possibilities to come along"
>>> I don't understand what and from who you are waiting somthing new for such a purpose?
>> Well, I guess I don't know either what it would be or where it would come from :-)
>> I just want to deploy to desktop browsers and mobile apps, preferably with the same or mostly same source code. If smth other than AS3/Adobe AVM allows me to do that with the same ease and power, AND it has less risks attached than sticking with AS3/Adobe VM, then I'd probably use that.
>>
>> On 16.11.2012, at 14:34, sébastien Paturel wrote:
>>
>>> i don't see any conflit here.
>>> it's timeframe consideration.
>>> In short term we maintain and make little enhancements (like better performances, with starling for example) to the current framework which has still viability for several years (not over 5 i think)
>>> And we prepare the long term, with a new code base rewrite.
>>>
>>> If you develop browser based front-ends you already has an issue with flex, as it will not run in tablets browsers !
>>>
>>> "writing yet another Gui framework on top of HTML/JS/CSS"
>>> Noone is proposing such a thing.
>>> Flex needs to be cross platform and with OOP language.
>>>
>>> "The runtime is free, easy to get and works the same in every browser almost since time began"
>>> Changing the source language does not mean that we don't deploy to the flash runtimes.
>>> Haxe is doing that very well.
>>> But the question is: does keeping AS3 make it possible to target OTHER runtimes like HTML5, or any other new in the future?
>>>
>>> "Which means that there is plenty of time to wait for other, better deployment possibilities to come along"
>>> I don't understand what and from who you are waiting somthing new for such a purpose?
>>>
>>>
>>> Le 16/11/2012 15:07, Hordur Thordarson a écrit :
>>>
>>>> Good points made by Ben and I totally agree that the rewrite-or-not decision cannot be made without first knowing if this project is to be about maintaining and improving the current Flex framework, or about creating a new and then possibly very different framework with little or no legacy support.
>>>>
>>>> I develop browser based database front-ends and I have to say that there is nothing out there that comes anywhere close to rivaling the maturity, abilities, development speed and deployment conveniance of the current Flex/Flash player combo. So while I understand the problem of being tied to the AS3 VM and Flash player, unfortunately this same combo is a big part of what makes Flex attractive to enterprize developers. The runtime is free, easy to get and works the same in every browser almost since time began. Building database front-ends and data vizualisation tools in HTML/JS/CSS requires you to give up a large chunk of your sanity, because the technology is immature and non-standardized, the toolset is years behind what Flex has and at deployment time you have to deal with endless browser diffs and bugs.
>>>>
>>>> So I certainly had hoped that Apache Flex would be about improving the current framework rather than ditching it and writing yet another Gui framework on top of HTML/JS/CSS.
>>>>
>>>> My opinion is, having read what there is to be had, about Adobe's intentions with the Flash player and ActionScript, that Flash player isn't going anywhere. And while it is there, it will most likely include the AS3 VM just like it has had the AS2 VM for years. Which means that there is plenty of time to wait for other, better deployment possibilities to come along.
>>>>
>>>> On 16.11.2012, at 13:55, Joan Llenas Masó wrote:
>>>>
>>>>> Flex to me is:
>>>>> 1. Cross browser/platform
>>>>> 2. MXML.
>>>>> 3. Modularity
>>>>> 4. Spark architecture
>>>> I would agree with this, BUT, and for many of us I think this is a big BUT, I would add #5 which is the extremely easy, well known deployment of client apps to any desktop where Flash player is available.
>>>>
>>>> Those are my two cents :)
>>>>
>>>> Hörður Þórðarson
>>>> Lausn
>>>> Iceland
>>>>
>>>> On 16.11.2012, at 13:28, Ben Dalton wrote:
>>>>
>>>>> It depends on the goals of the Flex project. If we are looking to create
>>>>> something that is purpose built for the Flash runtime, then I don't believe
>>>>> so.
>>>>>
>>>>> However, if we are looking at Flex as a toolkit to build rich interfaces
>>>>> and are willing to break from the SWF compile target being our core focus,
>>>>> then I believe yes.
>>>>>
>>>>> I think that question really needs to be answered first.
>>>>>
>>>>> While I love Flex as-is, we are seeing Adobe's priorities change for the
>>>>> runtime and even some version fragmentation that we hadn't before (pepper
>>>>> flash player in chrome and the MS flash player built into metro IE). It
>>>>> pains me to say this but it looks like the standard HTML js CSS world is
>>>>> receiving all of the developer efforts right now and I think that we should
>>>>> make that a focus if we want this project to survive and thrive beyond the
>>>>> next year or two.
>>>>>
>>>>> There is a conflict of interest here which I'm sure we are all aware of.
>>>>> The goals of building the best toolkit for rich applications for mass
>>>>> consumption and the goals of enhancing the current toolkit to continue
>>>>> servicing our enterprise clients seem to be in conflict.
>>>>>
>>>>> This is my two cents of an opinion and I will be glad if I am mistaken.
>>>>>
>>>>>
>>>>>
>>>>> On Friday, November 16, 2012, sébastien Paturel wrote:
>>>>>
>>>>>> After several discussions about the difficulty to break UIComponent for
>>>>>> example, and the whole re-architecturing of flex SDK issue.
>>>>>> I'd like to launch this poll to see if there's a consensus about it.
>>>>>>
>>>>>> So in your opinion flex SDk:
>>>>>>
>>>>>> 1- Need a complete re write
>>>>>> 2- Can be re architectured from the current code base
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>
RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code
base be re-architectured?
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>You're probably right, but for the minority who did write separate business logic, I think this will be the path of least resistance. And for those who didn't, it still might be easier to refactor >their code to get separation than have to rewrite every line. Anyway, that's the angle I'm taking for now. I can certainly be convinced otherwise. And it has the advantage that we have in >Apache Flex, every line of code we need to make it happen.
Fully agree, just providing perspective to the resistance.
>Now where is the link to your slides?
>Touché. Will send them over
Mike
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code
base be re-architectured?
Posted by Alex Harui <ah...@adobe.com>.
On 11/16/12 12:27 PM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
>> Because I expect the major factor in deciding what to do with your existing
>> apps is about the cost of moving. For sure, if you completely abandon Flex
>> you will have to rewrite all of your >views and all of your business logic.
>> If I offered a solutions where you still had to rewrite your views but not
>> too much of your business logic, I think that would make it an attractive
>> choice.
>
> Alex,
>
> There is one problem/fallacy here. The vast majority of the world did not
> write code in which their business logic was separate from their view. So,
> from that perspective, it is a full rerite.
>
Mike,
You're probably right, but for the minority who did write separate business
logic, I think this will be the path of least resistance. And for those who
didn't, it still might be easier to refactor their code to get separation
than have to rewrite every line. Anyway, that's the angle I'm taking for
now. I can certainly be convinced otherwise. And it has the advantage that
we have in Apache Flex, every line of code we need to make it happen.
Now where is the link to your slides?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code
base be re-architectured?
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>Because I expect the major factor in deciding what to do with your existing apps is about the cost of moving. For sure, if you completely abandon Flex you will have to rewrite all of your >views and all of your business logic.
>If I offered a solutions where you still had to rewrite your views but not too much of your business logic, I think that would make it an attractive choice.
Alex,
There is one problem/fallacy here. The vast majority of the world did not write code in which their business logic was separate from their view. So, from that perspective, it is a full rerite.
Mike
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by Joan Llenas Masó <jo...@garnetworks.com>.
>
> I can't wait to ear about what you have to propose for the #2 objective.
> Maybe thats why you are more confident about the "keep AS3" solution.
>
>
Same here!
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code
base be re-architectured?
Posted by Alex Harui <ah...@adobe.com>.
On 11/16/12 9:26 AM, "sébastien Paturel" <se...@gmail.com> wrote:
> Le 16/11/2012 17:53, Alex Harui a écrit :
>> I still remain
>> convinced that once you force folks to rewrite their business logic in
>> another language, then they are more likely to review all of the
>> possibilities out there, and there are currently many, like Sencha,
>> PhoneGap/Cordova, going native for mobile
> But they are JS frameworks and native dev is not comparable to multi
> platform development.
Cordova is definitely about multi-platform.
> In fact i think that some flex users already made a switch to native dev
> because of the lack of visibility for flex future.
>
> I can't wait to ear about what you have to propose for the #2 objective.
> Maybe thats why you are more confident about the "keep AS3" solution.
> But your final objective is to get full backward compatibility at the end?
I don't think full backward-compatibility is a requirement, but IMO, it is
most important for the business logic and that's where it should be easiest
to transcode as it should have fewer platform dependencies.
> Because you are the one who convinced me that a full rewrite was
> inavitable, so if we don't have full compability at the end of the
> rewrite, why using AS3 is so important for third party code already
> existing?
Because I expect the major factor in deciding what to do with your existing
apps is about the cost of moving. For sure, if you completely abandon Flex
you will have to rewrite all of your views and all of your business logic.
If I offered a solutions where you still had to rewrite your views but not
too much of your business logic, I think that would make it an attractive
choice.
>
> Do you think that trying to keep things like AS3 won't be paid by huge
> performances issues?
That's my hope. Still needs to be proven. IMO, the performance issues you
are hitting are due to the bad code in the framework, not AS3 itself.
That's why folks who do skip Flex and just write AS3 apps seem to have fewer
performance complaints.
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by sébastien Paturel <se...@gmail.com>.
Le 16/11/2012 17:53, Alex Harui a écrit :
> I still remain
> convinced that once you force folks to rewrite their business logic in
> another language, then they are more likely to review all of the
> possibilities out there, and there are currently many, like Sencha,
> PhoneGap/Cordova, going native for mobile
But they are JS frameworks and native dev is not comparable to multi
platform development.
In fact i think that some flex users already made a switch to native dev
because of the lack of visibility for flex future.
I can't wait to ear about what you have to propose for the #2 objective.
Maybe thats why you are more confident about the "keep AS3" solution.
But your final objective is to get full backward compatibility at the end?
Because you are the one who convinced me that a full rewrite was
inavitable, so if we don't have full compability at the end of the
rewrite, why using AS3 is so important for third party code already
existing?
Do you think that trying to keep things like AS3 won't be paid by huge
performances issues?
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code
base be re-architectured?
Posted by Alex Harui <ah...@adobe.com>.
It was nice to hear that some of you are still creating new apps or
modifying existing apps and Flash/AIR runs in enough places to satisfy you.
I hadn't heard that in quite a while.
My "mandate", which will be a year old in mid-December and could require
updating, and doesn't have to apply to anyone else in this project, is to do
two things:
1) fix important bugs so folks still working with Flex on Flash/AIR can get
their work done
2) provide a migration path off of Flash/AIR
I spent the first 11 months of Apache Flex getting donations in from Adobe
so we can execute on #1, and have spent this week on #2 trying to make sure
that the FalconJS code will actually generate something useful when it
lands.
There are other threads going on today about Haxe and AS4. I still remain
convinced that once you force folks to rewrite their business logic in
another language, then they are more likely to review all of the
possibilities out there, and there are currently many, like Sencha,
PhoneGap/Cordova, going native for mobile, or even Mike Labriola's new
project that he presented at 360Min and uses C# which I hope he will provide
a link to. Adobe was able to move folks from AS2 to AS3 because AS3 was
AS2-compatible and because it was a clearly better option since Flash was
faster than JS and truly ran everwhere. This is not the case anymore, and
none of these other languages are going to be as AS3-compatible.
Anyway, I am awaiting management clearance to actually drop some code into
Apache SVN. Then I will have something more tangible to discuss about how
to do #2. But I will warn you now, my vision is radical, but the goal is to
maintain what I think of as the essence of Flex which matches well with
Joan's list, but also include AS3 as the glue code in the MXML.
But for now, I am hopeful we have enough energy in the community to execute
on both #1 and #2. I don't think we have to choose one over the other.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by sébastien Paturel <se...@gmail.com>.
"I agree that the strategy should be maintain and enhance the current
framework while planning/preparing for the future."
Yes and talking about a complete rewrite has to be figured out quite
early if we want to be ready when we need.
"usable solution to that problem so I can easily deploy to an app for
Android/iOS with the same code base"
Yes for now and maybe 5 years max if we're lucky. But after that? even
during this 5 years timeframe, any new device, tv or whatever will use
HTML5 for sure, but will they embed flash player or AIR?
If we don't think of the future without Adobe runtimes right now, flex
will be stuck to the current targets, and will be totally dependant to
Adobes strategy with gaming. it seems quite dangerous for me.
"simply because HTML5 still has years to go before it can support the
data-rich apps that Flex in Flash player/AIR excels at"
Yes, and what you do when HTML5 is ready? flex will have no future
because its too late to start something.
We don't need to target HTML5 in the mobile browser with flex today OK.
we target natives app OK, but threw AIR runtime, and flex is totally
dependant to what Adobe will decide to do, but knowing that Adobe don't
care about the future of Flex anymore, and is pushing a lot the HTML5 tools.
and even without talking about HTML5, flex also need to target native
apps without AIR dependency.
Look, flex already can't target linux anymore because of Adobe
decisions... Haxe can for example.
Le 16/11/2012 17:10, Hordur Thordarson a écrit :
> Well, I got the feeling that some users on this list were advocating a total rewrite asap rather than maintaining and improving the current codebase. A new Flex framework, built in Haxe or some other language than AS3/MXML is a totally new framework that will have no support for the current codebase, which means I'm either stuck with the current technology or I have to rewrite all my stuff and unfortunately rewrites just-for-the-fun-of-it are hard to sell to clients.
>
> I agree that the strategy should be maintain and enhance the current framework while planning/preparing for the future.
>
> Yes, unfortunately Steve Jobs managed to kill Flash in mobile browsers (ok, other things contributed as well :-), so I can't deploy to Flash player in mobile browsers, but AIR is a perfectly usable solution to that problem so I can easily deploy to an app for Android/iOS with the same code base.
>
>> "writing yet another Gui framework on top of HTML/JS/CSS"
>> Noone is proposing such a thing.
>> Flex needs to be cross platform and with OOP language.
> I didn't mean that a new Flex would be written IN Html/Js/Css. But some see the solution to the Adobe VM dependency being to deploy to Html/Js/Css, generated by Haxe or some other tool. I don't, not because there is anything wrong with Haxe or whatever other tool would be used, but simply because HTML5 still has years to go before it can support the data-rich apps that Flex in Flash player/AIR excels at, and that can't be fixed at the compiler level because in the end you just get Html/Js/Css that the browser executes, with all the plusses and minuses that come with that technology stack.
>
>> But the question is: does keeping AS3 make it possible to target OTHER runtimes like HTML5, or any other new in the future?
> I guess the answer to that is probably no.
> Another question though would be do you want to target HTML5 as a runtime ? I certainly don't for now at least and many small miracles have to happen in the HTML/browser world for that to change for me. Keep in mind that most mobile development development today fex is via native apps. This is because the HTML5 browser apps can't compete either on the development side or on the execution/functionality side.
>
>> "Which means that there is plenty of time to wait for other, better deployment possibilities to come along"
>> I don't understand what and from who you are waiting somthing new for such a purpose?
> Well, I guess I don't know either what it would be or where it would come from :-)
> I just want to deploy to desktop browsers and mobile apps, preferably with the same or mostly same source code. If smth other than AS3/Adobe AVM allows me to do that with the same ease and power, AND it has less risks attached than sticking with AS3/Adobe VM, then I'd probably use that.
>
> On 16.11.2012, at 14:34, sébastien Paturel wrote:
>
>> i don't see any conflit here.
>> it's timeframe consideration.
>> In short term we maintain and make little enhancements (like better performances, with starling for example) to the current framework which has still viability for several years (not over 5 i think)
>> And we prepare the long term, with a new code base rewrite.
>>
>> If you develop browser based front-ends you already has an issue with flex, as it will not run in tablets browsers !
>>
>> "writing yet another Gui framework on top of HTML/JS/CSS"
>> Noone is proposing such a thing.
>> Flex needs to be cross platform and with OOP language.
>>
>> "The runtime is free, easy to get and works the same in every browser almost since time began"
>> Changing the source language does not mean that we don't deploy to the flash runtimes.
>> Haxe is doing that very well.
>> But the question is: does keeping AS3 make it possible to target OTHER runtimes like HTML5, or any other new in the future?
>>
>> "Which means that there is plenty of time to wait for other, better deployment possibilities to come along"
>> I don't understand what and from who you are waiting somthing new for such a purpose?
>>
>>
>> Le 16/11/2012 15:07, Hordur Thordarson a écrit :
>>
>>> Good points made by Ben and I totally agree that the rewrite-or-not decision cannot be made without first knowing if this project is to be about maintaining and improving the current Flex framework, or about creating a new and then possibly very different framework with little or no legacy support.
>>>
>>> I develop browser based database front-ends and I have to say that there is nothing out there that comes anywhere close to rivaling the maturity, abilities, development speed and deployment conveniance of the current Flex/Flash player combo. So while I understand the problem of being tied to the AS3 VM and Flash player, unfortunately this same combo is a big part of what makes Flex attractive to enterprize developers. The runtime is free, easy to get and works the same in every browser almost since time began. Building database front-ends and data vizualisation tools in HTML/JS/CSS requires you to give up a large chunk of your sanity, because the technology is immature and non-standardized, the toolset is years behind what Flex has and at deployment time you have to deal with endless browser diffs and bugs.
>>>
>>> So I certainly had hoped that Apache Flex would be about improving the current framework rather than ditching it and writing yet another Gui framework on top of HTML/JS/CSS.
>>>
>>> My opinion is, having read what there is to be had, about Adobe's intentions with the Flash player and ActionScript, that Flash player isn't going anywhere. And while it is there, it will most likely include the AS3 VM just like it has had the AS2 VM for years. Which means that there is plenty of time to wait for other, better deployment possibilities to come along.
>>>
>>> On 16.11.2012, at 13:55, Joan Llenas Masó wrote:
>>>
>>>> Flex to me is:
>>>> 1. Cross browser/platform
>>>> 2. MXML.
>>>> 3. Modularity
>>>> 4. Spark architecture
>>> I would agree with this, BUT, and for many of us I think this is a big BUT, I would add #5 which is the extremely easy, well known deployment of client apps to any desktop where Flash player is available.
>>>
>>> Those are my two cents :)
>>>
>>> Hörður Þórðarson
>>> Lausn
>>> Iceland
>>>
>>> On 16.11.2012, at 13:28, Ben Dalton wrote:
>>>
>>>> It depends on the goals of the Flex project. If we are looking to create
>>>> something that is purpose built for the Flash runtime, then I don't believe
>>>> so.
>>>>
>>>> However, if we are looking at Flex as a toolkit to build rich interfaces
>>>> and are willing to break from the SWF compile target being our core focus,
>>>> then I believe yes.
>>>>
>>>> I think that question really needs to be answered first.
>>>>
>>>> While I love Flex as-is, we are seeing Adobe's priorities change for the
>>>> runtime and even some version fragmentation that we hadn't before (pepper
>>>> flash player in chrome and the MS flash player built into metro IE). It
>>>> pains me to say this but it looks like the standard HTML js CSS world is
>>>> receiving all of the developer efforts right now and I think that we should
>>>> make that a focus if we want this project to survive and thrive beyond the
>>>> next year or two.
>>>>
>>>> There is a conflict of interest here which I'm sure we are all aware of.
>>>> The goals of building the best toolkit for rich applications for mass
>>>> consumption and the goals of enhancing the current toolkit to continue
>>>> servicing our enterprise clients seem to be in conflict.
>>>>
>>>> This is my two cents of an opinion and I will be glad if I am mistaken.
>>>>
>>>>
>>>>
>>>> On Friday, November 16, 2012, sébastien Paturel wrote:
>>>>
>>>>> After several discussions about the difficulty to break UIComponent for
>>>>> example, and the whole re-architecturing of flex SDK issue.
>>>>> I'd like to launch this poll to see if there's a consensus about it.
>>>>>
>>>>> So in your opinion flex SDk:
>>>>>
>>>>> 1- Need a complete re write
>>>>> 2- Can be re architectured from the current code base
>>>>>
>>>>> Thanks
>>>>>
>>>>>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by Omar Gonzalez <om...@gmail.com>.
On Fri, Nov 16, 2012 at 9:07 AM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> >> They could do a 180 on their views of AIR next November. Then what?
> IMO We'd still have some time to change course, as we could still use
> exiting versions of AIR and captive runtime.
>
> Justin
>
>
I'd rather be prepared for that now since nothing is stopping us from doing
so. :)
-omar
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
>> They could do a 180 on their views of AIR next November. Then what?
IMO We'd still have some time to change course, as we could still use exiting versions of AIR and captive runtime.
Justin
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Posted by Hordur Thordarson <ho...@lausn.is>.
> They could do a 180 on their
> views of AIR next November. Then what?
Well, then I'd be buggered for sure, that's the risk :-)
> This view is a little narrow minded. I would say apps like Gmail are pretty
> data-rich, and it runs great
Unfortunately the resources required to write and maintain a JS app like Gmail are not available to most of us. And to be clear, I do write lots of JS code so I am not totally ignorant on the subejct. And for all the effort that Google pours into Gmail, I think it could be done much better with much less effort with Flex :-)
On 16.11.2012, at 16:39, Omar Gonzalez wrote:
> On Fri, Nov 16, 2012 at 8:10 AM, Hordur Thordarson <ho...@lausn.is> wrote:
>
>> Well, I got the feeling that some users on this list were advocating a
>> total rewrite asap rather than maintaining and improving the current
>> codebase. A new Flex framework, built in Haxe or some other language than
>> AS3/MXML is a totally new framework that will have no support for the
>> current codebase, which means I'm either stuck with the current technology
>> or I have to rewrite all my stuff and unfortunately rewrites
>> just-for-the-fun-of-it are hard to sell to clients.
>>
>> I agree that the strategy should be maintain and enhance the current
>> framework while planning/preparing for the future.
>>
>> Yes, unfortunately Steve Jobs managed to kill Flash in mobile browsers
>> (ok, other things contributed as well :-), so I can't deploy to Flash
>> player in mobile browsers, but AIR is a perfectly usable solution to that
>> problem so I can easily deploy to an app for Android/iOS with the same code
>> base.
>>
>
> Yes, rewrites just for the fun of it are impracticable, but betting on the
> long term future of Flex as a multi-platform technology on a closed source
> runtime such as Adobe AIR is a huge gamble. They could do a 180 on their
> views of AIR next November. Then what?
>
>
>>
>>> "writing yet another Gui framework on top of HTML/JS/CSS"
>>> Noone is proposing such a thing.
>>> Flex needs to be cross platform and with OOP language.
>>
>> I didn't mean that a new Flex would be written IN Html/Js/Css. But some
>> see the solution to the Adobe VM dependency being to deploy to Html/Js/Css,
>> generated by Haxe or some other tool. I don't, not because there is
>> anything wrong with Haxe or whatever other tool would be used, but simply
>> because HTML5 still has years to go before it can support the data-rich
>> apps that Flex in Flash player/AIR excels at, and that can't be fixed at
>> the compiler level because in the end you just get Html/Js/Css that the
>> browser executes, with all the plusses and minuses that come with that
>> technology stack.
>>
>>
> This view is a little narrow minded. I would say apps like Gmail are pretty
> data-rich, and it runs great. I don't believe that HTML5 needs years before
> it is viable for data-rich applications, that is happening now. Granted
> there are technical capabilities that are yet to arrive in HTML5, but I
> don't expect it to be years before its completely caught up with Flash
> Player's capabilities that are commonly exploited in Flash/Flex
> applications. To put off looking at targeting HTML/JS/CSS would be a bad
> mistake for this framework, in my humble opinion.
>
> -omar
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by Omar Gonzalez <om...@gmail.com>.
On Fri, Nov 16, 2012 at 8:10 AM, Hordur Thordarson <ho...@lausn.is> wrote:
> Well, I got the feeling that some users on this list were advocating a
> total rewrite asap rather than maintaining and improving the current
> codebase. A new Flex framework, built in Haxe or some other language than
> AS3/MXML is a totally new framework that will have no support for the
> current codebase, which means I'm either stuck with the current technology
> or I have to rewrite all my stuff and unfortunately rewrites
> just-for-the-fun-of-it are hard to sell to clients.
>
> I agree that the strategy should be maintain and enhance the current
> framework while planning/preparing for the future.
>
> Yes, unfortunately Steve Jobs managed to kill Flash in mobile browsers
> (ok, other things contributed as well :-), so I can't deploy to Flash
> player in mobile browsers, but AIR is a perfectly usable solution to that
> problem so I can easily deploy to an app for Android/iOS with the same code
> base.
>
Yes, rewrites just for the fun of it are impracticable, but betting on the
long term future of Flex as a multi-platform technology on a closed source
runtime such as Adobe AIR is a huge gamble. They could do a 180 on their
views of AIR next November. Then what?
>
> > "writing yet another Gui framework on top of HTML/JS/CSS"
> > Noone is proposing such a thing.
> > Flex needs to be cross platform and with OOP language.
>
> I didn't mean that a new Flex would be written IN Html/Js/Css. But some
> see the solution to the Adobe VM dependency being to deploy to Html/Js/Css,
> generated by Haxe or some other tool. I don't, not because there is
> anything wrong with Haxe or whatever other tool would be used, but simply
> because HTML5 still has years to go before it can support the data-rich
> apps that Flex in Flash player/AIR excels at, and that can't be fixed at
> the compiler level because in the end you just get Html/Js/Css that the
> browser executes, with all the plusses and minuses that come with that
> technology stack.
>
>
This view is a little narrow minded. I would say apps like Gmail are pretty
data-rich, and it runs great. I don't believe that HTML5 needs years before
it is viable for data-rich applications, that is happening now. Granted
there are technical capabilities that are yet to arrive in HTML5, but I
don't expect it to be years before its completely caught up with Flash
Player's capabilities that are commonly exploited in Flash/Flex
applications. To put off looking at targeting HTML/JS/CSS would be a bad
mistake for this framework, in my humble opinion.
-omar
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Posted by Hordur Thordarson <ho...@lausn.is>.
Well, I got the feeling that some users on this list were advocating a total rewrite asap rather than maintaining and improving the current codebase. A new Flex framework, built in Haxe or some other language than AS3/MXML is a totally new framework that will have no support for the current codebase, which means I'm either stuck with the current technology or I have to rewrite all my stuff and unfortunately rewrites just-for-the-fun-of-it are hard to sell to clients.
I agree that the strategy should be maintain and enhance the current framework while planning/preparing for the future.
Yes, unfortunately Steve Jobs managed to kill Flash in mobile browsers (ok, other things contributed as well :-), so I can't deploy to Flash player in mobile browsers, but AIR is a perfectly usable solution to that problem so I can easily deploy to an app for Android/iOS with the same code base.
> "writing yet another Gui framework on top of HTML/JS/CSS"
> Noone is proposing such a thing.
> Flex needs to be cross platform and with OOP language.
I didn't mean that a new Flex would be written IN Html/Js/Css. But some see the solution to the Adobe VM dependency being to deploy to Html/Js/Css, generated by Haxe or some other tool. I don't, not because there is anything wrong with Haxe or whatever other tool would be used, but simply because HTML5 still has years to go before it can support the data-rich apps that Flex in Flash player/AIR excels at, and that can't be fixed at the compiler level because in the end you just get Html/Js/Css that the browser executes, with all the plusses and minuses that come with that technology stack.
> But the question is: does keeping AS3 make it possible to target OTHER runtimes like HTML5, or any other new in the future?
I guess the answer to that is probably no.
Another question though would be do you want to target HTML5 as a runtime ? I certainly don't for now at least and many small miracles have to happen in the HTML/browser world for that to change for me. Keep in mind that most mobile development development today fex is via native apps. This is because the HTML5 browser apps can't compete either on the development side or on the execution/functionality side.
> "Which means that there is plenty of time to wait for other, better deployment possibilities to come along"
> I don't understand what and from who you are waiting somthing new for such a purpose?
Well, I guess I don't know either what it would be or where it would come from :-)
I just want to deploy to desktop browsers and mobile apps, preferably with the same or mostly same source code. If smth other than AS3/Adobe AVM allows me to do that with the same ease and power, AND it has less risks attached than sticking with AS3/Adobe VM, then I'd probably use that.
On 16.11.2012, at 14:34, sébastien Paturel wrote:
> i don't see any conflit here.
> it's timeframe consideration.
> In short term we maintain and make little enhancements (like better performances, with starling for example) to the current framework which has still viability for several years (not over 5 i think)
> And we prepare the long term, with a new code base rewrite.
>
> If you develop browser based front-ends you already has an issue with flex, as it will not run in tablets browsers !
>
> "writing yet another Gui framework on top of HTML/JS/CSS"
> Noone is proposing such a thing.
> Flex needs to be cross platform and with OOP language.
>
> "The runtime is free, easy to get and works the same in every browser almost since time began"
> Changing the source language does not mean that we don't deploy to the flash runtimes.
> Haxe is doing that very well.
> But the question is: does keeping AS3 make it possible to target OTHER runtimes like HTML5, or any other new in the future?
>
> "Which means that there is plenty of time to wait for other, better deployment possibilities to come along"
> I don't understand what and from who you are waiting somthing new for such a purpose?
>
>
> Le 16/11/2012 15:07, Hordur Thordarson a écrit :
>
>> Good points made by Ben and I totally agree that the rewrite-or-not decision cannot be made without first knowing if this project is to be about maintaining and improving the current Flex framework, or about creating a new and then possibly very different framework with little or no legacy support.
>>
>> I develop browser based database front-ends and I have to say that there is nothing out there that comes anywhere close to rivaling the maturity, abilities, development speed and deployment conveniance of the current Flex/Flash player combo. So while I understand the problem of being tied to the AS3 VM and Flash player, unfortunately this same combo is a big part of what makes Flex attractive to enterprize developers. The runtime is free, easy to get and works the same in every browser almost since time began. Building database front-ends and data vizualisation tools in HTML/JS/CSS requires you to give up a large chunk of your sanity, because the technology is immature and non-standardized, the toolset is years behind what Flex has and at deployment time you have to deal with endless browser diffs and bugs.
>>
>> So I certainly had hoped that Apache Flex would be about improving the current framework rather than ditching it and writing yet another Gui framework on top of HTML/JS/CSS.
>>
>> My opinion is, having read what there is to be had, about Adobe's intentions with the Flash player and ActionScript, that Flash player isn't going anywhere. And while it is there, it will most likely include the AS3 VM just like it has had the AS2 VM for years. Which means that there is plenty of time to wait for other, better deployment possibilities to come along.
>>
>> On 16.11.2012, at 13:55, Joan Llenas Masó wrote:
>>
>>> Flex to me is:
>>> 1. Cross browser/platform
>>> 2. MXML.
>>> 3. Modularity
>>> 4. Spark architecture
>> I would agree with this, BUT, and for many of us I think this is a big BUT, I would add #5 which is the extremely easy, well known deployment of client apps to any desktop where Flash player is available.
>>
>> Those are my two cents :)
>>
>> Hörður Þórðarson
>> Lausn
>> Iceland
>>
>> On 16.11.2012, at 13:28, Ben Dalton wrote:
>>
>>> It depends on the goals of the Flex project. If we are looking to create
>>> something that is purpose built for the Flash runtime, then I don't believe
>>> so.
>>>
>>> However, if we are looking at Flex as a toolkit to build rich interfaces
>>> and are willing to break from the SWF compile target being our core focus,
>>> then I believe yes.
>>>
>>> I think that question really needs to be answered first.
>>>
>>> While I love Flex as-is, we are seeing Adobe's priorities change for the
>>> runtime and even some version fragmentation that we hadn't before (pepper
>>> flash player in chrome and the MS flash player built into metro IE). It
>>> pains me to say this but it looks like the standard HTML js CSS world is
>>> receiving all of the developer efforts right now and I think that we should
>>> make that a focus if we want this project to survive and thrive beyond the
>>> next year or two.
>>>
>>> There is a conflict of interest here which I'm sure we are all aware of.
>>> The goals of building the best toolkit for rich applications for mass
>>> consumption and the goals of enhancing the current toolkit to continue
>>> servicing our enterprise clients seem to be in conflict.
>>>
>>> This is my two cents of an opinion and I will be glad if I am mistaken.
>>>
>>>
>>>
>>> On Friday, November 16, 2012, sébastien Paturel wrote:
>>>
>>>> After several discussions about the difficulty to break UIComponent for
>>>> example, and the whole re-architecturing of flex SDK issue.
>>>> I'd like to launch this poll to see if there's a consensus about it.
>>>>
>>>> So in your opinion flex SDk:
>>>>
>>>> 1- Need a complete re write
>>>> 2- Can be re architectured from the current code base
>>>>
>>>> Thanks
>>>>
>>>>
>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by sébastien Paturel <se...@gmail.com>.
i don't see any conflit here.
it's timeframe consideration.
In short term we maintain and make little enhancements (like better
performances, with starling for example) to the current framework which
has still viability for several years (not over 5 i think)
And we prepare the long term, with a new code base rewrite.
If you develop browser based front-ends you already has an issue with
flex, as it will not run in tablets browsers !
"writing yet another Gui framework on top of HTML/JS/CSS"
Noone is proposing such a thing.
Flex needs to be cross platform and with OOP language.
"The runtime is free, easy to get and works the same in every browser
almost since time began"
Changing the source language does not mean that we don't deploy to the
flash runtimes.
Haxe is doing that very well.
But the question is: does keeping AS3 make it possible to target OTHER
runtimes like HTML5, or any other new in the future?
"Which means that there is plenty of time to wait for other, better
deployment possibilities to come along"
I don't understand what and from who you are waiting somthing new for
such a purpose?
Le 16/11/2012 15:07, Hordur Thordarson a écrit :
> Good points made by Ben and I totally agree that the rewrite-or-not decision cannot be made without first knowing if this project is to be about maintaining and improving the current Flex framework, or about creating a new and then possibly very different framework with little or no legacy support.
>
> I develop browser based database front-ends and I have to say that there is nothing out there that comes anywhere close to rivaling the maturity, abilities, development speed and deployment conveniance of the current Flex/Flash player combo. So while I understand the problem of being tied to the AS3 VM and Flash player, unfortunately this same combo is a big part of what makes Flex attractive to enterprize developers. The runtime is free, easy to get and works the same in every browser almost since time began. Building database front-ends and data vizualisation tools in HTML/JS/CSS requires you to give up a large chunk of your sanity, because the technology is immature and non-standardized, the toolset is years behind what Flex has and at deployment time you have to deal with endless browser diffs and bugs.
>
> So I certainly had hoped that Apache Flex would be about improving the current framework rather than ditching it and writing yet another Gui framework on top of HTML/JS/CSS.
>
> My opinion is, having read what there is to be had, about Adobe's intentions with the Flash player and ActionScript, that Flash player isn't going anywhere. And while it is there, it will most likely include the AS3 VM just like it has had the AS2 VM for years. Which means that there is plenty of time to wait for other, better deployment possibilities to come along.
>
> On 16.11.2012, at 13:55, Joan Llenas Masó wrote:
>
>> Flex to me is:
>> 1. Cross browser/platform
>> 2. MXML.
>> 3. Modularity
>> 4. Spark architecture
> I would agree with this, BUT, and for many of us I think this is a big BUT, I would add #5 which is the extremely easy, well known deployment of client apps to any desktop where Flash player is available.
>
> Those are my two cents :)
>
> Hörður Þórðarson
> Lausn
> Iceland
>
> On 16.11.2012, at 13:28, Ben Dalton wrote:
>
>> It depends on the goals of the Flex project. If we are looking to create
>> something that is purpose built for the Flash runtime, then I don't believe
>> so.
>>
>> However, if we are looking at Flex as a toolkit to build rich interfaces
>> and are willing to break from the SWF compile target being our core focus,
>> then I believe yes.
>>
>> I think that question really needs to be answered first.
>>
>> While I love Flex as-is, we are seeing Adobe's priorities change for the
>> runtime and even some version fragmentation that we hadn't before (pepper
>> flash player in chrome and the MS flash player built into metro IE). It
>> pains me to say this but it looks like the standard HTML js CSS world is
>> receiving all of the developer efforts right now and I think that we should
>> make that a focus if we want this project to survive and thrive beyond the
>> next year or two.
>>
>> There is a conflict of interest here which I'm sure we are all aware of.
>> The goals of building the best toolkit for rich applications for mass
>> consumption and the goals of enhancing the current toolkit to continue
>> servicing our enterprise clients seem to be in conflict.
>>
>> This is my two cents of an opinion and I will be glad if I am mistaken.
>>
>>
>>
>> On Friday, November 16, 2012, sébastien Paturel wrote:
>>
>>> After several discussions about the difficulty to break UIComponent for
>>> example, and the whole re-architecturing of flex SDK issue.
>>> I'd like to launch this poll to see if there's a consensus about it.
>>>
>>> So in your opinion flex SDk:
>>>
>>> 1- Need a complete re write
>>> 2- Can be re architectured from the current code base
>>>
>>> Thanks
>>>
>>>
RE: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architecture?
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
Maybe in this sense we should gather a rough idea of what people have as their needs/targets.
Should we start a [Discussion] thread separately to gather this information?
Looking for things like what you stated a below you... "I develop browser based database front-ends". Collecting the communities current uses could help drive/fuel the decisions for how we migrate vs. just guessing what the possible majority is.
-----Original Message-----
From: Hordur Thordarson [mailto:hordur@lausn.is]
Sent: Friday, November 16, 2012 9:08
To: flex-dev@incubator.apache.org
Subject: Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Good points made by Ben and I totally agree that the rewrite-or-not decision cannot be made without first knowing if this project is to be about maintaining and improving the current Flex framework, or about creating a new and then possibly very different framework with little or no legacy support.
I develop browser based database front-ends and I have to say that there is nothing out there that comes anywhere close to rivaling the maturity, abilities, development speed and deployment conveniance of the current Flex/Flash player combo. So while I understand the problem of being tied to the AS3 VM and Flash player, unfortunately this same combo is a big part of what makes Flex attractive to enterprize developers. The runtime is free, easy to get and works the same in every browser almost since time began. Building database front-ends and data vizualisation tools in HTML/JS/CSS requires you to give up a large chunk of your sanity, because the technology is immature and non-standardized, the toolset is years behind what Flex has and at deployment time you have to deal with endless browser diffs and bugs.
So I certainly had hoped that Apache Flex would be about improving the current framework rather than ditching it and writing yet another Gui framework on top of HTML/JS/CSS.
My opinion is, having read what there is to be had, about Adobe's intentions with the Flash player and ActionScript, that Flash player isn't going anywhere. And while it is there, it will most likely include the AS3 VM just like it has had the AS2 VM for years. Which means that there is plenty of time to wait for other, better deployment possibilities to come along.
On 16.11.2012, at 13:55, Joan Llenas Masó wrote:
> Flex to me is:
> 1. Cross browser/platform
> 2. MXML.
> 3. Modularity
> 4. Spark architecture
I would agree with this, BUT, and for many of us I think this is a big BUT, I would add #5 which is the extremely easy, well known deployment of client apps to any desktop where Flash player is available.
Those are my two cents :)
Hörður Þórðarson
Lausn
Iceland
On 16.11.2012, at 13:28, Ben Dalton wrote:
> It depends on the goals of the Flex project. If we are looking to create
> something that is purpose built for the Flash runtime, then I don't believe
> so.
>
> However, if we are looking at Flex as a toolkit to build rich interfaces
> and are willing to break from the SWF compile target being our core focus,
> then I believe yes.
>
> I think that question really needs to be answered first.
>
> While I love Flex as-is, we are seeing Adobe's priorities change for the
> runtime and even some version fragmentation that we hadn't before (pepper
> flash player in chrome and the MS flash player built into metro IE). It
> pains me to say this but it looks like the standard HTML js CSS world is
> receiving all of the developer efforts right now and I think that we should
> make that a focus if we want this project to survive and thrive beyond the
> next year or two.
>
> There is a conflict of interest here which I'm sure we are all aware of.
> The goals of building the best toolkit for rich applications for mass
> consumption and the goals of enhancing the current toolkit to continue
> servicing our enterprise clients seem to be in conflict.
>
> This is my two cents of an opinion and I will be glad if I am mistaken.
>
>
>
> On Friday, November 16, 2012, sébastien Paturel wrote:
>
>> After several discussions about the difficulty to break UIComponent for
>> example, and the whole re-architecturing of flex SDK issue.
>> I'd like to launch this poll to see if there's a consensus about it.
>>
>> So in your opinion flex SDk:
>>
>> 1- Need a complete re write
>> 2- Can be re architectured from the current code base
>>
>> Thanks
>>
>>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Posted by Hordur Thordarson <ho...@lausn.is>.
Good points made by Ben and I totally agree that the rewrite-or-not decision cannot be made without first knowing if this project is to be about maintaining and improving the current Flex framework, or about creating a new and then possibly very different framework with little or no legacy support.
I develop browser based database front-ends and I have to say that there is nothing out there that comes anywhere close to rivaling the maturity, abilities, development speed and deployment conveniance of the current Flex/Flash player combo. So while I understand the problem of being tied to the AS3 VM and Flash player, unfortunately this same combo is a big part of what makes Flex attractive to enterprize developers. The runtime is free, easy to get and works the same in every browser almost since time began. Building database front-ends and data vizualisation tools in HTML/JS/CSS requires you to give up a large chunk of your sanity, because the technology is immature and non-standardized, the toolset is years behind what Flex has and at deployment time you have to deal with endless browser diffs and bugs.
So I certainly had hoped that Apache Flex would be about improving the current framework rather than ditching it and writing yet another Gui framework on top of HTML/JS/CSS.
My opinion is, having read what there is to be had, about Adobe's intentions with the Flash player and ActionScript, that Flash player isn't going anywhere. And while it is there, it will most likely include the AS3 VM just like it has had the AS2 VM for years. Which means that there is plenty of time to wait for other, better deployment possibilities to come along.
On 16.11.2012, at 13:55, Joan Llenas Masó wrote:
> Flex to me is:
> 1. Cross browser/platform
> 2. MXML.
> 3. Modularity
> 4. Spark architecture
I would agree with this, BUT, and for many of us I think this is a big BUT, I would add #5 which is the extremely easy, well known deployment of client apps to any desktop where Flash player is available.
Those are my two cents :)
Hörður Þórðarson
Lausn
Iceland
On 16.11.2012, at 13:28, Ben Dalton wrote:
> It depends on the goals of the Flex project. If we are looking to create
> something that is purpose built for the Flash runtime, then I don't believe
> so.
>
> However, if we are looking at Flex as a toolkit to build rich interfaces
> and are willing to break from the SWF compile target being our core focus,
> then I believe yes.
>
> I think that question really needs to be answered first.
>
> While I love Flex as-is, we are seeing Adobe's priorities change for the
> runtime and even some version fragmentation that we hadn't before (pepper
> flash player in chrome and the MS flash player built into metro IE). It
> pains me to say this but it looks like the standard HTML js CSS world is
> receiving all of the developer efforts right now and I think that we should
> make that a focus if we want this project to survive and thrive beyond the
> next year or two.
>
> There is a conflict of interest here which I'm sure we are all aware of.
> The goals of building the best toolkit for rich applications for mass
> consumption and the goals of enhancing the current toolkit to continue
> servicing our enterprise clients seem to be in conflict.
>
> This is my two cents of an opinion and I will be glad if I am mistaken.
>
>
>
> On Friday, November 16, 2012, sébastien Paturel wrote:
>
>> After several discussions about the difficulty to break UIComponent for
>> example, and the whole re-architecturing of flex SDK issue.
>> I'd like to launch this poll to see if there's a consensus about it.
>>
>> So in your opinion flex SDk:
>>
>> 1- Need a complete re write
>> 2- Can be re architectured from the current code base
>>
>> Thanks
>>
>>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by Ben Dalton <be...@gmail.com>.
It depends on the goals of the Flex project. If we are looking to create
something that is purpose built for the Flash runtime, then I don't believe
so.
However, if we are looking at Flex as a toolkit to build rich interfaces
and are willing to break from the SWF compile target being our core focus,
then I believe yes.
I think that question really needs to be answered first.
While I love Flex as-is, we are seeing Adobe's priorities change for the
runtime and even some version fragmentation that we hadn't before (pepper
flash player in chrome and the MS flash player built into metro IE). It
pains me to say this but it looks like the standard HTML js CSS world is
receiving all of the developer efforts right now and I think that we should
make that a focus if we want this project to survive and thrive beyond the
next year or two.
There is a conflict of interest here which I'm sure we are all aware of.
The goals of building the best toolkit for rich applications for mass
consumption and the goals of enhancing the current toolkit to continue
servicing our enterprise clients seem to be in conflict.
This is my two cents of an opinion and I will be glad if I am mistaken.
On Friday, November 16, 2012, sébastien Paturel wrote:
> After several discussions about the difficulty to break UIComponent for
> example, and the whole re-architecturing of flex SDK issue.
> I'd like to launch this poll to see if there's a consensus about it.
>
> So in your opinion flex SDk:
>
> 1- Need a complete re write
> 2- Can be re architectured from the current code base
>
> Thanks
>
>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by Joan Llenas Masó <jo...@garnetworks.com>.
I'd go for re-architectured (to be more modular)
That doesn't mean I wouldn't want to port it to another language (haxe),
which would require a complete rewrite...
J
On Fri, Nov 16, 2012 at 2:43 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > Again, i know that Alex already gave a fairly try to break UIComponent
> and concluded that it was very hard, and starting over was much more easier.
> > It would be great if Alex could share this experience with more details.
> Or better yet share the code ;-) Perhaps if the code was made the code
> public someone here on the list might have an insight to getting around
> what problems exist or at the very least we could see where the issues are
> and how hard they might be to solve. I certainly don't doubt that it's a
> difficult problem to solve but we have lots of smart people on the list who
> are willing to have a go go at it.
>
> Could it be easier to break up UI component if not we're not 100%
> backwards compatibility with Flex 4? If there was a clear migration path
> (or better yet a conversion tool) that might be a path to consider.
>
> Thanks,
> Justin
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Again, i know that Alex already gave a fairly try to break UIComponent and concluded that it was very hard, and starting over was much more easier.
> It would be great if Alex could share this experience with more details.
Or better yet share the code ;-) Perhaps if the code was made the code public someone here on the list might have an insight to getting around what problems exist or at the very least we could see where the issues are and how hard they might be to solve. I certainly don't doubt that it's a difficult problem to solve but we have lots of smart people on the list who are willing to have a go go at it.
Could it be easier to break up UI component if not we're not 100% backwards compatibility with Flex 4? If there was a clear migration path (or better yet a conversion tool) that might be a path to consider.
Thanks,
Justin
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by sébastien Paturel <se...@gmail.com>.
@Eric:
As Alex stated we dont need to be as full featured as flex 4 to be
successfull in this path. And if first releases are good, it could bring
more people to accelerate the dev
The question is does "working with what we have" has a future? Its great
for maintenance mode, and keep it do what it does today, but can we
consider a future, meaning a cross platform future with what we have today?
"wouldn't it be an entirely new project?"
IMO no, again it depends on what we consider the essence of flex is.And the API would be quite the same.
@Stefan:
"The unique concrete information we have is an email from Thibault
warning about using Stage3D instead of DisplayObject."
We dont need more informations about VMNext and AS4 i think.
First even if its in AS3, the question of re architecturing still remains.
Second, we already know that the AS3 app will run on VMNext but any
enhancements will occure only in AS4.
We still need to confirm how hard it is to port AS3 to AS4, but it seems
quite a huge work according to people from this list who has access to
the specs of AS4. and if the framework is ported to AS4, how can we
target flash player 10 for example?
@Justin:
Again, if we could keep what we have and go ahead i'd be pleased too.
And starting from scratch sounds like a waste and a step backward for me.
But when i read Alex answers about the current architecture, i must be
more realistic.
Again, i know that Alex already gave a fairly try to break UIComponent
and concluded that it was very hard, and starting over was much more easier.
It would be great if Alex could share this experience with more details.
Le 16/11/2012 13:58, Erik de Bruin a écrit :
> Unless we want to release Flex 5 somewhere in the next decade, if at all,
> my opinion is we work with what we have, which is a lot, and add/change
> what we need.
>
> Also, wouldn't a complete rewrite of the framework, compiler and client
> side (delivery) platforms be an entirely new project?
>
> EdB
>
>
>
> On Fri, Nov 16, 2012 at 1:49 PM, sébastien Paturel
> <se...@gmail.com>wrote:
>
>> After several discussions about the difficulty to break UIComponent for
>> example, and the whole re-architecturing of flex SDK issue.
>> I'd like to launch this poll to see if there's a consensus about it.
>>
>> So in your opinion flex SDk:
>>
>> 1- Need a complete re write
>> 2- Can be re architectured from the current code base
>>
>> Thanks
>>
>>
>
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base
be re-architectured?
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Unless we want to release Flex 5 somewhere in the next decade, if at all,
my opinion is we work with what we have, which is a lot, and add/change
what we need.
Also, wouldn't a complete rewrite of the framework, compiler and client
side (delivery) platforms be an entirely new project?
EdB
On Fri, Nov 16, 2012 at 1:49 PM, sébastien Paturel
<se...@gmail.com>wrote:
> After several discussions about the difficulty to break UIComponent for
> example, and the whole re-architecturing of flex SDK issue.
> I'd like to launch this poll to see if there's a consensus about it.
>
> So in your opinion flex SDk:
>
> 1- Need a complete re write
> 2- Can be re architectured from the current code base
>
> Thanks
>
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> After several discussions about the difficulty to break UIComponent for example, and the whole re-architecturing of flex SDK issue.
> I'd like to launch this poll to see if there's a consensus about it.
>
> So in your opinion flex SDk:
>
> 1- Need a complete re write
> 2- Can be re architectured from the current code base
If pushed I'd go +1 to 2. The current code base is mature, reasonably well tested, has a decent architecture (with some history), mostly works well and has an large existing user base.
I really don't think we explored breaking up UIComponent in any signification way so there's still gains to be made there. IMO it's mostly been talk and considered opinion rather than actual code.
Of course every one is free to do what ever they want and I'd still be interested in option 1 (rewrite) and would help out where I can. They are probably enough people interested in both paths so it doesn't have to be an 1 or 2 option.
Thanks,
Justin