The processing.js project was started by John Resig who wanted to utilize the HTML5 canvas element and take advantage of the Java Processing language. It took about seven months to get a working version, consisting of 5000 lines of code but it was not a complete port of the Processing language. (Resig 2008)The project, similarly to other open source products, was released with the hope that a developer community will converge around it and contribute to development.  “In development I worked in a backwards mannerIn September 2009, we began the work to complete the port to JavaScript. Instead In order to facilitate an architecture for participation the source code had to be readily available and the inner workings of building the API up from project and the ground - I worked from missing functionality must be publicized. To this end the top, down, implementing enough source code was made available publicly on GitHub and an issue tracking system was used to manage the large number of issues needed to be resolved in order to complete the API port. A review process was setup to get individual demos working.” -http://ejohnensure that the code submitted was of sufficient quality.org/blog/processingjs/

From it's inception, Processing.js was designed to be more than just a rewrite of the Java functions provided by Processing to JavaScript. The projectJohn Resig wrote the original Processing.js parser to scan a Processing sketch for hints of Java code and convert that code to JavaScript. However, similarly if the parser encountered JavaScript code, it would leave the code intact. This method allowed not only for the conversion of existing Processing code to other open source productsJavaScript but the injection of JavaScript into Processing sketches as well. By allowing JavaScript to exist within a Processing Sketch intact, was released with Java and JavaScript code can exist together without any need to declare the hope that a developer community language you are using. Old sketches written for Processing will converge around it and contribute work but new sketches written for Processing.js can not only have Processing code but can make use of JavaScript to developmentinteract with other elements of the webpage.

In September 2009When the original Processing Language, also known as P5, we began was first developed Java was suppose to become the work to complete language of the Processing port to web while JavaScript. In order to facilitate an architecture for participation was a number of things needed to happenlittle toy language that many did not take serious. First and foremost However, as the source code had to be readily available. Secondlyweb matured, JavaScript became the inner workings language of the project and web but many of the missing functionality must be publicized and a dialog startedmisconceptions about it still persists. /*cite javascript the good parts here*/ To this end the source code was made available publicly on GitHub and an issue tracking system was used to manage the large number of issues needed to be resolved With recent developments in order to complete the port. A review process was setup JavaScript technology, JavaScript is now fast enough to ensure that handle the code submitted was demands of sufficient qualityrealtime interactive web graphics.

==DOM Integration?? Processing.js is more than just a Processing parser re-written in JavaScript. It is designed in a way that connects the Processing language (need also known as P5) with web technologies such as JavaScript, the HTML5 canvas element, JQuery, and various web services. Furthermore, Processing.js is built in such a better header)==way as to allow easy integration of new technologies as they emerge. It is designed to be fast and to take advantage of recent JavaScript developments to ensure that the platform is responsive.

ProcessingWhile syntactically JavaScript and Java are fairly similar, there are some fundamental differences that has made this conversion challenging.js The first is more than just a Processing parser written that we wanted to do this conversion dynamically in JavaScriptreal time. It is designed in a way The code produced by the converter needed to be fully object oriented and we had to provide support to all native Java functions and objects that connects the are supported by Processing language (. We also known as P5) had to take into account the differences between working with web technologies such as JavaScript, the HTML5 canvas element, JQuery, and various web servicesresources vs local resources. Furthermore, Processing.js is built in we had to consider how we would handle some fundamental differences between Java and JavaScript such a way as to allow easy integration of new technologies as they emergetyped vs. typeless variables, function overloading and variable name overloading.

The original code for Processing Language is .js used regular expressions to convert Java basedinto JavaScript when it was encountered. To run a Processing It did this by scanning for hints of Java code within the entire sketch in a web page, and then replaced the Java code has to be completely converted into with its JavaScriptequivalent. While syntactically Due to the difference in how Java and JavaScript and Java are fairly similaraccessed object properties from methods inside an object, there are some fundamental differences that has made the with statement was used as a simple solution to avoid having to prepend all function calls with "this conversion challenging." or "Processing.". The first is However, the use of the with statement also meant that the JavaScript generated would fall off Trace /*cite trace paper here... do we wanted need to talk about trace in the back ground section???*/ making the code run slower than it needed to do this conversion dynamically in real timesome browsers. The code produced Later this method of scanning the entire sketch was replaced by the converter needed to be fully object oriented and we creation of an abstract syntax tree that broke up the code into smaller pieces. Each piece then had the regular expressions applied to provide support to all native Java functions and objects (such as Strings) that are supported by Processingchange it. We also had This made it was easier to take into account apply the differences between regular expressions correctly without accidentally converting code that was already working with web resources vs local resources. Furthermore we had It also made it easier to consider how we would handle some fundamental differences between Java create proper inheritance structures and attach properties and JavaScript such methods to the correct object in the hierarchy chain as typed vs. typeless variables, function overloading and variable name overloadingsmaller pieces of code was being converted at any one time.

The introduction of the <canvas> tag into the HTML5 specification allowed Processing to be ported to JavaScript, thus enabling users to run 2D sketches within the browser without additional plug-ins. At the time when porting began, there was no plug-in free method of delivering 3D content. This limited Processing.js to its 2D functions. WebGL, A JavaScript API that is based on OpenGL ES 2.0, is now being implemented by Firefox, Chrome and Safari. It is now has become a viable candidate for use in Processing.js to render 3D sketches. Additionally, since WebGL closely matches OpenGL which is used by Processing, it substantially aided the porting processof the 3D Processing functions was relatively straight forward.

===Differencesbetween OpenGL and WebGL===The matter of porting Processing (which uses OpenGL/*1.x?? if it was opengl 2.0 it would have been even easier right?*/) was simplified because the WebGL interface is similar that of OpenGL, but there are a number of differences between the interfaces. Arguably, the The single largest difference between WebGL and OpenGL 1.x is that like OpenGL ES 2.0, the fixed-function pipeline was been removed. Because of this, not all Processing source code could not be ported directly. Instead, user-defined vertex and fragment shaders were necessary to write for lighting operations. Since some shapes in Processing aren't lit and others were, multiple shaders were written. One shader exists for lit objects such as boxes and spheres, another less complex shader was written for unlit objects such as lines and points.

Because typed arrays are only available for pre-release browsers, they cannot currently be used in 2D sketches. Once they become implemented in browsers, a significant amount of the Processing.js code base can make use of these structures, increasing performance throughout the library. ===Specification Changes and Browser Inconsistencies===As the specification is concurrently implemented in different browsers, several inconsistencies between browsers have appeared. These range from minor issues, such as Minefield and Chrome/Chromium return "function" while WebKit returns "object" when the type of a typed array is queried. Another is the way WebGL's readPixels() function is implemented. This function isn't used extensively in the library itself/* andor, but it is used mike said its in the Processing.js reference testing framework. ===Problems===WebGL provides a close match to OpenGL for incorporating 3D into Processing.js, but it does present some issues when trying to port over code. There are interface differences, changes to the interface are common, and some functionality isn't available at all such as point smoothing.  ==Browser Unification== One important feature provided by Processing.js is that it hides the differences between browsers. Web standards are often loosely defined, and thus variations can exist. These variations not only exist between different browser vendors but can even exist between versions of the same browser on different platforms. Something as simple as key events can vary widely between browsers. Processing.js hides all these intricacies from the user keeping it simple for content creators. ???*/

The processing.js project was started by John Resig who wanted to utilize the HTML5 canvas element and take advantage of the Java Processing language. It took about seven months to get a working version, consisting of 5000 lines of code but it was not a complete port of the Processing language. (Resig 2008).  “In development I worked in a backwards manner. Instead of building the API up from the ground - I worked from the top, down, implementing enough of the API to get individual demos working.” -http://ejohn.org/blog/processingjs/  The project, similarly to other open source products, was released with the hope that a developer community will converge around it and contribute to development.

In September 2009, we began the work to complete the Processing port to JavaScriptwas begun. In order to facilitate an architecture for participation a number of things needed to happen. First and foremost the source code had to be readily available. Secondly, the inner workings of the project and the missing functionality must be publicized and a dialog started. To this end the source code was made available publicly on GitHub and an issue tracking system was used to manage the large number of issues needed to be resolved in order to complete the port. A review process was setup to ensure that the code submitted was of sufficient quality.