4web.tex

\chapter{Web Development Technologies} 
\label{chapter:web}

Originally, the web was developed at CERN for sharing static scientific documents. Its foundation in HTML, URL and HTTP is still present although new technologies are becoming increasingly popular allowing the creation of dynamic applications. Furthermore, the developments in software engineering have affected web application development. The adoption of the Model-View-Controller design pattern for the web has spawn various frameworks based on different programming languages, such as Ruby, Java or Python~\cite{jazayeri:2007}.

There are also prominent frameworks written in Scala, such as Lift\footnote{ \url{http://www.liftweb.net/}}, Play\footnote{ \url{https://www.playframework.com/}}, Scalatra\footnote{ \url{http://www.scalatra.org/}} and Spray\footnote{ \url{http://spray.io/}}. However, the purpose of this thesis is not to build a self sustained system that requires continuous maintenance but to use existing course systems with minimum modification. Thus, these frameworks will not be introduced even though the lightweight framework Scalatra might be interesting for students to learn.

The obscuring of the traditional division of client side and server side tasks as well as the transition of desktop applications' to web have resulted in even more dynamic and efficient web applications. Browsers have become more powerful tools that can execute sophisticated client side processes and render vector graphics on the go.~\cite{jazayeri:2007}

Previously, visually impressive websites have used Java applets or have been built with Adobe Flash\footnote{ \url{https://www.adobe.com/products/flashruntimes.html}}. Flash is proprietary software and solely utilises ActionScript. Porting software written in Scala would require extensive effort and produce an application dependent on a browser plugin, which are notoriously vulnerable to security flaws. Wrapping exercises into Java applets would be technically easy as Java and Scala are interoperable. However, running Java in a browser is no longer considered secure and for instance the latest versions of the highly popular browser Chrome no longer support Java plugins. Additionally, there are some size issues in Java Applets that must contain all class files; usually class files are shrunken and jar-packaging is used. To summarise, even if Adobe Flash or Java applets could provide a working solution, they would not result in a modern or an appealing result.

HTML5 is considered as a replacement for Flash and together with JavaScript it enables building applications that work similarly in all browsers. Because HTML5 can not provide interactivity on its own, we will look into solutions based on JavaScript. In Section~\ref{section:client} we explore options that execute code on the client side, while Section~\ref{section:server} is concentrated on solutions for server side code execution.


\section{Client Side Code Execution}
\label{section:client}

In recent years, programming has become more accessible for beginners with the development of new easy to use and available tools. Writing and executing program code written in a compiled programming language no longer requires installing a programming environment but can be done entirely online. Even compiling and executing of code is possible online with libraries relying heavily on JavaScript.

Skulpt\footnote{ \url{http://www.skulpt.org/} and \url{https://github.com/skulpt/skulpt}} provides a JavaScript implementation of Python that runs in-browser. User-written Python code is first compiled into bytecode, and then decompiled to JavaScript. However, Python and JavaScript objects, functions, etc. are not equivalent. Hence, the JavaScript code generated by Skulpt is not proper JavaScript representation of Python and it can not be directly called from other JavaScript applications. Furthermore, Skulpt has been used together with the Online Python Tutor\footnote{ \url{http://pythontutor.com/}}~\cite{guo:2013} for teaching purposes in digital textbooks and in online programming courses.

A relatively new addition to JavaScript-based implementations is Scala.js\footnote{ \url{http://www.scala-js.org/} and \url{https://github.com/scala-js/scala-js}}, which is quite similar to Skulpt. Scala.js is a Scala to JavaScript compiler that transforms Scala code into intermediate \texttt{.sjsir} files. To produce proper JavaScript, the \texttt{.sjsir} files are linked and optimised into a single JavaScript file that can be incorporated with HTML. Unlike Skulpt, Scala.js provides much better interoperability with JavaScript code. Currently there are no documented examples of use of Scala.js for educational purposes.

Unlike Skulpt or Scala.js, Repl.it\footnote{ \url{http://repl.it/} and \url{https://github.com/replit/repl.it}} supports several programming languages (e.g. C, C++, Java, Python, Scheme). Skulpt provides an in-browser environment for exploring programming languages and enables also sharing code snippets through URLs like pastebin. The ideology behind Repl.it is thus quite different from Skulpt and Scala.js --- Repl.it provides, as its name suggests, only a \emph{read-eval-print-loop} and is not intended as a library for use in private projects. For each implemented programming language Repl.it contains a language interpreter written in JavaScript, which translates the code to executable JavaScript. The project is no longer actively maintained, as the developers are moving to a sandboxed solution.


\section{Server Side Code Execution}
\label{section:server}

A more comprehensive solution to executing code online is to set up a sandbox or a virtual machine. Compared with client side execution restricted server side environments can offer higher performance and better control over security. On the down side, when the code is executed on a server, the user sees only the end result of an execution. Implementation of interactive functionality is limited and possible only if the system provides a way for user input, which is generally standard input and has to be defined in advance for the entire duration of a program execution or the code needs to be compiled multiple times like in the solution that Yoo et al.~\cite{yoo:2011} propose.

Codepad\footnote{ \url{http://codepad.org/}} is an online compiler and interpreter for about a dozen programming languages (e.g. C, C++, Python, Scheme) and operates also as a pastebin application. Codepad uses chroot jail for compiling and executing the resulting programs, which strictly limits the resources. Additionally, the run is supervised with \texttt{ptrace} and many system calls are discarded.

Ideone\footnote{ \url{https://ideone.com/}} created by Sphere Research Labs\footnote{ \url{http://sphere-research.com/}}, like codepad, is an online compiler with support for several programming languages (e.g. C, C++, Java, Python, Scala, Scheme) and pastebin functionality. Compared with codepad, Ideone emphasises debugging --- the code can be edited after execution, without altering the shareable URL. Sphere Research Labs offers Ideone and its API (called Sphere Engine) as a paid service for businesses and its precise technical implementation is not portrayed on their web sites. However, the high level solution is presented --- the code is compiled and run on a remote server and the program's output is returned to the browser.

The general tendency seems to be that services that offer remote code execution on a server (e.g. Codecademy Labs\footnote{ \url{http://labs.codecademy.com}}, Coding Ground\footnote{ \url{http://www.tutorialspoint.com/codingground.htm}}, lynda.com\footnote{ \url{https://www.lynda.com/}}, Runnable\footnote{ \url{http://runnable.com/}}) also cater for commercial purposes. Therefore, in addition to the fact that service indeed compiles and executes code on the server side, no other technical facts are revealed.