The best discussion with very detailed information I've heard/read so far: Flex Show Podcast 158 http://www.theflexshow.com/blog/index.cfm/2011/12/23/Flex-Summit-Roundtable-The-Flex-Show-Episode-158 "We sat down with Jon Campos, Michael Labriola, and Jesse Warden to get their take on the recent Adobe Flex Summit." 70 minutes of good discussions about the Flex Summit, the non-existent business model for the Flex SDK, and the future of Flex.
If you have been active in the Flex world, you'll probably have heard the names of the participants before. It's fascinating to hear them witness that Adobe - besides the very expensive Flex 1 version - never had a working business model for the whole Flex development. 80% of the Adobe revenues are made with the Creative Suite product line, and the whole LifeCycle products seem to be a complete failure. According to the discussion, Adobe doesn't have any plan either for a smooth Flash/Flex -> HTML5 transition in the enterprise world. They weren't even able to deliver a one liner describing their strategy for Flex/HTML5 to the "technical management" (waiting for Tucker's comment here..). If someone at Laszlo is interested in learning from Adobe's failed Flex business model, this should be extremely interesting. On Thu, Dec 15, 2011 at 4:06 PM, P T Withington <[email protected]> wrote: > Simple mode should work. > > It should not be too hard to make Advanced mode work. The LFC compiler is > already doing a lot of the same stuff. > > On 2011-12-14, at 19:30, Raju Bitter wrote: > >> Thanks, Tucker. The use of the Closure compiler introduces several >> rules which you have to follow within your JS code: >> >> SIMPLE MODE >> "with" is not allowed: >> When you use with the Compiler can't distinguish between a local >> variable and an object property of the same name, and so it renames >> all instances of the name. >> Furthermore, the with statement makes your code harder for humans to >> read. The with statement changes the normal rules for name resolution, >> and can make it difficult even for the programmer who wrote the code >> to identify what a name refers to. >> >> String representations of function or parameter names: >> The Compiler renames functions and function parameters but does not >> change any strings in your code that refer to functions or parameters >> by name. You should thus avoid representing function or parameter >> names as strings in your code. For example, the Prototype library >> function argumentNames() uses Function.toString() to retrieve the >> names of a function's parameters. But while argumentNames() might >> tempt you to use the names of arguments in your code, Simple mode >> compilation breaks this kind of reference. >> >> ADVANCED MODE >> External references >> In order to rename global variables, functions, and properties >> correctly, the Compiler must know about all references to those >> globals. You must tell the Compiler about symbols that are defined >> outside of the code being compiled. Advanced Compilation and Externs >> describes how to declare external symbols. >> >> >> Using string names to refer to object properties: >> The Compiler renames properties in Advanced mode, but it never renames >> strings. If you need to refer to a property with a quoted string, >> always use a quoted string >> >> In Advanced mode the Compiler collapses object properties to prepare >> for name shortening. >> var foo = {}; >> foo.bar = function (a) { alert(a) }; >> foo.bar("hello"); >> will become >> var foo$bar = function (a) { alert(a) }; >> foo$bar("hello"); >> >> Full list of limitations can be found here: >> http://code.google.com/closure/compiler/docs/limitations.html >> >> I guess it would be quite a lot of work to modify the LFC and the JS >> generator to conform to the Clojure rules. >> >> - Raju >> >> >> On Wed, Dec 14, 2011 at 5:20 PM, P T Withington <[email protected]> wrote: >>> Presumably you could run OL with the -S option to get the JS 'assembley' >>> and then run it through the closure compiler and compare that with the >>> 'assembled' js code the OL compiler generates. >>> >>> On 2011-12-13, at 18:43, Raju Bitter wrote: >>> >>>> The simple Flex app without Closure optimizations is 5mb in size, the >>>> optimized version 2.5 mb. Wow! How much better off would OpenLaszlo be >>>> with the Closure optimization... >>>> >>>> On Wed, Dec 14, 2011 at 12:40 AM, Raju Bitter >>>> <[email protected]> wrote: >>>>> Here's a video recording of the presentation: >>>>> https://my.adobeconnect.com/_a295153/p7ysfeovw33/?launcher=false&fcsContent=true&pbMode=normal >>>>> >>>>> On Tue, Dec 13, 2011 at 5:29 PM, Raju Bitter >>>>> <[email protected]> wrote: >>>>>> The Spoon project team has posted some information in their blog on >>>>>> the Flex Summit demos of FalconJS. Here are some interesting facts: >>>>>> http://www.spoon.as/2011/flex-summit-live-updates/ >>>>>> >>>>>> + FalconJS will be donated as open source to Apache >>>>>> >>>>>> + FalconJS AS3 compilation: >>>>>> AS code -> falcon front end / falcon js code gen -> google closure >>>>>> compiler -> faster JS Code >>>>>> Standards used: HTML, JS, SVG >>>>>> >>>>>> + “Falcon JS” refers to two experimental utilities: >>>>>> – AS-> JS >>>>>> – MXML -> HTML/CSS/JS >>>>>> >>>>>> + "Seeing example apps running. They look really good." >>>>>> >>>>>> That actually sounds promising. The DHTML code should be much more >>>>>> optimized with Google Closure support, assuming that FalconJS supports >>>>>> the advanced compilation mode. >>>>>> >>>>>> There will be some changes regarding tooling >>>>>> – Flash Builder >>>>>> — will release support for apache flex >>>>>> — removing unpopular and expensive to maintain features: Design View, >>>>>> DCD, and Catalyst workflows >>>>>> – flash catalyst discontinued (with catalyst cs5.5 support for flex 4.5) >>>>>> – monocle continues as a priority >>>>>> >>>>>> It sounds like the latest components are optimized for FalconJS >>>>>> already, that means Adobe has done most of the work to have complex >>>>>> apps running in JavaScript. >>>> >>> >
