Writing such an article as this is difficult for me to do gracefully, and I don’t always strike the right balance. If it’s hard for me to do that, how much harder is it for the people with longer bars in the graph to gracefully react? If I were the creator of one of those longer bars, I can only hope I’d receive this article openhandedly. But I understand if they don’t. Thanks for writing in.

It’s great to see the YUI grid above adopt your approach, and it’s been both very rewarding and refreshing reading your articles. Few recognize and actually make good use of the dynamic aspect of javascript like this, and it’s very commonplace to be defensive of one’s own choices when presented with someone elses. I hope I would have received your article more openhandedly, had I written either of the other comparison targets.

Thanks for writing in. I wrote:

All I’m trying to do is demonstrate the general coding methodology I used, because I often see folks using a much less optimal solution…

Even though it sounds like it, I didn’t mean to say the other JS date-formatting systems were less optimal. I was again speaking about general application of code-generation techniques. I have seen other situations where code generation would be the best solution by far, but a programmer has avoided it, or as I speculate, the idea may not have even occurred to the programmer.

I agree with you that optimality is hard to gauge. I disagree that the code complexity is increased. I think code generation can significantly decrease complexity in many cases.

If it takes a few lines of code to write something that can make decisions at runtime, that’s a lot less complexity than hard-coding all possible decisions. Once those few lines are debugged and working, every decision is correctly handled at runtime; on the other hand, if every decision is hard-coded, every single one has to be debugged separately. There are a couple dozen date-formatting characters. Each one, if hard-coded, is susceptible to typos and edge cases, etc etc.

The general pattern I’m trying to point out in this comment is how to view the code from a higher level and abstract away from it, writing a machine to solve the tedious stuff. I think doing that can vastly simplify the code. Sometimes it’s much easier to solve a general problem than dozens of specific ones.

Back to specifics, your date-formatting code is actually a tiny bit longer than mine. I stripped comments and empty lines, and took the date-parsing code out of mine, leaving only the formatting code:

wc date-functions.js formatDate.js
  209   719  6128 date-functions.js
  216   927  7439 formatDate.js

Again, that doesn’t prove anything about code complexity, just like the benchmarks above don’t prove anything about optimality, but I think it’s impossible to say code generation “significantly increases the complexity of the code” across the board.

Speed does matter sometimes. Sometimes it doesn’t, and when it doesn’t, then other factors — maintainability, small code size, ease of deployment, etc etc — are obviously to be striven for. In every coding project, getting the priorities straight is the first priority. But if you were writing a JavaScript spreadsheet, which is a hot topic these days, speed would matter hugely.

Finally, your code isn’t the slowest. The tests aren’t apples-to-apples comparisons. The dojo code is the slowest. If the dojo code implemented three dozen formatting instructions, it would be enormously slow.

I respect that this is not a diss on anyone (I could have written, and probably have, much worse crap on my own site), but I have to admit, I take objection to these other solutions as “much less optimal”. Optimality is a hard thing to gauge, and I would firmly argue that speed is usually not of the essence in JS.

Dynamic code generation is no simple thing, to be glossed over, and significantly increases the complexity of the code. And for the most part, I do like to keep my JS simple (I’ve yet to actually use any JS lib, maybe my less, but well).

But it’s nice to be reminded of the fact that code-generation is available, should you choose if suitable (with the client tier becoming more heavy, this is probably already happening all over the world).