10 “Must-have” skills for Front-End Developers

I try to be a good netizen. Really I do. I know it’s not nice to trash a fellow blogger. However, a recent article by a well-meaning individual, [Update: name and link removed], is driving me crazy! I can’t just let this article go unchallenged.

The title of his article is 10 “Nice-To-Have” Skills for Front-End Developers. He starts out with this:

…since front-end coders are a dime-a-dozen these days, it pays to have experience, or, at least, rudimentary knowledge, in a number of other technologies that often don’t get listed under “mandatory” skills for a front-end position.

He then goes on to name 10 “Nice-To-Have” skills that, in my opinion, are way off base. Each of them is either a “must have” skill or a “dime-a-dozen” skill! One of the commenters hit the proverbial nail on the head:

If you don’t have these [skills], you’re not a “developer”, you’re a rank amateur.

I couldn’t agree more with the commenter. Maybe it’s because he used the term “developer”? If he wrote “UI designer”, I might not disagree. However, he uses both “front-end developer” and “front-end coder”, which to me are only a shade of gray from “front-end engineer” (the most seriously dedicated of the three).

So, anyway, if you’re a front-end engineer/developer/coder and if you’re sincerely interested in elevating your career, salary, and job satisfaction, you’ll heed my advice, not that other blogger’s. Below, I’ve listed each of his points. I’ll explain why he’s dead wrong and which must have skills you should be focusing on instead:
Continue reading

Javascript for Java Stoics, a Twitter series


Javascript for Java Stoics: Guess what. 10 years experience with Struts and JSP does not qualify you as a Web 2.0 tech lead! (true story)



Javascript for Java Stoics: Think recursion is overrated and convoluted? Try it in Javascript: it was designed for recursion!



Javascript for Java Stoics: Yes, the app must still work if users crank up the text size w/ Ctrl+/Cmd+ Bonus pts if it still looks good too!



Continue reading

A Better Javascript Un-memoizer. Part 1: Epic FAIL!

In my previous post, A Better Javascript Memoizer, some of you left some great feedback. (Thanks to all of you!) I think it’s because each of us has a different definition of “better”. That makes sense.

Actually, I just wrote that title quickly when I got inspired to start writing. Just before publication, I was going to change it to remove the word “better”. But as an experiment, I decided to keep it to see if it would elicit more feedback. Success! 🙂

Two people wanted to investigate cache invalidation, a.k.a. “unmemoization”, some more. Scratch that. Make that three people: I wanted to try it, too.

Here’s my attempt at better unmemoization in Javascript. I’m looking forward to more great feedback! (I really, really need it this time!)
Continue reading

A Better Javascript Memoizer

Last month, I had the pleasure of meeting tons of excellent and intelligent front-end engineers at JSConf 2009 — the conference for Javascript in Washington DC. If you are a front-end engineer — or even if you write programs in Javascript for back ends, mobile devices, or desktops — you absolutely have to go to JSConf 2010. It’s apparent that Javascript is quickly becoming one of the hottest languages for all environments and applications, and JSConf is the first (and only) conference that deals with Javascript exclusively.

JSConf 2009

Track A presentations from JSConf 2009

One of the Track A speakers was Stoyan Stefanov, a really smart guy from Yahoo. His presentation was about high-performance web apps, but on one slide in particular, I was struck by his implementation of memoization (slide 79 of 87) because he used the function instance to cache the results of the function itself.

If you’re not familiar with memoization, here’s a great overview:

In computing, memoization is an optimization technique used primarily to speed up computer programs by having function calls avoid repeating the calculation of results for previously-processed inputs.

Memoization (Wikipeida)

In other words, it’s a way to cache the results of function calls so that repeated expensive computations or lengthy lookups can be avoided.

Here’s Stoyan’s example:

function myFunc(param){
    if (!myFunc.cache) {
        myFunc.cache = {};
    }
    if (!myFunc.cache[param]) {
        var result = {}; // ...
        myFunc.cache[param] = result;
    }
    return myFunc.cache[param];
}

(Use your imagination to fill in some complex or lengthy task in place of the line with the “…”!)

Again, what struck me was his use of the function instance to cache the results. In Javascript, functions are first-class objects and can be assigned properties just like any other object. But should we do this? It certainly seems like this could cause intractable problems if used widely. Imagine if everybody started decorating functions and methods with properties? (Actually, debuggers such as Drosera and Firebug now use properties on function instances to help identify them in logs and traces. It seems to me we should try not to invade on that space!)

So, of course, I set out to answer the question, “Do we really need to use the function instance to hold the result cache?”

The answer is “No”. It’s really quite easy to avoid, too.
Continue reading