This article is mirrored on Medium.

It’s late and I’m walking back from the athletic complex to my car with my son, I say, ‘Nice job, buddy, you went hard,’ but my voice cracks …. I’m hoarse from yelling ‘Man up, get back, find your man, Now push it! Get your head up, see your teammates!’ as I attempt to teach a group of fourth graders how to both apply a full court press and break it … managed chaos at its best. I sit down in the front seat, and take a deep breath. Man, there is nothing like an evening of high velocity basketball after a long day of high velocity software. Only problem is tonight we lost, and I hate losing.

At Den, like any other early stage startup, velocity is king. In that regard, we are much like most startups, we build business requirements fast and at the highest quality possible.

In this highly competitive field, we are here to win. If building quality software, fast, is winning, concepts like technical debt, communication bottlenecks, monolithic architectures, and analysis paralysis are losing. As I drive home, I reflect on the last four whirlwind months. So far, at Den, we have been winning, we’ve built an amazing team and tech stack and our business partners are super pleased and excited. And most importantly, we have done it really fast.

So, how have we come this far this fast in building a high quality, cross platform mobile application and scalable microservice architecture in under six months? You may be surprised, but I feel it has more to do with the softer side of the industry than it does with the technical (that’s a future article).

1. We’ve Maintained a Strong Relationship between Business and Engineering

It starts with a relationship between our business partners built on a foundation of trust and engagement. We don’t look at our relationship with business as master-servant, we see it as an equal partnership, and I see myself as a Product Owner with an engineering background. Each of our engineers are future users of our application and are therefore emotionally invested in its success.

Also, my ability as CTO to communicate clearly our technical hurdles, skill set challenges, gaps in requirements, etc. is paramount to our success. For me, it is important to communicate challenges without making excuses. Every engineering decision that is made sets off a series of consequences, both good and bad. These trades will always come with negative consequences, depending on one’s perspective. A great Tech Fellow, Sam Price from USAA once told me, “Every decision you make will be wrong.” The key is making quick yet sound decisions, living with the outcomes, and communicating the trades as best you can to maintain trust between you and business partners.

It is also important to help engineers with understanding that a quick, smart decision must be made. Agree to disagree, but commit to the task, and help all understand that the decision is not necessarily short-sighted, and there will always be some negative consequences, some unseen and some foreseen. At the end of the day, analysis paralysis is not an option.

2. We’ve Understood and Balanced ‘Short term’ and ‘Long term’ Velocity

In our discussions, we are constantly differentiating between ‘short term’ and ‘long term’ velocity. Often, in past experiences, naive business partners press for decisions entirely based on short term velocity. At Den, as we rapidly develop, and respond to dynamic business needs, we leverage our collective experience to make sound technical decisions that positively impact our long term velocity. In other words, we want to make sure that later phases are not a nightmare of correcting all of the technical debt accumulated getting to MVP. Later development then becomes slow and painful, engineers get frustrated with the mess, business gets frustrated with the speed. So, we constantly balance sound architectural decisions that will impact our long term velocity with short term velocity wins.

When discussing with our business partners, the language we use to describe those decisions matters. If we trade a 2 hour task for an 8 hour, but it saves us 40 hours down the road when we need to pivot, we have made both a sound business and technical decision.

One key challenge is having the experience to anticipate those pivot points and understand all the technical implications behind the pivots, and very few can go at this alone. Which brings me to building a team of leads that possess, or have the potential to possess, all of the mixture of hard and soft skills I am alluding to.

3. We’ve Invested in Skillz

Nothing impacts velocity more than the individual inability of the engineer to achieve tasks. This manifests itself in a blend of intelligence, experience, creativity, communication skills, passion for the product, work ethic, attention to detail, empathy for others, and the ability to suppress one’s ego for the good of the team (but, more on that later).

Stephen Curry is perhaps one of the greatest modern examples of a technician that has elevated his status in his field through precision practice, time commitment, and attention to detail. We refer to him often in metaphor. When I played college basketball, decades ago, I had some great mentors. I used to shoot thousands of jumpers on Saturday mornings with Ricky Pierce and Avery Johnson. That was my first introduction to the insane amount of time it takes to become a professional. Being great is no accident, and it doesn’t stop until you retire. As CTO, the first 6 hires on our team had to be better than myself, and they had to be equally obsessed with building great software. All in all, the collective work ethic of the Den team is more than I have ever seen in any environment I have worked in.

As a management team, we also allow time, and invest in, our engineers. We encourage the exploration of new technologies and budget for attending conferences of their choice. In our first four months alone, we have attended WWDC, Dockercon, and Gophercon.

4. We are a Team

At Den, we have built a world class ‘team,’ not a group of great individuals. We are small, yet high performing, and we like it that way. High velocity and winning have no room for egos and drama. Each time we add a new personality, there is a chance we could rock our chemistry, so, we stay highly selective.

It also doesn’t hurt that the three founding members of Den are all former Division I collegiate athletes, having had the tenants of successful teams drilled into our heads early in life. So with that as a foundation, we were very calculated in going after the right mix of talent. All of our hires were from former organizations we had worked with in the past, or came highly recommended by a trusted colleague. The outcome of choosing the right mix is what enables the blending of our collective experience and skill sets, resulting in our ability to make sound decisions as a team.

Each member of our team is truly great at and passionate about what they do, and the working environment we have created is giving them the opportunity to get even better at a rapid rate.

Stay tuned for the technical side of our velocity strategy, as I map out our decisions from building our mobile application with Ember Cordova rather than React Native, why we chose CircleCI over Codeship, Quay as a container registry, and our combination of Node.js and Go services, thoughts about our Domain driven Microservice architecture, to details about using Terraform and Kubernetes on AWS.

In April, I had a chance to attend and speak at FITC 2015 in Toronto. This was an important talk for me as I was just three days into a new job, leaving the pond at frog design, to join my first startup, InVision. That was not an easy decision for me, in that I loved working for frog. My work at frog was the first time I had been giving the freedom to ‘focus’ in the workplace.

The culture at frog is certainly not for everyone, but for me, someone who has always been comfortable with creating my own path, it was in many ways ‘carte blanche’. The catch at frog is that, by design, you won’t be given much direction; you are expected to create and drive the direction. When I joined frog, my goals were to speak and write as much as I could while I focused on producing as high a volume of quality technical deliverables as I could for our clients. And in almost every case, while leading ‘greenfield’ projects for fortune 200 companies, I was able to stop and start over on each project building upon the momentum and experience of the previous endeavor. All of that real world learning fueled my writing and speaking. It was exhausting, in the good kind of way.

This was a very different model than building software within an enterprise, maintaining and/or augmenting legacy systems, or having frameworks and tools prescribed to you by the weight of enterprise processes and architectural directives. This was exciting because, as I said before, the freedom fueled growth, the healthy, self-directed type of growth.

So why did I leave? Another opportunity was presented to me that sparked a deep curiosity because in some ways the problem set was the antithesis of my work at frog, a product suite and engineering team that was being challenged to scale to millions of users. I knew that their challenge would help me grow too, and fill in even more gaps.

Now, production applications weren’t new to me when I joined InVision, but in some ways startup culture and the smaller engineering team was. While in some of my previous roles, I would be responsible for a small sliver of a very large pie, here my slice would be much larger, and the red tape would be few and far between. I could recommend an approach, build it, and deploy it within three days as compared to three months or sometimes even three years.

Another interesting pivot for me was to completely walk away from the Ember community, and dive into Angular and React/Flux, as if I was disgruntled with Ember or something. On the contrary, my first 3-4 months at InVision, I spent my time retro fitting the existing application with tooling that ember-cli provides out of the box. And, as Ember 2.0 is released, my appreciation for the work that community is doing is even greater than it was before. For now, I watch from afar, as I’m not actively developing an Ember app. On the contrary, I am much closer to the Angular and React communities than I was before, which makes for a nice trade off.

I have to say that working at InVision has been an amazing experience. We are a 100% remote team using the latest and greatest of tooling to keep up with each other and our software. Our software continues to evolve as does our DevOps automation, deployment models, code quality and our architecture. Not only that, we have been working night and day to build our teams with the best and brightest talent we can find. The company has tripled in the 6 months since I have been here. It has been an amazing whirlwind of growth.

I am currently focusing on leading the Application Core team. This was the challenge I was looking for in that I needed to learn the breadth of the product suite’s codebase before I could formalize a plan for evolving the architecture for scaling, addressing performance issues and technical debt, and improving developer workflow and code hygiene. Our application core team is now around 10 engineers and testers, and we begin to see the fruits of our labor. We are still growing and searching for great talent, feel free to reach out if you are interested.

An Early Adopter of Ember

Outside of architecting and developing complex web apps during my day job at frog design, I spent a good part of 2014 finishing up Building Web Apps with Ember.js, teaching Ember.js workshops, and giving a talk entitled: “The Art and Science of Shipping of SPAs with Ember.js.”

Each of these focus areas were obviously complimentary: the workshops serving as deep dives, the talks as the high level summaries, and the book and companion source code serving as a reference application and detailed documentation.

At work, throughout 2013, 2014, and now into 2015, I have leveraged this momentum to educate cross-discipline teams of developers and designers and execute some very ambitious JavaScript applications for numerous clients. In a rapidly changing environment, it has been a pleasure to grow a team that now possesses framework-level expertise, allowing us to rapidly iterate on application feature sets without having to reinvent the wheel.

For me, all of this has been a culmination of experiences that started in the mid 2000s with PHP and Flash work while doing small business web design and CMS development, to large scale production of JavaScript and mobile hybrid apps in the late 2000s, and to now UI/UX focused, enterprise, rapid application development.

Perhaps, this excerpt from the prelude of Building Web Apps with Ember.js explains my stance for the last couple of years:

Since 2009, I have worked on numerous applications using Backbone, Angular, and Ember. But today, I often recommend Ember.js to the clients I work with. This is primarily due to the fact that the conventions support well-known web application development patterns that I have custom written or pieced together from multiple open source libraries. Here, are the high level concepts that, in my opinion, make Ember so valuable:

• Ember’s object model supports a classic and well understood, object-oriented pattern of class inheritance through extend, object initialization, getters and setters, and class monkey patching.
• Ember models, controllers, and components extend the Object class, which ensures that these objects inherit Ember’s powerful default data binding.
• The router supports complex nesting for URL-driven applications that manage application state in a conventional way that can be understood by those with web-server-routing backgrounds.
• Recently, build, workflow, and testing tools in Ember have matured and become intuitive.
• Ember’s only dependencies are on jQuery and Handlebars.js, two very wellknown and documented libraries.
• Finally, the community is vibrant, passionate, and extremely active.

What’s Next?

Most recently, I find myself moving into a new phase that mirrors the needs and concerns of the clients I interact with on a daily basis: navigating the SPA landscape and making future friendly decisions based on the complex solutions matrix that is now Ember 2.0, Angular 2.0, and current React/Flux.

My latest talk: SPA 2.0: The latest in JavaScript frameworks will address these questions:

• What does the future hold for the building of complex applications on the Web Platform in 2015? How do we manage the complex SPA landscape, and help our clients make future friendly architectural decisions?

• Will an Angular 2.0 breaking rewrite send devs running for something better? Can React/Flux community offer a complete application framework solution for complex applications? Will Ember continue to evolve into a lighter framework that can shed it’s ‘monolithic framework’ reputation?

• As the Angular and React communities adopt the Ember Router and the Ember community is inspired by React’s Virtual Dom to take advantage of it’s existing under utilized view graph, the communities are adopting the best of each other. In what other ways are the individual framework communities learning from each other?

• Will native, cross browser web components become a reality? What is the IE roadmap in regards to custom elements, HTML templates, HTML imports, and shadow DOM? Will we begin writing web components in Ember without the use of handlebars syntax?

• Will functional reactive ‘stream’ patterns become common place with better integration into frameworks, as promises did in 2014?

• With ES6 modules ( and transpiler build steps ), as practitioners can we finally lay the JS module debacle to rest? Do Isomorphic JS architectures still make this a challenge?

SPA 2.0 Topic Areas

Here, are the areas my talks will focus on in 2015:

• Framework Maturity and Stability
• Developer Ergonomics, Tooling, and Front End Ops
• View Performance and Mobile
• Async Router
• Data Binding (1-way , 2-way use cases)
• ES6 modules
• Web Components
• Community and Documentation
• Release Cycle
• Client Side Data Stores
• Services and JSON Specifications

In the month of June, I had an opportunity to travel to Las Vegas to give a workshop and related talk at Future Insights Live 2014.

My workshop was an 8 hour, beginner to intermediate level, course on Ember.js. I’ve added it to our HTML Hacks training content. If you or your company need training, give us a shout.

Here is a brief outline of the workshop:

Introducing Ember.js

Getting Started with the Starter Kit

Ember Inspector Overview

Ember Object Model

• Application
• Object Model, Inheritance, Getter and Setters, init, and .super
• Object Model – Computed Properties
• Object Model – Computed Properties w/ @each
• Object Model – Observers
• Object Model – Bindings
• Object Model – Re-Opening Classes
• Object Model – Mixins
• Object Model – Enumerables

Handlebars

• Handlebars Templating Engine
• With Data in an Array
• Handlebars Helpers
• Simple
• Dependencies
• Handlebars Helper to Get Bound Data

The Run Loop / Backburner

• Backbone Example
• Simple example
• Flushing Router Transitions Queue
• Backburner and computed properties

HTMLBars

• Understanding Handlebars Metamorph
• Ember, Backbone Benchmarks
• HTMLBars/Backburner, Backbone, React Benchmarks
• HTMLBars Basics: no bind-attr
• HTMLBars Basics: no metamorphs
• HTMLBars Basics: logic

RSVP

• Simple
• RSVP Chai-as-promised
• RSVP and the Router – (more later)
• RSVP.hash, RSVP.all – (more later in Views)

Router

• Simple .map
• Router and Handlebars Helpers
• outlet
• render
• partial
• Routes vs Resources
• Async Router
• Understand Promises
• Understand hooks / active generation
• Simple RSVP hash from IndexRoute
• Nested Routes, Async Router, before/after model hooks, named outlets

Controllers

• ObjectController and ArrayController
• Controllers and Object Model
• Hierarchy
• Needs
• Sorting

Views

• Simple Views
• Custom View Helpers
• Layouts (simple handlebars compile)
• Built In Views
• Select

Components

• Custom Elements

Actions

Ember-Data and the FixtureAdapter

Wrapping It All Together

• RSVP.hash, Components, FixtureAdapter

In late April, I took my Ember.js talk to Louisville, Kentucky for the CodePaLOUsa conference.

In the process I discovered Doc Crow’s Southern Smokehouse and Raw Bar’s BBQ and Bourbon menu. I highly recommend it for anyone in the area trying to find authentic, local fare.

During the day, I also listened to some great talks from @sireb and @robtarr.

My presentation focused on demoing the latest versions of RockNRollCall demo application, the source code for my upcoming book, OReilly’s Building Web Apps with Ember.js.

At the beginning of November, I was given an opportunity to give two talks in Malmö, Sweden at the Øredev conference. First of all, I have to say I was extremely impressed with the conference. Although the theme was the Arts, I found it to be a developer’s conference with an artsy edge. The speakers I had a chance to see were developer’s developers, one of my favorites being a talk on Meteor by Chris Mather (@eventedmind) of eventedmind.com. I’ve maintained a peripheral view of Meteor, so it was good to get a beginner to intermediate overview of its capabilities. Given that I have been doing MongoDB / Ember-data client work as of lately, I am particularly interested in exploring minimongo.

The city of Malmö was also a pleasure to experience, and as you might imagine, the people of Sweden were very welcoming. One of the highlights for me was the speaker dinner at the Malmö City Hall, originally constructed in the Middle Ages. On a side note, I finally had a chance to meet and have dinner with Douglass Crockford, a long time inspiration and virtual mentor, who was in town to give the keynote on Managing Async with RQ.

Building Web Applications with Ember.js and Ruby On Rails from Øredev Conference on Vimeo .

My first talk was a preview of my new book O’Reilly’s Building Web Apps with Ember.js. I shared the stage with co-author and fellow frog, Thomas Q. Brady. We took the audience through the creation of RocknRollCall, an intermediate level Ember.js application that fills in many of the blanks that most of the ‘Getting Started’ applications don’t.

Some of the highlights of the book, and the talk, cover topics such as: a survey of Ember tooling, debugging with the Ember Inspector, Ember boilerplates, app initializers, promises in Ember, the needs API, Ember components, 3rd Party JavaScript Integration (jQuery, D3), Ember testing, SPA authentication, Ember-data and other client-side persistence solutions, and remote data persistence with Ruby On Rails and Node.js.

My second talk was HTML5 Hacks Evolved, where I continue to share more hacks from by first book HTML5 Hacks, and html5hacks.com. This talk is culmination of HTML5 specifications that will have you rethinking browser-based applications. Some of the highlights of this talk included: Web Workers, WebSocket w/ GeoLocation, Device Orientation, and LeapJS, Web Components / Polymer / Ember Components (Custom Elements, Shadow DOM, HTML Imports, Model Driven Views, and Local Storage.

HTML5 Hacks from Øredev Conference on Vimeo .

In 2014, I’m retiring the HTML5 Hacks talks, to begin focusing solely on Single Page Application development in 2014. My hope is to kick out an early release of Building Web Apps with Ember.js very soon, and finish the book in early 2014. After that I’ll be in Louisville, KY at Code PaLOUsa to continue the Ember.js roadtrip.

This post is mirrored from: html5hacks.com

I spend my days writing a lot of JavaScript, and helping companies deliver ambitious UX focused applications to the web. I author books on the subject, blog, and speak at conferences as often as I can.

I work for frog, a product design firm, that for the last forty years has been helping increase the profiles of brands like Sony and Apple through iconic design.

I work within a culture that has deep roots into the Maker Movement; A culture that was making before the Maker Movement was cool, the “original makers” if you will. Written upon our walls and slide decks is the tag, ‘Love What You Make’, and as you might expect many of the frogs that sit around me are craftsfolk, DIYourselfers, and tinkerers. It is not uncommon to see a flying quadcopter, a mesh sensor network of Arduinos, 3D printed prototypes, explorations in next generation gesture with the Leap Motion and Kinect, video production, motion studies, 3D modeling, along with the standard artistic mood boards and web and native mobile application wireframes. Let’s just say there is no shortage of creativity across every medium imaginable.

Sharing My Craft with my Children

All of that being said, I’m a parent of two young children. My little ones constantly challenge me to find ways to share quality time with them. The parents reading this know the juggling act.

What I try to do is architect bridges between my children’s curiosity and the passions of others that have explored their crafts in a deep way. Myself, and my wife, being the most important of those craftsfolk.

If I’m doing it right, when I spend time with my children, they should share in my excitement and passion. If I’m doing it wrong, I’m overwhelmed and exhausted from work. In my vision, my children should be witnessing a model of how to wake up everyday with the goal of embracing opportunity to create a combination of function and beauty within the world around them.

So it is in this context, that I met up with Mozilla’s Luke Crouch, and Tulsa Mini Maker Faire’s Scott Phillips to put together the closing keynote at the 200ok conference .

JavaScript Makers: How JS is Helping Drive the Maker Movement

The 200ok conference is on track to become Oklaoma’s premier web conference attracting a sold out crowd of web professionals from all over Oklahoma and the neighboring states. Going in, I felt as though I knew my audience well. In other words, if I spoke to them about languages they would understand, JavaScript and HTML5, my message would easily resonate. I also knew that given their location, Tulsa, OK, a presentation that touched upon work life balance and family values would immediate strike a chord as well.

So in the spirit of authenticity, I pretended as if getting prepared for a closing keynote dependent on hacked together hardware and software demos wasn’t challenging enough; I made the decision to include my 6 year old son, Carter with a flying drone and a custom configured Minecraft server accessible over conference wifi. I knew this would ensure that the presentation dangled on the brink of disaster, mirroring the chaotic reality of both open hacking and parenting.

My thinking was that a presentation on this topic should be authentic, and reflect the reality of my proposition, not be an ivory tower, academic/authoritative talk about how to share your craft with your children. I also made sure to not prep Carter. With a loose structure in place, we took the stage and worked our way through a story that consisted of 12 open software and hardware demos that showcased JavaScript as a primary scripting language, and a table full of hardware that ranged from a drone, a dissected wifli helicopter and erector set, a leap motion, and numerous prototyping boards.

Here are some of the highlights:

JavaScript and Prototyping Boards

Earlier this year I did a presentation at HTML5.tx that focused on building an Internet of Things with JavaScript and various open hardware prototyping boards such as Arduino, BeagleBone, and the Raspberry Pi. It was in that talk that I made a connection that eventually led to an introduction to Luke. So, given that the HTML5.tx content was of interest I started the presentation with a demo of the Arduino, Johnny Five, the original Beaglebone and BoneScript.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

  ...

  require('bonescript');

  ledPin = bone.P8_3;
  ledPin2 = bone.P8_4;

  ...

  app.post('/motion', function(req, res, next) {

    console.log(req.body['eventType']);

    res.send('Motion data collected for '  + req.body['eventType'] + ' event');

    if (req.body['eventType'] == "motionstart"){
      digitalWrite(ledPin2, HIGH);
    }
    else if (req.body['eventType'] == "motionend") {
      digitalWrite(ledPin, HIGH);
    }

  });

Nodecopter and the Leap Motion

I started with the basics of the node-ar-drone module:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

  var arDrone = require('ar-drone');
  var client  = arDrone.createClient();

  client.takeoff();

  client
    .after(7000, function() {
      this.animate('flipRight', 1000);
      this.animateLeds('blinkRed', 5, 2);
    })
    .after(3000, function() {
      this.stop();
      this.land();
    });

Later, a crowd favorite was mapping the gestures from the Leap Motion to the Parrot AR drone, so that a one finger clockwise gesture triggered a nodecopter takeoff. A counter clockwise gesture then landed it. I was able to put this together using the leapJS and node-ardrone node modules, based on some initial hacking by Markus Kobler, where he pulled this off at a Nodecopter London event.

Jesse Cravens blowing minds with a JS-driven copter. from Michael Gorsuch on Vimeo.

ScriptCraft: Running JavaScript from within Minecraft

Later, I showed how to script inside of the Minecraft virtual world, using Walter Higgins’ great ScriptCraft library. I wasn’t expecting the conference wifi, and single access point, to suffice in allowing Carter and I to interact within virtual world. I was also concerned about the dynamic IP, and having to change it on the fly, start/restart the server, etc. So I made the decision 10 minutes before to not have Carter log in, and I would just speak to the possibility instead. In true 6 year old fashion, he rebelled and logged onto my server, popping up in front of me wearing a Creeper mask, as I was mid stream explaining how to script wooden signs with his 1st grade sight words as a homework exercise.

1
2
3
4
5
6
7
8
9
10

Drone.extend('sightwords',function (){

    var wordsArr = ["have", "black", "three", "want", "get", "how", "two", "ten", "come", "went", "into", "know", "my", "do", "down", "who", "must", "let", "with", "red", "find", "will", "new", "live", "five", "you", "funny", "yes", "no", "may"];

    for (i = 0;i < wordsArr.length; i++){
        this.right(0+i).sign(wordsArr[i],68);
    }

    return this.move('sightwords');
});

Needless to say, his innapropriate behavior was a crowd favorite. I have to admit, it was mine as well.

Going into the talk, I knew I’d either be trying this again in the future or abandoning it as ‘one of those ideas’ that sounded good in theory, but was just not going to work. Where did I land? Well, let’s just say that Carter and I are looking for our next opportunity to share our experiences with other parents/web professionals.

As JavaScript-centric web applications continue to become the standard, and the browser continues to evolve into a full-featured web application platform, developers need powerful debugging tools to help quickly troubleshoot issues and fix them efficiently. Issues can range from HTML/CSS browser inconsistencies, JavaScript exceptions, and a myriad of performance issues that range from DOM access to network latency.

There a number of tools that web developers can use to help make debugging front end applications less painful.

In this tutorial, we will walk through the top tools available and how to use these tools by addressing some of the most common issues faced in modern web application. This is a beginner to intermediate level tutorial for web developers getting started with debugging the web, or programmers coming from other languages who want to better understand how to troubleshoot client side JavaScript, the DOM, performance, and network calls.

To demonstrate we will be debugging a simple web application. The source code is available here: https://github.com/jessecravens/techpro-debugging.

Read more at: http://tech.pro/tutorial/1404/debugging-modern-web-applications-part-1

JavaScript is executed in a single thread. If you’re not familiar with threads, what this means is that JavaScript can only execute one block of code at a time. If code is already executing, any interaction by the user will instantiate an asynchronous event that is queued up for later execution. Other events like those from XMLHttpRequests and timers, are also added to the queue.

So, as you might expect, a single-threaded architecture can be problematic to the user experience if a particular script takes a long time to complete.

Read more at: http://tech.pro/tutorial/1487/web-worker-patterns

For SXSWi and FluentConf this year, @boyofgreen and I created a demo application to showcase some of the hacks that we included in our book OReilly’s HTML5 Hacks.

The demo application, Nerdclustr, is an HTML5 mobile application that brings ‘nerds’ of all types together conferences and provides a visual map that updates in real time. The application was written with Node.js and the Express web framework. It demonstrates the following specifications: HTML5 Web Forms, Geo Location API, WebSocket, Canvas, CSS3 transforms.

Given, the attention that Web Components and Polymer.js have been getting lately, I felt this was a good opportunity to demonstrate some of the exciting new specifications that are making their way to modern browsers. For the sake of this tutorial, I’ll be using and providing screenshots of Google Chrome, but it should be worth your time to explore the status of each of the specifications in other modern browsers as well.

In this tutorial, we will take a look at the HTML5 specs mentioned above in detail. Then, we will explore Polymer.js and build out an example application.

Read more at: http://tech.pro/tutorial/1421/building-next-generation-widgets-with-web-components