JavaScript Craftsmanship: Why JavaScript is Worthy of TDD
Upcoming SlideShare
Loading in...5
×
 

JavaScript Craftsmanship: Why JavaScript is Worthy of TDD

on

  • 2,887 views

Slides presented to the Columbus Polyglot

Slides presented to the Columbus Polyglot

Statistics

Views

Total Views
2,887
Views on SlideShare
2,887
Embed Views
0

Actions

Likes
8
Downloads
31
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • Alternate title <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • http://en.wikipedia.org/wiki/Last_mile <br />
  • http://en.wikipedia.org/wiki/Last_mile <br />
  • http://en.wikipedia.org/wiki/Last_mile <br />
  • http://en.wikipedia.org/wiki/Last_mile <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • Working software is not a commodity - users aren&#x2019;t looking for you to provide a dumb pipe. Even if you&#x2019;re finding success without emphasizing amazing user interfaces, odds are good that you&#x2019;re missing opportunity. <br /> <br /> <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • &#x201C;Static Web&#x201D; in this discussion == HTML templating engines <br /> <br /> Focus - cultivating good server-side code in organizations is hard enough; taking the client-side context seriously is perceived as a bridge too far <br /> <br /> <br /> <br />
  • &#x201C;Static Web&#x201D; in this discussion == HTML templating engines <br /> <br /> Focus - cultivating good server-side code in organizations is hard enough; taking the client-side context seriously is perceived as a bridge too far <br /> <br /> <br /> <br />
  • &#x201C;Static Web&#x201D; in this discussion == HTML templating engines <br /> <br /> Focus - cultivating good server-side code in organizations is hard enough; taking the client-side context seriously is perceived as a bridge too far <br /> <br /> <br /> <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • Sources: <br /> 1. Trolling Wikipedia <br /> 2.http://royal.pingdom.com/2007/12/07/a-history-of-the-dynamic-web/ <br /> 3.http://ejohn.org/blog/bringing-the-browser-to-the-server/ <br />
  • When you have something plainly true to say, but you lack hard data, tell it like it&#x2019;s a joke. <br />
  • When you have something plainly true to say, but you lack hard data, tell it like it&#x2019;s a joke. <br />
  • When you have something plainly true to say, but you lack hard data, tell it like it&#x2019;s a joke. <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • Everyone is motivated to learn or otherwise take a language seriously for different reasons. JavaScript lacks a lot of common itches for doing so: <br /> <br /> > On vendor-backing, it wasn&#x2019;t a great start: <br /> &#x2022; JavaScript was a trademark of Sun&#x2019;s, but was immediately perceived internally as a competitor to browser Applets <br /> &#x2022; The other half of the equation was Netscape, leading Microsoft to essentially fork the language as JScript <br /> <br /> >A lot of power in few keywords - for the geek who wants to learn a language first by all of its constructs, there isn&#x2019;t much to see in JavaScript, and there are plenty of bad things (see Crockford&#x2019;s &#x201C;the good parts&#x201D;) - http://skilldrick.co.uk/2010/09/why-javascript-is-awesome/ <br /> On purity: &#x201C;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&#x2019;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&#x2019;t necessary when functions are allowed to be free as nature intended. You&#x2019;d think that it would feel limiting not having these features, but it&#x2019;s actually liberating. It feels clean, and pure. But powerful. Like a polar bear.&#x201D; <br /> <br /> >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&#x2019;s urgency to figure out how to write good, maintainable JavaScript <br /> <br /> >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 <br /> <br /> > 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. <br /> <br />
  • <br />
  • A few ideas: <br /> <br /> Performance - farming out logic to clients can cut on CPU usage on the server side <br /> <br /> User Experience - JS is the only show in town for dynamic front-ends; once <br /> <br /> Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you&#x2019;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 <br /> <br /> Better discriminate presentation-layer - when your web application&#x2019;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. <br /> <br /> It&#x2019;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. <br />
  • A few ideas: <br /> <br /> Performance - farming out logic to clients can cut on CPU usage on the server side <br /> <br /> User Experience - JS is the only show in town for dynamic front-ends; once <br /> <br /> Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you&#x2019;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 <br /> <br /> Better discriminate presentation-layer - when your web application&#x2019;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. <br /> <br /> It&#x2019;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. <br />
  • A few ideas: <br /> <br /> Performance - farming out logic to clients can cut on CPU usage on the server side <br /> <br /> User Experience - JS is the only show in town for dynamic front-ends; once <br /> <br /> Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you&#x2019;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 <br /> <br /> Better discriminate presentation-layer - when your web application&#x2019;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. <br /> <br /> It&#x2019;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. <br />
  • A few ideas: <br /> <br /> Performance - farming out logic to clients can cut on CPU usage on the server side <br /> <br /> User Experience - JS is the only show in town for dynamic front-ends; once <br /> <br /> Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you&#x2019;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 <br /> <br /> Better discriminate presentation-layer - when your web application&#x2019;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. <br /> <br /> It&#x2019;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. <br />
  • A few ideas: <br /> <br /> Performance - farming out logic to clients can cut on CPU usage on the server side <br /> <br /> User Experience - JS is the only show in town for dynamic front-ends; once <br /> <br /> Behavior can go where it logically belongs - Once over the hump of setting up a tested, organized JavaScript environment, you&#x2019;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 <br /> <br /> Better discriminate presentation-layer - when your web application&#x2019;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. <br /> <br /> It&#x2019;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. <br />
  • <br />
  • <br />
  • I excluded some obvious practices that are completely technology agnostic. <br /> <br /> Pair Programming - I left this in here, because in the past I&#x2019;ve noticed that if there&#x2019;s any point in the code that a pair most often splits up, it&#x2019;s in wiring up &#x201C;last mile&#x201D; JavaScript while one goes to fetch some coffee <br /> <br /> 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 &#x201C;and this is how we&#x2019;re going to define objects&#x201D; conversation is critical to keeping the codebase unsurprising. <br /> <br /> TDD - In this context, TDD buys you even faster feedback and a safe harness for introducing change. <br /> <br /> CI - With JavaScript tests to run, front-end bugs can be caught early (many orgs&#x2019; 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. <br /> <br /> Make Change Cheap - Left this at the end, but it&#x2019;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. <br />
  • <br />
  • Jam Study - http://www.nytimes.com/2010/02/27/your-money/27shortcuts.html <br /> analysis paralysis - &#x201C;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.&#x201D; <br /> <br /> 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&#x2019;s WebOS. Turned out that Jasmine emerged stronger than Screw Unit (which has had a weird history and lacked community/leadership) <br /> <br /> 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. <br /> <br /> qunit - the jQuery one. <br /> <br /> ..... and many many more not enumerated here <br />
  • On #3, JsTestDriver has a simple config file that doesn&#x2019;t require this dance. <br />
  • On #3, JsTestDriver has a simple config file that doesn&#x2019;t require this dance. <br />
  • On #3, JsTestDriver has a simple config file that doesn&#x2019;t require this dance. <br />
  • On #3, JsTestDriver has a simple config file that doesn&#x2019;t require this dance. <br />
  • On #3, JsTestDriver has a simple config file that doesn&#x2019;t require this dance. <br />
  • I&#x2019;ll take a shortcut by making some decisions for us. <br /> <br /> jasmine - pivotal.github.com/jasmine <br /> jasmine-gem - http://github.com/pivotal/jasmine-gem <br /> jasmine-maven-plugin - http://github.com/searls/jasmine-maven-plugin <br /> <br /> <br /> Oh, and if you&#x2019;re using .NET, there&#x2019;s something for you too: <br /> <br /> http://github.com/jeremylightsmith/HeadlessJavascriptTestingInDotNet <br />
  • Oh, and that slide still looked too hard, so after writing it, I went and created a jasmine-archetype :) <br /> <br /> http://github.com/searls/jasmine-archetype <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • A few slides discussing the numerous ways folks have approached classical object schemes in JS <br />
  • new pollute namespace <br />
  • Module pattern: http://yuiblog.com/blog/2007/06/12/module-pattern/ <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

JavaScript Craftsmanship: Why JavaScript is Worthy of TDD JavaScript Craftsmanship: Why JavaScript is Worthy of TDD Presentation Transcript

  • 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/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
  • 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 burying wires to connect endpoints to the smart & expensive central infrastructure
  • 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
  • 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
  • Carefully crafted server Customer software
  • $('#button').click( function(){ $.get('/me-outta-here'); } ); Carefully crafted server Last Mile Customer software
  • $('#button').click( function(){ $.get('/me-outta-here'); } ); Carefully crafted server Last Mile Customer software
  • 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 functionality
  • 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
  • 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
  • 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
  • But!
  • But! Unlike cable access, software itself is not a commodity
  • Carefully crafted server Customer software
  • Carefully crafted server Carefully crafted Customer software client software
  • Carefully crafted server Carefully crafted Customer software client software
  • Carefully crafted server Carefully crafted Customer software client software
  • Carefully crafted server Carefully crafted Customer software client software
  • Carefully crafted server Carefully crafted Customer software client 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) no one
  • 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
  • Inertia
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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:
  • 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
  • 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
  • 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 says, “Write all the JavaScript you want, but we only review and reward server-side code.”
  • 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.”
  • 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
  • Missing Itches
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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 discriminated presentation tier (for, say, mobile)
  • Why Awesomize JavaScript? • Performance • User experience • Behavior can go where it logically belongs • Better discriminated presentation tier (for, say, mobile) • Portability
  • 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 might answer: “First, try doing whatever you already do to make your other code awesome.”
  • 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 - 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
  • 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. Refresh a browser to execute a test as you go
  • 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
  • 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
  • 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
  • play
  • Tool Links • Code analysis JSLint http://www.jslint.com • Code coverage JSCoverage http://siliconforks.com/jscoverage • Compression Packer http://dean.edwards.name/packer
  • 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
  • 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 you think this topic will be perceived in two years?
  • “...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!
  • //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
  • //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
  • //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
  • //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
  • //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
  • //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
  • //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
  • 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