Author: Eric Elliot

It seems like every time somebody suggests to the JavaScript world that there’s a different (often better) way to do things than the status quo, the knee-jerk response is to say that the old way is faster, and start pulling out perf scores. That’s all well and good, but by that standard, we should all be writing everything in C. The perf differences between one technique and another in JavaScript is just one of many considerations you should weigh while you’re working. Other major factors that should not be cast asside include developer productivity, code readability, application flexibility, and extensibility. Think about the trade off before you make it. Don’t get me wrong, it’s essential that we keep performance in mind while we’re developing web applications, but your app isn’t going to be noticeably impacted by your choice of switch…case vs method lookup, or your choice of inheritance patterns. Maybe you’ve read Nicholas Zakas’ “High Performance JavaScript (Build Faster Web Application Interfaces)”, or Steve Sauder’s “High Performance Websites: Essential Knowledge for Front-End Engineers” and “Even Faster Websites: Performance Best Practices for Web Developers”. You know all the perf tricks. You have a good understanding of which constructs are faster than others in JavaScript. That’s a really good start. You’re doing better than most. The bottom line is this: Know what to optimize. If you work too hard for a 1% gain, you miss 99% of your potential. Concentrate on the big time wasters, first. What Slows Down A Typical Modern Web Application? For typical applications, your bottlenecks will be I/O or render-bound, or sometimes memory (a lot more a couple years ago, but even mobile devices are starting to pack a lot more RAM these days). Here’s my web application performance hit-list, in order of priority: Too Many Network Requests Hitting the network comes with a high cost. If you’re having performance problems, look here first, beginning with your initial page load. Your application start-up sequence is unavoidably going to leave a strong first impression with your users. If you make them wait, they may not stick around long enough to see all the results of all your hard work, and even after they have used your app, created an account, and made a time investment, every time you make them wait, you run the risk of driving them to your competitors. The more separate requests you have to make, the worse it gets, because each request introduces latency. Lots of tiny requests basically turn into a latency queue. Who cares how you instantiate your objects if your page never gets to finish loading before the user hits the back button or closes your app before it’s done booting? YSlow is a great resource to help you optimize page load times. Inefficient API endpoints can force a lot of separate requests. For example, I recently created a service that delivers a few different types of loosely related data. Sometimes, you may want to fetch each different type individually. You may

  Public constructors are problematic for a number of reasons, but chief among them for me is that they couple the calling code to the constructor implementation. In other words, it forces you to break the open/closed principle. Later on, if you need to make your object instantiation polymorphic, you’ll end up invalidating all of the code that used newdirectly. You might want to create a function that acts a bit like a constructor function, only it’s capable of returning multiple types of objects which will satisfy the contract of the interface (this is a lot like the purpose of an abstract class in other OO languages). This design sensibility is true in all OO languages (several of the GoF design patterns address this very issue), but in JavaScript, it gets even worse. If you forget to use newfor a constructor, but then you go assigning things to this inside your function, this is not the object you think it is, and you can end up with all sorts of nasty bugs involving accidentally shared state and so on. I’ve seen this stump a couple of different developers just in the past month. One forgot to use new to invoke a Backbone model (with disastrous consequences), and another left new off a constructor call in Node, which caused a bizarre, hard-to-find bug that you had to look in two different files to spot. The good news is that there is absolutely no need to use constructors in JavaScript. Just export a function that returns any object you want. You can even create flyweight objects that share public methods: var myPrototype = { methodA: function methodA() {}, methodB: function methodB() {}, methodC: function methodC() {} }; createFoo = function createFoo() { return (Object.create(myPrototype)); }; This code uses Object.create() to create a new instance with the shared prototype. Constructors Make Polymorphism Harder For example, say you have video player logic with multiple concrete implementations: HTML5 and flash. Using a factory (instead of a constructor), it’s pretty easy to detect the browser capabilities and return a new object with the HTML5 prototype for browsers that support it, or the flash prototype for browsers which don’t. Adding new prototypes to a factory is trivial. Using constructors and this, you’d have to alter constructor logic to add that functionality, especially if you’ve attached all the functions one at a time directly to the constructor’s prototype property after declaring the constructor. Why New Violates Open/Closed If you start with a constructor and later want to replace a constructor with a factory (the open for extension part of the open/closed principle), every place that referenced the constructor needs to change, because fetching the new object is coupled with the constructor method of instantiation via the new keyword. Trying to use new with a factory could cripple some of it’s capabilities and return broken objects. // Create a factory object that can be used to swap out the prototype used // to instantiate new instances. var factory =