JavaScript Craftsmanship
     Why JavaScript is worthy of TDD
You Don’t Call Yourself a Toy Maker
       So don’t treat JavaScript like a toy language
Justin Searls




 www.pillartechnology.com
Justin Searls
 •   searls@gmail.com

 •   github.com/searls

 •   twitter.com/searls




 www.pillartechnology.com
Justin Searls
                •   searls@gmail.com

                •   github.com/searls

                •   twitter.com...
Telecom
                 Customer
Infrastructure
Telecom
                 Customer
Infrastructure
x

   Telecom
                     Customer
Infrastructure
x

   Telecom
                     Customer
Infrastructure
Telecom
                 Customer
Infrastructure
Telecom
                 Last Mile   Customer
Infrastructure
Telecom
                 Last Mile   Customer
Infrastructure
Telecom
                 Customer
Infrastructure
Telecom
                 Customer
Infrastructure
a Word on Telecoms
a Word on Telecoms
• The “Last Mile” is the final leg of delivering connectivity to
  a customer
a Word on Telecoms
• The “Last Mile” is the final leg of delivering connectivity to
  a customer

• Labor-intensive task of...
a Word on Telecoms
• The “Last Mile” is the final leg of delivering connectivity to
  a customer

• Labor-intensive task of...
a Word on Telecoms
• The “Last Mile” is the final leg of delivering connectivity to
  a customer

• Labor-intensive task of...
Carefully crafted server
                           Customer
       software
$('#button').click(
                              function(){
                                $.get('/me-outta-here');
   ...
$('#button').click(
                              function(){
                                $.get('/me-outta-here');
   ...
Carefully crafted server
                           Customer
       software
Carefully crafted server
                           Customer
       software
JavaScript is Many Developers’ Last Mile
JavaScript is Many Developers’ Last Mile

• A final chore to connect users to our carefully-tended
  server-side functional...
JavaScript is Many Developers’ Last Mile

• A final chore to connect users to our carefully-tended
  server-side functional...
JavaScript is Many Developers’ Last Mile

• A final chore to connect users to our carefully-tended
  server-side functional...
JavaScript is Many Developers’ Last Mile

• A final chore to connect users to our carefully-tended
  server-side functional...
But!
But!
Unlike cable access, software itself is not a commodity
Carefully crafted server
                           Customer
       software
Carefully crafted server   Carefully crafted
                                               Customer
       software      ...
Carefully crafted server   Carefully crafted
                                               Customer
       software      ...
Carefully crafted server   Carefully crafted
                                               Customer
       software      ...
Carefully crafted server   Carefully crafted
                                               Customer
       software      ...
Carefully crafted server   Carefully crafted
                                               Customer
       software      ...
How’d we get here?
How’d we get here?

• Inertia: the static server-side web arrived first
How’d we get here?

• Inertia: the static server-side web arrived first
• Focus: good JavaScript is paramount to (almost) n...
How’d we get here?

• Inertia: the static server-side web arrived first
• Focus: good JavaScript is paramount to (almost) n...
Inertia
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
Year        Server                     Client
1993       CGI (Perl)
1995        PHP2
                             ...
Inertia
   Year            Server                    Client
   1993           CGI (Perl)
   1995            PHP2
         ...
Inertia
    Year            Server                     Client
    1993           CGI (Perl)
    1995            PHP2
     ...
Inertia
   Year            Server                    Client
   1993           CGI (Perl)
   1995            PHP2
         ...
Focus
An IT middle manager, an experienced craftsman, and a junior
developer walk into a bar...
Focus
An IT middle manager, an experienced craftsman, and a junior
developer walk into a bar...


• The IT middle manager ...
Focus
An IT middle manager, an experienced craftsman, and a junior
developer walk into a bar...


• The IT middle manager ...
Focus
An IT middle manager, an experienced craftsman, and a junior
developer walk into a bar...


• The IT middle manager ...
Missing Itches
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
Missing Itches
         Itch                         Is Missing
                         Numerous vendors competing,
Vendo...
One might respond:
One might respond:
   “Exactly! So why should I care
 whether my JavaScript is awesome?”
Why Awesomize JavaScript?
Why Awesomize JavaScript?

• Performance
Why Awesomize JavaScript?

• Performance
• User experience
Why Awesomize JavaScript?

• Performance
• User experience
• Behavior can go where it logically belongs
Why Awesomize JavaScript?

• Performance
• User experience
• Behavior can go where it logically belongs
• Better discrimin...
Why Awesomize JavaScript?

• Performance
• User experience
• Behavior can go where it logically belongs
• Better discrimin...
One might respond, again:
One might respond, again:

    “Well, fine. I’ll try taking JavaScript
seriously. But what does that even mean?”
One might respond, again:

    “Well, fine. I’ll try taking JavaScript
seriously. But what does that even mean?”

And one m...
A few fan favorites

• Pair Programming
• Team coding standards
• TDD
• Continuous Integration
• Make Change Cheap
A few fan favorites

• Pair Programming
• Team coding standards
• TDD
• Continuous Integration
• Make Change Cheap
JavaScript Unit Testing
Too many frameworks → Analysis paralysis (see: the jam study)
     Healthy ones:

     •   Jasmine...
What actions do I take?
What actions do I take?
1. Read around and decide on a tool
What actions do I take?
1. Read around and decide on a tool

2. Set up a project
What actions do I take?
1. Read around and decide on a tool

2. Set up a project

3. Create an HTML runner file (yuck!)
What actions do I take?
1. Read around and decide on a tool

2. Set up a project

3. Create an HTML runner file (yuck!)

4....
What actions do I take?
1. Read around and decide on a tool

2. Set up a project

3. Create an HTML runner file (yuck!)

4....
What actions do I take?
1. Read around and decide on a tool
   use Jasmine

2. Set up a project

3. Create an HTML runner ...
What actions do I take?
1. Read around and decide on a tool
   use Jasmine

2. Set up a project
   use rails or jasmine-ar...
play
Tool Links
• Code analysis
  
 JSLint http://www.jslint.com

• Code coverage
  
 JSCoverage http://siliconforks.com/jscove...
Learning Links

•   Book: “JavaScript: The Good Parts,” Crockford, 2008
•   Book: “Pro JavaScript Techniques,” Resig, 2006...
Inspirational Blog Links


•   “JavaScript: It’s Grown Up to be Taken Seriously”

•   “Why JavaScript is AWESOME”
Discussion

• What cool things have you seen/done lately?
• What’s blocking you from stepping up your JS game?
• How do yo...
“...everyone who’s ever written some object-oriented JavaScript
has built their own scheme of doing this, which can be rat...
//Trivial
function Ninja(weaponOfChoice) {
   this.weaponOfChoice = weaponOfChoice;
};
Ninja.prototype.attack = function()...
//Module Pattern
function Ninja(weaponOfChoice) {
   return {
      weaponOfChoice:weaponOfChoice,
      attack: function(...
//Using instanceof to guard against user forgetting `new`
function Ninja(weaponOfChoice) {
   if(this instanceof Ninja) {
...
//An abstraction to eliminate the redundant constructor
// call within the initialization block

// makeClass - By John Re...
//Mootools Ninja
var Ninja = new Class({
  initialize: function(weaponOfChoice) {
     this.weaponOfChoice = weaponOfChoic...
//Using the prototype.js framework
var Ninja = Class.create({
  initialize: function(weaponOfChoice) {
     this.weaponOfC...
//Using Dean Edwards' Base.js
var Ninja = Base.extend({
  constructor: function(weaponOfChoice) {
     this.weaponOfChoice...
Final Bonus Slide

"JavaScript already has most of the features people
complain about not having, in ways that aren't real...
JavaScript Craftsmanship: Why JavaScript is Worthy of TDD
Upcoming SlideShare
Loading in...5
×

JavaScript Craftsmanship: Why JavaScript is Worthy of TDD

2,530

Published on

Slides presented to the Columbus Polyglot

Published in: Technology
0 Comments
8 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,530
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
34
Comments
0
Likes
8
Embeds 0
No embeds

No notes for slide

  • Alternate title









  • http://en.wikipedia.org/wiki/Last_mile
  • http://en.wikipedia.org/wiki/Last_mile
  • http://en.wikipedia.org/wiki/Last_mile
  • http://en.wikipedia.org/wiki/Last_mile








  • Working software is not a commodity - users aren’t looking for you to provide a dumb pipe. Even if you’re finding success without emphasizing amazing user interfaces, odds are good that you’re missing opportunity.







  • “Static Web” in this discussion == HTML templating engines

    Focus - cultivating good server-side code in organizations is hard enough; taking the client-side context seriously is perceived as a bridge too far



  • “Static Web” in this discussion == HTML templating engines

    Focus - cultivating good server-side code in organizations is hard enough; taking the client-side context seriously is perceived as a bridge too far



  • “Static Web” in this discussion == HTML templating engines

    Focus - cultivating good server-side code in organizations is hard enough; taking the client-side context seriously is perceived as a bridge too far



  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • Sources:
    1. Trolling Wikipedia
    2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/
    3.http://ejohn.org/blog/bringing-the-browser-to-the-server/
  • When you have something plainly true to say, but you lack hard data, tell it like it’s a joke.
  • When you have something plainly true to say, but you lack hard data, tell it like it’s a joke.
  • When you have something plainly true to say, but you lack hard data, tell it like it’s a joke.
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.

  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so:

    > On vendor-backing, it wasn’t a great start:
    • JavaScript was a trademark of Sun’s, but was immediately perceived internally as a competitor to browser Applets
    • The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript

    >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn’t much to see in JavaScript, and there are plenty of bad things (see Crockford’s “the good parts”) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/
    On purity: “There are just objects and arrays (and arrays are just specialised objects). There are literals for objects and arrays. There are functions, and loops. And that’s pretty much it. No classes, no modules, no iterators, no generators, no templates or generics, no macros. None of these things because they just aren’t necessary when functions are allowed to be free as nature intended. You’d think that it would feel limiting not having these features, but it’s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.”

    >jQuery - before jQuery there was spaghetti code nonsense that accomplished little. After jQuery, there were three lines of jQuery that got the same job done, incidentally reducing everyone’s urgency to figure out how to write good, maintainable JavaScript

    >Selenium - web testing tools scratched the CI light itch first, so the pressure to harness JS in tests was somewhat sated because the JavaScript is indirectly covered by automated (if brittle) web tests, so folks had one less reason to think hard about test-driving

    > JavaScript is so flexible (and the communities using it so diverse) that there are often too many right ways to do something, which is a barrier to adoption by folks who get excited about learning The Right Way to accomplish something via idioms & conventions.


  • A few ideas:

    Performance - farming out logic to clients can cut on CPU usage on the server side

    User Experience - JS is the only show in town for dynamic front-ends; once

    Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you’re finally in a position to make an honest decision as to whether a feature is better suited to execute on the client or the server

    Better discriminate presentation-layer - when your web application’s view logic is mostly comprised of client-side javascript, your server side is probably going to grow into a lot of useful, reusable restful services. As a result, in well discriminated systems, a mobile application could be developed and hook into the same backend with less fuss.

    It’s portable - If you decide to port your server-side backend (say, from Java to Ruby), any client-side assets that are tightly coupled with server-side framework features will become part of the burden of the port. But if the client-side JavaScript was well designed, more of it would presumably survive the backend changes gracefully.
  • A few ideas:

    Performance - farming out logic to clients can cut on CPU usage on the server side

    User Experience - JS is the only show in town for dynamic front-ends; once

    Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you’re finally in a position to make an honest decision as to whether a feature is better suited to execute on the client or the server

    Better discriminate presentation-layer - when your web application’s view logic is mostly comprised of client-side javascript, your server side is probably going to grow into a lot of useful, reusable restful services. As a result, in well discriminated systems, a mobile application could be developed and hook into the same backend with less fuss.

    It’s portable - If you decide to port your server-side backend (say, from Java to Ruby), any client-side assets that are tightly coupled with server-side framework features will become part of the burden of the port. But if the client-side JavaScript was well designed, more of it would presumably survive the backend changes gracefully.
  • A few ideas:

    Performance - farming out logic to clients can cut on CPU usage on the server side

    User Experience - JS is the only show in town for dynamic front-ends; once

    Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you’re finally in a position to make an honest decision as to whether a feature is better suited to execute on the client or the server

    Better discriminate presentation-layer - when your web application’s view logic is mostly comprised of client-side javascript, your server side is probably going to grow into a lot of useful, reusable restful services. As a result, in well discriminated systems, a mobile application could be developed and hook into the same backend with less fuss.

    It’s portable - If you decide to port your server-side backend (say, from Java to Ruby), any client-side assets that are tightly coupled with server-side framework features will become part of the burden of the port. But if the client-side JavaScript was well designed, more of it would presumably survive the backend changes gracefully.
  • A few ideas:

    Performance - farming out logic to clients can cut on CPU usage on the server side

    User Experience - JS is the only show in town for dynamic front-ends; once

    Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you’re finally in a position to make an honest decision as to whether a feature is better suited to execute on the client or the server

    Better discriminate presentation-layer - when your web application’s view logic is mostly comprised of client-side javascript, your server side is probably going to grow into a lot of useful, reusable restful services. As a result, in well discriminated systems, a mobile application could be developed and hook into the same backend with less fuss.

    It’s portable - If you decide to port your server-side backend (say, from Java to Ruby), any client-side assets that are tightly coupled with server-side framework features will become part of the burden of the port. But if the client-side JavaScript was well designed, more of it would presumably survive the backend changes gracefully.
  • A few ideas:

    Performance - farming out logic to clients can cut on CPU usage on the server side

    User Experience - JS is the only show in town for dynamic front-ends; once

    Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you’re finally in a position to make an honest decision as to whether a feature is better suited to execute on the client or the server

    Better discriminate presentation-layer - when your web application’s view logic is mostly comprised of client-side javascript, your server side is probably going to grow into a lot of useful, reusable restful services. As a result, in well discriminated systems, a mobile application could be developed and hook into the same backend with less fuss.

    It’s portable - If you decide to port your server-side backend (say, from Java to Ruby), any client-side assets that are tightly coupled with server-side framework features will become part of the burden of the port. But if the client-side JavaScript was well designed, more of it would presumably survive the backend changes gracefully.


  • I excluded some obvious practices that are completely technology agnostic.

    Pair Programming - I left this in here, because in the past I’ve noticed that if there’s any point in the code that a pair most often splits up, it’s in wiring up “last mile” JavaScript while one goes to fetch some coffee

    Team coding standards - I view this one as more critical than on the server side, simply because the language itself is so flexible and so many frameworks do the same thing. Coalescing the team around an agreed upon “and this is how we’re going to define objects” conversation is critical to keeping the codebase unsurprising.

    TDD - In this context, TDD buys you even faster feedback and a safe harness for introducing change.

    CI - With JavaScript tests to run, front-end bugs can be caught early (many orgs’ automated UI tests are so slow that tests fail hours later). We might also be able to generate some helpful reports like static code analysis and coverage.

    Make Change Cheap - Left this at the end, but it’s worth noting that refactoring uncovered code is expensive, risky, and scary. Smart people will choose to leave it as-is to dodge the risk. This is something that Web UI test tools have an opposite impact; they tend to make change more expensive.

  • Jam Study - http://www.nytimes.com/2010/02/27/your-money/27shortcuts.html
    analysis paralysis - “Sixty percent of customers were drawn to the large assortment [24], while only 40 percent stopped by the small one [6]. But 30 percent of the people who had sampled from the small assortment decided to buy jam, while only 3 percent of those confronted with the two dozen jams purchased a jar.”

    Jasmine - lightweight pure JavaScript BDD semantic, inspired by qunit, originated when the pivotal team (using screw unit) needed a test framework that worked on Palm’s WebOS. Turned out that Jasmine emerged stronger than Screw Unit (which has had a weird history and lacked community/leadership)

    JsTestDriver - a great solution if you want to set up the infrastructure to allow the JsTestDriver server to capture each browser for tests. This setup & maintenance cost seems to be a lot of effort in the 20% space, where 80% of the value is just basic TDD and CI integration, which can be had much more easily elsewhere.

    qunit - the jQuery one.

    ..... and many many more not enumerated here
  • On #3, JsTestDriver has a simple config file that doesn’t require this dance.
  • On #3, JsTestDriver has a simple config file that doesn’t require this dance.
  • On #3, JsTestDriver has a simple config file that doesn’t require this dance.
  • On #3, JsTestDriver has a simple config file that doesn’t require this dance.
  • On #3, JsTestDriver has a simple config file that doesn’t require this dance.
  • I’ll take a shortcut by making some decisions for us.

    jasmine - pivotal.github.com/jasmine
    jasmine-gem - http://github.com/pivotal/jasmine-gem
    jasmine-maven-plugin - http://github.com/searls/jasmine-maven-plugin


    Oh, and if you’re using .NET, there’s something for you too:

    http://github.com/jeremylightsmith/HeadlessJavascriptTestingInDotNet
  • Oh, and that slide still looked too hard, so after writing it, I went and created a jasmine-archetype :)

    http://github.com/searls/jasmine-archetype






  • A few slides discussing the numerous ways folks have approached classical object schemes in JS
  • new pollute namespace
  • Module pattern: http://yuiblog.com/blog/2007/06/12/module-pattern/






  • JavaScript Craftsmanship: Why JavaScript is Worthy of TDD

    1. 1. JavaScript Craftsmanship Why JavaScript is worthy of TDD
    2. 2. You Don’t Call Yourself a Toy Maker So don’t treat JavaScript like a toy language
    3. 3. Justin Searls www.pillartechnology.com
    4. 4. Justin Searls • searls@gmail.com • github.com/searls • twitter.com/searls www.pillartechnology.com
    5. 5. Justin Searls • searls@gmail.com • github.com/searls • twitter.com/searls Recent Stuff iPad app for secure AES-256 note-taking: itunes.com/app/textual jasmine-maven-plugin for JavaScript testing: github.com/searls/jasmine-maven-plugin www.pillartechnology.com
    6. 6. Telecom Customer Infrastructure
    7. 7. Telecom Customer Infrastructure
    8. 8. x Telecom Customer Infrastructure
    9. 9. x Telecom Customer Infrastructure
    10. 10. Telecom Customer Infrastructure
    11. 11. Telecom Last Mile Customer Infrastructure
    12. 12. Telecom Last Mile Customer Infrastructure
    13. 13. Telecom Customer Infrastructure
    14. 14. Telecom Customer Infrastructure
    15. 15. a Word on Telecoms
    16. 16. a Word on Telecoms • The “Last Mile” is the final leg of delivering connectivity to a customer
    17. 17. a Word on Telecoms • The “Last Mile” is the final leg of delivering connectivity to a customer • Labor-intensive task of burying wires to connect endpoints to the smart & expensive central infrastructure
    18. 18. a Word on Telecoms • The “Last Mile” is the final leg of delivering connectivity to a customer • Labor-intensive task of burying wires to connect endpoints to the smart & expensive central infrastructure • Challenges are practical, not theoretical; typified by battling physical terrain, zoning rules, and basic economics
    19. 19. a Word on Telecoms • The “Last Mile” is the final leg of delivering connectivity to a customer • Labor-intensive task of burying wires to connect endpoints to the smart & expensive central infrastructure • Challenges are practical, not theoretical; typified by battling physical terrain, zoning rules, and basic economics • Nobody goes to college for four years to serve the last mile; the “real” hard problems are centralized
    20. 20. Carefully crafted server Customer software
    21. 21. $('#button').click( function(){ $.get('/me-outta-here'); } ); Carefully crafted server Last Mile Customer software
    22. 22. $('#button').click( function(){ $.get('/me-outta-here'); } ); Carefully crafted server Last Mile Customer software
    23. 23. Carefully crafted server Customer software
    24. 24. Carefully crafted server Customer software
    25. 25. JavaScript is Many Developers’ Last Mile
    26. 26. JavaScript is Many Developers’ Last Mile • A final chore to connect users to our carefully-tended server-side functionality
    27. 27. JavaScript is Many Developers’ Last Mile • A final chore to connect users to our carefully-tended server-side functionality • Labor-intensive – any code treated as dumb wiring is bound to grow out of control over time
    28. 28. JavaScript is Many Developers’ Last Mile • A final chore to connect users to our carefully-tended server-side functionality • Labor-intensive – any code treated as dumb wiring is bound to grow out of control over time • Challenges are practical – browser compatibility quirks and debugging crowd out intentional design
    29. 29. JavaScript is Many Developers’ Last Mile • A final chore to connect users to our carefully-tended server-side functionality • Labor-intensive – any code treated as dumb wiring is bound to grow out of control over time • Challenges are practical – browser compatibility quirks and debugging crowd out intentional design • Nobody goes to college for four years to write JavaScript; “real” code runs on the server-side
    30. 30. But!
    31. 31. But! Unlike cable access, software itself is not a commodity
    32. 32. Carefully crafted server Customer software
    33. 33. Carefully crafted server Carefully crafted Customer software client software
    34. 34. Carefully crafted server Carefully crafted Customer software client software
    35. 35. Carefully crafted server Carefully crafted Customer software client software
    36. 36. Carefully crafted server Carefully crafted Customer software client software
    37. 37. Carefully crafted server Carefully crafted Customer software client software
    38. 38. How’d we get here?
    39. 39. How’d we get here? • Inertia: the static server-side web arrived first
    40. 40. How’d we get here? • Inertia: the static server-side web arrived first • Focus: good JavaScript is paramount to (almost) no one
    41. 41. How’d we get here? • Inertia: the static server-side web arrived first • Focus: good JavaScript is paramount to (almost) no one • Missing Itches: factors that normally encourage people to take a language seriously are missing from JavaScript
    42. 42. Inertia
    43. 43. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    44. 44. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    45. 45. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    46. 46. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    47. 47. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    48. 48. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    49. 49. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    50. 50. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    51. 51. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    52. 52. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js
    53. 53. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js Woah. In the same year:
    54. 54. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js Woah. In the same year: 1. Server-side reached the sophistication of Ruby on Rails
    55. 55. Inertia Year Server Client 1993 CGI (Perl) 1995 PHP2 JavaScript 1.0, 1996 ASP 1.0 Macromedia Flash 1997 Java Servlet 1.0 1998 PHP3 JavaScript 1.3 (ECMA-262) 2005 Ruby on Rails 1.0 Prototype.js 2006 jQuery, Firebug 2007 env.js 2009 Node.js Woah. In the same year: 1. Server-side reached the sophistication of Ruby on Rails 2. Cross-browser JavaScript only began to become pragmatic
    56. 56. Focus An IT middle manager, an experienced craftsman, and a junior developer walk into a bar...
    57. 57. Focus An IT middle manager, an experienced craftsman, and a junior developer walk into a bar... • The IT middle manager says, “Write all the JavaScript you want, but we only review and reward server-side code.”
    58. 58. Focus An IT middle manager, an experienced craftsman, and a junior developer walk into a bar... • The IT middle manager says, “Write all the JavaScript you want, but we only review and reward server-side code.” • The experienced craftsman says, “JavaScript is awesome! But let’s code this story server-side so we can test-drive it.”
    59. 59. Focus An IT middle manager, an experienced craftsman, and a junior developer walk into a bar... • The IT middle manager says, “Write all the JavaScript you want, but we only review and reward server-side code.” • The experienced craftsman says, “JavaScript is awesome! But let’s code this story server-side so we can test-drive it.” • The junior developer gets the message and keeps his JavaScript craft at the level of copy-pasting hover menus from hotscripts.com
    60. 60. Missing Itches
    61. 61. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    62. 62. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    63. 63. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    64. 64. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    65. 65. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    66. 66. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    67. 67. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    68. 68. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    69. 69. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    70. 70. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    71. 71. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    72. 72. Missing Itches Itch Is Missing Numerous vendors competing, Vendor hype, docs, certs but not promoting or curating Language constructs Relatively few reserved keywords Frameworks (jQuery) mask pain Spaghetti code astoundingly well UI test tools (e.g. Selenium) offer CI Continuous Integration green light, indirect code coverage Language flexibility + community a Right Way™ to do __ diversity → competing conventions
    73. 73. One might respond:
    74. 74. One might respond: “Exactly! So why should I care whether my JavaScript is awesome?”
    75. 75. Why Awesomize JavaScript?
    76. 76. Why Awesomize JavaScript? • Performance
    77. 77. Why Awesomize JavaScript? • Performance • User experience
    78. 78. Why Awesomize JavaScript? • Performance • User experience • Behavior can go where it logically belongs
    79. 79. Why Awesomize JavaScript? • Performance • User experience • Behavior can go where it logically belongs • Better discriminated presentation tier (for, say, mobile)
    80. 80. Why Awesomize JavaScript? • Performance • User experience • Behavior can go where it logically belongs • Better discriminated presentation tier (for, say, mobile) • Portability
    81. 81. One might respond, again:
    82. 82. One might respond, again: “Well, fine. I’ll try taking JavaScript seriously. But what does that even mean?”
    83. 83. One might respond, again: “Well, fine. I’ll try taking JavaScript seriously. But what does that even mean?” And one might answer: “First, try doing whatever you already do to make your other code awesome.”
    84. 84. A few fan favorites • Pair Programming • Team coding standards • TDD • Continuous Integration • Make Change Cheap
    85. 85. A few fan favorites • Pair Programming • Team coding standards • TDD • Continuous Integration • Make Change Cheap
    86. 86. JavaScript Unit Testing Too many frameworks → Analysis paralysis (see: the jam study) Healthy ones: • Jasmine - http://pivotal.github.com/jasmine • JsTestDriver - http://code.google.com/p/js-test-driver • qunit - http://github.com/jquery/qunit • jspec - http://wiki.github.com/visionmedia/jspec Seemingly stale/dead ones: • JsUnit - http://www.jsunit.net • Screw Unit - http://github.com/nathansobo/screw-unit • ~16 more - http://ejohn.org/blog/which-unit-testing-framework
    87. 87. What actions do I take?
    88. 88. What actions do I take? 1. Read around and decide on a tool
    89. 89. What actions do I take? 1. Read around and decide on a tool 2. Set up a project
    90. 90. What actions do I take? 1. Read around and decide on a tool 2. Set up a project 3. Create an HTML runner file (yuck!)
    91. 91. What actions do I take? 1. Read around and decide on a tool 2. Set up a project 3. Create an HTML runner file (yuck!) 4. Refresh a browser to execute a test as you go
    92. 92. What actions do I take? 1. Read around and decide on a tool 2. Set up a project 3. Create an HTML runner file (yuck!) 4. Refresh a browser to execute a test as you go 5. Figure out how to integrate it into your CI build
    93. 93. What actions do I take? 1. Read around and decide on a tool use Jasmine 2. Set up a project 3. Create an HTML runner file (yuck!) use jasmine-gem or jasmine-maven-plugin 4. Refresh a browser to execute a test as you go 5. Figure out how to integrate it into your CI build use jasmine-gem or jasmine-maven-plugin
    94. 94. What actions do I take? 1. Read around and decide on a tool use Jasmine 2. Set up a project use rails or jasmine-archetype 3. Create an HTML runner file (yuck!) use jasmine-gem or jasmine-maven-plugin 4. Refresh a browser to execute a test as you go 5. Figure out how to integrate it into your CI build use jasmine-gem or jasmine-maven-plugin
    95. 95. play
    96. 96. Tool Links • Code analysis JSLint http://www.jslint.com • Code coverage JSCoverage http://siliconforks.com/jscoverage • Compression Packer http://dean.edwards.name/packer
    97. 97. Learning Links • Book: “JavaScript: The Good Parts,” Crockford, 2008 • Book: “Pro JavaScript Techniques,” Resig, 2006 • Functional JavaScript koans JsTestDriver - github.com/mrdavidlaing/functional-koans Jasmine - github.com/gregmalcolm/functional-koans • SproutCore Framework (and Greenhouse) • Brendan Eich at JSConf 2010 on ECMAScript 5
    98. 98. Inspirational Blog Links • “JavaScript: It’s Grown Up to be Taken Seriously” • “Why JavaScript is AWESOME”
    99. 99. Discussion • What cool things have you seen/done lately? • What’s blocking you from stepping up your JS game? • How do you think this topic will be perceived in two years?
    100. 100. “...everyone who’s ever written some object-oriented JavaScript has built their own scheme of doing this, which can be rather confusing.” - John Resig, Pro JavaScript (2006) Let’s make a Ninja object!
    101. 101. //Trivial function Ninja(weaponOfChoice) { this.weaponOfChoice = weaponOfChoice; }; Ninja.prototype.attack = function() { return "*thwack* goes the "+this.weaponOfChoice; }; var michelangelo = new Ninja('nanchaku'); document.write(michelangelo.weaponOfChoice); //nanchaku document.write(michelangelo.attack()); //*thwack* goes the nanchaku
    102. 102. //Module Pattern function Ninja(weaponOfChoice) { return { weaponOfChoice:weaponOfChoice, attack: function() { return "*thwack* goes the"+this.weaponOfChoice; } }; }; var michelangelo = new Ninja('nanchaku'); document.write(michelangelo.weaponOfChoice); //nanchaku document.write(michelangelo.attack()); //*thwack* goes the nanchaku
    103. 103. //Using instanceof to guard against user forgetting `new` function Ninja(weaponOfChoice) { if(this instanceof Ninja) { this.weaponOfChoice = weaponOfChoice; } else { return new Ninja(weaponOfChoice) } }; Ninja.prototype.attack = function() { return "*thwack* goes the "+this.weaponOfChoice; }; var michelangelo = Ninja('nanchaku'); //forgot `new`, but that's okay! document.write(michelangelo.weaponOfChoice); //nanchaku document.write(michelangelo.attack()); //*thwack* goes the nanchaku
    104. 104. //An abstraction to eliminate the redundant constructor // call within the initialization block // makeClass - By John Resig (MIT Licensed) function makeClass(){ return function(args){ if ( this instanceof arguments.callee ) { if ( typeof this.init == "function" ) this.init.apply( this, args.callee ? args : arguments ); } else return new arguments.callee( arguments ); }; } //Now for our ninja: var Ninja = makeClass(); Ninja.prototype.init = function(weaponOfChoice) { this.weaponOfChoice = weaponOfChoice; } Ninja.prototype.attack = function() { return "*thwack* goes the "+this.weaponOfChoice; }; var michelangelo = Ninja('nanchaku'); document.write(michelangelo.weaponOfChoice); //nanchaku document.write(michelangelo.attack()); //*thwack* goes the nanchaku
    105. 105. //Mootools Ninja var Ninja = new Class({ initialize: function(weaponOfChoice) { this.weaponOfChoice = weaponOfChoice; }, attack: function() { return "*thwack* goes the "+this.weaponOfChoice; } }); var NoisyNinja = new Class({ Extends: Ninja, initialize: function(weaponOfChoice,battleCry) { this.parent(weaponOfChoice); this.battleCry = battleCry; }, attack: function() { return '"'+this.battleCry+'!" '+this.parent(); } }); var michelangelo = new NoisyNinja('nanchaku','...'); document.write(michelangelo.weaponOfChoice); //nanchaku document.write(michelangelo.attack()); //"...!" *thwack* goes the nanchaku
    106. 106. //Using the prototype.js framework var Ninja = Class.create({ initialize: function(weaponOfChoice) { this.weaponOfChoice = weaponOfChoice; }, attack: function() { return "*thwack* goes the "+this.weaponOfChoice; } }); var NoisyNinja = Class.create(Ninja, { initialize: function($super,weaponOfChoice,battleCry) { $super(weaponOfChoice); this.battleCry = battleCry; }, attack: function($super) { return '"'+this.battleCry+'!" '+$super(); } }); var michelangelo = new NoisyNinja('nanchaku','...'); document.write(michelangelo.weaponOfChoice); //nanchaku document.write(michelangelo.attack()); //"...!" *thwack* goes the nanchaku
    107. 107. //Using Dean Edwards' Base.js var Ninja = Base.extend({ constructor: function(weaponOfChoice) { this.weaponOfChoice = weaponOfChoice; }, weaponOfChoice:'', attack: function() { return "*thwack* goes the "+this.weaponOfChoice; } }); var NoisyNinja = Ninja.extend({ constructor: function(weaponOfChoice,battleCry) { this.base(weaponOfChoice); if(battleCry) { this.battleCry = battleCry; } }, battleCry:'default -- O NOES IM BEING TOO LOUD', attack: function() { return '"'+this.battleCry+'!" '+this.base(); } }); var michelangelo = new NoisyNinja('nanchaku','...'); document.write(michelangelo.weaponOfChoice); //nanchaku document.write(michelangelo.attack()); //"...!" *thwack* goes the nanchaku
    108. 108. Final Bonus Slide "JavaScript already has most of the features people complain about not having, in ways that aren't really that ugly or intrusive, despite popular belief." - Scott S. McCoy
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×