List of videos

When writing complex business logic, it is critically important to maintain clean code though the judicious applications of Test Driven Development and Domain Driven Design. However, even these powerful techniques fall short of solving the problem at the heart of building complex software: building what the customer actually wants. Domain Specific Languages (DSLs) allow us to capture complex business requirements in code written in the language of the customer. Once an ubiquitous language between you and your customer is defined and implemented as a DSL, the code can quite literally be given back to the customer to edit and refine. This is not a theory, or a myth. I have done this under real-world constraints and deadlines, and you can as well. JavaScript's ability to blend Object Oriented and Functional Programming paradigms makes it an ideal language for authoring custom DSLs. Unfortunately, too often developers are unclear on how to identify when a custom DSL is an appropriate solution, and when it is, how to go about writing one. I will take you through the process of developing a few different custom DSLs from planning to implementation, as well as how to performance tune and debug your new custom language. My hope is that you will gain a powerful tool for managing complex software that will keep you sane, and your customers happy.

Interactive art can be a powerful means to inspire conversations, creativity, and wonder among groups of people. It is now easier to build interactive and collaborative apps with JavaScript, and these features can be used for expressive works. I'll describe using JS to make web art, as well as installation and projection art. Because of web standards as well as browser performance improvements, you can make JS art that is accessible on a variety of platforms. The openness of the JavaScript community inspires the openness of creative coding in JavaScript, producing works that invite exploration, learning, and hacking. http://2014.jsconf.us/

We spend so much time building things that we sometimes forget that we're building for, and with, other complex human beings. Remembering that we are people first is the first step to making a positive shift in the way we treat each other. http://2014.jsconf.us/

Web applications do not require an over-arching framework to be organized and maintainable. In fact, an application with modules from all over the place can in fact be maintainable, understandable, and encouraged. Instead of subscribing to one framework that provides developers with an entire slew of unused or unneeded functionality, an architecture can be built from the ground up using small modules from a variety of different sources. This kind of architecture is taking off in the Node community, and is starting to make its way in client-side javascript. This talk explores the differences between using a formal framework- like Ember, Backbone, Express, or Sails- and using a modular approach. Frameworks are not entirely out of the picture- there are a few examples of frameworks that encourage this kind of architecture by providing minimal structure in the right places. This talk will explore those frameworks, and the general ideas, benefits, and possible pitfalls of a modular architecture, from both the client and server-side perspective. http://2014.jsconf.us/

To most people in JS, functional programmers are perceived as academic hipsters raving about things like applicative functors, semigroup homomorphisms and Yoneda lemmas for no good reason except to make the rest of us feel stupid. And this is fair; there's no better way to make you feel pitifully mainstream than throwing category theory at you. Conversely, JS programmers tend to believe functional programming, therefore, can have no real world application because nobody in the real world has any idea what a Yoneda lemma is and they seem to be getting by just fine without it. Except we aren't. We've been living in callback hell for almost two decades now, and no matter how many control flow libraries we submit to npm, things don't seem to be getting any better. And that's where functional programming comes in—turns out callbacks are just functions, and those academics in their ivory towers with their Haskell compilers actually encountered and solved these problems long ago. And now we can have their solutions in JS too, because of functional reactive programming. To demonstrate, I'll attempt to write a browser based game, from scratch, with ponies, using RxJS, everybody's favourite reactive library, live on stage in 30 minutes with no callback hell in sight. And we'll be finding out if this reactive stuff is all it's cracked up to be or not. http://2014.jsconf.us/

We live in a time of vast computational resources - many of us carry around in our pockets what just thirty years ago would have been considered a supercomputer. But it's not just the hardware, these bite sized supercomputers run software using state of the art dynamic compilation techniques to deliver stellar performance without sacrificing flexibility. While all of this may sound incredibly futuristic, many of us still program these Dream Machines with miserly techniques not far removed from the best practices of the 1960s. We have cycles to spare, by investing some of them into immutable data structures our programs get new wonderful properties that enable us to design solutions at a much higher level of abstraction. Om is a new library I've created just to explore these possibilities. While Om itself is written in ClojureScript, we'll focus primarily on the big ideas present in Om all of which are easily portable to JavaScript. http://2014.jsconf.us/

Browser test automation can be intimidating leaving developers to spend their time manually testing browsers (many times in VMs) or opting to simply not test a range of browsers. Join John-David Dalton as he discusses browser test automation, removes the roadblocks/gotchas, and shows lots of awesome things you can do (code coverage, perf testing, tagging, & more). http://2014.jsconf.us/

In this talk, we will explore the techniques necessary to design and build CommonJS modules that work both in node.js and the browser using Browserify. We will look at both the general techniques needed, as well as a specific implementation with the Twilio module (npm install twilio), which is currently being converted to work both in node (REST API + utilities) and the browser (WebRTC + VoIP). http://2014.jsconf.us/