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
