Christophe Porteneuve

Hey Bill,

The book's approach is, well, pragmatic. Nowaways, in the browser space, there still exist enough quirks and cross-compatibility issues that any nontrivial task requires adaptation and therefore should lean on frameworks. I do mean "middle-ground" frameworks such as jQuery or Prototype, not necessarily full-fledged "SDKs" such as YUI, Dojo or Ext.

The book starts by covering the fundamental "building blocks" of any in-browser scripting, mostly around data manipulation, DOM tweaking, and event handling. All of this is presented as pure JS, pure DOM, and when applicable illustrated across all major frameworks.

Then it goes on with actual tasks (including three grades of form validation, btw) and does rely on frameworks for this. As a Prototype Core member, all other things being equal, I went with Prototype when other frameworks had no clear edge for the task at hand. The only task for which I went with jQuery is the lightbox task, as I deem FancyBox one of the best libs out there, and it's jQuery-based.

However, all tasks have a simple enough code that is easily translatable to other frameworks. In face, the source code is on Github, available for anyone to fork and adapt to other frameworks. There's a jQuery fork ready for people to tap in (I unfortunately can't find the time).

'HTH

JSMentors is pretty good, and the intent and guidelines for it are commendable. Good resource!

Hey Don,

The book is concerned with code quality insofar as it attempts to provide a best-practice approach for every task it tackles, and highlights related decisions in the explanation page.

However, as the book is task-oriented, it doesn't have a dedicated part about general principles. You'll have to look at other JS resources for that; I'm a fan of EloquentJavascript.net. A lot of people abide by Douglas Crockford's every principle, as outlined in his "JavaScript: the Good Parts" talks and book.

JSLint is certainly a good tool to use (particularly bound to Command+S in TextMate ;-)) as it promotes good habits, although some of them are not about code design or code quality per se, but more about making sure your code minifies well :-)

In general, the quality principles for JS are much the same as for other languages: clarity (e.g. meaningful identifiers, pertinent use of comments…), conciseness (which is not just brevity, but brevity without losing readability; 5 readable lines running adequately fast are better than half a line running at lightspeed but being unfathomable), modularity, etc.

Well, there's just no portable way, unfortunately. I wish there were, but you'll only find a handful of proprietary APIs sprinkled here and there. Currently the only portable solution is… Flash :-/

The main issue here would be browser support. Seeing all the work and centralization on JS happening these days, I don't see any browser-based alternative surfacing and becoming a challenger anytime soon.

Hey Venki,

Why, thanks for the kind words! :-)

Hey Miguel,

I should stress that earlier parts of the book explain this kind of feature (DOM loading detection) at length, there's an early task showing how to do that with every major framework and explaining when it's best to use this instead of full load.

The book's tasks never use stuff that is not explained earlier or in the task itself, although you couldn't see that from mere excerpts, naturally.

Hey Jorge,

Gawd, you could put JS to a TRUCKLOAD of uses. Anything that could happen in your web page, basically. The book's table of contents illustrates a lot of it : http://pragprog.com/titles/pg_js (grab the TOC's PDF). Here are a few general areas off the top of my head (not all covered in the book, because of quite a few constraints) :

Ajax / WebSockets / JSON-P communication, hence all kinds of mashups

Graphing, charting, maps… (static or animated, bitmap or vector, but rendered on the client side)

Analytics, tracking, etc.

Lightboxes

Advanced widgets (sliders, auto-completed text input, image carousels, slideshows, rating systems… you name it!)

Drag and drop (cart addition, item reordering, slider controls…)

Controlling a Flash or native widget (e.g. a video player)

Live chats (e.g. support or commercial staff chat between visitors and the site's company)

And much, so much more!

Best,

Hey Venki,

Well, first off, let me stress that the book requires at least minimal knowledge of JS: variables, types, loops, the concept of arrays, etc.

Now, most JS books focus on the language itself, or building advanced codebases out of the language, or solving rather hefty use-cases. This does fit a significant need, but my book attempts to address much more direct, and well-defined, everyday concerns.

The book is entirely task-oriented, and follows a very stringent format: one page to explain the need and the code, one page to code it all. That forces us to hunker down to a very specific problem and a best-practice solution to it. But the idea is to do over 30 cases of "need to achieve this? here's how!".

Grab the free samples on the book's page : http://pragprog.com/titles/pg_js to see for yourself what such tasks look like.

I hope you like it,

Hey Helena,

The book definitely does not require JS ninjahood. It starts by covering the few "advanced" techniques used all over skilled-enough codebases (and inside the task codes to keep them tight) so you don't need to come in with much more than your basic knowledge of variables, types, loops, and what an array is :-)

I hope you'll find it to your liking.

Best,

Have you tried styling your TD with "white-space: nowrap;" instead of playing with that old-fashioned HTML attribute? Perhaps that would work better in your situation?

Hey Mohamed,

First off, you can't nest forms in HTML. That's not valid and won't work.

If you want a single form to change its actions (its target page) depending on which submit is used, the only way you can achieve that is through JS (so if JS is not guaranteed or you need good accessibility, that's going to be an issue at some point).

Basically you need to map the markup-specified action to the one for the first submit in document order (so other ways of submitting your form, e.g. hitting Return in a non-capturing field, work properly). Then you observe click on the second submit and have it change the form's action property.

Still, this is poor UI design, or poor backend design. Perhaps your backend should look at which submit field got serialized (only the used submit field will get passed to the backend) and act accordingly?

Best,

Hey John,

Well, Node.js will require that you do know JS the language well enough. That, and event handling (a Node.js program is basically a big event loop).

Still, my book is browser-oriented, and not targeted at fundamental JS language. That specific need is better addressed by other books, or excellent online resources such as EloquentJavascript.net (which totally rocks and starts from absolute zero JS programming skill). As for Node, when you end up venturing there (it's a fascinating topic, no question about it), you'll find plenty of good resources around stuff like Node Knockout, the Weekly JS and Daily JS newsletters, and more.

'HTH

Hey Bear, thanks for having me over once again.

I should remind readers that I live in Paris, France. Therefore I'm 6 to 9 hours ahead of US times. Which is why I started replying to questions at, er… well, something like 3am on the East Coast, I guess :-)

This also means I won't reply during "my" night time, which is something like 2pm-3am New York time. Sorry, folks! I'll look into your stuff first thing in the morning :-)

Hey Shai,

Well, I'll assume your entire stuff is indeed client-side here, although you appear to use custom stuff (your XMLSerializer thingy is certainly not a standard API).

It is likely that the part of your script that is too slow is the loop building your markup.

When it comes to adding stuff to the DOM, there are really two ways: build DOM nodes and use appendChild as you go, or build the markup and put it inside innerHTML. You appear to know this.

However, the key to being speedier insertion-wise is to only add stuff to the DOM once you're done. Build your DOM fragment outside the DOM. So first, check you're not looping over something like "innerHTML +=", which would be very slow. Also make sure that you don't build an ever-larger String by concatenating to it.

The two ways (DOM-based and HTML-based) would ideally look like what follows. I'm assuming your table exists and you're only generating rows, but if you're going from table downwards, just adapt the code (a single root node for the DOM-based approach, and extra opening/closing lines for table and tbody in the HTML-based approach).

DOM-based:

var rows = []; for (…) { var row = document.createElement('TR'); // … build whatever's inside that row and row.appendChild it as you go rows.push(row); } // Done: now appendChild these. Let's say the parent tbody element is referenced by a "container" variable: for (var index = 0, len = rows.length; index < len; ++index) container.appendChild(rows[index]);

HTML-based:

var markup = []; for (…) { markup.push('<tr>'); // … add all the lines of markup inside that row, using markup.push for each markup.push('</tr>'); } // Done: now inject the markup. Let's say the parent tbody element is referenced by a "container" variable: container.innerHTML += markup.join("\n");

This way you only grapple with the rendered DOM once, which is important.

Now, if the loop itself is too slow, then you're in another kind of trouble. Making sure you don't use an ever-expanding String should help (which is why we use an Array of HTML lines here, and end up join'ing it). If it's still too slow, try profiling your code with whatever tools you have (Safari's Web Inspector, Firebug's Profile tool on Firefox…) to pinpoint the culprit part of your code.

'HTH