GNU
/
easejs
1
0
Fork 0
Code Releases Activity

Added 'Why ease.js?' section

closure/master
Mike Gerwitz 2011-03-09 18:51:55 -05:00
parent dd26cbcee9
commit b7273f4d46
1 changed files with 107 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

107
doc/about.texi
View File

@ -27,6 +27,7 @@ Current support includes:
While the current focus of the project is Object-Oriented design, it is likely 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. that ease.js will expand to other paradigms in the future.
@section History @section History
ease.js was initially developed for use at Mike's place of employment in order to 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 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 The project is owned and developed independently by Mike Gerwitz. There is no
ownership by his employer. 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.