Arbitrary Thoughts

Introducing ActionScript Blocks (ASBlocks)

Being in the time of changes, I as many others have taken a good look at my toolbox and taken up to review if there was anything in there I 1) could take out and hang back on the wall or 2) should put in my toolbox which wasn’t already there…

No need to worry, this is not another rant in the direction wether Flash/Flex is dead or not, Im merely sharing one of my more recent findings…

The ASBlocks project is a framework written in ActionScript3 AND Java to read and write ActionScript3 source code (classes, interfaces, functions and namespaces).

ASBlocks comes in 2 distinct flavors; ActionScript3 and Java. This means if you are looking to build a tooling application in Adobe Flex/AIR you can use the ActionScript as-blocks framework project. If you want a high powered, multi-threaded application backed by Java, use the jas-blocks framework project. Both frameworks implement the same ASBlocks Document Object Model (DOM). So shifting back and forth only has the learning curve of knowing each language.

Basically, all of this is referring to the processing and parsing of programming languages, relative to Input and Output from one processor to another in the compile or language processing chain. This project could be used to bridge the gap between Flex and other output technologies than AVM Bytecode (ActionScript Virtual Machine Bytecode) which is the current output since practically the only target runtime supported at the time of writing by Flex is Flash Player and AIR (Other AVM’s exist than Adobe Flash Player as you can see documented in other of my posts).

Now, things like ASBlocks can help change the landscape of runtimes being targeted by Flex, once you have an AST (Abstract Syntax Tree) for ActionScript in Java, its fairly straight forward to start using the AST to target various runtimes, such as e.g. HTML, CSS and JavaScript.

Flex’s MXML is by far the superior domain specific language for UI representation available for production today, and backed by a strong language such as ActionScript, it continues to make Flex a really interesting platform for building UI, regardless of speculations against the future of Flash Platform.

When Adobe donates Flex, Falcon (NextGen Flex Compiler) to Apache, its interesting and we will see more of this kind of topic as the maintenance and further development of Flex is put in the hands of the Global Developer Community, which I expect will help to speed up the evolution of Flex as well as spark of a new generation of DSL’s for abstracting complex UI patterns…

Check out ASBlocks…
http://labs.teotigraphix.com/doku.php/asblocks

ASBlocks is incepted and developed by Michael Schmalle, owner of Teoti Graphix…
@TeotiGraphix

 

Adobe Flex, Tools

Announcing “Project FlaXe”, a vision for the future of Flex

David Arno is in the same position as the lot of us working with Flex, its obvious that things will change in the years to come and one of the likely changes will be the much anticipated move to the Open Web Standards Technology Stack. However, this doesn’t change the fact that Flex will remain a superior application technology for years to come…

He has announced his idea and vision, Project FlaXe, and it goes something like this…

This set me thinking: could the community create a way of migrating existing Flex solutions away from the Flash player? The fact that the SDK will be handed over to an open source foundation offers a way of achieving this: compile Flex solutions to targets other than the Flash player. One way of doing this would be to take the mxmlc compiler code (which is part of the Flex SDK and thus maybe open for community modification too) and add a new backend to it that outputs JavaScript for example. A more exciting possibility though is haXe. Since its launch in 2006, AS3 has changed very little and so has become a somewhat outdated and stagnant language. As Adobe have shown no interest in evolving the language, Nicolas Cannasse developed a replacement for it: haXe. haXe is a more up-to-date, powerful and all-round-better language than AS3. In addition, it can be compiled to the Flash player, JavaScript, the command line and versions to output to Java, C# and iOS are being worked on. However haXe does have one weakness: the only interoperability between it and AS3 lies with the Flash player target, by using SWCs.

So I’m proposing “Project FlaXe” to address that and to turn haXe into a first-class Flex programming language.

Check out his blogpost…
http://www.davidarno.org/2011/11/14/announcing-project-flaxe-a-vision-for-the-future-of-flex/

Tools

"Enterprise JavaScript with Jangaroo" – a presentation 3 weeks ago at PLASTIC 2011

In order to get started understanding exactly what Jangaroo is trying to achieve and how far they actually are, this presentation from 3 weeks ago does a great job… take the 3 minutes it will take to run it trough, even one didn’t attend the session, the presentation speaks for itself…

ActionScript 3.0, Flex, JavaScript, Tools

Introducing Jangaroo…

Jangaroo is an Open Source project building developer tools that adopt the power of ActionScript 3 to create high-quality JavaScript frameworks and applications.

There are two main use cases when you might want to use Jangaroo tools:

  • JavaScript programming in the large – Adopt ActionScript 3 language features like packages, classes and inheritance, interfaces, private members, and many more to create even large-scale client-side Web code, where you otherwise would have used JavaScript directly. This approach is extremely helpful when creating frameworks with explicit public APIs, but also for larger applications that use such frameworks.
  • Running ActionScript 3 code directly in the browser – You are implementing a Web project that must not rely on plugins and/or requires close integration into an HTML Web site, possibly already using some JavaScript framework. You want to reuse or build upon existing ActionScript 3 code (utility classes, frameworks like FlexUnit, custom code) as well as JavaScript APIs and code.

This obviously is a very useful approach and if the end-result actually is useable, it would give us the very best of both worlds… especially since Jangaroo maintains edit-ability in the source between productions… very very useful in deed.

I will be taking Jangaroo for a spin at first given opportunity considering the magnitude of the benefits if the approach were made to work.
A really nice little “feature” is that Jangaroo keeps the generated code close to the source, even keeping line numbers to allow source-level debugging… pretty kewl !

Check it out…
http://www.jangaroo.net/home/

…and thanks to Kevin Newman for the heads-up, be sure to check out his blog…
http://www.unfocus.com/