Signals Blog

Ten Reasons Chemical Structure Images Should Be Rendered on the Browser, Not the Server

Chemical structure images are an essential part of many chemistry Web applications. The most widely-used approach employs the server as an imager, but this method leads to unpleasant, persistent problems: increased application complexity; decreased development agility; and technology integration issues to name a few.

Rendering Structures with ChemWriter

At Metamolecular, we believe that the Web browser, if properly equipped, can be a powerful tool for building cleaner, leaner, and less expensive scientific software. To demonstrate the point, take a closer look at the structure table above. Where were these images generated? In your browser!

The most recent update to our pure JavaScript cheminformatics package, ChemWriter, comes complete with the ability to not just edit but render chemical structures as well.

Getting started is as easy as applying markup that includes this fragment:

<div id="painter"></div>
  chemwriter.loadPainter('painter', {

You'll also need some minimal CSS to size and style the images:

.chemwriter .painter {
  width: 158px;
  height: 100px;

In this case, the structure encoded by your-molfile will be rendered into the supplied div element. All of the usual CSS rules about layout and appearance of this element apply.

Current Best Practice: Static Raster Images

Various workarounds to the problem of displaying chemical structures in Web browsers have been invented over the years. The vast majority can be placed into one of three categories:

  1. Generate images locally and upload them to a server.
  2. Generate images on the server as new structures are created.
  3. Generate images on the server dynamically when requested.

Although option (1) can work for small applications, this system can become impractical with even as few as 100 structures.

Option (2) eliminates the need to upload images to the server. This can work for much larger sites, but at the cost of increased overhead whenever a structure record is created, updated, or destroyed. Worse, for sites numbering in the 100K to one million record size, any change in page layout requiring new image sizes will lead to a rather large amount of effort to ensure it gets done right, that caches get cleared, and that nothing gets lost in the process. The size of this effort means that few will attempt it. Page designs could become calcified despite clear need to evolve the user interface. Finally, for databases numbering in the millions of structures, simply storing and managing these images could represent a major problem.

Option (3) offers the most flexibility. But like Option (2), it suffers from the need to integrate imaging software with the rest of the server stack (which may be non-trivial) and write/test/maintain the code that will render images correctly. A further disadvantage is performance, which can suffer due to highly concentrated bursts of imaging requests followed by the need to handle them and return responses. Various caching strategies can be employed, but at the cost of increasing the complexity of the server codebase.

In isolated cases, plugin-based components (particularly Java applets) have been used to render structure images. However, the result is often far less than optimal. Problems ranging from flicker during scrolling (especially on OSX systems), to browser crashes, to z-index incompatibility and other forms of inconsistent DOM integration are not uncommon. In addition, the usual issues with lack of support on mobile devices and other systems incapable of running the plugin apply.

Clearly, enlisting the browser itself to generate structure images from a lightweight representation offers advantages. This approach has now moved from merely possible to practical.

Ten Reasons ChemWriter Structure Display is Better Than Static Raster Images

  1. There's nothing to install or maintain on your server.
  2. There's no need for image file storage or maintenance.
  3. Test your page designs locally, without any image server running.
  4. Easily experiment with a variety of page layouts and image sizes.
  5. Reduce network requests (one single request for the page, versus potentially dozens of image requests).
  6. Reduce network bandwidth (less than 1K/structure versus 5K or more for raster images).
  7. When your connection tables change, your images change automatically.
  8. Easily produce expanded views of large or complex structures (e.g., marine natural products).
  9. Users don't wait for a client-server round-trip when updating structures in-place or requesting a larger view (more later).
  10. If you already own a ChemWriter license, there's nothing else to buy.

How It Works

The approach outlined here will work on all browsers, from Internet Explorer 6 (widely used in pharma) to iPad. To accomplish this, we've relied on the built-in capability of all browsers to render vector graphics. Internet Explorer versions 6, 7, and 8 use a system called Vector Markup Language (VML), first introduced in 1998. All other browsers, including IE9, render structures with Scalable Vector Graphics (SVG), a W3C standard and part of the new HTML5 specification.

Behind the scenes, ChemWriter ensures the correct vector graphics system is used with a given browser.


Chemical structure images are extremely important in a number of chemistry Web applications. Traditional approaches to generating them using raster images come with significant downsides. ChemWriter now has the potential to solve this problem, without plugins and without server-side software.

Future articles will offer ideas on how to take advantage of this new capability.