HTML5 Developer Conference, San Fran 2012

My notes from the #html5devconf in San Francisco, CA on Monday, October 15 & Tuesday, October 16 – 2012.

Cache is King

9:00am : Keynote
Steve Souders from Google

My Ramblings

  • mobile connections are high latency, duh
  • last modified & etag
  • conditional get requests suffer to latency, it’s still a request
  • cache-control/max-age: max seconds before checking
  • if you change the file: change the name (a la cdn)
  • cache-control: max-age=0, must-revalidate, no-cache – always new file, ALWAYS
  • cache deliberately!
  • heuristic cacheing: a “freshness lifetime” some fraction (10%), fraction of time since last modified
  • bringing it home (w/love): mostly good, but some that demonstrate ambigious caching (by doing nothing)
  • oooh app cache:
    • if anything is 404’d – nothing is cached
    • ~5mb
    • must update manifest AND resources (right)
    • takes two reloads – yes. app cache isn’t the shit it’s cracked to be
    • the point of apcache: touch the network as little as possible
    • updateReady work around for load twice issue
  • stick code in localStorage? WAT?
  • browsers will get smarter with local preferred caching. that won’t help us though.

My Summary

The cache IS in fact king, and while many many things matter payload size, number of requests, execution time, etc – not having to fetch something is faster than having to.

Browserify – Use Node Modules in the Browser

James Halliday from Browserling

My Ramblings

  • npm is amazing – don’t forget! 16k packages
  • “make crazy mad science happen”
  • node modules return values, don’t modify context
  • require is the other side of the commonjs
  • browserify will recursively traverse the entire dependency graph
  • can also use node core api –watch and save as you will
  • huh: you can require a json file with node and it returns the object back to you.
  • jsonSTREAM would allow us to only parse what we want from bloated json responses from the server.

My Summary

It sounds super awesome to do this. If we could get our backend to node, we might totally do this. Also, James/Substack totally comes across as a super genius; In the good way.

HTML5: Postcards from the Bleeding Edge

Peter Lubbers from Google

My Ramblings

  • wifi dead – couldn’t note take, but this was more about building websites than games. in fact, most of the new apis and such discussed aren’t supported on mobile yet anyway.

My Summary

As noted above, this is more relevant to desktop, mobile is out for now.

What You Could Have Built With HTML This Whole Time

Stephen Blum from PubNub

My Ramblings

  • html has perceived limitation.
  • this talk has an actual limitation

My Summary

Maybe it was an off talk/day or something, but this presentation came across as more about promoting the company than sharing.

Single Page Web Applications: JavaScript End to End

Josh Powell from Rocket Fuel

My Ramblings

  • this talk is packed
  • general info about what a SPA is (single page application), perks:
  • distributed load, one language, one data format
  • “all javascript, all the time”
  • cons: back button, search, messy, analytics, sense of errors on client side, approach:
  • back: use history api & hash (onhaschange)
  • search: use #! & ?_escape_fragment_=key=value
  • messy: use patterns “do the work”
  • analytics: do the work to GA api
  • exceptions: throw errors somewhere (airbrake, bugsense)

My Summary

It was srsly hot in this upper room. The talk was solid, tech focused, and relevant. It was short though, only 30 minutes. Might be worth buying the book.

When I start a company.

  • Do not get an office.

    Use communal spaces for times we must meet and work in-person. Use the internet and computers for everything else.

  • Do not get phones for people.

    If people don’t have phones, they don’t need one. Use their personal numbers.

  • Do not buy “company” computers.

    Give them a stipend to buy their own machine or they can use one they have. You wouldn’t be hiring them if they didn’t have their own machine.

  • Do not get business cards.

    Use peoples individual cards. If you’re the founder, then your personal card probably has the business logo on it.

  • Use google apps.

    To get your names at your domain. but just forward that to individual email addresses.

  • When we need to meet with clients.

    Take all the rent for an office and shelves and such we’ve saved, and go to a swanky place. or a dive bar.

I think the point is that the individual brand is here. When you hire someone, you are hiring them. The people they know. The brand they have and are. Don’t spend all this time building up a facade brand of the your company version of said person.

CSS Vendor Prefixes!

Updates Again

So @t (Tantek) via a @meyerweb @alistapart interview: This is the key point

“In addition, we are considering only supporting the -webkit- prefixed version of a property if and/or when we also support the unprefixed version.” Where we is Firefox Moble.

@meyerweb delivered a great interview, asking simple, pointed questions that needed to be asked. And @tantek did an excellent job answering them directly. All in all, it makes the kerfuffle over this seem a little less relevant, or does it? I take exception with a few assertions.

  1. “When users see a substantially worse experience in a different browser on the site on the same device, they blame the browser, not the site, nor the device.”: Um, most users don’t know what a browser is, much less have multiple ones installed on a mobile device and know enough to blame one over the other.
  2. “Should we give up on vendor prefixes now, despite their imperfect but impressive track record?”: This was asked by Tantek. Is this a joke? No. Of course not. The implied meaning here is unclear to me.
  3. “As web developers, there are few key things we can do…”: And then goes on to list things, which, as far as I can tell, are what developers should be doing anyway.

While I do agree that the responsibility for doing things right and doing the right things falls on developers, this whole things is starting to feel like Mozilla/Firefox Mobile whining.

Here is the problem: Supporting another agents vendor prefix takes away the ability of the developer to control (by virtue of which prefixes are implemented) which agents receive this information.

  • Developers: Keep doing your job. CSSWG nor Mozilla cannot make you do or not do it well.
  • CSSWG: Don’t bail on vendor prefixes.
  • Mozilla: Browser-up.


@plniss clarifies:“Having a vendor prefix in a specification will simply not happen, ever. What has been discussed is simply adopting the WebKit implementations of those properties as the standard, however the standardized properties will not have the -webkit- prefix.”

Huzzah! Furthermore:

“The issue here is other vendors implementing support for -wekbit- prefixed properties in direct violation of the standards.”

#word However, the CSSWG can’t make browsers not do stupid things.

@ppk sounds off: – I disagree with the idea that developers aren’t responsible and love the idea of -beta- prefixes.

@dandean pointed me to this: – #word. Also, -beta- would be better, though responsibility stays in developers hands.

@catalinred retweeted: – more of the same responsibility song. #like


The more I think about it, -beta- would have it’s own challenges. Sure, we’d know we’re doing something experimental – which is good, but it would prevent us from targeting specific user-agents, or NOT targeting them. That would kinda suck.

I’m still sorting through all the articles posted and the initial discussion, and while certainly folks have passionate opinions – which is a good thing! – perhaps things will look better in the morning. After a breath. After a snack. How I would love some toast right now.

There’s, and, and, and, and, and the original discussion.

Btw, how fantastic is it that this discussion was so published? Huzzah for standards bodies! And also for everyone sharing their thoughts and participating. Not to be too much of a Gumdrops Gary, but this whole process is awesome. It’s the future of humanity. #theInternetWillSaveUs

If you haven’t watched the When We Build video, do so.

It is our responsibility as designers and developers to do the right thing. We know how and the resources from where to grab the stack of vendor prefix fallbacks that covers our targeted user agent audience, and remains standards compliant (using the non-prefixed versions).

Standards bodies are here to slow everything down a bit. Not be so hot-headed. To establish a path that will endure. Browser/Agent makers are here to meet the needs of the now. Implement all the newest proposed features. Make up new features. This creates an inherent tension between the two. This tension is good. And designers and developers have the glory of deciding how to proceed. What to implement for whom based on their target audience.

Being a designer/developer really is the best job.

It seems some respectable folks are coming down on the side of doing away with vendor prefixes. I don’t understand that. Though, to be fair, I’m not respectable. If browsers/agent makers are threatening to shoots the standards body in the head (by incorporating support for vendor prefixes explicitly), is it really a rational response for the standards body to shoot itself in the head (dropping vendor prefixes altogether)? I don’t think so.

The standards folks can’t stop browser/agent makers from doing something stupid.

I have found this vendor prefix route to be far superior to what we used hafta do, what with comment escaping hacks, or relying on the incorrect implementation working correctly in it’s incorrectness. Bleh. That sucked. Prefixes are much better. Plus as the path for the future gets rolled out, ever onward, and old prefixes fall away in favor of supported implementations, they do no harm. We should still remove them anyway.

The standards folks can’t stop designers and developers from being lazy.

These things we build are alive. The go on and on. They require love. The need to be pruned at the right times and for the right reasons. Designers and developers who aren’t doing the right thing won’t be designers and developers for too much longer. Putting code in production on behalf of clients for the world to consume is a sacred trust. We are the defenders of how the new world will be. It is a total rush. Even when it is tedious.

Hopefully everyone will take a day off from this sensitive area. Do some work. Read. Whatever. And come back to this when you’re feeling calm. It’s natural to get heated over this – it is important. But let’s not do anything rash.

We are where we are because of the path that lies behind. Let’s try to remember that.