incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Rovira <carlos.rov...@codeoscopic.com>
Subject Re: Cross-compiling Flex to HTML5/Javascript (Was : Update on Falcon donation)
Date Wed, 29 Aug 2012 23:08:36 GMT
Hi Alain,

maybe I was talking too much without own knowledge or experience. I
never use GWT and was talking about what other colleges told me of
their experience and what I read...

so can't really say nothing. Sorry again.

Carlos


2012/8/30 Alain Ekambi <jazzmatadazz@gmail.com>:
> You dont see the relevance of Google making GWT opensource ?
>
> Use the right tool for the right job.
> Why use GWT for a small app ?
>
>
> This is the same for Flex. I see people using Flash/Flex where they should
> not then complain about performance.
>
> If you are not targeting AIR or the Desktop browser you should not even
> think about Flex/Flash as an option.
> That s the way  it is(for now).
>
> Now concerning  compiling Flex/AS3 to JS i m not a fan of that. There s
> nothing wrong with Flex as the way it is now. If i want to do mobile
> webapps Flex is def not the framework i will think about. Regardless of it
> it compiles to JS or not.
>
>
> 2012/8/30 Nick Tsitlakidis <nickt@perfectedz.com>
>
>> From my experience, using it for a simple site or a small app would
>> possibly create overbloated js indeed. But when it comes to middle or large
>> scale apps the code is heavily optimized and the end result makes sense in
>> terms of size and complexity.
>>
>> Regarding Google making the framework fully open source, that is correct,
>> but I fail to see the relevance. If anything, this is one more similarity
>> with Flex in Apache.
>>
>> On Thu, Aug 30, 2012 at 1:31 AM, Carlos Rovira <
>> carlos.rovira@codeoscopic.com> wrote:
>>
>> > AFAIK Google has made the same with GWT as Adobe with Flex. But GWT
>> > has the problem to generate overbloated JS code...
>> >
>> > 2012/8/30 Nick Tsitlakidis <nickt@perfectedz.com>:
>> > > Hello guys, I'm following all the topics here but I post rarely because
>> > > most of the times someone else has said something that I agree with
>> 100%.
>> > >
>> > > This time though, I was trying to think about similar technologies
>> which
>> > > are either compiled to js or they are converted in js in some other
>> way.
>> > > So I thought about GWT. The appproach google has taken with it is very
>> > > similar to Flex. They even have a skin architecture equivalent.
>> > > What I'm trying to say is, what if we could achieve something similar.
>> > They
>> > > seem to be translating Java to JS without a problem because they
>> exclude
>> > > Java features that are not compatible.
>> > > It's a small Java subset, I'll give you that, but developing in Java
>> and
>> > > creating skins just like in Flex is way more interesting and agile
>> > compared
>> > > to pure HTML and JS.
>> > >
>> > > As far as I can tell, both languages are not that different (Java and
>> > AS3).
>> > >
>> > > Any thoughts on this?
>> > >
>> > > On Wed, Aug 29, 2012 at 10:55 PM, Om <bigosmallm@gmail.com> wrote:
>> > >
>> > >> On Wed, Aug 29, 2012 at 12:19 PM, Michael A. Labriola <
>> > >> labriola@digitalprimates.net> wrote:
>> > >>
>> > >> > >Can you please elaborate?
>> > >> >
>> > >> > >The point I was trying to make was that HTML5 language itself
is
>> not
>> > >> > designed to be extensible.  Using Javascript does not really count
>> (in
>> > >> this
>> > >> > >context)
>> > >> >
>> > >> > >As far as using the DOM, I assume you mean the Microdata format.
>> >  This
>> > >> > results in non-standard HTML most of the time and is not supported
>> > across
>> > >> > browsers.  And it deals more with extending data semantics and
>not
>> > >> > functional extension.
>> > >> >
>> > >> > In flex, IMO, we worried too much about extension and not enough
>> about
>> > >> > composition.
>> > >>
>> > >>
>> > >> I think that is besides the point.  There is nothing in MXML that
>> > prevents
>> > >> composition.  It is just that the current set of Flex components are
>> > built
>> > >> like that.  We can fix that given time and effort.  There is no need
>> to
>> > >> structurally modify MXML to achieve this.
>> > >>
>> > >> Whereas with HTML(5) there is nothing in the standard that will let
us
>> > do
>> > >> specialization (via inheritance or composition)  I cannot dream up
new
>> > >> elements and expect a browser to understand it out of the box.
>> > >>
>> > >>
>> > >> > So long as I have a good series of patterns (and the discipline
to
>> > follow
>> > >> > them) then I can look at the HTML DOM elements as the Atoms of
the
>> > >> universe
>> > >> > and assembly them with some bonds (JavaScript) to make an element.
>> And
>> > >> then
>> > >> > in turn assemble those to make any application.
>> > >> >
>> > >>
>> > >> Right, we need Javascript to do this kind of extension to HTML.  To
do
>> > this
>> > >> in the Flex world would mean that we either
>> > >>
>> > >> * Bring in JS as a language we support in Flex
>> > >> or
>> > >> * Keep Flex as it is (i.e. Actionscript based) and have a AS to JS
>> > >> translation layer.
>> > >>
>> > >> The latter is a better approach because of various reasons ranging
>> from
>> > JS
>> > >> not being a real OOP language, no package organization possible, etc
>> (we
>> > >> all know why AS is better than JS)
>> > >>
>> > >> I think being able to code in MXML and Actionscript would be a key
>> goal
>> > of
>> > >> this cross-compilation effort, right?  Unless we want to fundamentally
>> > >> change what 'Flex' means.
>> > >>
>> > >>
>> > >> > So, the key is not trying to extend the Atom but trying to assemble
>> > it in
>> > >> > useful ways and allow those to be extended or recomposed. So far,
I
>> > have
>> > >> > found few limitations of this approach and often times ended up
much
>> > >> > happier.
>> > >> >
>> > >> >
>> > >> I definitely agree with you on this.  But again, this requires
>> > Javascript
>> > >> to assemble things.  My above points still hold good as well.
>> > >>
>> > >>
>> > >> > Mike
>> > >> >
>> > >> >
>> > >> Thanks,
>> > >> Om
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Nick Tsitlakidis,
>> > >
>> > > CEO and Software Architect at Perfect Edge LTD.
>> > > www.perfectedz.com
>> >
>> >
>> >
>> > --
>> > Carlos Rovira
>> > Director de Tecnología
>> > M: +34 607 22 60 05
>> > F:  +34 912 35 57 77
>> > CODEOSCOPIC S.A.
>> > Avd. del General Perón, 32
>> > Planta 10, Puertas P-Q
>> > 28020 Madrid
>> >
>>
>>
>>
>> --
>> Nick Tsitlakidis,
>>
>> CEO and Software Architect at Perfect Edge LTD.
>> www.perfectedz.com
>>



-- 
Carlos Rovira
Director de Tecnología
M: +34 607 22 60 05
F:  +34 912 35 57 77
CODEOSCOPIC S.A.
Avd. del General Perón, 32
Planta 10, Puertas P-Q
28020 Madrid

Mime
View raw message