How did you initially get into web development? How did you fall in love with it?
I was a computer programming geek from the age of about 11 years old. I started, like most, in Q-Basic, then Turbo Pascal, then C, way back in the days of DOS 5.0 pre-windows. I knew back then I wanted to be a programmer. And I'm one of the rare few who actually followed through on that "childhood" ideal.
But then in high school, I was heavily into both art (painting, drawing, etc) and computers. At one point I actually thought I was going to major in Art, instead. Then a harsh Art professor review of my portfolio towards the end of my senior year convinced me otherwise! :) So I went back to my first love. But I still wanted to be able to mix design and code, and the web was the best medium for that.
My first web development (HTML, CSS) was some small contracts for family & friends type clients (they were hideous but they still live on in archive.org), but my first big exposure was working at my university on the country's first large-scale student web portal (first written in Zope, then ported to PHP), which in part ran the first ever online elections for student government at a major university. I was hooked ever since. :)
You've worked for a number of big development organizations like Mozilla, Zynga, and appendTo. What experiences do you leave those organizations with? What have you learned by developing at shops with millions of users??
It may sound a tad harsh, but the experience I take away from those jobs was that I didn't like, nor was I cut out for, such organizations. I'm kind of a rogue, pretty direct and blunt, don't play the politics game well, and I care far more about impacting the community than impressing a boss. I sucked as an employee. And in all fairness, many (not all!) of my employers also kinda sucked. So I was better off going independent, which I did almost 2 years ago. Best "career move" I ever made.
On the other hand, I did have a chance while in those jobs to work on some projects that really had a global visibility, which I do consider to be very valuable experience. I helped build a site that launched during the super bowl, for instance. That was fun and stressful. I built the homepage for a major airline. I worked on developer tools (at Mozilla) that help millions of developers do their jobs everyday.
The biggest lesson I learned was no matter how big the audience of some site or project, what it still boils down to is that a single user, a person, sits in front of a device and interacts with something I built. Quality and care and attention and details and performance matter. That person should be delighted by what I built. In that sense, it doesn't really matter if there are a few dozen or a few dozen million of those persons who see it.
You've become a figurehead of HTML5Hub. What is the mission of HTML5Hub and how can people get involved?
As an Open Web Evangelist for the HTML5Hub, it's one of the coolest initiatives I've been part of, and a huge honor. The Hub as we call it is sponsored by Intel, who are making fantastic strides with their efforts to elevate and advance the web platform.
The goal of the site is to find and highlight the best of what the HTML5 platform is doing, but from the viewpoint of the "common man" (and woman!) community developer. There's plenty of sites to showcase the popular kids, but we wanted to find the undiscovered jewels and make them shine brighter.
We're using the site as a place to foster detailed conversations about where the web is, as well as where it needs to go, by publishing great content written by an expanding array of contributors, hosting live online round-table discussions, and, most recently, partnering with big brands to build original web experiences that leverage and stretch the limits of what interactive HTML5/JS can do.
We hope to inspire even bigger and better experiments and productions and continue to highlight the amazing things developers come up with. We want anyone who visits to feel welcome to participate in these efforts, and to that end we invite any and all developers to join us by contributing content, spreading the word, and even working on projects with us. All you need to do is speak up and let us know, and we'll plug you into this new HTML5 Revolution!
Your "Museum of Mario" project is incredible. How did it come about and what was the most challenging part of the project? How did you conquer that challenge?
Like I said, HTML5Hub is committed to pushing the envelope and challenging what's possible in interactive browser experiences across all the various devices. Museum of Mario breaks new ground as our latest endeavor, and it's made a huge splash, which we're thrilled about.
We at the HTML5Hub share a common love for early days of gaming and there is no more iconic character than Mario, nor a more deserving subject who, after 32 years of running and jumping and swimming and flying, more than deserves an amazing tribute. We approached IGN to partner with them to launch an interactive immersive anthology of Mario's history across the decades and consoles that define Nintendo in the gaming world. They were as thrilled as we were to take on such a monumental task.
We knew from day one that just any old blog post about Mario wasn't going to cut it. Far more than the words on the page, what makes Mario such a deep part of all our collective memories is the evolution of blocky graphics and quirky but memorable music. We just had to bring those memories to life with this site.
I worked with a fantastic group of developers at the HTML5Hub as well as some amazing creative designers, and Museum of Mario came to life. The biggest challenge we faced was that we refused to compromise or dumb down the experience from desktop to mobile, because we wanted to show how the web platform really is cross-device ready. It was really difficult to squeeze all that interactive experience into a tiny phone size, embrace the multi-touch tablet screens, and stretch out on sprawling desktop displays, but we leveraged many best practices in responsive design and we pushed hard to come up with a truly unified multi-screen experience. That to me is the most exciting part about the launch of this project.
Developers who've been around since the IE4-6 days have a massive appreciation for the HTML5 — we've come a long way. Where is HTML5 lacking? What should be next?
There's some easy softball answers to that question. A big thing holding the platform back is the lack of agreement over media codecs (and the bigger issue of whether DRM of content even belongs in such channels).
But beyond those political hot-buttons, I think one major lacking in HTML5 is that the markup side of the site can't perform the same sorts of "responsive" tricks that CSS can. For instance, imagine a site with markup (and script) for a panel of information which simply is hidden on smaller screens via media-queries. The fact that we can't use media-queries (or something like it) as part of the initial request/response at the server side to suppress the sending of markup/code which won't be needed means we often force way too much down the pipe to just be hidden on devices which are likely on metered bandwidth connections anyway.
The mobile-first mentality doesn't sit well with me, though, because it similarly sits at the other extreme, by not delivering content on a desktop until you make subsequent requests, which creates extra overhead and first-page-view delays. We shouldn't be doing User-Agent parsing — that's an evil legacy the web long since needs to ditch. But in replacement, server-side detection of client capabilities so the delivery payload is optimized for the device it's headed to is a big gap in the platform's ablilities, and I look forward to when that's addressed.
BTW, "Client Hints" is possibly a step in that direction, depending on how broadly they develop the idea, but this is still a major gap we need to close quickly. I really hope this doesn't take years for browsers to agree on something to move forward. It needs a fast-track.
What do you think of Firefox OS and other mobile ecosystems built on HTML5?
As someone who owned the first webOS devices and stubbornly refused to give them up until recently, even long after the HP debacle, I can firmly say I'm one of the biggest proponents of the open web platform extending to mobile OS's. I think it's got potential to be one of the most disruptive, but healthiest, changes to the landscape ever. I'm super excited about FirefoxOS.
But I have a fear. My fear is that FirefoxOS will be just another developer-experiment and won't succeed where it's predecessors failed. And here's why I think that. It has nothing to do with the technology or even the company behind it. Those are both in the best position we could hope for.
What I fear is that without a concerted effort to first lure the best user-focused content (that is, the big brand label apps) to the platform, to develop a big and vibrant user-base, the app ecosystem of FirefoxOS may struggle in the same way that webOS did: the catch-22 that developers won't spend time building for it if the users aren't there, even if they want to, because the business folks can't justify it.
This is not a build it and they will come scenario, much as we developers might like to believe. If developers build a mobile OS that's really philosophically attractive to other developers, but my kids can't play Angry Birds and my wife can't sync her exercise tracker and my grandpa can't play his satellite radio channels... then FirefoxOS won't make much of a dent beyond us webdev geeks.
I want for some company with deep pockets and a vested interest in the advancement of this platform to subsidize the development of several dozen big brand apps for the platform. Make it so lucrative that it's impossible for some brand to refuse to build for FirefoxOS. And those apps have to be as good or better quality as their Android or iOS counterparts. We have to break the catch-22 by bringing the users first, so that developers will not only love the theory of a web-platform OS, but they'll have the business excuse to actually spend time building for it!
And oh yeah, as one conference audience member recently said so astutely, there's gotta be a gold FirefoxOS device. That's a must!
When we started as web developers, browser support for given features was crazy. Each browser was implementing their own APIs and we were adding "best if used in" text on websites. A decade on, how do you feel about the browser landscape?
The browser landscape is in good shape. That's not the issue. Developers are still in some sort of drunken hang-over from the IE6 days and refuse to let go of the obsession over browser version support. They can't see the version is an arbitrary marketing label. They only recently started trying to feature-detect, and we've still got the unfortunate legacy of hundreds of millions of lines of non-feature-detected code hanging around. That's gonna take a long time to retire.
But more importantly, we as developers let others who don't understand our platform dictate to us false premises like "the site/app has to look, feel, and behave identically in all browsers and versions". This is as toxic lie and misdirection of the web platform as there could possibly be. It's wasting untold amounts of developer talent trying to back-fill functionality/UX into older browsers. I feel like any other software discipline would laugh at us for such folly.
We have to stop developing 10 years in the rear-view mirror, and instead embrace where the platform is, and where it's headed. We have to embrace and celebrate the diversity of web experience across browsers and devices. We have to learn to delight users with what the web can do, rather than entertain foolish notions of "backwards compatibility" by hacking old browsers into faked conformity. We've got to fight for user democracy — the user has the right to choose which browser they want to use to experience the web — instead of thinking we as developers have the right to dictate their experience.
And most of all, we need to grow the confidence and nerve to push back on our clients and bosses and marketing departments when they try to feed us these lies veiled as "requirements". We have to have the courage to refuse, and walk away, when someone tries to force such platform regression. The web is where it's at now and where it's headed, not where it was a decade ago. Hear more about why I say "Browser Versions Are Dead".
LABjs was perhaps one of the first widely deployed general (non-framework) script loaders. But it didn't start out that way. I accidentally fell into that position. I built LABjs as an experiment for an employer implementing a SPA-type app, needing the ability to dynamically load scripts. Somewhere along the way, it actually became a great way to optimize not only dynamic loading but also initial page-load loading.
Within a few months of LABjs becoming popular, about a dozen other projects sprung up with variations in APIs and packaging. Unfortunately, and still to this day, none of those projects' authors seemed to care (aka, obsesses) as much as I did about all the niche and corner-case issues around generalized script loading. Loaders that took short-cuts or made simplifying assumptions about various use-cases were very common. Also, it was very common for someone to just want to offer a different API to LABjs, but in so doing, they failed to provide the same robustness of loading capability.
To this day, I still wish projects had chosen either to implement the fullness of general loading (including the various "hacks" necessary for legacy support as well as the new "standardized" stuff like "ordered async"), OR they had just wrapped LABjs as it stood in a different API. It was very unfortunate to see a lot of, for lack of a better term, cheaper knock-offs, to the detriment of the community.
Along the way, the obsessions I had over script loading dropped me smack in the middle of a minor "crisis" where browser updates broke all of dynamic script loading's assumptions, meaning LABjs (in use at the time on some major sites like Twitter) was dead in the water. Months of negotiating and flat-out begging against the spec process and various browsers finally settled on "ordered async" (
async=false) as the 80%-use-case standardized compromise. That was standardized as a result of my efforts, and now appears in all major browsers, so I'm proud of that one tiny little contribution to the platform. :)
Many people think the age of script loaders is (long) over, because of the "concat all files into one" performance mantra. Interestingly, though, HTTP2.0 will be out soon, and once it arrives, I'm predicting the age of script loaders is going to be re-born. Here's why: in HTTP2.0, having one big file is way less performant than lots of tiny files. So we're going to stop doing script/CSS concat, image spriting, etc. That means developers are going to have a choice: go back to "script tag soup" with dozens or hundreds of script tags, or use script loaders and/or dependency managers.
We'll see how things play out, of course. But I think a lot of the community is are going to have to revisit script loading before too long. LABjs, for its part, is still around, still maintained, and still stable. It's ready to help optimize site script loading for anyone who's looking.
Have you kept up with the Promises proposal? What are your thoughts on its direction?
I think promises are a really good solution to asynchronous flow control. But I think most people misunderstand what that's all about.
"Callback Hell" is not, as you might have been led to believe, about nesting/indentation of nested callbacks. It's about inversion of control, where you have to hand complete control of your "next step" (aka continuation) of your code over to some other utility/method. You hope it will execute it not too early, not too late, not too many times, not too few times, with proper/expected parameters, and hand you back the return value in some way. That's an awful lot of trust (aka loss of control). AND it hard-codes your flow which makes it much harder to respond to errors, perform re-tries and timeouts, etc.
Promises are a pretty elegant solution, because they invert the control back to your code. Instead of asking some method to execute your continuation, you ask to be notified (event handling ftw!) of when that step completes, and then you decide what to do next.
That having been said, I do not like how promises have had to become some rigid standardized thing to be useful, to the exclusion of any other "promises like" approached that pre-dated the standards efforts. To me, promises are pattern, not a prescription. I have a promises-like library called asynquence that I first built several years ago, that attempts to make working with promises a little less cumbersome. But it's not "Promises/A+ compliant" and so it's now automatically a second class citizen. Look at how some Promises/A+ folks are so derogatory toward jQuery's "non-standard" promises. As if exploring the pattern from many angles is now a bad thing and we all have to cookie-cutter identical.
The worst sin of all was the decision to assume that any object which has a
then() method is a "Promises/A+ compliant" promise (aka "thennable"), essentially just ignoring those of us who already had utilities with
then() on the API. There were other options, and any of them would have been better than where this particular dumb compromise landed. But...whatever.
Promises are super powerful, and they get even more powerful when we layer in the power of generators coming in ES6. We've barely just scratched the surface of those combinations. I will continue to explore, and I'm not all that concerned about lack of "standards conformance". I see that as a positive, not a negative.
What projects are you currently working on?
Some of my favorites I'm tinkering with these days:
- asynquence (async flow control)
- grips (templating)
- let-er (ES3+ let-block block scoping transpiler)
- literalizer (heuristic lexer for JS)
- esre (JS code style formatter)
It actually probably springs from my time as a UX Architect. I realized that UX is not just about design and interaction, but also about, importantly, performance. Being able to crowd-source performance testing across a variety of devices, browsers, etc was a huge boon to being able to do mature performance optimization decisions, rather than just guessing or blindly citing common "performance myths".
I'll be honest, though: recently I've been thinking that we're far too myopically focused on micro-benchmarks. Just because you see some operation X is 10% faster than Y, in isolation, doesn't mean that X is better for your app across the board. Optimization is far more affected by the holistic performance profile of your app, because the modern JS engines are far more sophisticated than we realize.
Trying to construct a test to isolate and even "defeat" the engines' performance optimizations so you can then take a 4 micro-second duration task and extrapolate overall performance metrics on your app, is just... silly. We need to take a step back and realize what makes a good jsPerf test and what is just junk-science. We have to test real things in our code, things that "take awhile" to execute, not isolated micro-benchmarks.
Two quickies: anonymous function expressions. There's just never an excuse for using one. Always name your function expressions. Period. Better stack traces, better code maintenance. No downsides. No, I don't care if it leaked memory in IE6. You've got far bigger problems in IE6 than that niche issue. Name your function expressions. Always. And btw, stop doing so many inline/lamba functions. Just because you use jQuery doesn't mean every function needs to be an inline function. First class function declarations usually make for clearer code. And they are already named!
Also, stop trying to mix lexical closure code (aka, the module pattern, etc) with
this-based coding. They are two separate orthangonal systems, with pros and cons to each. Pick one or the other for any given piece of your program. If you find yourself doing crap like
var self = this all over, you are (probably) doing it wrong. That's cheating
this binding mechanisms and falling back to lexical closure. That's the hard way. Learn
this, and learn lexical scope, and use one or the other, but don't mix them.
ES6 (and ES7, it seems) are making some huge changes to our language. Some of the additions are wonderful. Block scoping is great (except for the fact that they made the bone-headed decision to opt-out of the better let-block form of
let). Array comprehensions, modules, etc. Those are all great. But
class is downright ridiculous. See my "JS Objects" write-up to see why. Arrow functions are basically
var self = this which I just covered — they look good on slides, but I think they make for worse code in reality.
But my beef with some of the new stuff isn't an indictment on the language or its maturity. It's evolving, and some of that will be good and some of it will suck. I wholeheartedly praise the TC39 committee for pushing our language where it's headed. We need progress, and most of what they've come up with is really great. I can't hold their mistakes against them! :)
The real problem is that the majority of JS developers don't understand the ES5 (or even ES3) of the language yet. They know enough to write code for their job, but they haven't taken the time to understand
prototype, closures/scope, etc. When they layer on ES6 and beyond, it's only gonna get worse. Developers need to take more seriously the depth of the task of learning JS.
Those who do are rewarded with an incredibly rich and vibrant language, with lots of hidden power. They get to shuffle off the trite sound-bytes of "The Good Parts" and actually learn "The Tough Parts" so they can use all of what JS has to offer. I wish more developers spent that effort before they tried to embark on weighty/complex decisions like "Angular vs. Ember vs. Backbone".
Server-side JS is huge. It's massive. It's a big part of the reason JS has become the most ubiquitous language on the planet and far supplanted Java and the JVM as the universal target. I don't know if Brendan Eich imagined that JS would show up inside of lightbulbs someday 20 years down the line from his invention, but it was definitely some accidental genius. And we also have to owe a lot of credit to Ryan Dahl's choice of JS for his node.
That having been said, I'm not totally convinced that node.js is the ultimate in server-side JS. It's awesome and I use it every day. But I think it's an interim step. I think the next step is JS based operating systems. I'd like to see someone actually build JS into a deeper layer of the server stack, maybe even (crazy!) down at the kernel level. We're doing JS-as-OS on mobile phones. It's time we see that happen in servers as well.
The more we can start to treat JS code as just code and not as "front-end" or "back-end", the better. The best apps shouldn't care where their code runs. Those decisions should be made on the fly, responding to performance and other conditions. Years ago I talked about "middle end" app architecture as embracing JS that runs in both client and browser, and today I still feel like we're just digging into that potential.
Such efforts are going to even further erase the lines between client and server, to where it won't matter anymore. That kind of thing is nothing but healthy (and exciting!) for the future of being a JS developer, IMO.
What advice would you give to new developers? How can they become the next Kyle Simpson?
Definitely don't become the next Kyle Simpson. It's lonely being the fringe rebel and trying to make enough waves to cause change. But it is worthy work if you can stand it. :)
My best advice for a new developer is somewhat unconventional, as are most things I say. The common wisdom is to be a generalist and get as wide a variety of experience as you can. I think you should instead experiment around until you find one technology that you like and are good at, and then specialize in that for awhile. Not forever. But really take the time to learn it inside and out. I think mastery is a lost art. We're all, as a community, too scatterbrained with hopping between a dozen different things.
When I meet people out in the community on the road, or when I was in a position to interview people at my previous employments years back, I was always far more impressed by someone who deeply knew at least one thing, than by someone who broadly but barely knew lots of things. Find one thing you're good at, and strive to be the best at it. That'll eventually garner the respect of your peers, and once you have that momentum going, you have the freedom to explore and master other things.
Also, foster and encourage open development (always write your code, from line 1, on github if you have the option!). And be creative with your solutions and your problem solving.
What are you working on these days? What can we expect from Kyle Simpson in the future?
By trade, I spend a lot of time teaching workshops (on JS, HTML5, etc) and speaking at conferences. I also work on book writing (well, I pretend to have time for that, anyway!). I generally try to work as an independent (self-titled) "Open Web Evangelist" and promote the open web platform as best I can to as many as I can.
But in between all that, I still tinker on a variety of OSS projects on github. I've been working on a templating engine (for both HTML and CSS!) called grips and an async-flow-control helper called asynquence.
Most recently, though, I've been experimenting with new kinds of code tools. I'm exploring different approaches to JS code parsing (what I call "heuristic lexing"), building code-transpilers, working on tools for code-style formatting, and pushing for better standardized parse-tree representations to enable more sophisticated code analysis and transforms.
All that stuff is part of a loose grand vision I have for developers for optimizing the language they write in to best suit their own style. It's some pretty crazy and ambitious stuff, but that's what keeps me hacking these days.