Building Isomorphic JavaScript Apps

Chapter 16. Final Thoughts

Charlie Robbins

I do not know what I may appear to the world, but to myself I seem to have been only like a boy playing on the sea-shore, and diverting myself in now and then finding a smoother pebble or a prettier shell than ordinary, whilst the great ocean of truth lay all undiscovered before me.

Isaac Newton

In October 2009, I had never written JavaScript professionally. In fact, I had barely spent more than a few hours playing with the language. At the time I was writing frontend trading systems and other bank software in WPF (Windows Presentation Foundation), a technology I had been involved with at Microsoft. If you had told me that “isomorphic JavaScript” would become this widespread a concept before my original writing on the topic, I surely would have laughed. I want to highlight these facts to remind you that you really don’t know what is possible until you try.

Families of Design Patterns, Flux, and Isomorphic JavaScript

Isomorphic JavaScript was not the main topic of my original blog post on the subject, “Scaling Isomorphic Javascript Code.” The term was just a footnote to contextualize and justify what I thought was a much more impactful software design pattern at the time. The way that developers have adopted the term and abstract concept far more than any concrete software design pattern is fascinating.

Software design patterns evolve in a somewhat similar way to religions: there are multiple interpretations of the core ideas for each ...