Anders Hejlsberg Is Right: You Cannot Maintain Large Programs In JavaScript
There’s a quote over on a Channel 9 video of Anders Hejlsberg:
Erik Meijer: Are you saying you cannot write large programs in JavaScript?
Anders Hejlsberg: No, you can write large programs in JavaScript. You just can’t maintain them.
With a follow-up post on DZone asking if you agree with this quote or not. I haven’t listened to the interview so I honestly don’t know if the quote is taken out of context or not. But honestly, I don’t think it matters if the quote is taken out of context because …
Anders Is 100% Correct
No ifs, ands or buts about it. Maintaining large JavaScript apps is nearly, if not entirely, impossible.
But Derick, You Write Large JavaScript Apps…
I write JavaScript applications that appear to be large. They may be large systems, but in reality they are very small applications (“programs” as Anders says). In spite of 5 to 10 thousand lines of JavaScript code per system, easily, my applications follow the secret to building large applications:
“The secret to building large apps is never build large apps. Break your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application” – Justin Meyer, author JavaScriptMVC
And that’s what I do. I write dozens of small “applications” – modules, really – that are then composed in to larger functional systems at runtime.
Improving Ander’s Quote
Like I said, Ander’s quote is 100% correct. I think Ander’s quote quote can be improved, though.
Did you notice that Justin Meyer’s quote didn’t mention JavaScript at all? The truth is, it doesn’t matter what language you’re writing in. This secret to writing large application is applicable to all of them. It’s why we have functions, objects, modules, classes, and other ways of grouping related sets of functionality and/or data together.
So, Ander’s quote should read:
Erik Meijer: Are you saying you cannot write large programs in [any language]?
Anders Hejlsberg: No, you can write large programs in [any language]. You just can’t maintain them.
Maintaining Large Systems
You’ll have to pardon the link-bait title of this post, and really pay attention to the semantics and language for a moment.
Anders is correct, but not because he is talking about JavaScript. He is correct because it is not possible to maintain large applications in any language / platform / runtime. Write small applications as modules, classes, assemblies, libraries, and/or any other type of modularization technique for your language and runtime environment. Then compose those small “applications” (modules, etc) in to large systems which are easier to write and maintain, in JavaScript or any other language.
How to Process Large Volumes of Data in JavaScript
In my previous posts, we examined JavaScript Execution and Browser Limits and a method which can solve “unresponsive script” alerts using Timer-Based Pseudo-Threading. Today, we’ll look at ways to handle large volumes of data within the browser.
A few years ago, developers would never have considered alternatives to complex server-side processing. That perception has changed and many Ajax applications send huge quantities of data between the client and the server. In addition, code may update the DOM which is a particularly time-consuming browser process. However, attempting to analyze that information in one go can make an application unresponsive and throw script alerts.
JavaScript timers can help prevent browser locking issues by splitting a long data analysis process into shorter chunks. Here’s the start of our JavaScript function:
function ProcessArray(data, handler, callback) The ProcessArray() function accepts three arguments:
- data: an array of items to process
- handler: a function which processes an individual data item
- callback: an optional function called when all processing is complete.
Next, we’ll define configuration variables:
var maxtime = 100; // chunk processing time var delay = 20; // delay between processes var queue = data.concat(); // clone original array maxtime specifies the maximum number of milliseconds permitted for each chunk of processing. delay is the time in milliseconds between processing chunks. Finally, queue is clone the original data array–that won’t be necessary in all cases but, since the array is passed by reference and we’re discarding each item, it’s the safest option.
We can now use a setTimeout to start processing:
setTimeout(function() < var endtime = +new Date() + maxtime; do < handler(queue.shift()); >while (queue.length > 0 && endtime > +new Date()); First, an endtime is calculated — this is a future time when processing must cease. The do…while loop processes queued items in turn and continues until every item has completed or endtime has been reached.
JavaScript supports both while loops and do…while loops. The difference is that do…while loops are guaranteed to perform at least one iteration. If we used a standard while loop, the developer could set a low or negative maxtime , and the array processing would never start or complete.
Finally, we determine whether further items need to be processed and, if necessary, call our processing function after a short delay:
if (queue.length > 0) < setTimeout(arguments.callee, delay); >else < if (callback) callback(); >>, delay); > // end of ProcessArray function The callback function is executed once every item has been processed.
We can test ProcessArray() with a small test case:
// process an individual data item function Process(dataitem) < console.log(dataitem); >// processing is complete function Done() < console.log("Done"); >// test data var data = []; for (var i = 0; i < 500; i++) data[i] = i; // process all items ProcessArray(data, Process, Done); The code will work in every browser including IE6+. It’s a viable cross-browser solution, but HTML5 provides a far nicer solution! In my next post, we’ll discuss web workers …
Share This Article
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.