Eric Elliott

Rick Goff wrote:Hi, Eric. I haven't had a chance to see your book yet but thanks for writing it. The title suggests to me that you're treating javascript as an "ecosystem," like when we talk about "programming java applications," which assumes a stack of languages and tools. Do I have that right?

In other words, at the risk of getting a "damn, you're stupid" from a certain predatory mammal, what languages are the topic of your book?

(Ducking)
Rick

The book certainly touches on a variety of tools and libraries available to JavaScript programmers. See this post for a list of libraries covered. It does not discuss other languages in-depth. I assume the readers already know HTML and CSS, and I consider them out-of-scope for discussion in the book. I could hardly cover everything there is to know about developing applications on the web platform.

It also does not cover the many compile-to-JavaScript languages popping up. Nor does it discuss virtual machines that run in JavaScript.

That said, if you have some experience with related technologies, and some experience with JavaScript, you'll find plenty to digest in this book.

- Eric

B. Katz wrote:Greetings Eric,

Having taken a look at the description of all the info that is packed into your book, I'm pretty sure the reviewer at Amazon was having a difficult time trying to keep it inside the character limits of a Book Description. hehe

It started to make my head spin it was so much listed info, but one thing I was curious about is whether or not you cover any of the packages like ORBX.js from Mozilla or any other media-based JavaScript packages?

TIA. And, I look foward to reading the book thoroughly!


Regards,

B.Katz

Hi B.Katz,

ORBX.js was just announced and demoed days ago, so I haven't had a chance to play with it yet (way to be on the ball, by the way!). The book mentions the existence of things like HTML5 video, the audio APIs, and WebGL, but it doesn't go into detail for any of them. Instead, it concentrates on general purpose application design principles and how to apply them in JavaScript, as well as a deep dive into modern JavaScript programming techniques and design patterns.

I would be very interested in a book about audio/video programming in JavaScript, myself. If somebody doesn't write one soon, maybe I'll make that my next project. I haven't decided, yet. =)

- Eric

howard franklin wrote:
<a class="special" href="javascript:setSId('484919','N/A','int/readI.do?intid=1340387')"/>P388</a>

Keep JavaScript out of your HTML, and HTML out of your JavaScript. If you're using jQuery, you can do this:

$('.special').on('click', function() { // set cookie here... return true; });

Midhun Dandamudi wrote:Welcome Eric! I waiting for such a book ever since I started learning node. Here it is. Thank you.

If you're just starting out with Node, you might be interested in Getting Started With Node and Express, a free excerpt from "Programming JavaScript Applications" on my blog.

Steve Dyke wrote:Or leave the div container as block but change the css position attributes to bring it into view or move it off the view port as necessary?

I would not do that.

pawan chopra wrote:Hi Eric,

Welcome to JavaRanch. I have been working in Javascript for about 2 years now. Started with frameworks like Extjs , JQuery. Now I am working on application using Backbone , underscore , RequireJS etc. Learning all these was never easy as You have to approach different resources and forums etc. I saw one of your answer about Frameworks used in the book. I just wanted to ask you few questions:

-- Have you used those frameworks to build applications or the book has detail explanation of each implementation, Even if its part of the framework?
-- Is this a book about putting everything at the right place? Like when to use which framework and how?
-- Everyday you wake up you get to know a new JS framework which has solved some existing problems. Is this book goes beyond these frameworks learning and focus on Concepts?

I wish you all the best for your book. I am sure this will add great value to Programming world. Thanks for your efforts.

Hi Pawan,

The book's primary focus is on concepts. Specifically, the first half talks about modern JavaScript programming techniques and style in general, while the second half talks about most of the concerns you'll encounter in the course of building a modern JavaScript applications. It does not discuss a wide variety of libraries or frameworks, or the pros and cons of each. For that, the best resource I know of is TodoMVC. I didn't set out to try to compete with that in book form. My selections are based primarily on what most people are using for general purpose applications, as well as my confidence with the technology at hand.

You will find plenty of example code, but the book does not attempt to document the whole API of any library or framework. I trust my readers know how to use Google and refer to official API documentation. Instead, I talk about how to use the tools to build a real application, and when there are potential stumbling blocks that arise from the use of a particular library or framework, I do address those.

- Eric

Hi Eric - looking at the table of contents for the pre-release version of your book, I see you are covering (what I consider) more advanced topics such as Polymorphism and Lambda functions. In other materials I've read, there seems to be some different opinions on how these are to be implemented properly in JavaScript. Would you care to comment on your approach to these topics in this book?

Also, would you recommend the pre-release eBook is available now or wait for the final version in October?

Thanks!

I'm not aware that there's a whole lot of current controversy about lambda functions. They exist in JavaScript, and you can't really get very far without using them or encountering them. (A lambda in JavaScript is just a function expression that gets passed or exported to other functions. For example, all callbacks are lambdas. All higher-order functions use or export lambdas).

As for polymorphism, there are many different kinds of polymorphism. I am aware of controversy over object polymorphism, but I primarily focus on function polymorphism in the book -- specifically, the more common parameter type polymorphism that you'll find in things like jQuery. The main jQuery function can take a number of different types as input. For example, strings can represent CSS selectors or tag names. Pass a function, and it acts like a shortcut for $(document).ready();

Some people think that you shouldn't use that kind of polymorphism at all -- if you really want to do things like that, they should be different methods. Those people are entitled to their opinion, and I don't have a strong opinion to the contrary, but it's hard to argue with the success of jQuery.

- Eric

Michael Swierczek wrote:
At my day job I work primarily with Java, and I've been at that long enough that I'm strongly in "the grass is greener on the other side of the fence" mode. With that disclaimer out of the way, I think maybe the type system in Clojure or Perl6 might be good: you can specify the type parameters if you want, but the code usually runs fine without them (unless you've made a type-related error). It's an optional help.

I'm with you.

My oldest kid is nine, and I'm trying to make writing software interesting for him but I can't get him much past "Hello World" before his mind wanders. It's a credit to you and probably to whoever raised you that were you playing with Basic by age 5.

I got interested because of video games. I was obsessed with them, and I wanted to make my own, even at a very young age. I got a thrill out of making text adventure games. I was learning to read and write, and making games that resembled Adventure (Colossal Caves), only with a lot more animals (cats and dogs at first, because they were easy to spell).

These days, kids seem to be getting excited about games like MineCraft, or even hardware programming with Lego Mindstorms.

Games like Light Bot may engage them for a while, too (warning, annoying ads).

TeachKidsToProgram.com may have some interesting things.

They're never too young to get them started on web technologies.

One thing that I think made a difference for me -- when I was a kid, almost every computer available booted up into a programming environment (generally BASIC). I don't think modern web browsers are very far detached from that, but definitely show them how to get to the JavaScript console. Have node installed, and teach them how to start it. Maybe they'll fiddle with it when they're bored with other things.

- Eric

On the front-end, I use:

Mout (like Underscore, but with a bunch of great methods that Underscore lacks. Most of these are useful enough that they should be part of the JavaScript language).
Browserify (I strongly prefer this over AMD / Require.js, but I also use those a lot for work).
Backbone
Backbone.stickit
jQuery
cuid (for safe, client-side id generation)

I'm rooting for Derby.js to take off, and I will probably write all my personal projects using Derby until I'm confident that it's capable of handling production projects. I really like the approach. It really feels right and natural for the JavaScript language.

Take a look at TodoMVC.com to get a good idea of what each popular MVC framework is like to work with.

See this post for an overview of libraries and frameworks explored in the book.

I don't go into any detail about how to integrate with other languages such as PHP, Ruby, etc... Instead, the focus is on building Applications in JavaScript, including the advantage of building the full stack using nothing but JavaScript (with Node and Express on the back end).

Michael Swierczek wrote:
1. The book title implies the book is oriented towards building applications. But the table of contents - asynchronous operations, functional programming, interfaces, lambdas, etc... looks like more than half is just dedicated to the Javascript language itself. I don't see that as bad, I'm just asking whether the book is really half learn Javascript and half learn how to make non-trivial Javascript applications.

The first half is about modern JavaScript programming techniques. The second half is about organizing modern JavaScript applications, and walks the user through the process of building an application with Node / Express on the back end, and Backbone / jQuery on the front end.

2. Does the book walk through building one particular sample application as an example, or is it broken into a few sample applications? Or does it not work that way, and all of the sections have examples isolated from each other?

There are lots of tiny samples to explore building-block concepts, interspersed with a sample application build that brings it all together.

3. I'm just curious, given your expertise in Javascript, what you think of Typescript (Microsoft's open source superset of Javascript that includes type parameters and a class and module system), or the languages that compile into Javascript, like Dart, Coffeescript, or Clojurescript. Are you satisfied with working in raw Javascript, or do you have a favorite path forward that you believe would work best to make the language easier to use for complex applications?

The primary goal of Typescript as I see it is a little at odds with the spirit of JavaScript, which has a flexible type system. Sometimes it is useful to set the type of a thing, and always be sure that it is what you want it to be. For that, a pre-defined type does make sense. I'm not convinced that TypeScript's approach is the answer, but I'm very glad that Microsoft is experimenting, and if that experiment gains momentum, maybe we'll see some of the ideas come into the language itself.

I do have a gripe about TypeScript - Microsoft presents it as something that people should be using instead of JavaScript, rather than as an experiment that gives people access to exploratory concepts of what JavaScript could become. I'd prefer it if it was framed more to help the language evolve, rather than as a compile-to replacement for JavaScript, proper.

The premise of the language is that JavaScript is not capable of rich tooling without something like TypeScript. I think that Tern has officially proven that thesis wrong. Always bet on JS.

4. When I'm reading someone's work, it helps me to understand their approach if I know what other areas of study and programming languages they know and like to use. (e.g. Larry Wall, creator of Perl, is a linguist. Martin Odersky, who created Scala, worked on the Java compiler at Sun and helped design Java generics. etc...) So... if you like, please inform us of your background and other languages you like to use, if any.

I started with BASIC when I was five years old, and progressed through machine language (programming directly in hex), assembly language, pascal, C, C++, delphi, Java, perl, and finally JavaScript. I learned a little Lisp for computer aided drafting / scripting 3d models, and experimented with Haskel. In the course of my work, I've had to dip my toes in PHP and Ruby, but I wouldn't say that I know either of those, or that they have influenced the way that I think about programming.

5. As mobile devices get more computing resources and browsers get more resource efficient, do you think we will ever reach the point when it really does make sense to write all mobile applications except heavily computational ones (photo editing, games with cutting edge graphics) in HTML5 + Javascript instead of native applications? Or in other words, do you think the concepts Mozilla is trying to promote with Firefox OS will ever take off, even if Firefox OS itself is dead in the water?

I think eventually, even heavily computational ones will be done in thick/thin client fashion, where cloud storage, collaboration, and computing resources are available when you're online, but the apps are still functional when you're offline. I know it's sometimes hard to imagine high-powered mobile devices, but look how far they've come just in the last few years. In five more years, the smart phones we're carrying now will look like dinosaurs. Today's low-end smart phones will be the primary internet and communication access mechanism for much of the third world. The average middle-class American family will be carrying around phones every bit as capable as the laptops we are using today -- maybe more capable. Moore's law is alive and well.

With today's deeply integrated auto-update features in the browsers, a cell phone in five years will be mostly a browser device, and most of the native functionality of the phone will be exposed to JavaScript in the browser. We're already trending there, and there's no reason to think that trend is going to change. Just have a look at the different mobile browser version results on RingMark. In terms of graphics capabilities, FireFox is really doing some groundbreaking stuff, and I'm sure a lot of that work is going to spread quickly to their mobile browser and OS, so even rich, immersive HTML5 / WebGL based gaming is going to be possible on mobile devices.

The future for mobile technology in the browser is bright.

That really depends. If you build your application on Node, you don't need Tomcat, but Node is certainly not a drop-in replacement for Tomcat.

Node and Tomcat are two very different things. Tomcat is a server for Java applications with a lot of built-in features and extras that are available with no add-ons.

Node is a server-side JavaScript environment that powers JavaScript applications. It is not a server, but you can build servers in Node with a few lines of code.

Node features:

A fast JavaScript engine (built on V8).
Asynchronous by default philosophy (nothing should block).
Event-loop design (much like the browser environment).
Networking as a first class citizen (create production capable servers with few lines of code).
A highly usable streams API.
A large, rapidly growing developer community.
A simple, CommonJS-based module solution that guarantees module encapsulation (your var declarations are limited to module scope).
A developer friendly package management system with thousands of open-source packages to choose
from.

To learn more about node, see my recent blog post: Getting Started with Node and Express.

I've answered a similar question here: https://coderanch.com/t/611081/HTML-CSS-JavaScript/JavaScript

Both. The first half of the book is packed with modern JavaScript techniques and style guide. The second half of the book walks you through the process of building an application using Node / Express on the back end, and Backbone / jQuery on the front end. More importantly, it teaches you the principles of how to organize and architect JavaScript applications in general, so you can apply that knowledge no matter what libraries or tools you decide to use.

Hi Kathleen,

This is what my book is all about. As for concerns about errors, JavaScript has some really great tooling to help prevent and discover errors:

* JSLint / JSHint - discover syntax and style issues
* Unit testing - A good practice no matter what language you develop in, unit tests will help you make changes to your code with confidence, knowing that if any of your changes break major functionality, you'll know about it quickly.
* Chrome debugging tools - From stepping through the callstack to profiling memory, network, and painting operations, Chrome's debugging tools have got you covered.
* Tern - Code intelligence for JavaScript on par with the kind of intelligence you'd expect in a strictly-typed language.
* Trace.gl - visualize the entire code-flow execution of your program in realtime. Zoom in on specific methods, inspect variable values, explore the call-stack, all while your program is running live.

JavaScript tooling has really come a long way, and it's improving at an exponential rate. As the most popular programming on the planet, JavaScript has a significant advantage in this area. A lot of people have an interest in seeing the development process improve, and with all that momentum behind it, you can be sure that even better tools are right around the corner.