Foreword

Until four years ago, every major web application that I had written used the tried-and-trusted thread-per-request execution model. A few niche applications that I had been involved with—a chat server and a push notification system—may have used some form of evented I/O, but I would have laughed at the suggestion that that model should be used for general web development. At that time in our industry’s history, the word “reactive” was virtually unheard-of.

The switch to reactive applications has been the biggest architectural change since the web itself, and it has swept across our industry at lightning speed. What I considered far-fetched four years ago, I now use every day, and I am lead developer of Play, a framework that embraces it. With the concept evolving from relative obscurity to mainstream best practice in such a short time, it’s no wonder that countless web developers are asking the question, “What is reactive?” This is where Reactive Web Applications perfectly fills a gap.