Eventually I managed to trick ASDoc into completing, but it has opened up further cans of worms. There are a whole bunch of practices in the JASPA code base that the AS3 compiler really doesn't like. I've tried to be strict, but apparently not strict enough. In some cases I feel that AS3 is just being unreasonable, for example, you cannot have private constructors in AS3. A common practice for singleton classes is many OOP languages.

Here's another example, where an extended event class provides access to an extended target -

public class EventTarget {
}

public class Event {
    public function get target():EventTarget;
}

public class SpecialEventTarget extends EventTarget {
}

public class SpecialEvent extends Event { 
    override public function get target():SpecialEventTarget;
}

The overridden getter that returns a sub-type of the target is considered invalid. I don't see how this is bad practice. Surely a more specific type of event should be allowed to return a more specific type of target, especially as the extended target still has all the traits of the original target.

Of course you can always cast with the as operator:

mySpecialEvent.target as SpecialEventTarget;

The question is, do I really want JASPA to be tied so closely to AS3? At the end of the day it is a separate language, and is designed for compiling into JavaScript not for emulating ActionScript.

I am not caught between two options.
1. Alter the JASPA codebase to be even more like AS3
2. Write a JAS documentor, jasdoc

What do you think?

> http://www.webdevgeekly.com/r/www.webdevgeekly.com/mp3/geekly6.mp3

I should clarify a few things for anyone listening:

1. I did get a rude email from Douglas Crockford, but not nasty or in any way aggressive. When I very politely asked for his opinion on the project he responded: "I don't care for ActionScript"; No "hello", no signature… Call me old fashioned, but I think that's unnecessarily rude.

2. "I wonder how they're doing parts of this" (Harmony and ECMA4 gets mentioned)
As any JS evangelist will tell you, Adobe went off and did pretty much their own thing with AS2/3; JAS syntax follows that path as opposed to the current path of ECMAScript. The ‘compiler' is implemented in pure PHP. You can test the JAS Parser on its own here, or test the full compiler at jaspa.org.uk. Rather than a JavaScript engine, or interpreter like SpiderMonkey that might run in a browser, the JASPA compiler is really a converter which allows you to deploy regular JavaScript to browsers that have no idea how to interpret JAS, or any other super-set of ECMAScript for that matter.

3. Providing libraries that ActionScript developers are used to – e.g. jaspa.net.URLVariables
I do attempt to follow AS conventions where possible. The URLVariables class is a good example, because it is API agnostic. That is to say that it is a rather abstract utility that could be used in DOM scripting, but equally in any other API, such as server side JavaScript for Flash Media Server for example. It is important to note that the JASPA compiler and JAS syntax are not in any may married to these libaries and APIs. It is platform for which anyone is free to develop their own such utilities.

4. Finally to anyone who wants to try out JASPA, please bear in mind that it is a non-commercial project with a single developer who has a full-time job. The "they" is really a "he". The compiler itself is a beta, and some of the API classes I've been putting together are somewhat alpha.

There's too much ambiguity and room for misconception in a single headline. Online-reading habits being what they are, if you're not interested in the headline, you won't read what's under it. I suppose this is why people use rather abstract strap-lines like jQuery's "Write less, do more" and "jQuery is a new kind of JavaScript library".

I don't think JASPA can get way with statements this abstract, so I'm currently running with:

"Write JavaScript with the expressive power of ActionScript"

Not catchy, I know; needs work. I've also put a real-time compiler demo on the JASPA home page to try and get the message across. I may regret this as the compiler uses a lot of juice. Good job it's not popular ;)

I just read this blog article by John Resig, the author of jQuery. The article in general is a criticism of various projects like my very own "JASPA" – A criticism of frameworks that attempt to bring JavaScript into the 21st century by abstracting it into a different language.

I knew I wasn't alone with JASPA – There is GWT and Jangaroo for Java, Pyjamas for Python, and Cappuccino with its own syntax called Objective-J. These projects are all slightly different takes on one core principal – that to truly make JavaScript "better" you can't just write JavaScript, you have to introduce a more advanced syntax to leverage more advanced features.

Understandably JavaScript evangelists like John don't all like this idea, and I do understand why. John makes some good points; most of which I completely agree with, but also some that I feel apply equally to his own jQuery and libraries like it.

Native JavaScript vs foreign language syntax

Pure-JavaScript libraries like jQuery, Prototype, Base2, (the list is endless) all attempt to address the short-comings of JavaScript from the inside, so to speak. That is to say that they are implemented in JavaScript and can never escape JavaScript. John argues that this is preferable, but I argue that the way in which these kind of libraries attempt to bend the syntax of JavaScript make them guilty of most of the same charges. Furthermore I argue that these libraries stand in the way of someone new to JavaScript gaining any real understanding of it.

My main defence of JASPA is of course that the language syntax is that of ActionScript (AS3), which regardless of its rocky relationship with ECMAScript 4, is still an evolution of JavaScript, and not a total departure from it, which is what John Resig seems to be most offended by.

So naturally I posted a comment about my feelings..

.. except not only did I manage to cock up the posting of the comment, but for all I know it will be taken down to punish me for my shameless self-promotion. So because of these reasons, and because I feel I made some good points, I thought I'd re-post my comment here with a tiny bit of editing.

--8<-------
I see your point when it comes to non-ECMAScript languages, but what about ActionScript? I chose AS3 to implement my "abstraction" called JASPA – jaspa.org.uk

I know many JavaScript evangelists reject ActionScript, (especially due to its recent history with ES4), but it's like writing an extended version of JavaScript rather than a whole different language.

The OOP enhancements in ActionScript are intuitive and the syntax for procedural code remains largely the same. I would in fact argue that the OOP enhancements in ActionScript are much more intuitive than constructs like this:

$(document).ready(function(){
   // ...
});

- or sugaring approaches like this:

Class.method('example', function(){
   // ...
});

I appreciate what these kind of constructs achieve, but I cannot agree that they are particularly intuitive or respectful to the natural form of JavaScript. I would go further and suggest that people who aren't JavaScript experts may not see how these formations really relate to JavaScript syntax, particularly due to the use of whitespace.

There some libraries that convert functions to strings and overwrite them with altered versions – surely this approach is even less intuitive and has even less respect for JavaScript than an extended form which provides real OOP enhancements such as classes, packages, imports, and super; not to mention strict typing.

Anyhow, I would ask that anyone looking at JASPA realises that what I am doing is purely out of respect for what JavaScript is and what it isn't.

I've been trying to find the time to sort out the official site for this project, and a wiki seems like a good format for organizing all the fragmented information that until now I've been posting on this blog. The wiki is likely to be the primary source of information and documentation on the JASPA project.

Check it out: » jaspa.org.uk/wiki/JASPA

At jaspa.org.uk/examples you can view interactive examples and full, highlighted source code. These examples are going to grow, particularly those in the jaspa.dom package, as this is heavily under construction. When an API feature is enabled an example will be added to this repository to serve as both a reference and a test case.

I've decided to set up an open source project for the jaspa.dom package; it is to be found on SourceForge.
http://sourceforge.net/projects/jaspa-dom. It's my first attempt at anything like this, so I'm bumbling around a bit, but the downloads are there and the CVS repository is also up and running. Any developers who are serious about helping develop this API should put a request to join the project on SourceForge.

What?

The main JASPA project is a platform which allows you to write a grown up language (practically identitcal to AS3), and have it compiled into regular JavaScript. If you don't know why this is really cool, then you may as well stop reading now.

japsa.dom is the name of the DOM scripting package which allows you to compile browser-based code with JASPA. It's a completely separate project, and is quite possibly larger and more complex. It is certainly less mature. The JASPA compiler is behaving pretty well, but the API code base is very much incomplete.

Language vs API

The thing about JavaScript is that it's pretty much an empty shell. You can't actually do anything without an API of some sort. Your web browser provides one such interface – it lets you access window, and document and generally lets you do stuff. Likewise the Flash Player provides MovieClip et al.

JASPA is API-neutral. That is to say that it just compiles code, but has no idea what document is until you tell it. This is actually quite easy, because JASPA supports native class definitions, so you can create a sort of class template and state that there's an object called document which has a property called body, and so on. In ActionScript these are known as intrinsic classes. In JASPA they are called native classes – (native is a reserved word in ECMAScript, so I thought I'd play ball).

Anyhow, this is all very well for Flash, because it knows there's going to be a MovieClip. In fact it's all very well for most environments that support JavaScript – except of course web browsers. You can't just call document.addEventListener, because our old friend MSIE doesn't have such a thing. It's known as attachEvent instead, and it's not just a naming issue either – the differences run deep, but that's another blog.

A poor solution would be to create a loosely typed global object. If the Window class was declared dynamic you could merrily type anything you wanted. The application would compile just fine, and if you're code is flawless your app would run fine too. But if you're going to do this then there's little point in using JASPA. You won't get code hints in your "as" editor, and you won't benefit from the compiler picking up your mistakes.

Total abstraction

A better solution would be to take this opportunity to build a complete abstraction layer. Wouldn't it be great if you only ever had to call the standard API functions, just like in ActionScript, and on any browser your code would just work. That, in a nutshell, is the purpose of the jaspa.dom package. To achieve this, the API consists of wrapper classes for practically every object in the browser environment. When writing your JAS code you will be largely unaware of this.

Some parts of the API go even further than just abstract the objects. due to the huge differences between the IE and the standard event model this is completely abstracted too. That is to say that event flow is emulated so the standard model works identically cross-browser.

As this article has become rather long, I'll go into some of the abstraction techniques in future posts.

The acronym JAS derives from JavaScript/ActionScript, but officially it means "JavaScript; Advanced Syntax". This is partly due to potential trademark problems, and partly to make the distinction that it IS a separate language. The JASPA compiler contains absolutely no Adobe technology, or source code whatsoever.

The JAS syntax is designed to be as close to AS3 (ActionScript) as possible. When I say "as possible", I mean that ideally I'd have made them identical, but for reasons too time-consuming to describe, certain things are in, certain things are out, and certain things behave a bit more like AS2. Ultimately JAS is an extension to the ECMAScript (ES3) standard, proving the kind of OOP enhancements that ActionScript programmers will find very familiar.

I shall digress and describe the similarities and differences between JAS and both ActionScript languages, feature-by-feature.

[ UPDATE: See http://jaspa.org.uk/wiki/JAS_language ]

Strong typing
The same fundamental type-declaration principals of AS2 & AS3 are in JAS. The AS3 as operator is supported as well as AS2-style type-casting.

Untyped objects
The concept of an untyped object is supported, but AS3 wildcard syntax is not. i.e. var Obj:*; is invalid in JAS. To declare an object untyped, just don't declare any type at all. As per AS3, untyped objects are the only ones that may contain the special value undefined.

Compile-time vs run-time
As per AS2, the JASPA compiler will not complete if there are type errors, or if illegal property access is attempted. However some runtime checks are also performed, particularly when AS2-style workarounds have been used to cheat the compiler.

Packages & Classes
AS3-style package and class declarations are supported, as are the folder/file naming conventions. Classes are imported with the import keyword. Package-level members are not supported, but there is an internal namespace. Unlike AS3, classes are not permitted outside a package declaration block. Private classes, (those available only within a class file), are defined inside the package block instead.

Code hiding
public, private, protected, and internal namespaces are supported, but custom namespaces are not. Unlike AS2, cheating these namespaces at compile-time will result in run-time errors. The AS3 keywords final and override are also enforced.

Interfaces & abstract members
These are not currently supported, but rest assured they will be.

Super calls
super is fully supported. Use of super() in class constructors is implemented as per AS3, which improves slightly on the AS2 implementation.

Getters & setters; property overloading
get and set function keywords are supported, and even enforced at runtime.

Native XML (E4X)
This is not implemented at all in the JAS syntax. There are no plans to support E4X.

Meta data
Not supported at all. There is no plans and probably no reason to support such a thing.

Closures
As per AS3, JAS supports implicit closures when passing, assigning or returning function objects. R.I.P Delegate.create!

Constants
The const keyword is supported. At runtime constants are treated as read-only variables.

Rest arguments operator
The ... (RestArgs) operator is supported in function arguments as per AS3.

Function parameter defaults
Default function parameters are supported;
e.g. function ( a:Number = 1 ){}

int & uint
After some experiments in implementing non-native integer classes, these have been omitted from JAS. They may be introduced in future, but as they will always be non-native there is little advantage of including them

I don't get it; what does it do?
It generates regular JavaScript from code written in a language called JAS, which is practically identical to AS3. You can write packages and classes, and take advantage of all your favourite OOP features, and JASPA will convert this into code that will run perfectly in a web browser or any other environment that implements a compliant JavaScript engine.

Can I convert my Flash projects into HTML sites?
No. JASPA really has nothing to do with Flash. The JAS language adopts the syntax of AS3; the relationship ends there.

Why doesn't JASPA compile my ActionScript successfully?
Firstly, the JAS language is not ActionScript – It is modelled very closely on it. Full details of supported language features here.
Secondly, the API available in the Flash Player consists of objects that are unknown to JASPA. If you want to reference a class called MovieClip, you'll have to write one.

I love JQuery/Scriptaculous/etc.. Why should I use JASPA instead?
JASPA is not an effects library, and it is not designed to make your life easier. It is designed to empower you. If you think JQuery is the bees knees, then you should probably keep using it. However, if you want to write serious application logic that must run in JavaScript then JASPA is your man.

Is JASPA free / open source?
The API code written in JavaScript and JAS is open source. It's released under the GNU General Public License, and the cross-browser API has even got its own Sourceforge project. The compiler software written in PHP is free (as in gratis), but not strictly open source. You can use the compilers free of charge as much as you like and generate JavaScript for any purpose you wish, but the PHP code is not distributed with a recognized free software license.

What does JASPA stand for?
Offically: "JavaScript; Advanced Syntax with PHP", but originally just a mish mash of JavaScript/ActionScript/PHP

Does JASPA improve performance?
No. JASPA is a code generator, not a runtime engine. The code it generates cannot be any more efficient than whatever JavaScript engine executes it. Furthermore, JASPA is designed with robustness in mind, so you will probably find the code generated is quite long-winded and heavier than anything you would write from scratch.

Why is the compiler written in PHP?
The shortest answer is that I am a PHP developer. I'm sure if I was a Java developer it would be written in Java. It has some advantages being written in PHP. If you don't have access to a command line, the compiler can be run through the browser. Also there may be future development of JASPA that integrates more tightly with PHP.

Write robust object-orientated applications in a strongly-typed language (modelled on AS3) and compile it into regular JavaScript to run in a web page, or any other environment that implements a JavaScript engine.

Download JASPA from SourceForge
https://sourceforge.net/project/showfiles.php?group_id=243463

The JASPA project is split into two main components:

1. The compiler
2. The cross-browser abstraction API

1. The compiler

The compiler is API-neutral; Its job is to compile object-orientated code written in the JAS syntax, and convert it to regular, clean JavaScript suitable for running in any ECMAScript-compliant host program, such as a web browser. The compiler comes in two flavours: A command line compiler, which is the most useful; and also a web-based compiler which is handy in development and testing, or when a command line is not available.

The compiler is largely complete, but there is still some work to do to support some outstanding language features.

 2. The cross-browser abstraction API

If you want to build web applications with JASPA, the compiler needs to know about all the objects and methods exposed by the browser. This is easily achieved by writing native class interfaces, much like intrinsic classes in ActionScript. However, browser scripting today poses the same huge problem that it did 10 years ago; Vendors don't all provide the same API. Hence a comprehensive abstraction layer is required to provide a single, standardized interface that works across all modern browsers.

Although the JASPA compiler is largely complete and pretty stable, work on this API is still very much in progress.
More about all of these topics will be organized into further blogs. In the mean time, please have a go with the compiler and let me know what you think of it.