Programming languages in chemistry: a review of HTML5/JavaScript.

This is one part of a series of reviews concerning the application of programming languages in chemistry, edited by Dr. Rajarshi Guha. This article reviews the JavaScript technology as it applies to the chemistry discipline. A discussion of the history, scope and technical details of the programming language is presented.

Introduction

Computer literacy is an essential skill for scientists. Computers can execute the same operations humans can perform, but far more consistently and at rates far beyond human capability, allowing researchers to investigate numerous hypotheses in short order. Programmers have even more advantages, as they can directly communicate with the computer to achieve their desired goals, as opposed to relying on software someone else has created for another purpose.

Many programming languages have been developed to facilitate instructions to the computer. Each has its advantages, which is why they each exist. Each programming language also has its disadvantages, which is why the rest exist.

When the Internet was introduced, society quickly changed, not just in allowing computers to communicate with each other, but by allowing people to communicate with each other, nearly instantaneously from around the world. JavaScript (JS) is a programming language born of the Internet. From a crude and basic programming language for creating cheap, gimmicky effects on web pages, it has developed into a ubiquitous and flexible technology where engine performance is regarded as a crowning achievement among browser developers. Today, every computational device, from desktops to laptops to mobile phones and Augmented Reality (AR) devices has essential access to the Internet, and therefore contains a web browser wherein JavaScript can be run. As a result, JavaScript is one of the most important programming languages in existence.

This review investigates the relevance and impact of JavaScript on the chemistry discipline. We begin by discussing the history of the programming language; then we investigate the scope and features of the language and how it applies to chemistry; last, an outline of the technical details of the JavaScript programming language is presented to allow those interested in chemistry and cheminformatics to effectively create JavaScript applications.

What is JavaScript?

JavaScript is a programming language enabling developers to interact with the functionality provided by web browsers. More specifically, JavaScript is a scripting language, which means (a) traditionally, JavaScript source code is interpreted at runtime and not pre-compiled into byte code and (b) practically, its main purpose is to modify the behavior of another application typically written in a different programming language, in which it is interpreted and run in real time.

While JavaScript is aptly named as a scripting language, the first part of the name misleadingly refers to the Java programming language [1]. JavaScript has no functional relationship with the Java programming language. The Java part of JavaScript was used to inspire interest in the new scripting language, as Java was and still is a very popular programming language; additionally the original Netscape browser that included JavaScript was written in Java. JavaScript has since become an essential and arguably more important programming language than the one inspiring its name. Hence, the programming language many developers use today to build and interact with web applications is famously known as JavaScript.

Origin

In the early days of the Internet, the web browser provided users with static pages to view information. Innovators at Netscape Communications, producers of the popular Netscape Navigator browser, believed web sites should provide more dynamic material and a programming language would provide a solution. In 1995, Brendan Eich, an employee of Netscape Communications, developed what is now known as JavaScript [2].

Initially, JavaScript only provided basic features, but the power of such a programming language on the web was quickly realized, and the continued success of Netscape Navigator was, in no small part, a reflection of that power. Alternatives to JavaScript were inevitable and a number of companies started to produce more feature-rich browser plug-ins that would install their platforms into browsers to be run in web pages. Adobe Flash [3], Java applets [4] and Microsoft Silverlight [5] are a few well known examples. These plug-ins became popular solutions for developers, but a hindrance for users as plug-ins required installations, had to be frequently updated, and were prone to security issues. Plug-ins eventually fell out of favor with users as HTML5 arrived and JavaScript evolved. Flash, Java applets and Silverlight are all now deprecated technologies.

Other companies, instead of replacing JavaScript, attempted to modify and extend the language in an attempt to control it (a process known as “embrace, extend and extinguish”). In 1996, Microsoft produced JScript [6], which was a reverse engineered version of JavaScript for their Internet Explorer (IE) browser. IE would now be accessible to JavaScript developers, but the implementation was deceitful. Proprietary features specific to IE were built into JScript. As a result, users were forced to use IE for many online applications, impeding the open web in a process known as fragmentation. Fragmentation produces an anti-competitive, positive feedback loop giving a dominant group (in this case, the dominant browser, IE) power over the future direction of the Internet. These attempts ultimately failed due to healthy competition amongst browser developers. Microsoft browsers now aim to legitimately support JavaScript. Creative methods for fragmenting the JavaScript language continue to exist with TypeScript from Microsoft [7] and Dart from Google [8], which aim to provide a more familiar programming syntax for developers and compile into standard JavaScript.

JavaScript has survived many challenges since its inception, and a lot of credit should be given to the Netscape team for their foresight. In order to protect the JavaScript language early on, the Netscape team pushed for an open standardization of the language, and they were successful. We all benefit from the universal and strong support for JavaScript in every existing browser today. In spite of the attempts to replace or commandeer the standard, JavaScript persisted and has become a signature programming language for most developers, and remains an important tool for the scientific communities including chemists.

ECMAScript

The European Computer Manufacturers Association, now known as Ecma International [9], took over the governance and standardization of JavaScript in 1996 and continues to maintain the specification for the language to this day. The JavaScript specification is officially named ECMAScript, defined by the ECMA-262 standard published by Ecma International [10]. So paradoxically, JavaScript led to the development of the ECMAScript standard that now governs the development of JavaScript. JavaScript also contains functionality to access technology standards not governed by Ecma International, such as HTML5 [11] and Web Graphics Library (WebGL) [12] for 2D and 3D graphics in webpages.

JavaScript is not the only implementation of ECMAScript. Due to the large number of developers programming in JavaScript (and therefore ECMAScript), ECMAScript has been used as the framework to develop other, non-browser-based technologies. Node.js [13] compiles ECMAScript for server systems. ActionScript [14] was an Adobe implementation of ECMAScript providing scripting functionality to the now deprecated Adobe Flash Player platform. Rhino [15] and its replacement Nashorn engine [16], provide Java based ECMAScript scripting environments in Java applications. The multitude of ECMAScript implementations causes confusion as many engines based on ECMAScript are described as providing a JavaScript environment in their particular platform. This is false and due to name recognition. JavaScript is strictly the web based implementation of ECMAScript for internet browser engines.

While ECMAScript certainly has a range of utility and implementation across a variety of platforms, this review focuses on the JavaScript implementation of ECMAScript as it applies to client side HTML5.

HTML5

The content we view on the Internet is made possible by a union of several technologies, mainly Hypertext Markup Language (HTML), Cascading Style Sheets (CSS) and JavaScript. HTML is an Extensible Markup Language (XML) protocol defining the Document Object Model (DOM). XML is a protocol defined by a clear and extensible syntax of elements and properties [17]. The DOM is an organization of the elements and properties defining the data for the page. CSS provides a powerful way to control the rendering properties of elements in the DOM, as well as selectors for efficiently styling classes and groups. JavaScript is the programming language that allows a developer to perform functions and interact with the DOM.

HTML5 is a moniker describing the most recent iteration of these internet technologies, namely it is the current version (version 5) of HTML. HTML4 defined most of the history of the Internet. HTML4 provided only limited functionality to website authors; therefore solutions like Flash and Java applets came into existence. HTML5 defines features previously only available in plug-ins, directly through native browser functionality while providing extensibility not possible with previous versions of HTML.

New web technologies emerged, such as native video support, localStorage, , WebSockets and many more, allowing developers to fully support any application, natively in the browser. Access to these features needed to be facilitated, and the programming language to control all this additional functionality is JavaScript, the native browser language. JavaScript became much more powerful due to the evolution of HTML.

At the time of writing this review, HTML5 has had many years to mature. We now see HTML5 applications across every platform imaginable, fueled by the growth of mobile devices where internet browsers are first class citizens. It is this wealth of functionality, access and ease of distribution that has lead to JavaScript becoming an essential programming language for scientists and especially for chemists. Several large, open source, JavaScript chemistry libraries are actively maintained, including the ChemDoodle Web Components [18], Kekule.js [19] and 3Dmol.js [20], to support the chemistry community.

Features

JavaScript is not developed with scientists in mind and is not, in any way, optimized for the sciences. The first high level programming language, Fortran [21] (“FORmula TRANslation”), was specifically designed to support advanced mathematical and scientific equations, and due to its performance, is still used today in many academic circles. Python [22] is a scripting language with an easy to learn syntax and core libraries dedicated to scientific computing. Yet, JavaScript exhibits a number of unique qualities greatly benefiting scientists. Development tools are available on every scientist’s computer through a web browser, free of charge. Distribution through the Internet is intrinsically supported. The free availability is essential to the core goals of science to distribute fact and information and to inspire and educate individuals to pursue knowledge. Regardless, there are a number of caveats to using JavaScript, and any scientific programmer should be aware of all of the technical features discussed below.

Performance

The speed of calculations is a top priority when considering a programming language. The faster an application is, the more calculations it can compute and the more users it can serve. JavaScript performs on the slower end of programming languages. As a scripting language being run in a web browser, JavaScript cannot be faster than the platform it runs on, typically a C [23] derivative. The interpretation of JavaScript at runtime makes it inherently slower than its platform environment, even when taking advantage of just-in-time (JIT) compilation. Simple JavaScript applications can provide a quick and efficient interface, but will suffer as the complexity of calculations increases. Chemistry algorithms are especially sensitive, where molecules are represented as graph data structures. Runtimes for graph theoretical algorithms will scale exponentially as molecule size increases.

The "Performance results" section describes some tests to compare JavaScript and Java performance for cheminformatics tasks. Runtimes are clearly slower for JavaScript, but maybe acceptable if simple data is run in an efficient browser. However, as the data structures become more complex, the runtimes for JavaScript increase significantly and at a greater rate than Java. The results also highlight another issue: JavaScript performance varies widely between browsers, and this must be considered when creating any JavaScript application, as users will have their preferred browser. Extrapolating to the most expensive computational chemistry tasks, a fully ab initio quantum mechanics calculation would take days on a super computer, and would surely be wasted as a JavaScript implementation. However, there have been some implementations of intensive chemistry algorithms in JavaScript. Ertl et al. demonstrated a fully functional database with graph isomorphism searching directly in JavaScript [24], transpiled from OpenChemLib [25] (transpiled source code is automatically generated from source code in another programming language). The JavaScript cheminformatics library, Kekule.js, includes molecular geometry optimization features transpiled from OpenBabel [26]. GLmol has an extension allowing it to create full molecular surfaces for proteins based on the EDTSurf algorithm [27]. Not one performs at commercially acceptable speeds.

Poor performance is further compounded when trying to target mobile platforms, as mobile devices typically have less powerful hardware than traditional computers. This is a serious burden on the developer, as special care is needed when crafting JavaScript applications, and the efficiency of written code must always be scrutinized. Web sites and applications that are slow to load or execute will be immediately ignored by web surfers and penalized by search engines.

It is clear that native implementations will always have a significant performance advantage over JavaScript implementations. Regardless, there are encouraging trends as technology evolves: we continue to see more powerful processors on smaller devices, mitigating performance issues. Eventually, the slow JavaScript applications of today will be the fast applications of tomorrow. And for now, JavaScript’s poor performance is far outweighed by its ubiquity on all platforms.

Distribution

When creating any application, a developer intends to reach as many users as possible. Developers therefore choose a programming language suited to the platforms presentable to the largest number of potential users. Because each Operating System (OS) is unique (Windows executables cannot be run natively on macOS, for instance), significant resources are required to port applications to each platform. If these resources are not available, the choice becomes which users to exclude. Fortunately, some programming languages were conceived to obviate that choice by providing a layer over the native platform of several operating systems, so code can be “written once and run everywhere” (coined by Sun Microsystems), thereby maximizing the developer’s effort. This was the inspiration to create the Java programming language; to allow developers to provide applications across Windows, macOS (formerly Macintosh and Mac OS X), Linux and others. Java remains a popular programming language today for producing scientific applications. Similarly, JavaScript became the programming language of the web; every significant web browser in existence, across traditional, mobile and emerging platforms, has built-in support for JavaScript. Many popular platforms, such as iOS, do not support Java, but do support JavaScript. In this way, JavaScript has surpassed Java as a universal programming language; no other programming language rivals JavaScript in its accessibility.

On mobile systems in particular, there is significant disagreement among developers about native implementations versus web based systems. Phones are technological Swiss army knives. Yet many of their features are not accessible in JavaScript (similar to how native desktop OS features are not always available in Java). To further capitalize on JavaScript work, systems like PhoneGap [28] and Cordova [29] use the native WebView components of the mobile operating systems to create native apps that can take advantage of features not available in mobile web browsers. WebView based solutions also provide a means for deployment through popular mobile app stores. Currently, a different approach for creating mobile apps using just web technologies called a Progressive Web Application (PWA) [30] is gaining popularity among developers. Such JavaScript implementations can help chemistry software developers avoid significant development costs for each platform.

Another reason JavaScript is easy to distribute is no pre-compilation is required, nor is the creation of an executable. It is important to understand, while a server is required to host and distribute web applications, as a scripting language, JavaScript source code is downloaded and interpreted at runtime. Therefore, licensing becomes very important as JavaScript source code is difficult to protect, and is very easy to view, understand, modify and copy. Owners of proprietary projects must keep this in mind. Open source projects may benefit from this as the code is readily accessible when used, but special care should be taken to understand one’s own licenses or the licenses associated with the JavaScript libraries being integrated. For instance, the commonly used General Public License (GPL) [31] will automatically become enforceable for JavaScript code as the mere act of accessing a web page running GPL licensed JavaScript code requires that code to be distributed to client machines.

Finally, due to the issues involved in distributing large JavaScript projects, several JavaScript source processors exist, including Google Closure Compiler [32], the Yahoo! User Interface (YUI) [33] library and UglifyJS [34]. These tools can minify and optimize source code by using certain patterns to shrink the size of JavaScript source downloads and optimize the code for more efficient performance (minification is a term specific to web technologies such as JavaScript, where small download sizes are optimal, and should not be confused with chemical applications of minimization, such as energy minimization or waste minimization). Such post-processing is strongly recommended when writing usable scientific programs. Some of these tools also have the ability to obfuscate JavaScript source, and when run completely, will destroy any intentionally public Application Programming Interface (API), but may help to protect proprietary code. It should be clear though, no amount of JavaScript obfuscation will be able to stop a determined hacker from reverse engineering or finding vulnerabilities in JavaScript work.

Security

Aspects of the JavaScript programming language make security an important concern. Traditional applications run on the OS. Users will verify the legitimacy of the programs they use or rely on virus scans to protect their computers. JavaScript, however, is run on webpages just by visiting them. Given the vast number of users visiting web pages continuously, JavaScript is a prime vector for hackers to distribute harmful software. To reduce risk, JavaScript is sandboxed in the web browser and does not have access to the same features essential to other programming languages. There is no access to the file system or the system clipboard for copy and paste functionality. Browser producers may impose further restrictions, including ignoring running code attempting to identify and track users or disabling JavaScript based ads in web pages. Performance intensive applications may also be throttled by browsers. For example, there are limits to the resources available to WebGL canvases, and any long running algorithms may be halted.

The client side execution of JavaScript leaves it open to another attack vector. Since JavaScript is interpreted at runtime, any capable developer can remove, modify or inject their own behavior into web applications. This introduces special concerns for products enforcing integrity of data, such as eLearning systems. If grading mechanisms for such a system are exposed in JavaScript, a student can simply modify relevant code when running that application to achieve a perfect score without doing the exercises. System vulnerability can be compounded, as individuals without programming knowledge may naïvely rely on 3rd party hacks to control the JavaScript software, exposing them to malicious behavior including the wide-scale transmission and monitoring of information about the application and its users.

If any personal or proprietary data is processed in JavaScript, the data will have to be downloaded and accessible to the user, compromising any confidentiality. Regardless of the best practices a company should uphold, new laws are now ratified to protect user information. The European Union (EU) began to enforce the General Data Protection Regulation (GDPR) in 2018 [35], requiring all companies to gain consent for the acquisition and handling of user information. Handling of data in JavaScript is also troublesome for electronic laboratory notebooks, where 21 CFR Part 11 [36] compliance is required. So JavaScript applications need to be built in a way to protect the integrity of systems and the confidentiality of information. These considerations are essential, but inherently difficult, for small scientific startup companies.

There are some common practices a developer should follow when creating JavaScript applications. Hypertext Transfer Protocol encrypted using Transport Layer Security (HTTPS) [37] utilizes a Secure Sockets Layer (SSL) technology to encrypt communications between users and a server, protecting them from hackers and data snooping. Implementation of HTTPS requires significant technical knowledge to implement, and financial resources for the SSL certificate, but without it, users are left vulnerable. Any unprotected web application will, at best, be viewed suspiciously and will ultimately be penalized by search engines. Sensitive data should only be handled in JavaScript when absolutely necessary. Any user information, for instance, proprietary molecular data, should be encrypted and sent to a properly administered server for any storage or processing.

The accessibility of JavaScript applications is worthwhile to scientists, although security issues are a significant concern. Another powerful quality of JavaScript makes up for this weakness. As a web technology, JavaScript has built-in, real-time access to server resources, protecting user information and proprietary algorithms on an administered server. Any technology can then be distributed through a JavaScript graphical user interface (GUI). As a result, JavaScript possesses a unique ability for making even the most specific, hard to use, and unsupported scientific code bases accessible to users around the world. JavaScript truly facilitates collaboration and the dissemination of knowledge.

Legacy code

As web applications grew, developers pursued creative ways to engage with users in JavaScript, the primary restriction being that content on a page was limited to what was downloaded. If content was to be changed, for example based on information in a server database, the web interface needed to communicate the changes to a server, then re-download the new content to be viewed, forcing the user to tolerate a reload of the web page. Microsoft introduced a new solution to this in 1999 with the XMLHTTP ActiveX control in Internet Explorer [38]. This new technique facilitated direct access to a server in JavaScript. As an asynchronous call, connections to the server would not block the responsiveness of the interface, and the direct communication of information back to the JavaScript call allowed the developer a powerful technique to interact with the user. All other browsers adopted this technique as the standard web technology, XMLHTTPRequest (XHR). Development patterns making use of the XHR object became known as Asynchronous JavaScript and XML (AJAX).

For security reasons, AJAX requests were limited to contacting the host origin, but HTML5 brought XHR2, which provided a new protocol to allow XMLHTTPRequest to contact and validate connections to external origins.

A system utilizing AJAX to communicate chemical information to the server can take advantage of any chemistry technology in existence. Even old legacy code can be hosted on a server and accessed with a JavaScript GUI. Proprietary code can be protected, and programs requiring advanced expertise and resources to compile and run can be deployed as a service. CPU intensive algorithms, such as energy minimization or quantum mechanics calculations, can be hosted on powerful servers, so users have an alternative to longer run times on their less powerful computer. Many chemistry databases are working to provide services through AJAX. One notable example is the Macromolecular Transmission Format (MMTF) [39] JavaScript libraries distributed by the Research Collaboratory for Structural Bioinformatics (RCSB), aimed to improve Protein Data Bank (PDB) handling in web applications.

Although XML is stated as part of the AJAX process, any protocol may be used to communicate with the server. Most applications use JavaScript Object Notation (JSON) [40], which is a protocol for defining data structures in JavaScript. JSON is a native feature in JavaScript syntax, so JSON in JavaScript source is easily written and efficiently processed. Several JSON formats were conceived specifically for chemistry. The ChemDoodle JSON format is designed as a minimalistic and extensible definition for molecules and their associated chemical and graphical objects and properties, both in 2D and 3D [41]. Both the open source ChemDoodle Web Components and OpenBabel provide support for ChemDoodle JSON. The OpenChemistry project [42] has also defined a Chemical JSON format [43]. OpenEye proposed a chemistry oriented JSON format with a focus on extensibility, but it has ceased to exist. Use of the browser JSON.stringify() and JSON.parse() functions allows the developer to convert between JavaScript and String objects, to facilitate JSON communication with a server through AJAX.

Another popular chemistry protocol for the web is Chemical Markup Langauge (CML) [44]. CML is an XML format, just like HTML, so CML can be embedded directly in the DOM, but it must be manually processed to be handled in JavaScript, unlike JSON formats. CML is a mature chemistry protocol with support in a number of toolkits, making it a prime choice for server side handling.

Another method to use legacy code bases in JavaScript is called transpilation, where source from another programming language is automatically converted into JavaScript source. The JavaScript vulnerabilities in performance and security remain. JSME [45] was transpiled from a Java applet to JavaScript with the use of the Google Web Toolkit (GWT) compiler [46]. Kekule.js developers use Emscripten [47] to port functionality from the C library, OpenBabel, to JavaScript. JSmol [48] is a transpilation of the Jmol Java applet into JavaScript making use of the SwingJS tool [49]. There are three considerations when using a transpilation tool: (1) the process will not be perfect, so the resulting code will have to be scrutinized, and likely post-edited, to ensure proper behavior; (2) the transpiled code may be injected with a middle layer introducing overhead in the application, compounding the performance issues in JavaScript possibly leading to the inconvenience of loading screens; (3) the resulting transpiled code, constructed by a machine, is difficult for the average developer to decipher. Transpiled source code defeats the purpose of open source software in JavaScript, as the original code base is necessary to make any changes, and the transpilation process must be run again to produce a JavaScript result. Proprietary code transpiled into JavaScript is inherently more prone to reverse engineering than the original source. Transpilation is best reserved for GUIs when the authors do not have the technical ability or opportunity to create a complementary JavaScript project.

Some JavaScript applications are impractical due to performance and security issues. Through servers, JavaScript developers can protect their systems and users and benefit from existing technology. This is very important for chemists, as there is a significant amount of computational innovation across many programming languages since the inception of computer systems. We want to retain access to the work of the computational chemists of the past. In the end, JavaScript applications excel at providing graphical user interfaces when paired with server side functionality.

Graphics

Several steps were necessary to bring JavaScript to its current excellence in visualization. JavaScript originally only manipulated HTML DOM elements and CSS. So the early chemistry interfaces were limited to input forms allowing some calculation to be output. Further work allowed for the presentation of periodic tables. WebElements [50] and Ptable [51] are two of the earliest examples. Rendering of molecular structures was not practical with just the HTML elements available; Adam Grossman demonstrated a simplistic molecule viewer with just HTML elements and CSS [52].

The advent of HTML5 and the introduction of the element enabled JavaScript to create graphics. With the element, a JavaScript developer can draw 2D graphics in a DOM element. When text rendering capability was added to , chemists had all the tools necessary for publication quality 2D graphics natively on the web. The ChemDoodle Web Components library [18] was the first JavaScript solution for rendering 2D chemical structures using . Several tools attempted to use to render orthographic 3D structures, including CanvasMol [53], ChemDoodle and TwirlyMol [54]. More complex PDB structures incorporating ribbon diagrams were successfully rendered by Jolecule [55] using just graphics in 2D.

Introducing 3D hardware accelerated graphics as a JavaScript ability was the next step. WebGL was introduced to provide JavaScript bindings for OpenGL, specifically OpenGL ES 2, through the element. The ChemDoodle Web Components library was again the first toolkit to provide 3D graphics of molecules using WebGL [56]. SpiderGL [57] was also documented. GLmol [58], and associated forks (a fork is a copy of the original project where new developers typically work towards a different goal), are based on the three.js WebGL library [59].

Scalable Vector Graphics (SVG) [60] is a complementary graphical feature in HTML5. SVG is an XML protocol defining 2D drawing instructions for graphics, but lacks capability for defining 3D objects. HTML5 is based on a bitmap buffer, so the scale and resolution of the screen or device must be properly taken into account for clear graphics. SVG rendering is independent of the resolution or scale of the device. Creating dynamic applications with SVG is more difficult as any changes require DOM manipulation.

The most important interface enabled by these graphical features is a chemical sketcher. Chemistry is unique because a molecular structure is the core unit to be communicated. The browser natively supports other interfaces through forms containing text fields and check boxes and calendars, but lacks a chemical sketcher. The availability of a JavaScript based chemical sketcher is therefore essential to chemists. The first example of a chemical sketcher in JavaScript was jsMolEditor [61]. Currently, advanced, open source, chemical drawing interfaces exist in pure JavaScript, including the ChemDoodle sketcher [62], Ketcher [63] and in Kekule.js.

One serious topic involving interfaces is accessibility for individuals with disabilities. Chemistry software developers should concern themselves with making their work accessible. HTML5 introduced features for controlling graphics and sound, and touch screens allow many creative input solutions through software and hardware accessories. JavaScript is present on these emerging platforms, with APIs to work with traditional mouse and keyboard events as well as touchscreen events and gestures. This is beneficial for organizations creating educational products as the Americans with Disabilities Act (ADA) requires accessibility considerations in chemistry software in the United States [64]. Many governing bodies enforce accessibility in public software as well, adhering to the Web Content Accessibility Guidelines (WCAG) specification [65], which is an International Organization for Standardization (ISO) standard. Through JavaScript, the communication of chemistry between individuals and computers has never been easier.

Chemical applications on the web greatly expanded with the capability of communicating chemistry in both 2D and 3D in JavaScript. Currently, almost every major chemistry related software product has integrated a web based interface using JavaScript. Two notable examples are SciFinder, and a new solution from the Chemical Abstracts Service (CAS), SciFinder-n [66], using JavaScript interfaces to provide further access. SciFinder presents the venerable CAS content collection, a clear validation of the importance of JavaScript interfaces in commercial chemistry products.

Further innovation

Many new JavaScript features continue to be conceived. A feature called localStorage (and its companion sessionStorage) allows JavaScript applications to store information through page loads [67]; Web Workers provides a framework for multi-threaded JavaScript applications [68]; the

Programming

JavaScript exhibits the common aspects of most programming languages. Semantics and a syntax familiar to programmers are defined to communicate with the computer. There are primitives, functions and for loops. JavaScript also harbors a number of significant differences including its scopes and context, the global namespace and the need for browser standardization. In this section, an outline of important topics for programming chemistry in JavaScript is presented. Many resources exist to introduce those interested in computer science to programming. JavaScript is a web technology, and the vast majority of instructional material for JavaScript can be found freely on the Internet. We will be focusing on the technicalities of JavaScript programming. The instruction begins with a reinforcement of JavaScript basics to prepare readers for more complex constructs, leading to the implementation of Object Oriented Programming (OOP) in JavaScript and how chemistry can be represented.

At the time of this writing, the latest version of ECMAScript is version 9, also known as ECMAScript 2018 [10]. Technologies evolve rapidly and information herein may become obsolete as changes are made.

Reinforcing the basics

JavaScript is an easy language to learn, but a very difficult one to master. Additionally, certain programming constructs can be coded using many different syntactical approaches, making the language very inconsistent. Yet, this lack of rigidity makes the language very malleable, and the possibilities are only restricted by the creativity of the developer. Developers attempting to create the complex applications necessary for chemistry without fully understanding the unique aspects of the language will encounter serious issues. Most importantly, an understanding of scope, context and closures is necessary to properly direct the behavior of JavaScript applications. These topics are covered in more detail in the following sections.

Several source code listings accompany the following topics. There are several ways to execute JavaScript code. The first is through a browser’s JavaScript console. The second is by including JavaScript directly in the DOM for a loaded web page using