About GNU ease.js
Current support includes:
- Simple and intuitive class definitions
- Classical inheritance
- Abstract classes and methods
- Traits as mixins
- Visibility (public, protected, and private members)
- Static, constant, and final members
While the current focus of the project is Object-Oriented design, it is likely that ease.js will expand to other paradigms in the future.
The library would be required to work both server and client-side, supporting all major web browsers as far back as Internet Explorer 6. Since it would be used in a production system and would be used to develop a core business application, it must also work flawlessly. This meant heavy unit testing.
This involved writing a simple script to concatenate all the modules and appropriately wrap them in closures, thereby solving the CommonJS issue. The required assertions were ported over to the client. The only issue was then ECMAScript 5 support, which with a little thought, the browser could gracefully fall back on by sacrificing certain features but leaving the core functionality relatively unscathed. This provides a proper cross-browser implementation and, very importantly, allows the unit tests to be run both server and client side. One can then be confident that ease.js will operate on both the server and a wide range of web browsers without having to maintain separate tests for each.
Needless to say, the development was successful and the project has been used in production long before v0.1.0-pre was even conceived. It was thought at the beginning of the project that versions would be unnecessary, due to its relative simplicity and fairly basic feature set. The project has since evolved past its original specification and hopes to introduce a number of exciting features in the future.
GNU ease.js is authored by Mike Gerwitz and owned by the Free Software Foundation. On 22 December 2013, ease.js officially became a part of GNU with the kind help and supervision of Brandon Invergo.
ease.js was first inspired by John Resig’s post on “Simple JavasScript Inheritance”1. This very basic example provided a means to define a “class” and extend it. It used a PHP-style constructor and was intuitive to use. Though it was an excellent alternative to defining and inheriting classes by working directly with prototypes, it was far from a solid solution. It lacked abstract methods, interfaces, encapsulation (visibility), and many other important features. Another solution was needed.
Using John’s example as a base concept, ease.js was developed to address those core issues. Importantly, the project needed to fulfill the following goals:
- Intuitive Class Definitions
Users of Object-Oriented languages are used to a certain style of class declaration that is fairly consistent. Class definitions within the framework should be reflective of this. A programmer familiar with Object-Oriented development should be able to look at the code and clearly see what the class is doing and how it is defined.
- Interfaces / Abstract Classes
Interfaces and Abstract Classes are a core concept and facilitate code reuse and the development of consistent APIs. They also prove to be very useful for polymorphism. Without them, we must trust that the developer has implemented the correct API. If not, it will likely result in confusing runtime errors. We also cannot ensure an object is passed with the expected API through the use of polymorphism.
Basic inheritance can be done through use of prototype chains. However, the above concepts introduce additional complications. Firstly, we must be able to implement interfaces. A simple prototype chain cannot do this (an object cannot have multiple prototypes). Furthermore, protected members must be inherited by subtypes, while making private members unavailable. In the future, when traits are added to the mix, we run into the same problem as we do with interfaces.
- CommonJS, Server and Client
The framework would have to be used on both the server and client. Server-side, Node.js was chosen. It used a CommonJS format for modules. In order to get ease.js working client side, it would have to be wrapped in such a way that the code could remain unchanged and still operate the same. Furthermore, all tests written for the framework would have to run both server and client-side, ensuring a consistent experience on the server and across all supported browsers. Support would have to go as far back as Internet Explorer 6 to support legacy systems.
Everyone knows that Object-Oriented programming incurs a performance hit in return for numerous benefits. ease.js is not magic; it too would incur a performance it. This hit must be low. Throughout the entire time the software is running, the hit must be low enough that it is insignificant (less than 1% of the total running time). This applies to any time the framework is used - from class creation to method invocation.
- Quality Design
A quality design for the system is important for a number of reasons. This includes consistency with other languages and performance considerations. It must also be easily maintainable and extensible. Object-Oriented programming is all about restricting what the developer can do. It is important to do so properly and ensure it is consistent with other languages. If something is inconsistent early on, and that inconsistency is adopted throughout a piece of software, fixing the inconsistency could potentially result in breaking the software.
- Heavily Tested
The framework would be used to develop critical business applications. It needed to perform flawlessly. A bug could potentially introduce flaws into the entire system. Furthermore, bugs in the framework could create a debugging nightmare, with developers wondering if the flaw exists in their own software or the framework. This is a framework that would be very tightly coupled with the software built atop of it. In order to ensure production quality, the framework would have to be heavily tested. As such, a test-driven development cycle is preferred.
- Well Documented
The framework should be intuitive enough that documentation is generally unneeded, but in the event the developer does need help in implementing the framework in their own software, the help should be readily available. Wasting time attempting to figure out the framework is both frustrating and increases project cost.
The above are the main factors taken into consideration when first developing ease.js. There were no existing frameworks that met all of the above criteria. Therefore, it was determined that ease.js was a valid project that addressed genuine needs for which there was no current, all-encompassing solution.