JSConf US 2014

Even something as simple as a dropdown menu or a bar graph can introduce usability problems. From a slide out menu disappearing when a user's mouse moves a few pixels too far, to requiring NASA-like levels of precision to mouse over the right element, there are algorithms already implemented in Javascript to help us overcome these problems. If an algorithm is defined as "a step-by-step procedure for calculations", let's visually break down those steps for 2 different non-trivial algorithms and explore how these algorithms are applied to some standard & everyday user interface patterns. We'll first look at an algorithm for predicting a user's intentions by calculating mouse speed and direction, and then tackle determining hit state for hundreds of non-uniformed, variably sized and placed UI elements. Slides: http://markmarkoh.com/jsconf2014 http://2014.jsconf.us/

NaN http://2014.jsconf.us

We have everything we need to read DVD-video discs in a browser, so why don't we start? For that purpose, I ported libdvdread and libdvdnav libraries to JavaScript so that we can parse the DVD-video info files and emulate a virtual machine. But this comes with technical challenges such as browsers being bad at manipulating huge files or not supporting the codecs used in DVD (MPEG-2, AC-3...). That's why this port comes with a server in Node.js to circumvent these limitations. The resulting project is a mix of websockets, video elements, media source extensions and a lot of open source love. Get ready for a mind blowing demo! http://2014.jsconf.us

In 1980 the United States Department of Defense (DoD) released the equations and source code used to predict the positions of satellites around the Earth. These simplified perturbations models (SGP4) were originally written in FORTRAN IV and have since been ported to C++, Java, MATLAB, and Pascal. And now, with a JavaScript port, it's time to bring satellite tracking to the browser! In this talk we'll learn how to use existing tools to calculate and plot realtime satellite positions on a map using Leaflet.js and satellite.js. Along the way we'll sneak in some orbital mechanics concepts, minus a lot of the hardcore math. Perturbations, polar orbits, orbital eccentricity, Kepler's laws, orbital propagation, oh my! We will also learn about the pitfalls of 2D map projections, and why a 3D projection is more accurate and intuitive. If there's time, we'll go one step further and build a 3D satellite tracker using WebGL. http://2014.jsconf.us/

Comparing Angular, Backbone, Ember, Polymer and React. We're all building a client-side framework. And they're all different implementations of the same stuff. I want to compare the approaches that popular frameworks take to solving these patterns. If they even try to solve them at all. I also want to include info about the custom framework that Yammer uses. It'll be illustrative to see how all of these have different approaches to the same set of patterns. http://2014.jsconf.us/

What will it take for native code to become part of the web platform? The web platform has many wonderful qualities, but easy interoperability with other platforms is not one of them. Do you want to simultaneously develop for both native mobile and the web? Or use an awesome library in your web app, but it's written in C++? Well... you can. Almost. Maybe. Sometimes. Sort of. Many disclaimers and restrictions apply. But what will it take for the answer to just be "yes"? This talk will dive deep into the world of native code on the web, compiling C++ into JavaScript, and look at the gaps that need to be filled. A number of intertwined topics will be touched on, including: Emscripten, PNaCl, pepper.js, JS VM and browser internals, web workers, nitty-gritty details of JavaScript and C++, multi-threaded programming, and the horror of memory models. All will be explained, as long as you're willing to take the plunge. http://2014.jsconf.us/

MontageJS is an open source framework for building large single-page Web applications. The framework's unique component model can simplify frontend Web development and increase opportunities for code reuse. In this session, you will learn how to take advantage of the MontageJS component system to build modular Web apps that are easy to maintain as they grow. The presentation will illustrate how component-based composability strengthens frontend Web development. http://2014.jsconf.us/

Emotional safety is the most important predictor of the health of an organization and a community. But more importantly, it has a enduring repercussions on our lives as individuals. Like, our real lives—the ones we live for our whole lives. I've worked in intensely unsafe professional environments prior to joining the team at &yet. I'd like to candidly share some of the lessons I've learned from my unique perspective as a female who isn't a software developer but who spends much of her life around them (including co-organizing events like RealtimeConf, RedisConf, and TriConf). Being "in the developer world but not of it" has given me perspective to identify blind spots within our culture as a company and a community. Traditionally copywriters on a software team are viewed as a supporting role: we help sell what gets made. But what if all contributors to a team were true equals capable of leading and shaping a continuously improving company culture? That's the foundation of emotional safety.

This talk covers build tooling, processes, and your development workflow. You'll get a glimpse as to why you should be building, and why you should put together a build process from the get-go. Then we'll move on to tooling. Here I'll discuss some of the most popular JavaScript build tools, namely Grunt, Gulp, and npm. We'll investigate how each one performs for certain tasks, and I'll help you forge your own build sword. Lastly, I'll discuss the benefits of going for the module format Node.js uses, which is Common.js, and how you can leverage those modules in the browser, using a tool called Browserify. Slides: https://speakerdeck.com/bevacqua/front-end-ops-tooling http://2014.jsconf.us/

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/

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.

New to working with canvas? Never fear, we'll give you a light introduction to some of the high-level concepts about working in 3D space and go through some minimal examples before we do a deep dive into grittier details. We'll look at in-browser tools as well as plugins found in multiple browser ecosystems: not just one, because the web is everywhere and your game should be too. We'll talk about how to debug and improve the performance of both 2D and 3D canvas contexts, including WebGL code. Though we will be talking largely about games, we'll also look at chart libraries as well and discuss using canvas as compared to SVG. Even if you're only working with a 3rd party library, you need to know how to profile performance and spot jank, as well as what action to take when you find it. You'll learn how to mitigate the overhead of doing a lot of 3D math, as well as how to get good performance on low-end devices. http://2014.jsconf.us/

This talk is about a modular frontend which is an approach not common to most frontend developers. No jQuery, no frameworks. Instead many small, simple abstractions are used, published to npm and bundled with browserify. The NPM-style frontend prefers modularity and simple abstractions that do one thing well. This talk includes: * Various approaches to creating standalone "components" or "widgets" that are published to npm, including styles & templates. * How to compose various modules together to build your own "framework" with your own trade offs. * How to compose an application from smaller applications * Build small UI components with thin interfaces that you glue together in your application. Your entry point is small, containing the minimal glue code and each UI component addresses its own concerns.

We've talked a lot about big concepts such as the Virtual DOM, re-rendering the entire app on every update with a diff algorithm, server-side rendering ... But there's another side to it: all the design decisions that makes React work for large projects. Slides: https://speakerdeck.com/vjeux/why-does-react-scale-jsconf-2014 http://2014.jsconf.us/

How does the transition into ES6 modules work for browsers exactly? How do we enable modular version-managed front-end architecture in the process? jspm provides almost-magical package management for JavaScript built around the principles of version-managed ES6-modules and the dynamic ES6 module loader from the core. In short, jspm starts off by making ES6 modules work dynamically in browsers today through the dynamic ES6 Module Loader polyfilll, then we make all existing module formats work through this same loader, then then we add offline build workflows for production and a command-line package manager to allow modular dependency management. Finally turn the whole thing around and add a CDN with server-push, and you have install-free version-managed module loading in the browser.

This talk will be about the current state of the union in Exceptions and stack traces in JavaScript in not only browsers but Node.js.

A dive in to how we use Jest to unit test our JavaScript at Facebook, why unit testing should be as easy and painless as possible, and how to make it that easy.

Template specialization is a way to dynamically switch the partials in your views based on the request/response context. This becomes vital for big corporations like Paypal since we have cases where parts of the views are customized based on locale, device, user profile based A/B tests etc.This idea was born out of the work we did to support template specialization with Krakenjs suite - the open sourced bootstrapping framework from Paypal. However, the idea is general enough to be implemented directly with vanilla express apps. This talk will demo template specialization in express apps with dust templates. Dust is a powerful javascript template engine which works well with node.js, and also provides the hooks required to add this capability. Additionally, I will also go over the recipe to enable specialization for any template engine, provided the engine exposes the hooks to tap into the render work flow to do your magic!

This talk is about my deliberate choice to try writing a Node.js ORM with no respect for simplicity, maintainability, or goodwill towards mankind -- but that reads like a dream.

The future of JavaScript is too exciting to put on hold while native implementations get around to supporting much-needed new features like classes, generator functions, and modules. This talk dives into the concepts and techniques involved in transforming these futuristic syntaxes into JavaScript-of-today, through the lens of Facebook's Regenerator project, which efficiently simulates ES6 generator functions (and soon async functions too!) using plain ES5. Listeners will come away from this talk with a deep understanding of Regenerator's implementation, and also (hopefully!) a headful of ideas for designing transformations of their own.

Slides http://tjanczuk.github.io/about/jsconf2014.html#/ Humankind has been scripting JavaScript from other programming environments for generations. Time has come to reverse the roles. Let's script C# from Node.js, in-process. On Windows, Mac, and Linux. Combine the power of single threaded V8 with multi-threaded CLR. Run +70k NPM packages and .NET Framework with +20k NuGet modules and Node.js in one application. Live on the edge of two great technologies using Edge.js.

Introducing RaveJS. Rave eliminates configuration, machinery, and complexity. Stop configuring and tweaking file watchers, minifiers, and transpilers just to get to a runnable app. Instead, go from zero to "hello world" in 30 seconds. In the next 30 seconds, easily add capabilities and frameworks to your application simply by installing *Rave Extensions* and *Rave Starter* packages from npm and Bower, the leading JavaScript package managers. Finally, install additional *Rave Extension* packages to apply your favorite build, deploy, and testing patterns.

The performance of your web app is important. This you already know. But how do you know your web app is performing well for all of your users? Before you can even begin that analysis, you need a way to measure your web app's current performance. Out of the box tools provide us metrics, but most only provide an overall view. This case study of building the XFINITY X1 single-page web app will demonstrate what frontend performance data should you be gathering, how to gather it, and then what do with that data. Slides: https://speakerdeck.com/johnriv/the-truth-about-your-web-apps-performance http://2014.jsconf.us/

The 10x programmer is a unicorn. We love to lionize the amount of dedication, time, and thought that goes into creating great software -- but we forget the very real cost it can entail, both emotionally and physically, on the programmer. Depression, RSI, burnout: these are all real issues facing our field.

It's just me and my silly nerdy friends, playing with NodeBots on stage. Watch our antics, see how we think through things, and ask us questions!

For the last three months I've worked remotely from Swaziland, Southern Africa. In doing so I learned a lot about the do's and don'ts of remote work and (in particular) what its like to work remotely from a developing nation.

At Social Tables, we believe in giving engineers a lot of responsibility when it comes to building new features. For instance, they may talk directly to customers to figure out feature requirements, and have them design the UI themselves. But is this a good thing? I'll make the case that it can actually be a great way to collaborate with other teams inside your company and bring diversity of thought into an engineering organization. I'll also talk about some of the pitfalls we've run into.

Babylon.js is an open-source project built with simplicity in mind in order to help web developers creating 3D games. During this session, you will discover how simple it can be to play with 3D without having to deal with WebGL plumbing! Slides: http://www.slideee.com/slide/unleash-3d-games-with-babylon-js-jsconf-2014-talk

The robotics revolution has already begun. You can even buy drones and robotic devices at local retail stores. Unfortunately, it has been too hard to develop code for robots, and nearly impossible to create solutions that integrate multiple different kind of devices. That is why we created Cylon.js, a JavaScript framework for open source robotics & the Internet of Things. Cylon.js makes it easy to write apps that communicate with many different kinds of hardware devices all at the same time. The time has come for the next generation of open source robotics, and Cylon.js is ready to help!

It was recently discovered that types have been a thing since before Haskell.

Open source projects are better when they take advantage of a greater range of experience in the use and development of software. This includes both traditional code contributions/bug fixes, as well as other forms of contribution like localization, design, and copy-writing.

Tired of building apps that aren't as beautiful as the code that powers them? This talk will be a basic guide to visual design for the full stack developer. We'll go over design principles that will help you create beautiful and useable applications.