Welcome to WebmasterWorld Guest from

Forum Moderators: open

Message Too Old, No Replies

The Advanced JavaScript Developer Interviews

defining the virtuoso

5:00 pm on Feb 6, 2009 (gmt 0)

Senior Member from CA 

WebmasterWorld Senior Member httpwebwitch is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Aug 29, 2003
votes: 0

Ever feel like you've reached a horizon, and need a new challenge? After some years of working with JavaScript, you'll probably have all the basics down. Loops, conditions, variables. Functions, Arrays, Objects. DOM, window, opener, event, range, blur, XHR and $()... JavaScript is complex enough to keep someone immersed for many years before they grok the entire contents of the Book With The Rhino On The Cover.

But what then? It's not over when you get to the appendix. You've still got patterns and best practices, XSS, XHR, security, calling and currying and namespacing and unobtrusiveness - topics that by themselves fill entire books. I think one of the exciting things about JavaScript is that it's evolving slowly and innovating quickly - and new topics and techniques come out of the woodwork (AJAX and JSON being good historical examples) that can potentially change everything. And it's a rich language, accessible to a beginner yet with enough texture to support a curriculum of remarkably advanced techniques.

But what are those "most advanced" topics? What do the experts find challenging, and what defines a JavaScript virtuoso?

I wrote to a few JavaScript experts, and asked them this question:

What is the most advanced JavaScript technique you
are familiar with? When you felt like you knew
JavaScript inside and out, what technique or
concept pushed that boundary?

Here is how they answered.

Michael Mahemoff,
author of "Ajax Design Patterns"

There's a lot of cool stuff going on right now, standards-based graphics and sound foremost in my mind. But I'll focus here on something I've always found oddly fascinating: fragment identifiers and the quirky exploits around them. The humble "frag ID" is not exactly the pinnacle of the Ajax revolution, but it remains misunderstood and under-utilised by developers, and a feature which the browsers could do more to support. By design, fragment identifiers do just as their name suggests - they identify fragments of a document. Type in http://example.com#foo, and the browser will helpfully scroll to the "foo" element. However, they can be used for a lot more than that, thanks to peculiarities in the way they are handled by browsers.

Most importantly, by writing Javascript to change the fragment identifier, you're able to update the page URL, without effecting a page reload. This fact alone means - contrary to a popular Ajax myth - you can support bookmarking and history in an Ajax application. Furthermore, fragment identifier information is never sent to the server, unlike the rest of the URL, which leads to some interesting applications related to security and privacy. Another powerful application is interacting between iframes from different domain [softwareas.com], something which is theoretically "impossible" in older browsers and tremendously important for embedding third-party widgets on web pages. And when I began working at Osmosoft, I discovered yet another application: providing startup context to web apps, such as TiddlyWiki [tiddlywiki.com], which run off a file:// URL...as they're unable to read conventional CGI parameter info.

I first researched this stuff for Ajax Design Patterns [ajaxpatterns.org] in 2005, and at that time, there were only a couple of scattered blog articles on the topic. Today, we can see the pattern in action in various high-profile places such as Google Docs and GMail. When I view my starred documents in the former website, for example, the URL is [docs.google.com ]. That said, many developers still aren't using this feature to its fullest, and library support is somewhat lacking. It's encouraging to see IE8 has a new event for monitoring the fragment identifier, which suggests the story is not over for this rarely discussed property.

David Walsh,
Senior Web Developer and MooTools Enthusiast

My discovery of MooTools and other javascript frameworks like jQuery, Prototype, and Dojo sent me into the thrilling world of advanced javascript. While the goals of each framework are to make writing javascript easier and more fun for the developer, I found myself desperate to find out how exactly javascript wizards like Valerio Proietti and Sam Stephenson were able to achieve the magic of their frameworks. I began by studying the MooTools source code and asking questions on the #mootools IRC room. I eventually came to understand most of what was happening and respect the beauty of the frameworks' functionality.

The most advanced javascript technique I am familiar with is one that I'll completely never achieve which taking something that's already 'perfect' and making it better by using less memory, increasing its flexibility, and extending its usefulness. This technique isn't mastered by one person but achieved through the strength of the javascript framework's community. While it's great to master the basic parts of javascript, the prospect of taking the known and improving it is the most redeeming.

Aaron Newton
Contributor: MooTools JS Framework, Author of MooTools Essentials (Apress)

I've been developing JavaScript for years now but MooTools is the framework that unlocked many of its secrets for me. I've written thousands of lines of JavaScript and I still find myself learning new tricks on a regular basis. At this point it's a rare thing indeed that I find something about JavaScript that I didn't know already (and often it's something trivial that I wasn't aware of, but would never use anyway). What's challenged me the most in recent months and years is how I think about the code I write.

MooTools does a great job of exposing some of the best parts of JavaScript so that you can write clean, reusable code. Its Class structure and "mixin" patterns allow you author highly abstract patterns and inject them into the places that you need them. Until recently, however, I thought of the classes that I authored (FormValidator, SlideShow, etc) as being in a different category to the code I wrote for a specific application. Consequently, code that I thought as being 'generic' - not about any specific site - I would author as classes with cleanly delimited methods, options, events, etc. that were clearly designed to be extended and mutated for future reuse. But if I was working on, say, a shopping cart or a sign-up form, anything that I viewed as being unique to the application I would just bang out inside a DomReady statement.

This kind of development is very expressive and very fast, but eventually it becomes unwieldy. Now I try to think of everything as classes - even things I never plan to reuse. From the smallest 4 lines of code to the really long sets of functionality that describe something totally unique to the UI of a site. The result has been remarkable. I find myself re-using things far more often, the code I author is far more legible and maintainable, the footprint between my application and the code I write is very, very small (where I once had dozens and dozens of lines in a DomReady statement, now I just had invocation statements - new Foo(options)). All these things come together to encourage me to write cleaner, more abstract, and more manageable code and the upshot is I end up with more portable, reusable stuff.

All excerpts quoted with permission from their respective authors

Add yours below.

11:41 am on Feb 9, 2009 (gmt 0)

Senior Member

WebmasterWorld Senior Member 10+ Year Member

joined:Sept 22, 2002
votes: 0

Compared to the authors above I'm just a mere mortal, so please put this in perspective...

I've been trying OO javascript for a while now, and love the clean code it creates simply by forcing me to think more structured about what I want to achieve. Still need to get to grips with event handling in objects, though.

Another new thing for me is the <canvas> object, which allows the creation of images with javascript. Absolutely fascinating. Unfortunately one major browser doesn't really support it - it is like 1997 all over again.

3:30 pm on Feb 9, 2009 (gmt 0)

Senior Member from CA 

WebmasterWorld Senior Member httpwebwitch is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Aug 29, 2003
votes: 0

For me it was "binding" and "currying". Those are concepts that did not fit easily in my head. I really had to break them down, read a lot of articles trying to explain it (evidently it's not easy to explain), and tinker with some experiments before I really understood what effect Partials and Closures have on the "this" scope of a function. You only get into currying situations when you're writing code with a fairly advanced level of complexity anyways.

Another technique that recently blew my mind was using the window.name property to store state. It's gettable and settable and totally hidden and exists for as long as the current window is open, even across domain boundaries. It's a nifty back door to cross-site data transfer, but I fear it's only a matter of time before browsers notice the leak and plug it.

7:14 pm on Feb 9, 2009 (gmt 0)

New User

10+ Year Member

joined:Aug 14, 2008
votes: 0

I have been around the block a time or two with JS. If you would like a corporate web developer's answer of this question, here it is:

I use simple JS to run things such as countdown timers, making an image visible at different times of the day, even form handling. The things that really get me thinking and reminds me why I enjoy this line of work, is when I have to use JS to work with other languages/programs. Things like using JS to grab things about the user, send it to flash and have actionscript add more to it, and send it back to the JS so it can be sent to a CGI script to get it recorded on a log file (yes, this was a task for a survey my CEO wanted). Funny thing is, this was easier achieved then it sounds.

I cannot speak for all, but the reason for the example I gave, is that JS is awesome by itself, but it makes things interesting and a lot more fun for the developers when we can use other languages and programs to really put our scripts to work.

4:37 pm on Feb 10, 2009 (gmt 0)


WebmasterWorld Administrator coopster is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:July 31, 2003
votes: 2

It's interesting that Michael Mahemoff commented on the fragment identifier, especially in light of what he noticed in Google Docs and the recent news regarding Google AJAX Powered Serps Kills Referals [webmasterworld.com].
8:30 pm on Feb 10, 2009 (gmt 0)

Preferred Member

10+ Year Member

joined:Nov 20, 2007
votes: 0

I never quite understood why flash took off, when JavaScript was quite capable of doing so much with graphics and was already running on 99% of users machines.
10:59 pm on Feb 10, 2009 (gmt 0)


WebmasterWorld Administrator phranque is a WebmasterWorld Top Contributor of All Time 10+ Year Member Top Contributors Of The Month

joined:Aug 10, 2004
votes: 174

I never quite understood why flash took off

some people don't like open source so for web content that typically means flash or java.
i think flash may provide a more accessible language to content developers and has historically been more geared toward movie making than graphics per se.

1:31 pm on Feb 11, 2009 (gmt 0)

Full Member

10+ Year Member

joined:Aug 3, 2005
votes: 0

I know this probably sounds really novice, but i only dabbled with JS and as i am a PHP developer never really learnt it to a decent level. My breakthrough came when i discovered JS Frameworks (JQuery is the one i use). They make it so much easier and cleaner to do things, AJAX mainly. Using this method changed the way that i was writing systems.

Im sure that i will have some more difficult challenges to overcome in the future - but for someone starting off with JS frameworks are massively useful.