Brit Gardner

Updates from March, 2012 Toggle Comment Threads | Keyboard Shortcuts

• 

  britg 8:58 am on March 15, 2012 Permalink | Log in to leave a Comment
  Tags: dev ( 23 ), spdy, websockets ( 2 )   

  SPDY and Its Relation to WebSockets 

  When SPDY was first announced I didn’t pay too much attention as history has shown it takes years before these things become widely adopted, if ever. Recently though, Twitter launched support for the protocol and I noticed (via this Chrome plugin) that quite a few of the sites I visit on a regular basis (mostly Google properties) are actually using SPDY in production.

  Interesting. I guess it’s time to pay attention.

  But, WebSockets!

  My first question, without knowing too much about SPDY, was what its relation was to WebSockets — are they two competing implementations solving the same problem? The short of it is: No, they are complimentary and will coexist. Here’s my best attempt to relate the two:

  SPDY is an augmentation to HTTP with the goal of making synchronous HTTP requests faster.

  WebSockets is an alternative to HTTP with the goal of facilitating real time communication.

  The big point here being that SPDY shouldn’t require too much application-level refactoring, whereas supporting WebSockets means building an application specifically for bi-directional communication.

  Push

  A word often bandied about is push and it has two different meanings with these technologies.

  SPDY Push is a technique where more than just the requested resource is sent down the pipe to a browser, but within the context of a single request. Example: on a given HTML page there’s a good assumption that the corresponding .js and .css and a few images will be requested. SPDY can send all of these in a single request, eliminating quite a bit of RTT (round trip time).

  WebSockets Push facilitates asynchronous communication between the server and browser. The server receives new data from another source and rather than waiting for the browser to request the new data, it is simply pushed through an already-open connection.

  Complimentary

  The two protocols are actually complimentary. WebSockets makes its initial handshake with servers over HTTP to discover if the ws:// protocol is supported, and one of SPDY’s primary methods of optimization is compressing and caching HTTP request headers.

  From the SPDY Whitepaper

  Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers… We found a reduction of 45 – 1142 ms in page load time simply due to header compression.

  So, in an ideal future the RESTful request-based web is driven by SPDY, and all of the real-time communication and “app-ifying” is handled via WebSockets. Two peas in a pod!

  Bill, and Curt are discussing. Toggle Comments

   
  • 

    Curt 7:40 pm on May 2, 2012 Permalink

    Hi, nice write up. You have helped me understand the difference between these 2 seemingly similar techs. I think that SPDY should find a new term besides Push as it adds confusion and does not describe the act of sending multiple resources simultaneously.

  • 

    Bill 9:24 am on May 15, 2012 Permalink

    I concur, excellent write-up. Note that you meant “complementary”.

  Reply Cancel reply

  You must be logged in to post a comment.

• 

  britg 11:01 am on January 15, 2012 Permalink | Log in to leave a Comment
  Tags: css3, dev ( 23 ), forgecraft ( 3 ), javascript ( 14 )   

  Forging Forgecraft: Integrating CSS3 Transitions with Javascript 

  Forgecraft is a game currently in development using Ruby on Rails, Backbone.js, and all sorts of HTML5 buzzwords. Read an introduction here, and play the demo here.

  With Forgecraft, and any game really, there are usually quite a few animations running concurrently. I found these moments to be choppy, unresponsive and frustrating when they were implemented in javascript (especially on lower CPU environments like the iPad) and needed another solution. CSS3 transitions were an obvious choice to check out, as they’ve been shown to be a great way to add a little pizzazz to a modern web app and can be executed natively (and even GPU accelerated).

  But, can they provide the technical underpinnings for an interactive gamely element? To be effective in this context, they’d have to be:

  • responsive, consistent and reliable
  • noticeably smoother than their javascript counterparts
  • simple to integrate with scripting

  Regarding the first 2 points, CSS3 transitions’ effectiveness will really depend on your particular use-case. With Forgecraft they were definitely response, reliable, and smoother than javascript and I decided early on to use them in lieu of javascript wherever I could. But, I won’t go into the benchmarks and A/B comparisons in this article… perhaps later. Let’s just skip straight to the useful part:

  Product Intergortion obscure 30 Rock reference →

  Integrating CSS3 transitions with the game’s scripting is pretty straight forward:

  • Define transitions in CSS on your master element
  • Define classes with resulting properties changed
  • Trigger a class change using javascript
  • Listen for the transition-end event with javascript

  Of course, there are a few pitfalls with each of these steps that I’ll go into here. Let’s take an example from Forgecraft: the Bonus Strike event. Randomly while forging the player will see a bar pop-up like this:

  

  The bar moves from left-to-right and the player’s goal is to click the icon when the moving bar is directly under the target (large white) bar. The moving bar is animated with CSS3 transitions.

  Defining the CSS:

  We have a bar that needs an initial negative offset (the start position) that transitions to its final position. Simple enough: we define the base CSS on the #bar element and give it two classes (.new and .activated) defining each of its states. We also define the transition between the two states:

  
  

  position: relative;

  background-color: rgba(153, 153, 153, 0.3);
  border-right: solid 5px white;

  -moz-transition-property: left;
  -webkit-transition-property: left;
  -o-transition-property: left;
  transition-property: left;
  -moz-transition-duration: 1.5s;
  -webkit-transition-duration: 1.5s;
  -o-transition-duration: 1.5s;
  transition-duration: 1.5s;

  }

  #bar.new {
  left: 0px;
  }

  #bar.activated {
  left: 600px;
  }
  

  One pitfall you may run into: for the animations to work in Firefox, you have to explicitly define the initial state for whatever property you are transitioning. In this example we are transitioning the left property of the #bar element. You normally wouldn’t define left: 0; — that’s the default! But Firefox requires this to trigger the transition when that property changes.

  Triggering the Animation in Javascript

  Using jQuery, we simply apply the classes that we defined in the CSS when we want to trigger the transition.

  
  

  Listening for the transition-end event

  CSS3 Transitions would be useless if we couldn’t get their context from within our scripting. Luckily, a series of events are fired in javascript while the transitions are running, just like you’d expect in a javascript-based animation. The primary event we care about is when the transition ends as you’ll most likely want to trigger callbacks.

  Unfortunately, each browser vendor has decided to name these events differently… typical huh. Modernizr to the rescue! (If you’re not using Modernizr, you should be. But that’s another blog post altogether).

  There’s a hidden gem in the comments in the source code of Modernizr that explains how to use its .prefixed() API to make a simple wrapper around the browser-specific transition event names. Here’s how I implemented it for the transition-end event. Feel free to use this wherever you need it:

  
  

  var transEndEventNames = {
  ‘WebkitTransition’ : ‘webkitTransitionEnd’,
  ‘MozTransition’ : ‘transitionend’,
  ‘OTransition’ : ‘oTransitionEnd’,
  ‘msTransition’ : ‘msTransitionEnd’, // maybe?
  ‘transition’ : ‘transitionEnd’
  },

  CSS3_TRANSITION_END = transEndEventNames[ Modernizr.prefixed('transition') ];
  

  Bam, now we can use one simple event binding to handle all browsers:

  
  

  Stopping a Transition Early

  When the player hits the hammer-and-anvil icon during the Bonus Strike event, I needed to stop the animation early. The easiest way I found to do this, was to just set the animating property to its current value. The transition delta becomes 0, so the animation stops:

  
  

  Transition: End

  You may find that integrating CSS3 Transitions into your game makes your interactions smoother and more responsive, and with a simple API for scripting against transition events, developing against them should look and feel a lot like working in pure javascript.

  ---

  More Forging Forgecraft:

  • Introducing Forgecraft
  • A Hybrid SQL MongoDB Data Solution
   
• 

  britg 6:42 pm on May 30, 2009 Permalink | Log in to leave a Comment
  Tags: compass, css, sass   

  How To Apply Full CSS Reset on an Arbitrary Selector with Compass 

  Compass comes with a very handy utility for completely resetting the styling accross all browsers. In the author’s own words on the github wiki:

  The Reset module provides mixins that allow you to reset your html so that every element has browser-supplied no styling

  The default compass stylesheet comes with this module included, i.e. the @import compass/reset.sass you see at the top, and spits out the reset styles into the global namespace.

  But, lets say you have a separate stylesheet that is to be included on a third party domain and that is namespaced under a selector. You can still take advantage of the Compass reset styling through the following method:

  @import compass/utilities/general/reset.sass
  
  #hh
    +global-reset

  The result is the complete resetting of every child element of your namespace, i.e:

  ...
    #hh div, #hh span, #hh object, #hh iframe, #hh h1, #hh h2, #hh h3, #hh h4, #hh h5, #hh h6, #hh p,
    #hh pre, #hh a, #hh abbr, #hh acronym, #hh address, #hh code, #hh del, #hh dfn, #hh em, #hh img,
    #hh dl, #hh dt, #hh dd, #hh ol, #hh ul, #hh li, #hh fieldset, #hh form, #hh label, #hh legend, #hh caption, #hh tbody, #hh tfoot, #hh thead, #hh tr {
      margin: 0;
      padding: 0;
      border: 0;
      font-weight: inherit;
      font-style: inherit;
      font-size: 100%;
      font-family: inherit;
      vertical-align: baseline; }
  
  ...