Writing a book is not an easy job, and writing a tutorial on programming language is even harder. "The Book of JavaScript" (No Starch Press) is a well written tutorial, with clear and well explained code samples.   Below is a transcript of my dialog with Dave Thau, the author of this book.

Q. For many years JavaScript was considered as a sort of a second-tier programming language with a limited use of prettifying Web pages. The first and second editions of your book  were published six years apart.  How would you compare the now-and-then positions of JavaScript  ?

A. When the first edition of the Book of JavaScript came out, JavaScript was already a mature language.  In the six years between then and the new edition, the language has changed in three directions.  First, the language itself has added a number of new features, including new
useful methods to extant objects, regular expressions, try/catch blocks, and array generics.  These features help people write better and more powerful JavaScripts.  Second, when the first edition came out, browser support for the W3C Document Object Model specification was spotty.  The W3C DOM standard for dealing with style sheets didn't come out until after I was done with the book.  Now the ECMAScript and DOM standards are quite mature and the browsers do a good job of implementing them.  Third, the browsers have added support for XML and
asynchronous calls, which make  Ajax possible. These changes have led to the current resurgence of interest in JavaScript.

Q.As per Tiobe Programming Community Index, during the last year the use of Java, C, C++ has declined while the use of scripting languages such as Python and JavaScript has increased.  How would you explain this?

A. I think the growing popularity of scripting languages comes from their generally lower barrier to entry, and their applicability to a growing need for "smallish" coding projects.  Scripting languages don't have the compilation stage, which slows developers down, and scripting language syntax is often simpler than in languages like Java, C++ and C.  The latter three languages are great for complex projects.  They're also still the top three languages on the Index.  However, for Web programming, the power provided by these languages is generally
unnecessary.  Many of the scripting languages that are gaining in popularity are popular specifically because they are aimed at programming for the Web.  JavaScript, PHP, and Ruby on Rails are great examples of this.  As more people learn the joys of Web programming,
the popularity of these scripting languages will continue to grow.

Q. Two years ago, a catchy acronym AJAX gave JavaScript a second life. You've included three AJAX chapters in your book. Did you do it just to increase book sales or you believe that that this set of techniques has a bright future?

A. In the past, JavaScript code was always trapped in the browser.  You could do many great things with it, but the interaction between the Web browser and the Web server was very limiting.  Ajax simply put a name on a programming style that was made possible when the browsers allowed JavaScript to communicate with Web servers in more complex ways.  I think the popularity of services like Google Maps, Flickr, and Zillow comes partly from the Ajax-enabled interfaces they provide. Ajax boils down to letting a browser request information from a Web server in the background and displaying the information dynamically when the server responds.  This type of communication is very natural, and will always be an important technique in any Web programmer's toolkit.

Q. One of the major JavaScript drawbacks is that it has to deliver tons of code to the client's machine. Recently, I've seen an  application that would download  5MB of JavaScript code to the client's machine. Do you have any practical recommendations for proper design of applications that use JavaScript?

A. Five MB?  That's incredible!  Unless the application is meant to run without a working Internet connection, I can't see a reason to download that much JavaScript.  One of the most useful architectures in Web programming is the model-view-controller paradigm, which separates code meant for displaying information from code which creates and manipulates that information.  JavaScript should be used primarily for interacting with and displaying information and
interfaces.  Code for the non-visual manipulation of data should remain on the server-side.

Q. That particular application has duplicated the business logic on the client in JavaScript in desperate attempt to improve responsiveness of the system...One of the most popular questions that real-world programmers have to answer is where to put business logic, and I do not mean
just validation rules like in your book sample of Dictionary.com. Imagine an enterprise application with lots of business rules - is JavaScript the right place for it?

A. This is more of a question about the best way to split client and server code.  A clean separation of concerns, like that recommended in the model-view-controller architecture, is the only way to write applications with any hope of scaling, or surviving over time. Currently, there is no broadly used server-side version of JavaScript; it is almost entirely used on the client side.   As JavaScript has tended to be browser-bound, it is not the place to code an enterprise
application.  It is best suited to managing interfaces and information display.  This isn't a comment on JavaScript as a language.  As mentioned early, JavaScript is quite mature and could be used as a server-side language.  However, there has been very little movement in
that direction.

Q. In my opinion, using JavaScript on the server size is a stretch...In your book, you often put comments like this code will only work in IE or in FireFox. Incompatibilities of Web browsers is a known  issue. Do you think that say five years from now all major vendors of Web browser will reach an agreement that will allow you to remove these comments from the third edition of your book?

A. In the early days of JavaScript, standards did not exist, or were being created. That has changed, and I think the vendors are doing a good job of following the standards.  The places where browsers diverge are in the "extra" features they offer.  I don't think the browser vendors will ever cease adding these extras.

Q. What's in the future? ECMA-262 specification, fourth edition is in the works, which to the best of my knowledge will become JavaScript 2.0 – a serious re-write of the language.  Do you think JavaScript 2.0 will be supported by Web browsers in the near future or it's more like a concept car?

A. ECMA-262 version 4 has been in the works for years now, and I hear that it's supposed to come out some time in 2007. Some of the features have already been added into JavaScript 1.6 and 1.7, and are supported in Firefox 2.  Most of the features I know about help people write
better programs.  The major browser vendors will certainly implement whatever parts of the specification relate to the Java runtime.

Q. Is there a question that I forgot to ask but you'd like to answer?

Nope!  Thanks for taking the time to review my book. I greatly appreciate it.

It was a pleasure. Your book will be of great help for anyone who's planning to learn or  teach JavaScript.