Performance Characteristics of Modern JavaScript Systems

Consider a modern system based on React, Redux, Meteor and MongoDB. Such a system conforms to an architectural ideal that I call Absolute MVC, in which the user interface is updated exclusively in response to state changes (i.e., UI actions or back-end changes). Meteor Live Query is state-of-the-art with respect to detecting back-end changes and pushing them to the UI via Websockets, particularly when MongoDB oplog tailing is enabled. This allows the UI to be 100% event-driven.

In my own experience, modern system performance isn’t usually constrained by the server; in fact, this is one of the advantages of a JavaScript-based SaaS application: a remarkable amount of processing can be offloaded to the client. Consider that with a traditional web application based on LAMP, all HTML rendering is done on the server and that HTML result is sent to the client on a silver platter. Moving those rendering functions to the client dramatically reduces the load on the server, and that can consequently reduce hosting costs.

What are the performance considerations of a modern JavaScript system? It all boils down to one word: rendering. State changes trigger event listeners that must judiciously re-render parts of the UI.

In React/Redux/Meteor, a recurring concern is whether a given component should be sensitive or insensitive to state changes. By default, React components will re-render unconditionally in response to state changes, so one of the low-hanging optimizations is to hand-craft rules that can analyze state changes and prevent re-rendering unless absolutely necessary. These rules are expressed in React lifecycle method shouldComponentUpdate.

In short, performance optimization of modern JavaScript system is largely a matter of minimizing rendering and re-rendering.