Web app development is trending towards running all user logic and interaction code on the client-side, leaving the server to expose REST or RPC interfaces. Compilers are targeting JS as a platform, and the next versions ECMAScript are being designed to take that into account. Client-side frameworks such as Backbone, Ember, and Require encourage the creation of feature-rich applications that not only have a lot of code, but have a lot of interactions between components, and between components and data.
This is all great and can lead to some excellent user experiences, but there's no question that it's harder to develop web applications vs web pages.
I'd like to highlight 3 relatively common mistakes with easy solutions, and talk about some specific things we've encountered and learned at ReadyForZero.
1. Stripping cache-busting headers
You may serve static content through a CDN, which is of course desirable. If you pass requests to your real server on a cache-miss (eg: "custom-origin" on AWS points to your real website), you should be careful. You probably use a cache-busting string inside the name of the served file to serve new versions when they're deployed, so that your filenames look something like this:
- Initial state, both servers are serving HTML1 and JS1.
- Server A restarts, serving HTML2 and JS2.
- Client with HTML2 requests JS2 from the CDN, which since the file is new causes a cache miss.
- CDN passes this through to your custom origin, and this happens to go to server B.
- Server B, since it hasn't restarted, strips the cache-busting string and serves the old version.
- CDN caches the old version under the new name.
2. Serving one gigantic JS bomb
One cautionary note: require.js gives up trying to load a resource after a certain amount of time, this is specified in the waitSeconds option, and the default time is 7 seconds, which depending on where your users are (eg: mobile), may be quite short.
3. Not aggregating error events
At ReadyForZero we trap onError events at the top level, and send them back to the server and get a daily report summarizing how many users got errors and what they were. We've found that many times the error messages are insufficient, so we also pass back the last few events from our event system. Having the most recent Backbone or jQuery events that were triggered is often helpful in providing the user's exact context when they triggered the error.
Low hanging fruit
The frustrating part is that we shouldn't have to worry about any of this shit. Companies should be worrying about their products, and building them out quickly and correctly. Making sure that some of these easy wins are set up will let you focus on the big stuff.
People spend a lot of time obsessing over funnels, but just getting your app working properly can lead to gains just as big.