\documentclass{sigplanconf}

\usepackage{amssymb}
\setcounter{tocdepth}{3}
\usepackage{graphicx}

\usepackage{url}
\urldef{\mailsa}\path|{tim.coppieters, lphilips, alombide, wdmeuter}@vub.ac.be|


\usepackage{listings}
\usepackage{color}
\usepackage{listings,calc}

\newcommand{\lstul}[1]{\underline{\mbox{\tt #1}}}

% Switch between footnote or cites for urls
%\newcommand{\www}[1]{\cite{#1}}
 \newcommand{\www}[1]{\footnote{\url{#1}}}

\usepackage{courier}


\definecolor{lightgray}{rgb}{.9,.9,.9}
\definecolor{darkgray}{rgb}{.4,.4,.4}
\definecolor{purple}{rgb}{0.65, 0.12, 0.82}

\lstdefinelanguage{JavaScript}{
  keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break},
  keywordstyle=\color{blue}\bfseries,
  ndkeywords={class, export, boolean, throw, implements, import, this},
  ndkeywordstyle=\color{darkgray}\bfseries,
  identifierstyle=\color{black},
  sensitive=false,
  comment=[l]{//},
  morecomment=[s]{/*}{*/},
  commentstyle=\color{purple}\ttfamily,
  stringstyle=\color{red}\ttfamily,
  morestring=[b]',
  morestring=[b]"
}
\lstset{
   language=JavaScript,
   backgroundcolor=\color{lightgray},
   extendedchars=true,
   basicstyle=\scriptsize\ttfamily,
   showstringspaces=false,
   showspaces=false,
   numbers=left,
   numberstyle=\scriptsize,
   numbersep=9pt,
   firstnumber=1,
   tabsize=2,
   breaklines=true,
   showtabs=false,
   captionpos=b
}

\newcommand\synerj[0]{\textsc{SynerJ}} 
\hyphenation{par-a-digm con-structs RFID-tag-ged RFID-en-abled computer-science-books}



\begin{document}

\special{papersize=8.5in,11in}
\setlength{\pdfpageheight}{\paperheight}
\setlength{\pdfpagewidth}{\paperwidth}

\conferenceinfo{CONF 'yy}{Month d--d, 20yy, City, ST, Country} 
\copyrightyear{20yy} 
\copyrightdata{978-1-nnnn-nnnn-n/yy/mm} 
\doi{nnnnnnn.nnnnnnn}

\title{\synerj{}: a Live Collaborative Web Development Environment}

% the name(s) of the author(s) follow(s) next
\authorinfo{Tim Coppieters \and Laure Philips \and\\ Andoni Lombide Carreton\titlenote{The author does currently work for Mobile Vikings} \and Wolfgang De Meuter}
{Software Languages Lab, Vrije Universiteit Brussel}
{\mailsa}

\maketitle


\begin{abstract}

Thanks to evolutions of the web platform, web applications are becoming increasingly complex. Unfortunately, certain inherent characteristics of the web platform and the lack of development tools render web development a tedious endeavor. A way to solve this problem is to evolve the web platform itself, but this is a disruptive approach that would break many existing applications. In this paper, we propose \synerj{}, a live collaborative web development environment in the spirit of Self and Smalltalk IDEs that is built directly onto the existing web platform. \synerj{} aims to strongly reduce the complexity in developing, deploying, and maintaining web applications through tool support without modifying the web platform itself.

%Web programming is becoming more and more important, but it faces some problems. There are new problems, by the shift of web applications, such as distributed programming, but there are still some old problems such as the impedance mismatch of web technologies and tedious development cycles. By looking at pure object-oriented programming languages such as Smalltalk these problems are addressed in the framework \synerj{}.
\end{abstract}
\category{D.2.6}{Software Engineering}{Programming Environments - Integrated Environments}
\terms 
Design, Languages
\keywords
Web applications, Prototype-based, Collaborative Web IDE


%% INTRODUCTION %%

\section{Introduction}

Recent evolutions of the web platform have lead to increasingly complex web applications that go far beyond simple form-based web pages. However, to maintain backwards compatibility, the programming tools for building such rich web applications have not significantly evolved, or are only introduced piecemeal. This renders web development a tedious endeavour, suffering from a number of problems.

Web applications are traditionally developed as a three tier architecture, where the database, web server and client are each a tier.
Typically, the server is developed in languages like Java or PHP, the client uses the HTML, CSS and JavaScript languages, while the database requires SQL to query the data (in case of a relational database). To obtain a meaningful application, the programmer must manually bridge the gaps between these different technologies. An obvious one is that different data representations are used for the same data within the single application. This is known as the \textbf{impedance mismatch problem} \cite{Cooper06links} of web technologies. 
Within the client tier, one must employ a markup language (HTML), a style language (CSS) and a scripting language (JavaScript). JavaScript provides a prototyped object-oriented environment, while HTML and CSS are tied together through the use of identifiers, classes and selectors on DOM element types, requiring the web developer to again manually overcome this mismatch \cite{Hemel11mobl,Mikkonen}. 
On top of this, cross-tier technologies such as Ajax for asynchronous communication can be added to the technology stack.

Figure \ref{fig:three_tier} summarizes the classical three tier architecture of a web application. 
%On top of that, there is also a mismatch between the client-side languages, namely HTML, CSS and JavaScript. 
%Together they define the user interface of the application that shows up in the browser. The runtime representation of the user interface is called the DOM (Document Object Model), and this structure can be changed at runtime by using JavaScript.
%Although these client-side languages separate representation, style and interaction, they also force you to program in two different styles to work with one and the same data \cite{Hemel11mobl}. 
%JavaScript provides a prototyped object-oriented environment to work in, while HTML and CSS are tied together through the use of id's, classes and selectors on element types. 
%There are systems who address this problem by building new nifty systems on top of these technologies, but these systems lack backward compatibility and thus do not receive a lot of support in the industry. \\ 

\begin{figure}[h]
  \centering
  \includegraphics[width=0.9\linewidth ]{figures/threetier}
  \caption{Three tier architecture of a web application} \label{fig:three_tier}
\end{figure}

% Moet naar andere sectie.
%Several state of the art technologies solve the impedance mismatch problem by providing one single programming language that covers the three tiers of a web application.  Examples of these so-called tierless or single-tier languages are Hop \cite{Serrano06hop}, Links \cite{Cooper06links} and OPA\footnote{\url{http://www.opalang.org}}. These languages allow the programmer to focus on the logic of the application instead of writing glue code to solve the mismatches between the different technologies. On top of that, they allow bidirectional communication between client and server, something that can be achieved in a traditional setting by using WebSockets.

%The rise of Node.js\footnote{\url{http://www.nodejs.org}}, a JavaScript server language, and NoSQL databases such as MongoDB brings more and more coherence to the different tiers. Although data can be represented and handled in the same fashion on all tiers, the programmer is still obliged to program the 3 tiers separately. \\ \\


%\subsubsection{Tedious Development and Lack of Tools}
\textbf{Developing for the web is tedious} in comparison to developing for other platforms because traditional development tools that were designed for other platforms are not usable on the distributed web platform. 
A reason for this \textbf{lack of tools} is the dynamic nature of JavaScript, which makes it hard to perform techniques such as static analysis to reason about the code \cite{tajs2009}. 
One could use a less dynamic language and compile that language to JavaScript, an approach undertaken by Google by compiling Java to JavaScript using the Google Web Toolkit (GWT) \www{http://developers.google.com/web-toolkit/}. This approach however, comes with a cost: existing web development libraries for JavaScript (such as jQuery \www{http://jquery.com/}) cannot be used anymore, and the impedance mismatch between a language like Java and languages such as HTML and CSS becomes even larger than before, which renders scripting a web page an extremely tedious process.

An alternative approach is embracing the dynamic nature of JavaScript and use this to build advanced development tools. These tools however, are currently just debuggers (e.g. Firebug \www{http://getfirebug.com/}) and the read-eval-print loop of modern browsers. This means that debugging client-side code is tedious because using browser tools one cannot directly modify the code, since it is served by the server. This hinders the incremental development made possible by such a dynamic language.

%The current development cycle of a web programmer is mostly the following: in a first step he first writes some code (both client- and server-side) in its favorite text editor and then runs it. The server code may already produce some errors, which are probably prompted to its terminal. After manually debugging the server-side code, the application can be tested in the browser and further errors can show up.\footnote{For simplicity, test and other additional cycles are omitted.} The browser is a fairly complete debugger for front-end code and it allows the programmer to adjust code on the fly and see the changes, using tools like FireBug. Of course these changes aren't reflected in the static source code, so the programmer needs to go back to his text editor to adjust the code there when he got it right. \\ 

%\subsubsection{Consistency of Highly Distributed Applications}

As mentioned above, current programming technology for the web strongly focusses on the classical three tier model. However, a highly responsive web server such as Node.js\www{http://www.nodejs.org/} in combination with the lightweight, bidirectional communication offered by WebSockets, enable web applications that are both much more interactive and distributed on a much finer-grained level. In many cases, data is replicated over several clients and the server (e.g. by sending around JavaScript objects as JSON strings) and can be modified on all these locations. Not all these data are necessarily persistent, which means that the database is no longer the central source of synchronization. This requires web developers to \textbf{implement distributed consistency mechanisms} by hand over and over again to keep the replicated data consistent.

%Web applications themselves are shifting away from traditional data representation, where the user sporadically submits some information, to highly interactive applications. Instead of displaying a single HTML-document to the user, applications allow clients to interact, collaborate, etc.
%  Moreover, web applications nowadays start to offer a (minimal) functionality when the user is not connected to the server. 
%As a consequence, when the replicated data on the client-side changed, these changes need to be propagated to the server in such a way that the data is synchronized and consistent on each client.  
%These interactive applications thus have the constraint to be highly synchronized, meaning that when one user changes something to the environment, this needs to be reflected to all the other users directly.
%
%Although new web technologies such as WebSockets already address this new requirement fairly well by allowing bidirectional communication between client and server, this is still done on an arguably low level. In an ideal environment synchronization should be a natural thing for the programmer to do, or it should even happen automatically and transparent for the users.
%
%When talking about synchronization, one must also take into account that network traffic is the greatest factor of performance, which should thus be taken into account. 

The approach we envision addresses the mentioned problems in the following way:
%The goal is to address these three problems with a single system. In order to address them properly, some requirements are set up:
\begin{enumerate}
\item{%A framework where HTML, CSS and JavaScript are used in a unified prototyped environment.
To circumvent the impedance mismatch of web technologies, we propose to represent \textbf{every single application entity as an object} (in the object-oriented sense). 
These objects may represent internal application logic or may be presentation entities (such as HTML elements). 
The second category may contain style properties (i.e. CSS), which can be adapted just like any property. 
Objects may refer to any kind of other object. In our approach, there is no difference between a model, a view, and a controller. 
Every single object can play any of these roles. Modifying a view from the browser GUI has the expected effect on the underlying data both on the client and on the server. 
Web applications are entirely expressed in terms of such objects, eliminating the impedance mismatch.}
\item{%Transparent synchronization of applications.
Objects conceptually live on the server, but can be replicated to all clients. 
Modified replicated objects should \textbf{transparently synchronize} with the server and other clients to maintain a consistent state of the web application with which multiple clients are interacting. 
Modifying objects can happen by users that interact with presentation objects from their browsers' GUIs, or by side effects caused by the internal application logic. 
By relying on simple per-object rules, a simple consistency mechanism can be obtained. 
For both programmer and user, the web application is presented as a single instance running on a server with which can be directly interacted and that can be modified, even though parts of the application are in reality running in the browser and synchronizing with the server.}
\item{%An IDE that runs live on top of the framework. 
Building on top of the aforementioned infrastructure, a \textbf{purely object-based IDE} can be built which is much more advanced than current web development tools and ties much closer to the programming model and the resulting applications. In fact, development tools part of the IDE become just other web applications conceived by the same object-based building blocks. 
This allows for a different development cycle for web applications, much more akin to the incremental development cycles found in image-based programming technology such as Smalltalk IDEs, but now in a browser. Modular application pieces become objects with a clear object-oriented interface which are stored on the server and can be seamlessly integrated into another web application, reducing the tedious development of traditional web development approaches. Similarly, new development tools are built using the same concepts, allowing for easy customization of an IDE.}
%\item{Zero setup: fully cloud and browser based. }
\end{enumerate}
To demonstrate the feasibility of this approach, we built \synerj{} \footnote{The complete code of \synerj{} can be found at \url{https://github.com/ticup/SynerJ}}: a live collaborative web development environment adhering to the above requirements. \synerj{} is discussed in the next section. 
In Section \ref{relatedWork} we elaborate on related work followed by a discussion on avenues of future research and possible enhancements to \synerj{} in Section \ref{futureWork}. Finally, Section \ref{conclusion} concludes this paper.

%% SYNERJ %%

\section{\synerj{}}
\label{sec:synerj}
\synerj{} is a framework that allows programmers to develop web applications in a browser environment by using mainstream web technologies.
The framework addresses the aforementioned problems by meeting the proposed requirements.

First of all, it introduces a small layer where it unifies HTML, CSS and JavaScript in one simple prototyped environment. The environment consists of objects which have normal properties, attributes, CSS properties and event handlers. \synerj{} supports prototype-based programming, allowing to factor out all common behavior in a prototype object. This inheritance is achieved through setting the \emph{prototype} property of an object to another object. Not only behavior, but also style and event handling can be stored in a single prototype object. For instance, the entire style of a collection of objects can be easily altered by simply changing its prototype.

Secondly, these objects and their properties are synchronized by default over all clients and server. This means the programmer works in an environment that is transparently synchronized. From now on, we refer to the set of objects in a single running \synerj{} instance as \emph{the environment}. More concretely, a master/slave model is used to centralize the data and push the changes on this data to the clients.
The server is used to maintain requests to change the data and keep all the replicated environments up to date and synchronized. 

On top of this unified synchronized framework there is a graphical in-browser IDE, which consist of an \emph{Inspector}, \emph{Editor} and \emph{Evaluator}.
The Inspector allows the programmer to inspect objects, but also to delete or create them. The Editor on the other hand provides a way to change the properties of objects, while the Evaluator lets the programmer interact with the environment programmatically.

Moreover, because the IDE merely inspects an application and adjusts it directly, it is possible to do collaborative development where the changes of one developer are directly reflected into the environment of the other programmers. \synerj{} makes sure that no collisions between different clients can happen and that every client receives the changes of other clients.
%In the next section, we show how a simple web application can be incrementally developed using \synerj{}.

We first introduce the framework by its overall architecture, after which we show how the typical development process for web applications is altered by \synerj{}.

\subsection{Architecture}

\synerj{}'s implementation relies exclusively on standard web technology. 
%\paragraph{}
To start, it is important to note the difference between the architecture of a traditional web application server and \synerj{}.
Figure~\ref{traditional_setting} depicts a traditional architecture, where the server is the main program which produces different views for the client so it can use different pieces of the program. 
Figure~\ref{synerj_setting} depicts \synerj{}'s architecture, where the main program is actually the client-side code, being HTML, CSS and JavaScript and the server merely serves these environments and keeps all instances of an environment synchronized at all time. An \emph{environment} is a single running instance of \synerj{}. From now on we use environment to refer to the set of objects in such an instance rather than the instance itself.
% TODO here
Thus a client in \synerj{} is in fact so rich that the difference between the client and server is blurred. 
This resembles the so-called diffuse applications of the Hop programming language \cite{Serrano06hop}, that do not strictly implement the traditional client-server architecture.

\begin{figure}[!h]
  \centering
	\includegraphics[width=0.75\linewidth ]{figures/client-server_traditional}
  	\caption{A traditional web application architecture: the server is the main program, clients get to see different parts of it.} \label{traditional_setting}
\end{figure}

\begin{figure}[!h]
  \centering
	\includegraphics[width=0.75\linewidth]{figures/client-server_synerj}
  	\caption{\synerj{}'s setting: the main client-side program is the main program, the server manages these programs and keeps them synchronized.} \label{synerj_setting}
\end{figure}

%\paragraph{}
The \synerj{} server is written in Node.js, an HTTP server on top of the V8 by Google, which in the first place can handle a lot of user interaction because of its event-driven kernel. The most important part though is that it is entirely JavaScript-based. This allows to emulate browser behavior and thus to run client-side code on the server. This completely closes the gap of data representation and program representation between client and server.
\synerj{}'s server makes use of this browser emulation by running every environment in memory in the same manner the application would be running on the client (browser). One and the same application is thus running on the server and possibly on several clients. Since these applications are in essence just a DOM tree, they can be easily transferred from the server to the client using the well-known web technology stack. Because applications are kept in memory at all times, persistence is just a matter of backup for when the server crashes. This makes persistence boil down to just writing away these files to disk. When the server is restarted, the environments can be loaded back into memory in the same way the clients do this when they load an environment. We will revisit persistence concerns in Section \ref{futureWork}. \\

%\subsubsection{Replicated Object Synchronization}\label{synchronization}
In order to synchronize all instances of an environment at all times, every instance can be accessed through two API's, namely the \emph{Synchronized} and \emph{Core} API. These API's include actions such as creating objects, setting properties, manipulating their tree structure, etc. The Synchronized API performs such actions on the environment in context of all instances, while the Core API only applies them to the target instance. The strength and simplicity lies within these API's, which are used in two different ways:

\begin{enumerate}
\item{The first is by the IDE which uses the client's Synchronized API to make changes to the environment. The client's Synchronized API simply passes the request through to the server, which then triggers that same Synchronized API request on the server's environment. This in its turn triggers the corresponding core action first on the server by using the Core API, which possibly adds information such as a new identity for a newly created object.
The action than gets propagated to all client instances that perform the action on their environment as well.}
\item{The second is by execution of code. Code, whether it is a method or a piece of code originating from the evaluator, is always executed in context of the instance on the server. This means executed code directly uses the server's Synchronized API. By consequence any change made is reflected on all running environments.}
\end{enumerate}

The flow of these API's is depicted in Figure~\ref{architecture}.
\begin{figure}[!h]
  \centering
	\includegraphics[width=0.75\linewidth]{figures/architecture_simple}
  	\caption{The flow of API calls between the instances of the environments.} \label{architecture}
\end{figure}

The Core API and (un)marshalling code is in essence mostly one and the same on client and server. This could lead to tremendous code duplication, but because client and server are both written in JavaScript this code can simply be shared. Additionally, because this core code can be run on both server and client, this also results in reduced network transport. For instance, if the prototype property of an object is changed, it could possibly inherit a lot of new CSS properties. Traditionally the server would calculate these changes and instruct all clients to change each property separately. In \synerj{}'s setting, because this core code can be shared, the server merely instructs the clients to set the prototype property and server and clients do the property calculations for themselves.

As explained earlier, changes are always first centralized on the server in order to maintain high synchronization between all instances. 
This means that after a client altered the environment, the change is only reflected when the server finished the desired operation.
Waiting for the percolation of this change to the client side does not disruptively affect the developer's working experience.

\subsection{Environment}
As mentioned before, the environment is a single running instance of \synerj{} and embodies a set of objects: \emph{graphical} and ``\emph{normal}" objects.
Because \synerj{}'s goal is to use conventional web technologies as building blocks, the graphical interface uses the DOM tree\www{http://www.w3.org/DOM/}, which is platform- and language independent. Because a DOM object does not support prototyped inheritance, abstractions on top of these objects are necessary.
The approach of extending the DOM objects forces the programmer to rely on a certain implementation of the DOM tree. The W3C web standard does not specify an implementation of the DOM tree and thus extending specific implementations renders \synerj{} to be not platform-neutral.

We did not choose to extend or write a new abstraction for the DOM tree, but got inspiration from the approach the jQuery library takes.
Instead of extending or writing a new abstraction, the library has a jQuery object that can be used to query the DOM tree. When these objects are queried, not the DOM objects themselves are returned, but a wrapper around those objects. It is then possible to send messages to that wrapper like it is the actual DOM object.
So a graphical object in \synerj{} is also a wrapper, or some kind of proxy, for the actual DOM object it represents.

The normal objects are used for the logic part of the web application. For the reason that \synerj{} is a prototyped environment, the business logic is abstracted into these prototyped objects that interact with the graphical objects. \\

Because \synerj{} provides a visual way of programming, programmers do not only structure their code in files and directories, but an additional way to depict the code is needed.
Obviously the graphical objects are visualized using a tree representation, equivalent to the DOM tree. In addition, the normal objects are also represented as a tree. 

By implementing the normal objects as ``hidden'' graphical objects, the tree structure and tree manipulation methods are gained for free.
An advantage of this approach is that \emph{template graphical objects} can be made, that are implemented as normal objects and thus have no graphical representation.
However, this normal object can now have style properties and UI event handlers and can thus act as a prototype for the actual graphical objects.
An example application is implementing normal objects for colors: e.g. a \texttt{Black} and \texttt{Red} object. They have a single property, namely the CSS property color set to the color they stand for. The graphical object \texttt{Text} (a \textsc{div} element containing text) can change its prototype to either the \texttt{Black} or \texttt{Red} object and thus as a result changing the color of its text. 

Another consequence of this design choice is that the entire \synerj{} environment at its core is a DOM tree, incorporating the logic and the user interface of the environment.
This simplifies persistent storage and the transferring of the environment. The environment gets parsed when sending it between server and clients into an HTML file containing the DOM tree, a CSS file for the style properties and a JavaScript file to add event handlers to the user interface. Browsers are able to parse these files and generate a correct DOM tree corresponding to the environment, the core of the application. \\

Typically when multiple clients can edit a shared environment, some form of collision detection and/or handling must be incorporated.
Developers that use \synerj{} could for example wind up in the situation where two of them are editing the same function. When one of them commits his changes, the other client's work on this function is lost because the change of the other developer gets pushed into his environment. As a solution, \synerj{} uses a simple locking system where a client must first send 
a \emph{lock request} to the server to gain a lock on a certain object. Only when the object has no other lock, the client receives permission to edit the object. When the editing user has commited his change to the locked object, the object is freed again. When the client disconnects, the object also gets automatically freed again.

\subsection{Developing in \synerj{}}

In this section, we introduce a small example application that -- to show the development process promoted by \synerj{} -- is adapted incrementally. 
This example application is a toy car with an engine that can be turned on or off and to which coordinates can be given to drive to. What follows is the cycle of creating this application in \synerj{}. 

%\paragraph{}
To start, a new environment is created by visiting \\ \texttt{http://host/car.create} and providing the correct credentials. \texttt{car} is an existing object on the server. To edit the environment, \texttt{http://host/car.admin} is visited with a browser, providing the correct credentials again. This will display the, currently empty, environment accompanied with some editing tools\footnote{To visit the environment without development tools or permissions one can simply visit \texttt{http://host/car}, which shows the application as users will see it.}.

%\paragraph{}
The Inspector is one of the main tools and manages all objects of the environment in a tree. For graphical objects, this tree makes up the DOM tree, for the normal objects it is just a way of structuring them. By using the Inspector a \textsc{div} object named \emph{car} and a child \textsc{div} object thereof named \emph{wheel1} is created.

%\paragraph{}
The Editor allows to inspect and edit a particular object, be it its properties, style, attributes or event handlers. The Editor can be accessed by double clicking an object in the Inspector. To bundle the behavior and style of our newly created objects, two normal objects, named \emph{carProto} and \emph{wheelProto}, are created. The \emph{car} and \emph{wheel1} objects are both given a property named \emph{prototype}. This is achieved by clicking on the bottom empty cell of the object's properties, which provides an input field to enter a name for the property. Afterwards the prototype objects are assigned to the \texttt{prototype} property of the respective object by dragging their inspector representation onto the prototype value field in the editor. Figure~\ref{example1} depicts the current state of the Inspector and the action of dragging an object onto a value field to assign it. The car needs four wheels, therefore the \emph{wheel1} object is copied three times through the Inspector.

\begin{figure}[!h]
  \centering
	\includegraphics[height=63px]{figures/example1}
  	\caption{Dragging an object from the Inspector onto a value field in the Editor assigns that object to the corresponding property.} \label{example1}
\end{figure}

%\paragraph{}
Next, some CSS properties are assigned to the prototype objects to dictate the style of the body and wheels of the car. CSS properties are added through the Editor just like normal properties, in a spreadsheet-like manner. By giving some \texttt{background-color}, \texttt{width} and \texttt{height}, the car object is now a red rectangle and the wheel objects a blue square. By switching to \emph{Development Mode} all objects their event handlers are detached and special editing facilities are provided. For instance, objects can now be dragged around, changing their \texttt{top} and \texttt{left} CSS properties accordingly. Figure~\ref{example2} shows a snapshot of the current state of the environment.
\begin{figure}[!h]
  \centering
	\includegraphics[height=69px]{figures/example2}
  	\caption{A second snapshot of the environment, showing the GUI created for the car and the CSS that makes up the body of it.} \label{example2}
\end{figure}

In order for the car to drive, some methods are added to the \emph{carProto} object. Assigning a function skeleton to a property provides a full fledged editor with syntax highlighting and checking to edit the function instead of the normal input field. Doing so, three methods are added, namely \texttt{turn}, \texttt{vertical} and \texttt{horizontal}, which allow to change the direction of the car. Figure~\ref{example3} depicts the implementation of the \texttt{turn} method in the editor.

\begin{figure}[!h]
  \centering
	\includegraphics[height=135px]{figures/example3}
  	\caption{The \texttt{turn} method shown in the editor.} \label{example3}
\end{figure}

Another development tool readily supported by \synerj{} is an evaluator which allows the programmer to interact with the environment in a programmatic manner (i.e. using traditional JavaScript with the addition of some \synerj{} primitives to access the framework). Figure~\ref{example4} depicts how this can be used to test the newly created \emph{turn} method. Notice the use of the \emph{\synerj{}} object, which allows to retrieve the objects by their identity. Furthermore, these objects have an API to manipulate CSS properties, HTML attributes, event handlers and to perform DOM operations which is similar to that of the jQuery library\www{http://jquery.com/}. Their normal properties can be accessed and set by the dot-operator, just like normal JavaScript objects. Figure~\ref{example3} exemplifies the CSS manipulation API and Figure~\ref{example6} the use of the dot operator.

\begin{figure}[!h]
  \centering
	\includegraphics[height=90px]{figures/example4}
  	\caption{Interaction with the environment can also be done programmatically through the use of the Evaluator.} \label{example4}
\end{figure}

%\paragraph{}
Now that the car can be properly directed, it is time to get it driving. A naive implementation to do this would be to add a method \texttt{drive} that takes an \texttt{x} and \texttt{y} coordinate as arguments and then periodically changes the position of the car until the coordinates are reached. There is one problem with this implementation though. When the method is executed multiple times at the same time, a closure is created for each execution and this will result in the car jumping between different routes. A first improvement would be to add an \texttt{xDist} and \texttt{yDist} property to the car, which will then be used by the methods to drive to. This will result in all methods using the same \texttt{x} and \texttt{y}, but it will still result in more instances of the method running at the same time. A better solution is thus to have one main loop constantly running that checks whether the \texttt{x} and \texttt{y} coordinates are met and moves the car accordingly. The \texttt{drive} method then merely sets the \texttt{xDist} and \texttt{yDist} properties to the given values, while the main loop does the computations for the driving. An \texttt{ignite} and \texttt{stop} function is provided to start and stop the main loop. In order to see if the car is ignited a siren is added that flickers if so.

%\paragraph{}
Figure~\ref{example6} shows the result of using the \texttt{turn} method on the \emph{car} object in the Evaluator.

\begin{figure}[!h]
  \centering
	\includegraphics[width=0.90\linewidth]{figures/example6}
  	\caption{The result of executing the drive method on the car object through the evaluator.} \label{example6}
\end{figure}

%\paragraph{}
The engine of the car is now added through the \texttt{ignite} method, together with its complementary \texttt{stop} method. The implementation of the \texttt{ignite} function can be seen in code snippet ~\ref{example8}. It uses the \texttt{setTimeout} function to change the color of the sirene and to move the car, if necessary, according to the current and given position.

%\begin{figure}[!h]
%  \centering
%	\includegraphics[width=0.95\linewidth]{figures/example7}
%  	\caption{The ignite function of the carProto object.} \label{example7}
%\end{figure}

Code snippet ~\ref{example8} depicts the final implementation of the \texttt{ignite} method. The Evaluator to test this method:
all code can be executed at once or only the selected lines ca be executed. 

\begin{lstlisting}[float,language=JavaScript,label=example8,caption=Ignite method of the carProto object,  escapeinside={\#}{\#}]
function ignite () {
	var sirene = this.sirene;
	var car    = this;
	var step   = this.step;
	
	this.running = true;
	
	function up () {
		sirene.setCss('background-color', 'green');
		if (car.running) {
			var xDist = car.xDist;
			var yDist = car.yDist;
			if (car.xDist) {
				if (Math.abs(xDist) < step) {
					return car.xDist = false;
				}
				var dst = (xDist > 0) ? step : - step;
				car.horizontal();
				car.setCss('left', parseInt(car.getCss('left')) + dst + "px");
				car.xDist = car.xDist - dst;
			} else if (car.yDist) {
				if (Math.abs(yDist) < step) {
					alert('Your car has arrived!');
					return car.yDist = false;
				}
				var dst = (yDist > 0) ? step : - step;
				car.vertical();
				car.setCss('top', parseInt(car.getCss('top')) + dst + "px");
				car.yDist = car.yDist - dst;
			}
			setTimeout(down, 100);
		}
	}
	
	function down () {
		sirene.setCss('background-color', 'red');
		setTimeout(up, 100);
	}

	up();
}

\end{lstlisting}
%\begin{figure}[!h]
% \centering
%	\includegraphics[width=0.90\linewidth]{figures/example8}
 % 	\caption{The ignite function of the carProto object.} \label{example8}
%\end{figure}


%\paragraph{}
To make it possible for visiting users (people who can not access the developer tools) to interact with the car, a toolbar is added with a start/stop button, an x- and y-input field and a goto button. 

%\begin{figure}[!h]
%  \centering
%	\includegraphics[width=0.90\linewidth]{figures/example9}
%	 \vspace{-1em}
%  	\caption{The application with the toolbar in order for normal users to interact with the car.} \label{example9}
%	\vspace{-1em}
%\end{figure}

%\paragraph{}
To wrap it up, an extra prototype layer is added on top of the \emph{carProto}. This layer is responsible for the representation of the car. By making a blue and green representation it is possible to change all the cars their color by simply assigning the \emph{blueCar} or \emph{greenCar} object as prototype to the \emph{carProto} object. Figure~\ref{example10} depicts this addition. \\

\begin{figure}[!h]
  \centering
	\includegraphics[height=160px]{figures/example10}
  	\caption{After assigning the greenCar as prototype of the carProto all cars will be green.} \label{example10}
\end{figure}


If one would create an application like this in a proper way, there would be the need for a Factory object, which creates new cars, assigns the proper property, etc. This has been left aside for the sake of brevity. Finally it is important to understand that every preceding step performed to create this car is synchronized. This means that other clients that are visiting the web applications see all changes instantly. Of course programmatic changes are handled in the same manner, so when the car is driving, all clients will see the car driving, not only the invoking client.

This application can now be used as it is. People can visit it (without all the development tools) and interact with the car. It is also possible to export the application. This provides the user an HTML, CSS and JavaScript file together with a version of the \synerj{} runtime for offline usage. In this manner the application can also be ran as a local browser-based application.



%Although this means when clients change something to the environment, they need to wait for the server to finish the desired operation before the change is actually reflected in the client its environment, this does not disruptively affect the developer its working experience.

%% EVALUATION %%

\subsection{Evaluating The Work}
Given the development cycle of the car application, it can be investigated whether \synerj{} meets the proposed requirements \footnote{Next to the toy example discussed in this paper, we implemented a number of other applications, such as a collaborative todo-list application where users can schedule, edit and prioritize tasks}.

\paragraph{A Unified Prototyped Environment}
It is clear that the programmer is using normal HTML, CSS and JavaScript technologies, but in one unified prototyped framework. CSS and event handlers are applied to one object, and can be applied to more objects through prototypical inheritance, just like normal properties. Furthermore, normal objects and DOM-tree (graphical) objects  are treated as one and the same, it is just that graphical objects have a representation on screen, normal objects do not.

\paragraph{Transparent synchronization of applications}
The framework explained as above is completely synchronized on a level of objects, properties, CSS properties, event handlers etc. This means the programmer can create completely synchronized applications without having to actually program the synchronization. As seen with the \texttt{drive} and \texttt{ignite} functions of the car, this does not mean he needs to watch out for certain pitfalls.

\paragraph{An IDE that runs live on top of the framework}
As shown, a minimalistic graphical IDE is provided on top of the framework. This IDE can inspect and edit the environment on the fly. It is also possible for the user to extend his/her environment programmatically through the use of the evaluator. Although this IDE already allows the programmer to develop in a very convenient way, there is still much room for improvement. It would for example be possible to add more extra features to the `Development Mode', such as in the Lively Kernel. This means adding direct action features on the object. Clicking on an object its graphical representation (not the inspector representation) would then for example provide a menu which allows you to inspect, resize, delete, rename... the object.

\paragraph{Zero setup: fully cloud and browser based}
All the programmer needs is a browser and an internet connection. He can create a new environment through the use of a simple HTTP request API and start editing the application in his browser. \\

The framework itself was evaluated by writing tests within the framework itself \footnote{The tests can also be found at \url{https://github.com/ticup/SynerJ}}. An approach using headless browsers, such as Zombie.js, to test the \synerj{} client is not workable because the implementation uses too much \emph{exotic} technologies such as web sockets. Instead, a test application was implemented in \synerj{} itself. It extensively tests the environment's API and checks if all correct actions are performed.
The application covers most situations and throws an error at the point where a certain test failed. Cases where e.g. the server reboots are harder to test and thus not incorporated. 


\section{Related Work}
\label{relatedWork}
We discuss two bodies of related work. The first are web development tools that aim to address similar problems. The second part are purely object-oriented development environments, which are the main source of inspiration for \synerj{}.

\subsection{Web Development}
%\subsubsection{Cloud-Based Programming}
Cloud-based web application editing platforms such as \textsc{Codeita} \www{http://www.codeita.com} and \textsc{jsFiddle} \www{http://jsfiddle.net} focus 
on creating collaborative applications in the cloud. 

\textsc{Codeita} uses an FTP server on which code and compilation files can be uploaded under projects. Developers can work together on these projects by using the web interface. By storing the projects in \emph{the cloud}, the projects are protected from hardware failures on the clients.

\textsc{jsFiddle} is often utilized for writing, testing, debugging, reviewing, \ldots JavaScript code. The collaboration option provides a chat for communication between clients and highlights where other developers are working in the code. Other collaborators can also fork a project.

In contrast to \synerj{}, these approaches do not synchronize changes instantly and the application is not adjusted lively. \\
%Furthermore they also do not provide an additional graphical IDE and neither are the applications directly synchronized.

On the contrary, the Meteor framework \www{http://www.meteor.com} is a purely JavaScript framework for modern web applications. It does not offer an IDE but supports hot code pushes, meaning that alterations to the JavaScript, HTML of CSS files that form the application are hot-pushed to each browser running the application.


Many JavaScript frameworks exist to ease the development of the front end of a web application, such as \textsc{Backbone.js} \www{http://backbonejs.org/}. This framework can be combined with for example \textsc{Skull.io} \www{https://github.com/codeboost/Skull.io}. While this combination provides a way for the programmer to easily synchronize objects and to program in a more enhanced JavaScript environment, this still requires the programmer to bridge the impedance mismatch with the backend manually.

%\subsubsection{Lively Kernel}
The \textsc{Lively Kernel} \cite{Ingalls:2008} by Sun Microsystems is an implementation of Smalltalk in the browser. The \textsc{Lively Kernel} was the main source of inspiration for our work.
The \textsc{Lively Kernel} namely uses `Morphs' to take care of presentation concerns, which is reminiscent to our approach in \synerj{} for presentation objects. However, because the \textsc{Lively Kernel} is a pure Smalltalk implementation, it is not (backwards) compatible with the wealth of existing web development libraries for JavaScript. With our work, we set compatibility with the current web technology stack as a goal. Furthermore, the environment the programmer works in is not synchronized, nor does it provide a way to make its application transparently synchronized. 

\subsection{Purely Object-oriented Development Environments}
\synerj{} is influenced by pure object-oriented languages that combine language and development tool technology.
The main example is Smalltalk. An important difference is that Smalltalk tools can rely on the extensive metaprogramming facilities of the language, whereas \synerj{} is forced to rely on the more primitive facilities of JavaScript instead of a full-blown meta-object protocol. An avenue for future work that we are considering is redesigning part of \synerj{} by relying on recent evolutions of the ECMAScript standard introducing more extensive metaprogramming facilities, such as proxies \cite{js-reflection}.

\textsc{Seaside} \cite{ITS08} allows to design web applications in Smalltalk through the use of continuations to model the flow between different components. For this, it exploits the support for continuations in Smalltalk.
% TODO: JTalk is nu Amber?
\textsc{Amber} \www{http://amber-lang.net/} is a Smalltalk implementation on top of JavaScript, which allows the programmer to write client-side JavaScript in Smalltalk.
Although Smalltalk systems were a large source of inspiration, \synerj{}'s prototype-based object model is more akin to Self \cite{Ungar87}.

%\paragraph

\section{Future Work}
\label{futureWork}
% Two things:
% Database Persistence, mention Ken-library, ongoing work
% Benchmarking \synerj{}
An application in \synerj{} is basically just a DOM tree. Although this simplified and minified a lot of work, such as persistence, setup and network transfer of the environment, this introduces some unnecessary overhead to the program. While this overhead is currently not visible in the created test applications, benchmarking tests should be created to test for scalability of this solution. In case this implementation becomes a clear drawback in larger applications, normal object should be implemented as normal JavaScript objects and not DOM elements. A special treatment for those object is then of course required. Meaning they will need their own persistence, network transfer and startup management, which was out of reach for this paper.\\

% Synchronization
The current synchronization mechanism as explained in Section ~\ref{sec:synerj} is still very optimistic. Although it has some very basic protection mechanisms, such as not allowing developers to adjust the same object at the same time, it does not cover some more intrinsic problems of distributed systems. Because of its simple symmetric client/server design, through the use of the API's, the \synerj{} framework would be an excellent candidate to perform synchronization research on. This work could go from simply comparing hashes of the environments and reloading the client environment if it is out of sync with the server to more advanced solution such as applying transformational operations at the level of the current API.
Another approach could be to exploit Cloud Types \cite{Burckhardt:2012} and its recent implementation for JavaScript \cite{Coppieters:2014} into the \synerj{} environment. This would enable eventual consistency, meaning that the distributed environments will \emph{eventually} become consistent with each other.
%% CONCLUSION %%
\section{Conclusion}
\label{conclusion}
By drawing inspiration from purely object-oriented languages such as Self \synerj{} tries to solve some problems web development is currently facing. In this way it addresses the problem of impedance mismatch of the client-side technologies by offering a unified way of using these languages in a prototype-based object-oriented environment. Furthermore it also allows distributed programming by fully, and transparently, synchronizing the programming/application environment at a level of objects and their different properties (like base, CSS and event properties). At last it also offers an alternative to the current tedious development cycle by providing a graphical IDE on top of the application that allows the programmer to inspect and edit it on the fly.
Using \synerj{}, web development becomes an incremental and collaborative effort with a set of advanced and easily extensible development tools.

\bibliographystyle{plain}
\bibliography{paper}

\end{document}