From b7273f4d4614345286330699fe00a36b68721d59 Mon Sep 17 00:00:00 2001 From: Mike Gerwitz Date: Wed, 9 Mar 2011 18:51:55 -0500 Subject: [PATCH] Added 'Why ease.js?' section --- doc/about.texi | 107 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) diff --git a/doc/about.texi b/doc/about.texi index eb091f9..fd39bb5 100644 --- a/doc/about.texi +++ b/doc/about.texi @@ -27,6 +27,7 @@ Current support includes: 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. + @section History ease.js was initially developed for use at Mike's place of employment in order to move the familiar concept of Object Oriented development over to JavaScript for @@ -71,3 +72,109 @@ the future. The project is owned and developed independently by Mike Gerwitz. There is no ownership by his employer. + +@section Why ease.js? +There already exists a number of different ways to accomplish inheritance and +various levels of encapsulation in JavaScript. Why ease.js? Though a number of +frameworks did provide class-like definitions, basic inheritance and other minor +feature sets, none of them seemed to be an all-encompassing solution to providing +a strong framework for Object-Oriented development in JavaScript. + +ease.js was first inspired by John Resig's post on "Simple JavasScript +Inheritance"@footnote{John's blog post is available at +@uref{http://ejohn.org/blog/simple-javascript-inheritance/}.}. 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: + +@table @strong +@item 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. + +@item Encapsulation +The absolute most important concept that ease.js wished to address was that of +encapsulation. Encapsulation is one of the most important principals of +Object-Oriented development. This meant implementing a system that would not +only support public and private members (which can be done conventionally in +JavaScript through ``privileged members''), but must also support +@emph{protected} members. Protected members have long been elusive to JavaScript +developers. + +@item 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. + +@item Inheritance +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. + +@item CommonJS, Server and Client +The framework would have to be used on both the server and client. Server-side, +@uref{http://nodejs.org, 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. + +@item Performance +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. + +@item 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 @emph{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. + +@item 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. + +@item 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. + +@end table + +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. +