incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hordur Thordarson <hor...@lausn.is>
Subject Re: [POLL] - Must Flex 5 be a complete rewrite or can flex code base be re-architectured?
Date Fri, 16 Nov 2012 16:57:01 GMT
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
>>>>>> 
>>>>>> 
> 


Mime
View raw message