List of videos

The current schedule for the completion of ECMAScript 6, the next version of JavaScript, dictates that the language specification be finished by the end of the second quarter of 2014. Most browser vendors have made informal commitments to have ES6 implemented by the end of the year. Over the last couple years, we've heard a lot about the many new features in ES6, along with the debate (and bickering) which has gone into its design. ES6 stands to be the most substantial change to JavaScript since ES4 (which didn't work out that great, as most users of ES5 are aware). With this much change comes a lot of complexity. Many of the new features (like generators or proxies) are powerful, basic abstractions, and as such combine in complex (and potentially unexpected) ways. In many ways, a new version of JavaScript offers the possibility of returning us to the wild frontier days that JavaScript only recently left behind, with library and framework vendors each choosing their own combinations of features to build powerful (and complicated) architectures that can really only be understood on their own terms. However, as a community we've learned a lot over the last half decade or so, and I think we've learned how to tackle this problem head on. I've come up with a strategy that I think would allow us to collaboratively get to a good place with ES6 relatively quickly. I'll go over this strategy and point to the areas where I think we ought to spend the most time to get the most positive results. It's up to us -- as a community of designers, developers, and implementors -- to get out in front and provide tooling, documentation, and training that will help ourselves use these new features effectively, before folklore and superstition start to take root. And it's important to remember that finishing ES6 frees the JavaScript standards bodies to concentrate on ES7, where our feedback from using ES6 will help them refine what comes next. http://2014.jsconf.us/

We've been talking a lot about Web Components as a community. Encapsulation, templating, custom elements, polyfills: it's an exciting time to be a developer! (taco-button, anyone?) Before we create the next generation of soulless div tags, we should consider the role of semantics in shiny, new technologies. In this talk, we'll discuss web accessibility in a bleeding-edge way to illustrate that accessibility conversations don't have to be boring or old-school. Slides: http://marcysutton.github.io/accessibility-of-web-components/slides.html#/slide1 http://2014.jsconf.us/

After building more and more rich and complex JavaScript apps at Airbnb, we started to see the single-page app approach break down. The language and environment barriers between our Rails server and fat client app caused code duplication and the lack of server-side rendering led to slow initial page load performance and SEO headaches. The dream of a shared UI layer and reusable business logic led us to start experimenting with ways to bring these apps back to the server. We started by converting our mobile web site, a Backbone app, to also run on Node.js and Express, which led to the open-source Rendr library. Since then we've learned a lot and have begun to refine our understanding of "isomorphic JavaScript". There are a wide range of approaches which might be considered "isomorphic" — an app could share just a few tiny modules of business logic, or just templates, or route definitions; or it might try to share the entire application code. The more code that is shared, the more abstractions have to be built to shim the differences between the very dissimilar environments of web browser and server, and the more complex and tightly-coupled the result will be. This talk will give some broader context for isomorphic JavaScript, show some real world examples, explain common application patterns for isomorphic apps, and then dive into the open-source tools and libraries that you can use to build isomorphic apps: libraries like Handlebars and Superagent and build tools like Browserify and Esprima. http://2014.jsconf.us/

Ember, Angular, React, Polymer, and Backbone. Following in jQuery's footsteps, these projects (and others) are helping to drive some future APIs in the browser. While they all get lumped into the category "Frontend MVC", an intimate look at each reveals they are quite different. These stark and subtle differences matter when choosing one for your project. In this session, you'll see each project's sweet spot, and where each struggles. You'll get a healthy dose of code as we explore the primary APIs. You will walk away with a better understanding of the goals and intended use-cases for each project. http://2014.jsconf.us/

How do you get the browser to render arbitrary HTML to a canvas? Sounds easy? We would beg to disagree. While implementing an "HTML renderer" in pure JavaScript we will visit various areas of the modern browsers. Some ugly, some hacky, some really perverted, but definitely intriguing and powerful.

With the advent of the Web Audio API, processing audio signals is now possible in realtime within browsers. Let's take a look into what raw audio data actually is, the signal processing theory behind it, and practical implementations of analyzing audio using the Web Audio API. We'll see how effects processing, audio analysis tools, and DSP algorithms can be constructed, used, and shared all in JavaScript. http://2014.jsconf.us/

JavaScript is single threaded, not ideal for distributed processing of large/complex workloads. There are several options out there for distributing the load over multiple cores, but what if we wanted to distribute the load over many servers AND cores? http://2014.jsconf.us/

There are many tools you can use to create mobile apps with JavaScript; tools like Apache Cordova, Ripple, the Cordova CLI, emulators, and a myriad of JavaScript libraries. In the Visual Studio team, we set out to make app building using Cordova a little easier, curating a set of these tools for developers using a single development environment. In this session, I'll walk you through the tool-chain and show you how we tied them all together using JavaScript and open source. You may discover a few new tools along the way and you'll get some insight into how we combined pre-existing tools with unique capabilities.

You know WebKit but think it without DOM. Put inside our core engine and your javascript codes running into native libraries of iOS and Android devices.