Fancy working with a small team remotely? SupportBee is hiring developers!
Take a look at our jobs page
When I started dabbling with programming (around the year 2000), Bruce Eckel was one of my favorite technical authors. Thinking in C++ was one of the first great programming books that I read back in the days. Apart from the fact that you could read his books online for free, Bruce always taught you to think in a language. His books were in stark contrast to other reference books like C++ The Complete Reference that covered almost everything about the language but did not show you how to think in a particular language.
I had a similar experience when I started working with Backbone.js a couple of years back. Having been a Ruby on Rails programmer for many years, I could easily understand what Backbone.js offered - Models, Views and Collections. However, I struggled with the Single Page mindset. I had many questions - How do I structure my code? How do I test drive my code? What patterns should I follow for building a desktop like app? This book should help you think about and answer some of these questions and get you into the Single Page Mindset.
However, before we talk more about the Single Page Mindset, let's quickly talk about traditional JS enhanced apps.
You can interact with an API in a similar way. Only in the case of an API, the succcess method needs to parse the response and then do whatever is needed. If there are multiple sections of the page that need an update, you have to keep track of them and update them. If you have a page listing several products and you want to fetch and update the price for every product, the success handler will now look something like
Finally, there is a class of single page apps that involve fairly significant screen updates as you work with them. Different screens have distinct (bookmark-able) URLs just like a traditional JS enhanced apps. A good example is Gmail. Your inbox, a single email, settings and contacts are different bookmarkable screens. You can go back and forth between these screens in Gmail without reloading the page in the browser. Our own application, SupportBee is a multi-screen single page app too.
Let's look at the second example where we update multiple product divs based on the JSON response that we get. There are several problems with code
product_id. To be able to do so, you have to render the divs with
As we go over the rest of the book you will be exposed to the Backbone.js way of handling these issues. To keep things sane, Backbone uses a MVC (Model, View, Collection) pattern and keeps data and logic and presentation separated. Also, extensive use of event binding ensures that you don't have to manually remember to update HTML whenever you change the data. Without getting ahead of ourselves and without diving into any Backbone.js specific code, let's see how we would conceptually handle this situation in Backbone
pricechanges (independent of where/how it's changed), the new price is reflected in the view.
Single Page Apps are certainly harder to build (atleast when you are just starting out with a new project). There are several unique challenges faced by them. The biggest one is that you are now giving up on many features that browsers provide to typical web applications. The biggest one being a clean state that is offered on every page reload. For example, if you were building Gmail and a user could drop a label on an email when viewing the email, you would have to make sure that on going back to the inbox, the label immediately shows up. In a conventional web-app, going back to the inbox would reload the page and fetch the new inbox page from the server. This would guarantee that the new email listing has the ticket with the right label.
Another browser feature that users heavily depend on is the back button. Many single page applications break this expectation. Special care must be taken (that is code must be written!) to make sure that the back button works as expected in these applications. Finally, many users are used to copying the URLs for specific screens or bookmarking them for easy access later. If special care is not taken, screens in a single page application might not have a unique URL.
I have blogged about the pros and cons of building a single page app in the past. The post is still relevant today.
What else would you like to see? What do you think is missing or not needed?comments powered by