1. DSLs in JavaScript
Nathaniel T. Schutta

2. Who am I?
• Nathaniel T. Schutta
http://www.ntschutta.com/jat/
• Foundations of Ajax & Pro Ajax and Java
Frameworks
• UI guy
• Author, speaker, teacher
• More than a couple of web apps

3. The Plan
• DSLs?
• JavaScript? Seriously?
• Examples
• Lessons Learned

4. DS what now?

5. Domain Specific Language.

6. Every domain has its
own language.

7. “Part of the benefit of being
"into" something is having an
insider lexicon.”
Kathy Sierra
Creating Passionate Users
http://headrush.typepad.com/creating_passionate_users/2006/11/why_web_20_is_m.html

8. Three quarter, knock
down, soft cut.

9. Scattered, smothered,
covered.

10. Large skim mocha, no
whip no froth.

11. Not general purpose.

12. Simpler, more limited.

13. Expressive.

14. Terse.

15. $$('.header').each(function(el) {el.observe("click", toggleSection)});

16. Not a new idea.

17. Unix.

18. Little languages.

19. Lisp.

20. Build the language up...

21. Lots of attention today.

22. Rails!

23. Ruby is very hospitable.

24. So are other languages ;)

25. Internal vs. External.

26. Internal.

27. Within an existing language.

28. More approachable.

29. Simpler.

30. No grammars, parsing, etc.

31. Constrained by host
language.

32. Flexible syntax helps!

33. Ruby ;)

34. Fluent interface.

35. Embedded DSLs.

36. External.

37. Create your own language.

38. Grammars.

39. Need to parse.

40. ANTLR, yacc, JavaCC.

41. Harder.

42. More flexibility.

43. Language workbenches.

44. Tools for creating
new languages.

45. Internal are more
common today.

46. Language workbenches -
shift afoot?

47. http://martinfowler.com/articles/mpsAgree.html
http://martinfowler.com/articles/languageWorkbench.html

48. Meta Programming System.
http://www.jetbrains.com/mps/

49. Intentional Programming
- Charles Simonyi.
http://intentsoft.com/
http://www.technologyreview.com/Infotech/18047/?a=f

50. Oslo.
http://msdn.microsoft.com/en-us/oslo/default.aspx

51. Xtext.
http://wiki.eclipse.org/Xtext

52. Why are we seeing DSLs?

53. Easier to read.

54. Closer to the business.

55. Less friction, fewer
translations.

56. Biz can review...

57. “Yesterday, I did a code
review. With a CEO...
Together, we found three
improvements, and a couple of
outright bugs.”
Bruce Tate
Canaries in the Coal Mine
http://blog.rapidred.com/articles/2006/08/30/canaries-in-the-coal-mine

58. Don’t expect them to
write it though!

59. Will we all write DSLs?

60. No.

61. Doesn’t mean we
can’t use them.

62. General advice on
building a DSL:

63. Write it as you’d
like it to be...

64. Even on a napkin!

65. Use valid syntax.

66. Iterate, iterate, iterate.

67. Work on the
implementation.

68. http://martinfowler.com/dslwip/
http://weblog.jamisbuck.org/2006/4/20/
writing-domain-specific-languages
http://memeagora.blogspot.com/2007/11/
ruby-matters-frameworks-dsls-and.html
http://martinfowler.com/bliki/DslQandA.html

69. Not a toy!

70. JavaScript has been
around for a while.

71. Many dismissed it as
“toy for designers.”

72. It’s not the 90s anymore.

73. We have tools!

74. Developers care again!

75. Ajax.

76. Suffers from the “EJB issue.”

77. Powerful language.

78. “The Next Big Language”
http://steve-yegge.blogspot.com/
2007/02/next-big-language.html

79. Runs on lots of platforms
- including the JVM.

80. Ruby like?

81. “Rhino on Rails”
http://steve-yegge.blogspot.com/
2007/06/rhino-on-rails.html

82. Orto - JVM written
in JavaScript.
http://ejohn.org/blog/running-java-in-javascript/

83. JS-909.
http://www.themaninblue.com/experiment/JS-909/

85. JSSpec.

86. JavaScript testing DSL.

87. JSSpec? Really?

88. /**
* Domain Specific Languages
*/
JSSpec.DSL = {};

89. BDD for JS.

90. Like RSpec.

91. Not quite as elegant.

92. describe('Plus operation', {
'should concatenate two strings': function() {
value_of("Hello " + "World").should_be("Hello World");
},
'should add two numbers': function() {
value_of(2 + 2).should_be(4);
}
})

93. value_of?

94. "Hello".should_be("Hello");

95. Sorry.

96. No method missing.

97. We’d need to modify
Object’s prototype.

98. Generally a no-no.

99. Though it’s been done.
http://json.org/json.js

100. Null, undefined objects.

101. Design choice - consistency.

102. describe('Plus operation', {
'should concatenate two strings': function() {
value_of("Hello " + "World").should_be("Hello World");
},
'should add two numbers': function() {
value_of(2 + 2).should_be(4);
}
})

103. describe - global
defined in JSSpec.js.

104. Creates a new
JSSpec.Spec()...

105. And adds it to an
array of specs.

106. value_of - global
defined in JSSpec.js.

107. value_of - converts parm
to JSSpec.DSL.Subject

108. Handles arbitrary objects.

109. JSSpec.DSL.Subject
contains should_*.

110. Added to prototype.

111. JSSpec.DSL.Subject.prototype.should_be = function(expected) {
var matcher =
JSSpec.EqualityMatcher.createInstance(expected,this.target);
if(!matcher.matches()) {
JSSpec._assertionFailure = {message:matcher.explain()};
throw JSSpec._assertionFailure;
}
}

112. this.target?

113. JSSpec.DSL.Subject = function(target) {
this.target = target;
};

114. this in JS is...interesting.

115. Why is everything
JSSpec.Foo?

116. JS lacks packages
or namespaces.

117. Keeps it clean.

118. Doesn’t collide...unless
you have JSSpec too!

119. Not just a DSL of course.

120. Defines a number
of matchers.

121. Also the runner
and the logger.

123. Some CSS to make it pretty.

124. ~1500 lines of code.

125. Clean code.

126. Why would you use it?

127. Easier to read.

128. function testStringConcat() {
assertEquals("Hello World", "Hello " + "World");
}
function testNumericConcat() {
assertEquals(4, 2 + 2);
}

129. var oTestCase = new YAHOO.tool.TestCase({
name: "Plus operation",
testStringConcat : function () {
YAHOO.util.Assert.areEqual("Hello World", "Hello " + "World", "Should be 'Hello World'");
},
testNumericConcat : function () {
YAHOO.util.Assert.areEqual(4, 2 + 2, "2 + 2 should be 4");
}
});

130. describe('Plus operation', {
'should concatenate two strings': function() {
value_of("Hello " + "World").should_be("Hello World");
},
'should add two numbers': function() {
value_of(2 + 2).should_be(4);
}
})

131. Better? Worse?

132. What would you rather
read 6 months later?

133. http://jania.pe.kr/aw/moin.cgi/JSSpec

134. ActiveRecord.js

135. JavaScript ORM.

136. Seriously?

137. Yep.

138. Let’s you use a DB
from JavaScript.

139. Client or server ;)

140. Gears, AIR, W3C
HTML5 SQL spec.

141. In-memory option too.

142. Some free finder methods.

143. Base find method.

144. Migrations.

145. ActiveRecord.Migrations.migrations = {
1: {
up: function(schema){
schema.createTable('one',{
a: '',
b: {
type: 'TEXT',
value: 'default'
} });
},
down: function(schema){
schema.dropTable('one');
}
}
};

146. Validations.

147. User.validatesPresenceOf('password');

148. More to come...

149. Supports basic relationships.

150. Early stages...

151. On GitHub, contribute!

152. http://activerecordjs.org/

153. Objective-J

154. Objective-C...for JS.

155. JavaScript superset.

156. Cheating...kind of.

157. Native and
Objective-J classes.

158. Allows for instance methods.

159. Parameters are
separated by colons.

160. - (void)setJobTitle: (CPString)aJobTitle
company: (CPString)aCompany

161. Bracket notation for
method calls.

162. [myPerson setJobTitle: "Founder" company: "280 North"];

163. Does allow for
method_missing.
http://cappuccino.org/discuss/2008/12/08/
on-leaky-abstractions-and-objective-j/

164. http://cappuccino.org/

165. Coffee DSL.

166. Lessons learned.

167. Viable option.

168. Widely used language.

169. Not necessarily easy.

170. Syntax isn’t as flexible.

171. Lots of reserved words.

172. Freakn ;

173. Hello prototype!

174. Verbs as first class citizens.

175. Object literals.

176. DSL vs. named parameters
vs. constructor parms.

177. new Ajax.Request('/DesigningForAjax/validate', {
asynchronous: true,
method: "get",
parameters: {zip: $F('zip'), city: $F('city'), state: $F('state')},
onComplete: function(request) {
showResults(request.responseText);
}
})

178. Fail fast vs. fail silent.

179. Method chaining is trivial.

180. Context can be a challenge.

181. Documentation key.

182. PDoc,YUI Doc.
https://www.ohloh.net/p/pdoc_org
http://developer.yahoo.com/yui/yuidoc/

183. JavaScript isn’t a toy.

184. Not quite as flexible.

185. Plenty of metaprogramming
goodness!

186. Questions?!?

187. Thanks!
Please complete your surveys.