>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.rov...@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 <ni...@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 <bigosma...@gmail.com> wrote: > > > >> On Wed, Aug 29, 2012 at 12:19 PM, Michael A. Labriola < > >> labri...@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
