incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alain Ekambi <jazzmatad...@gmail.com>
Subject Re: Cross-compiling Flex to HTML5/Javascript (Was : Update on Falcon donation)
Date Wed, 29 Aug 2012 22:40:10 GMT
GWT generates overbloated JavaScript ?
Where do you have that one from ?

GWT's Java to JavaScript compiler is one the best out there (The closure
compiler beeing imho the best).
And GWT 2.5 just added the closure compiler as a compilation option.

2012/8/30 Carlos Rovira <carlos.rovira@codeoscopic.com>

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message