Single Page Web Applications: Lessons from My Five-Year-Old

By Michael Mikowski, UI Architect at SnapLogic and product designer

DeveloperWeek has come and gone but the event marked a couple of achievements — for all of us here at SnapLogic and for me personally. First, our SnapLogic Integration Platform won the Top Innovator of the year award for Platform Tools. Second, DeveloperWeek was an opportunity for me to present on a topic that is near to my heart – writing JavaScript applications that don’t suck.  The presentation was part of the emerging Data 2.0 series of events which included four days of educational sessions, technology-specific app development contests, developer technology exhibits and keynote talks from leading engineers.

My talk, “Single Page Web Applications – Techniques for JavaScript at Scale,” was taken from my upcoming Manning book, “Single Page Web Applications – JavaScript End to End.” I’ve been writing JavaScript since its introduction, and designed and coded my first Single Page web Application (SPA) for US and European AMD shopping sites in 2007.  Since then, I have been the architect of three more commercial SPAs and a primary developer of another.  With all this experience, I’ve made virtually every mistake one could have made when creating large-scale JavaScript applications.  In fact, the book might be better titled “Bone-headed JavaScript mistakes I’ve made and how you can avoid making them too.”

Single Page Web Applications (SPAs) push most of the processing to the browser, including HTML rendering and business logic.  The user loads a web application once during a session; JavaScript then orchestrates all updates and interaction with the server. SPAs provide users with a fluid, comfortable experience whether they’re surfing at their desk or using a phone app on a sketchy 3G connection. Developing for an SPA provides unique challenges that I wanted to present.

Consider my five-year-old son: We let him wear whatever he wants to kindergarten because he doesn’t have any responsibilities. He’ll learn soon enough some days call for a suit. It’s a good analogy for how we used to allow the single “front-end” developer “guy” do whatever he wanted when the web was young.  We didn’t care too much how he got his job done because it really didn’t matter – the font-end was the icing on the cake.  All the templating, logic, and data came from the back-end.  So what if the developer used global JavaScript variables, or horrible syntax or didn’t comment on the code? Coding responsibility was minimal, so it was okay for him to do whatever he wanted because his work was virtually disposable.

Fast-forward to my son’s first job interview and I hope he’ll be thinking a lot more about his outfit. And just like my son will need to grow-up and understand that it is now important for more formal attire, SPA architects need to recognize that more formal structure and discipline is required for creating and maintaining JavaScript for their projects.  SPAs are driving us to develop JavaScript on the order of magnitude or larger than what was previously seen before – projects over a hundred thousands of lines are not uncommon. Instead of having just a single front-end developer, we now have six or eight because all those roles that used to be handled by the back-end – like templating and business logic – are now front-end jobs (and conversely, there are fewer back-end developers). Quality assurance methods that we have embraced for years on the back-end are now worth using on the front-end.

DeveloperWeek was a terrific place for me to present this topic, and I had a lot of fun doing it. Hopefully I helped other developers create large SPAs that are scalable, modular, maintainable, effective, and fast.  I also got to watch other presentations and be exposed to the cutting edge of web development techniques and technology.  I’m already looking forward to the next one!

Watch Michael’s talk: Single Page Web Applications: JavaScript End-to-End (The Hard Stuff)