The first evident difference I could see was that the Mootools port don't use interfaces as the interfaces package was missing from the folder tree.
I also immediately looked for any Unit Tests folder as it was an important thing missing in the Objs port. But it seems that here, as with Objs, Mootools don't have any compatible Unit Test framework to test the port. Apparently Mootools developers use JSSpec, a test Framework to test their builds, but this is "only" a generic "Behavior Driven Development" framework.
Differences are more subtle when looking at the pseudo-classes code.
Mootools doesn't provide any package support.
Another difference is that Mootools pseudo-classes use an initializer method instead of the legitimate constructor, as explained on this example extracted from the mootools help website :
This is a common implementation in prototyped languages and I assume it to be really convenient to use when working on the EmployeeAdmin demo.
The inheritance between two pseudo-classes is made by associating the super class reference to an Extends property in the subclass. This is a neat way to implement inheritance.
As you can see in the two examples above, there's no need to import classes in the context of the one which will use them, the class uses a direct reference to a class object instance instead. So, as each class object instance need to be built with the Class keyword, classes need to be declared following a strict order, e.g: Class B cannot use a reference to a Class A before this class has been built. This happens when using inheritance and constants referring to other classes simultaneously or simply when the initializer uses references to other classes. In some situation, this can lead to intractable problems where cross-references between classes require an order of declaration simply impossible to reach.
This said, some of this problems can easily be avoided by following good practices in code design. But whatever you do, even if you avoid the intractable situation, in big projects, it requires to change the classes declaration order so often that it can became a real problem.
In the other hand, the Mootools port and applications made with it are more clear that with Objs because you don't have the long import list at the start of each class.
This first means that Mootools cannot coexists with most of the framework like Prototype, Jquery, etc... without some extra work. But it can also introduce unwanted problems in your own webpage with some existing code. That's what happened to me during the EmployeeAdmin development, I had to search during several hours the origin of a strange behavior on the User Profile form before understanding that the problem came from the Function.prototype.create method added by Mootools that override a create method in one of my own classes.
Working on the EmployeeAdmin demo
Converting from Objs to Mootools
To build this EmployeeAdmin Mootools demo, I used the previous one from the Objs port and converted it progressively to Mootools. A great part of this work was easily made using Regular expressions and a good code editor.
The only problems I had are listed above. The biggest one was when Mootools inject one of its methods instead of one of my own classes with prototyping.
I used the example Justin Wilaby made for his port. It helped me not to be wrong with his port and Mootools. Plus he adds an interesting UIComponent class I reused.
Omnigrid Advanced DataGrid
Upgrading to the EmployeeAdmin 1.4 version
Cliff Hall involuntarily made me a bad joke by upgrading the Flex EmployeeAdmin demo from 1.3 to 1.4 while I was working on it. So I had to upgrade mine just before releasing it today. The upgrade mainly adds a PrepViewCommand, a PrepModelCommand and change the Flex based design to the PureMVC graphic chart.