16. a Word on Telecoms
• The “Last Mile” is the final leg of delivering connectivity to
a customer
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. 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. 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
26. JavaScript is Many Developers’ Last Mile
• A final chore to connect users to our carefully-tended
server-side functionality
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. 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. 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
39. How’d we get here?
• Inertia: the static server-side web arrived first
40. How’d we get here?
• Inertia: the static server-side web arrived first
• Focus: good JavaScript is paramount to (almost) no one
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
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Focus
An IT middle manager, an experienced craftsman, and a junior
developer walk into a bar...
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. 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. 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
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
79. Why Awesomize JavaScript?
• Performance
• User experience
• Behavior can go where it logically belongs
• Better discriminated presentation tier (for, say, mobile)
80. Why Awesomize JavaScript?
• Performance
• User experience
• Behavior can go where it logically belongs
• Better discriminated presentation tier (for, say, mobile)
• Portability
82. One might respond, again:
“Well, fine. I’ll try taking JavaScript
seriously. But what does that even mean?”
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. A few fan favorites
• Pair Programming
• Team coding standards
• TDD
• Continuous Integration
• Make Change Cheap
85. A few fan favorites
• Pair Programming
• Team coding standards
• TDD
• Continuous Integration
• Make Change Cheap
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
89. What actions do I take?
1. Read around and decide on a tool
2. Set up a project
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. 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. 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. 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. 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
98. Inspirational Blog Links
• “JavaScript: It’s Grown Up to be Taken Seriously”
• “Why JavaScript is AWESOME”
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.
101. “...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!
102. //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
103. //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
104. //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
105. //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
106. //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
107. //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
108. //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
109. 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
Notas del editor
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
