Preface

Since 2006, I’ve worked with the development of web applications in one form or another. I started out writing a web application for Norway’s largest retailer, which was based on JavaServer Pages (JSP) and later migrated toward JavaServer Faces (JSF). At the time, these technologies were great, and they served their intended purpose. Back then (before Ajax became widely used), the request-response cycle of HTTP demanded that most of the logic be put on the server side and that the server deliver complete markup, scripts, and style sheets to the browser on every request.

Even though these server-side approaches to writing web applications did their job, issues arose whenever state was a concern. Because the server is required to do the bookkeeping for all the logged-in users, managing state quickly becomes a difficult and memory-hungry task. How do you deal with users opening multiple tabs in your application and switching between them? How do you persist your session data when you want to scale the service across multiple (virtual) machines? How can you easily scale out horizontally in a consistent fashion if you have user-state stored on the server side?

As I started working on the open source project Montric (named EurekaJ at the time), I quickly decided that if I wanted to scale the application horizontally without requiring a separate session cache, I’d need to invest in learning one of the JavaScript frameworks that had started to gain momentum and popularity.