Last week I had lunch with Manusheel Gupta who was visiting Massachusetts from India. Manu was the person who managed the SocialCalc project on the One Laptop Per Child (OLPC) side. SocialCalc is a project that I did for SocialText, which consisted of an Open Source spreadsheet engine written completely in JavaScript, along with proprietary code that connected it to the SocialText system. The OLPC used an Open Source wrapper to connect SocialCalc to the XO laptop's system.

Manu told me that SocialCalc is still part of the XO experience for perhaps a million users (supported by a group called Seeta). He also told me how he and a group he works with have been using it in mobile apps. They wrap a web view in native code, load it with a carefully crafted spreadsheet, and then sell the combination as an app on Android and iOS stores. They have several different such combinations. Recently, they had 11 apps in the Amazon Android Top 100 Finance Paid Apps listing, including ones at #1, #5, and #11. (Making apps for mobile devices out of wrapped HTML and JavaScript is very common, more than you have probably been led to believe.) I've also heard of other uses of the SocialCalc code, such as in the Sheetnode module for Drupal, and Audrey Tang's multi-user EtherCalc.net. (Audrey was my main technical partner at SocialText in the latter parts of the project, and she documents the internals at that link.)

It's nice to see how one piece of JavaScript code can be adopted by others and live on to provide a major set of functionality for inclusion in other projects. (It's also nice to know that others can pick up my code.) As far as I know, SocialCalc is the most capable Open Source JavaScript-only spreadsheet module with standard formulas, functions, and formatting.

Other, more influential, JavaScript modules

SocialCalc is a relatively narrow JavaScript module, but other modules are helping JavaScript become a major force for providing client-side functionality. Of course, there is the ubiquitous jQuery and related libraries that has simplified the creation of a vast number of web sites and web apps. New libraries like that from Sencha are making it easier to create mobile web apps that look and feel like traditional native mobile apps, and they even showed how a JavaScript app for accessing Facebook could out-perform the "official" native code app. On the proprietary side, Google and even Microsoft are showing the incredible level of functionality that you can provide in a browser or web view in the productivity app world.

It is becoming increasingly clear that the combination of HTML5, CSS3, and JavaScript, along with the latest browsers, is emerging as a dominant (and in many areas THE dominant) user interface programming system.

New milestones

A major milestone, at least to me, happened last week when it was announced that Firefox 19, released as a production version, has a built-in PDF viewer that is written completely in JavaScript. The project to create this viewer is called PDF.js.

The PDF file format is pretty complex. It is something you would expect to be rendered by programs written in C++ or some other compiled language, not a scripting language originally used for simple text and DOM manipulation. However, JavaScript has grown up, and the standard graphics capabilities of the browsers have advanced, so now you can do something even as sophisticated as PDF rendering, and make it run quickly.

I found some interesting writeups about the implementation: There is a list of various publications and presentations about PDF.js on GitHub. I found this one, a PDF of slides from Yuri Delendik, titled "Evolving With Web Standards: The Story of PDF.js" to be informative. I also found the "live demo" on the PDF.js GitHub page interesting in two ways: It seemed to work quite well when I used it to read the same document in IE10 on my Microsoft Surface Pro (fonts, illustrations, and all), and the sample document it displayed, "Trace-based Just-in-Time Type Specialization for Dynamic Languages," explains how they made JavaScript run faster.

From these resources, you can see the feedback loop that exists between the needs of programmers and the upgrading of browser functionality and speed. Is the animation too rough when you make a simple loop changing the position of an element on the screen? No problem -- they just modify WebKit, et al, to use the graphics hardware and access that functionality with CSS. Are array operations too slow? No problem -- provide a more direct way to access the data. Interpreted code that accesses dynamically typed values running too slow? No problem -- innovate in just-in-time compilation. Not only are the CPUs getting faster through Moore's Law (2x every 18 months, modified by power consumption goals) but algorithm changes and strategies of switching from software to hardware give factors of 10 speedups to specific operations.

I remember working so hard to make sure that SocialCalc could handle a few hundred or a thousand rows of data in a timely manner on the low-speed XO laptop or under Internet Explorer 6 on an old PC. Now it runs much faster even with five or ten times as much data without changing the code.

There are other recent JavaScript-related developments: Mozilla previewed the first commercial build of their mobile operating system built around HTML5 on February 24th (you can already install it on a few existing Android phones), and today, February 26th, Microsoft announced the availability of IE10 on Windows 7, bringing improved support for CSS3 and touch events to their widely-used platform.

(Note that while I am focusing here on JavaScript, the language goes hand-in-hand with the environment in which it is running. In this case, on the user device, that means along with HTML and CSS which have also been evolving.)

I find this is pretty exciting. I like JavaScript. The three major browser engines, WebKit (Safari, Chrome, Android, etc.), Gecko (Firefox), and Trident (Internet Explorer), support it and CSS quite well (compared to the old days), and have special features targeted at touch-enabled and mobile devices (e.g., multi-touch and GPS support). It is much easier to make code that runs almost everywhere than it ever was in the early PC days with many operating systems and processor platforms. It's not perfect, and it's not for all types of apps, but it sure is above the bar necessary for an awful lot of common business applications, including the huge number of custom apps that will be needed for everything from sales support to tablets mounted on walls and equipment. With the prevalence of Bringing Your Own Device, and the need to support traditional desktop/laptop systems as well as smart mobile devices, I think we can see the new, smooth-performance place that has emerged for JavaScript when developers decide what to use when they build their apps.