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.
We have everything we need to read DVD-video discs in a browser, so why don’t we start?
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!
Guillaume is passionate about web technologies and loves hacking and building crazy things on top of open technologies. He’s also fascinated by video games, animation, and, as a Japanese speaker, foreign languages.
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.
Macros allow you to extend a language with new syntax and semantics, just like you would build new APIs on top of native ones. There’s no reason the language itself shouldn’t be extensible, which allows it to grow naturally.
I love programming language research, and hack on compilers and games in my free time. During the day I work for Mozilla on the Developer Tools. I achieved the ultimate yak-shave: spent 3 months building my own desk before I could work on some code.
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.
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”?
How do you get the browser to render arbitrary HTML to a canvas? Sounds easy? We would beg to disagree.
How does the transition into ES6 modules work for browsers exactly? How do we enable modular version-managed front-end architecture in the process?
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.
Guy is currently working on a number of open source projects relating to module loading and package management in the browser. He is the author of jspm and SystemJS, and co-authored the ES6 Module Loader polyfill. Based in Cape Town, South Africa, he also enjoys spending time in the US and works as a freelance web developer.
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:
Your entry point is small, containing the minimal glue code and each UI component addresses its own concerns.
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.
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.
I’m a software engineer from Salt Lake City, Utah. I have been creating websites since the early 90’s and currently work as a software engineer @instructure
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.
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.
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.
Ryan Paul is head of Developer Relations at Montage Studio, a startup dedicated to helping developers build large frontend Web applications with reusable components. He is a Linux enthusiast and open source software developer. Ryan also writes articles about software development for Ars Technica, a popular technology news site.
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.
Brian is a bassist, an event organizer of BrooklynJS, a mentor of NodeSchool, and a cat owner. When he’s not being one of those other things, he’s a software architect at Mozilla working on the OpenBadges project
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.
Bodil is a compulsive conference speaker in the fields of functional programming and internets technologies, and is a co-organiser of multiple developer conferences in Scandinavia and the UK, mostly because she’s still learning how to stop. She is a prolific contributor to the Free Software community, and has recently taken up designing new programming languages as a hobby. In her spare time, she works as a developer for Future Ad Labs, a London based startup that wants to make advertising a productive member of society. Her favourite pony is Pinkie Pie.
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.
David Calhoun is a UI engineer working at Skybox Imaging in Mountain View, using open web technology to build interfaces for satellite imagery and video processing, a satellite imagery scheduling interface, and a websocket-powered telemetry dashboard. Prior to that he’s worked on the Node.js-backed CNET mobile website, as well as Yahoo! Mobile. He also occasionally contracts for WebMocha. Most recently he’s lived in Kyoto, Japan for a year, which was an amazing and humbling experience. He tweets at @franksvalli and writes longer stuff at (davidbcalhoun.com), and was even once lucky enough to be published in Web Performance Daybook Volume 2.
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.
By day, Jenn works at &yet as the Chief Jenn Officer, contributing to the departments of marketing, design, editorial, internal affairs, conference organization, awesome, and user experience.
By night, she spends her time tweeting sporadically as @renrutnnej, starts the beginnings of many, many side projects, conducts mini-experiments with code, and hangs out with her two favorite people in the whole world wide web: Lee and Mila.
At Fidelity we have several security/quality checkpoints across many departments to validate that applications and platforms protect customer data. Security code reviews, penetration test, risk audits, legal compliance and many other factors go into signing off on an application. Fidsafe is a new virtual safe deposit box offering by Fidelity that is the first application to be served outside the Fidelity firewall on the cloud. Fidsafe challenges every aspect of how the organization builds and deploys software. We had to answer a lot of questions and provide practical tooling/solutions to get Node into production.
We will cover what it takes from top to bottom build and operate a secure and scalable service backend implemented in Node.js and deployed to AWS. Topics covered:
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.
Neil works as a lead developer at IntercontinentalExchange (ICE), a global network of exchanges and clearing houses for financial and commodity markets, which recently acquired the New York Stock Exchange. He is the UI architect of ICE’s social, messaging, and app integration platform, and lead implementer of the platform’s core systems. Neil’s true passion lies in coaching engineers on the practical application of software engineering and architectural design principles under the real-world situations common in developing mission-critical enterprise software.
Jenn Schiffer is a web developer. From the early age of 37 she held the amulet of scripts from which the soul of the Node baby cries. The noises had awoken the spirits from whic
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.
Angelina Fabbro is a web developer and engineering developer advocate at Mozilla. Full stack development, programmer education, and crafty hacks. Plays well with others. Do not taunt happy fun ball.