This summer, I’ve seen all kinds of programming approaches as I’ve bounced between the Web, XSLT, Erlang, and XML, with visits to many other environments. As I look through the cool new possibilities for interfaces, for scaling up and down, and for dealing with data, I keep seeing two basic patterns repeating: walking trees (of data or document structure), and handling events.
Walking trees can be annoying, to put it mildy. The Document Object Model (DOM) is famously a headache for JavaScript (and other) developers. There are obvious opportunities for advanced developers to focus on graphs and other more flexible data structures as well. Trees are not necessarily the most efficient way to store information, especially when their content changes regularly.
However, trees have become a rather natural default, and not just for objects, for good reason. They provide as clean a representation of an HTML (or XML, or JSON) document tree as can be found. While they are more complex than flat tables, they can provide more efficient representations of nested query data than the usual simple denormalization. If something “has many”, a tree lets you show that relationship directly rather than just creating repeating many. We’ve also become very good at identifying locations within trees (letting us skip the ‘walking’), decorating trees, and establishing links among different parts of trees.
Sometimes, especially in front-end web development, those decorations and links connect to the second common pattern: event handling. While event handling has humble origins, a necessary practice for interacting with humans or with other processes and computers, skillful event handling lets you create applications that run and scale smoothly. It doesn’t matter if you’re interacting with humans (client-side JavaScript, for example), or other processes (as in Erlang or Elixir).
Languages that take event handling as a normal part of life frequently evolve extensions, libraries, and frameworks to make it easier. Part of what made Ajax so exciting for the Web was the support developers created not only to mask the variations on XmlHttpRequest, but to deal with its generally asynchronous nature. JavaScript best practices seem to become more and more asynchronous on a weekly basis, forcing developers to figure out how events should flow through functions. In a more extreme case, Erlang, Elixir, and the OTP library are an enormously powerful set of tools for defining and managing message flows. (Queue management is another end of this field.)
These two broad practices seem to me to have replaced the need for many of the more specialized tools developers have used for the last five decades. They aren’t new: both models emerged almost as quickly as computers could support their needed level of abstraction. They seem, however, to grow more dominant every day. Learn them well, figure out how your environments handle them, and you’ll be able to manage many complex tasks with a minimal set of tools. There will often be room for further refinement, but you’ll have a solid base on which to build.