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 22:31:31 GMT
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

Mime
View raw message