JavaScript Insights at HTML5 Dev Conf

A few months ago, over chai freddos with my friend Ariya Hidayat, I was considering what a good, comprehensive toolkit for JavaScript looks like — I wanted to know what set of tools Nicholas Zakas uses, for instance, at Box. And I thought, at the time, that it would be great to work on a significant product to be able to develop such a tool kit. Now that I have my new job, I’m in a very good place to do that. It’s a “careful what you wish for” moment.

Fast-forward to tomorrow, Ariya and I are co-presenting a talk at the 2013 HTML5 Dev Conf called JavaScript Insights. It’s an experiment, and I hope it goes well.

Ariya and I have very different backgrounds — geographically and professionally — but we are very like-minded. For example, we share the opinion that web development is a mess, it could be much better, and we like to find and suggest improvements for how we make software for the web. In essence, Ariya and I are best practices geeks.

We’re interested in web performance, but also maintainability, developer velocity and happiness. We want better lives for web developers. How do we make that happen? We find, make, and offer tools.

The presentation is distilled from one that Ariya has been giving for a while — a talk full of value and possibilities. This is our culling and organization of that content — I hope we’ve made it more palatable and practical.

And if I’ve made a mess of it, it’s only because tools for JavaScript are all over the place. It’s a challenge to deliver this content.

Our responsive images solution, we have

Images are the bulk of what we move around the web; they comprise over 60% of the average web site’s payload. (Latest HTTP Archive stat: 61.3%)

Different use cases would ideally be served different image resources (“responsive images”). For example, a 27″ iMac plugged in to a company network can make use of a large HD image, but a Blackberry in a desert with a spotty wireless signal can’t. If you serve a large image to the Blackberry in the desert, the user might not get anything.

And what if the person with the Blackberry is bitten by a snake and needs to identify it as poisonous by sight? He finds the page of poisonous snakes but the photos are too big for his phone and connection. Maybe he sees one or two poisonous snakes, but not the deadly one that bit him. He dies. The man dies!!!! (Fool shouldn’t have had a Blackberry. Anyway…)

poisonous snakes

This is an improbable situation, and kind of silly. But we can easily think of more dire and practical examples. Basically, the content of the Internet can be useful in remote and / or time-sensitive situations.

For web developers, focusing on the problem of delivering images in 2013 is a worthy subject to noodle, especially if we are concerned with performance. In this area we will find our biggest wins — where we can offer the most value and make the biggest improvements — UX-wise and performance-wise.

So how do we solve the problem of responsive images? There are many ideas and opinions — hard work and good stuff. Here’s a comprehensive run-down with links to resources. Generally the tack is to serve up different versions (sizes) of an image, some with different crops, perhaps, that might be more suitable small screens / low bandwidth.

But all of the current offerings have drawbacks. They use a new, unsupported element (picture), or a new, hardly-supported attribute (srcset), or JavaScript (not appropriate), or a third-party service — or a combination of these. And often we can’t avoid having multiple copies of the image download; while trying to conserve the information we send, we end up delivering more.

The biggest flaw of this mode of thought — selectively serving more appropriate images — is not poor support, or using the wrong technology for presentation, or trying too hard and shooting ourselves in the foot. It’s that it puts the burden of the solution on the content producer.

Not only is this unrealistic (few will do this extra work), but we should not raise the bar for anyone wanting to put a picture on the Internet. If the solution involves serving more than one image, it will never be elegant. But more importantly, it will never be practical.

For those of us who really care about this subject, the lure of a responsive images solution is like a candy house that we can’t help going into. But it’s trouble.

If we take a step back we can imagine what would really be nice: a responsive image file format that contains different versions of the image — a storage locker, as described by Christopher Schmitt. So tidy! And if our image editor could generate this file for us — nay, if this was the default for our image editor — that would require the least amount of work. We’d actually do it.

But new image formats don’t come along every day and many years must pass before there is wide browser support. We don’t currently have images with different copies of the image or…hold on…wait. Don’t we? Isn’t that what a progressive jpeg is?

Yes! The man lives!!!!

Problem solved, at least on the producer side. Yoav Weiss, an images+performance expert, talks about this possibility on his blog, exploring a scenario for a technical implementation. This is a eureka moment. We know it is possible because it’s observable; browsers download and display the first scan of a progressive jpeg before downloading the whole thing. They just need to calculate when they have sufficient information and stop.

Web browsers know more about the system they are installed on than content producers do, obviously. And knowing details such as screen size, pixel depth, and having a means to anticipate network speed and stability put browser vendors in a much better position to solve the problem of responsive images. Browsers want to be fast. It’s their most desireable quality and it makes them competitive in the market. If the problem of responsive images is a big issue for us as developers, it’s also a big issue for browser vendors for the exact same reasons.

Today we can offer videos and know the browser will not download the whole thing, blocking content. What is the difference between a video and an image, really? Why can’t we serve an HD image the same way, especially as the craving for HD images grows?

Now here’s where I really get in trouble by taking this idea to it’s most extreme place: someone who wants to share an image should be able to provide one that is carelessly large — as big as any end user can use, today and in the near future — without worry. Someone wanting to share an image should be assured that the web client will download only what it needs. “Joe Photographer” shouldn’t need to know anything about responsive images.

Remember when people used to email digital photos and it would clog your inbox and you would say “Stop doing that!” and hurt their feelings when they, in their ignorance, were just trying to share with you? Technical limitations made us jerks. My mom shouldn’t have to edit in Photoshop. My mom shouldn’t know about Photoshop. And I should be nicer to my mom.

The image exceeds the size Save for Web & Devices was designed for

The Internet Protocol of August 1979 refers to the robustness principle which basically says that a client should be liberal about what it receives. Specifically that it “should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear).” It might be stretching it to consider images “datagrams” and a poorly sized image as a “technical error.” Or is it? Regardless, it’s a fact that we do not include images among the things we liberally receive.

We should either change our philosophy and say we’re “liberal about what we accept, with the exception of images” or we can keep our philosophy and include images. And while we’re at it let’s make setting “height” and “width” with pixels obsolete — at least for web content producers. (Can we do this?! Hm…it will take a bit more thought.)

With progressive jpegs we have our foot in the door. Browser vendors can choose not to implement new solutions — new markup and attributes — but they can’t take something away from us that we’ve always had. We must not forget we have progressive images, they should always be the default for the web (why aren’t they, Adobe Photoshop?), and browser vendors need to focus on using progressive images as responsive images.

The problem with the direction that I’m advocating for is that it’s out of our control and we need to wait for a better implementation. And how can we wait, when this is one of the most important problems of web development? As long as we know our ultimate direction, I think it’s fine for us to create and use temporary solutions. That is, it’s fine for us to go into the candy house, as long as we remember that it’s not our house.

In summary, it should not be the responsibility of the content producers to discover the screen size, pixel depth and network connection of an end user and serve up a custom resource. This is information the client knows best. We should pose questions to browser vendors, and if there are any gotchas with the technical implementation of using a progressive image as a responsive image, we should better understand why.

I would love to get your feedback on this subject and I encourage you to disagree with me. I’ll get the comments fixed on this blog and respond to all. Please email me at nosbora at gee -mail period com.

more to think about: Daan Jobsis discovered that you can increase the size of an image while also increasing the compression and you get a smaller image that looks good on both standard and retina displays. The resolution is higher, the file size is smaller, and it looks great everywhere. More pixels cost us less. What?! Forget what you know. Even without progressive scans we can have faster, higher-resolution images. We should not be afraid to offer more pixels.

Three options for sharp, responsive logos

Web developers and graphic designers don’t like to see blurry logos, like we often see on retina displays. Generally, we will “fix” a unsharp logo by serving a PNG that is twice the resolution. This is a decent solution, but not an ideal one. Rasterized graphics will always be resolution dependent. Logos, in particular, wants to be what they are: vector, or line art. Here are some suggestions for making a logo crisp and responsive:

1. Icon Font

If you’re already using an icon font, and your logo is a single color, and it’s not too complicated… just add your logo as a glyph to the font. This is my favorite solution because it’s *free*; you don’t need to make an extra request, and your font file will not grow substantially.

2. SVG

Some people think “Dammit, why aren’t we using SVG already?” To me, SVG is like a very nice, but not perfectly ripe, fruit. Here’s why:

  • You need a fallback for IE 8, and maybe previous Android (but fallbacks are easy)
  • It’s an extra request OR an un-cacheable inline graphic
  • SVGs saved out of Illustrator are generally much bigger than PNGs, and need special care — for example, refined bezier curves — to be decently optimized

Once you put the effort into making an SVG logo, you can do special things with it, like style and animate with CSS.

3. @font-face

You can also load the font that your logo was created in, and then display it as text. But it may not be that easy, or an option. Branding is very particular, and logos often have special kerning between pairs of letters, as well as custom glyphs and art. It’s not always feasible to reproduce some logos as text. I see that the css-tricks logo is simply text with a font applied, but that font is also used in the body — they get it for free.

(One last idea: I suppose we could combine #1 and #3 and include the specific letters that make up a logo as glyphs in an icon font. That seems messy and perhaps is trying too hard. Let’s NOT make that #4, but it’s an interesting idea.)

There you go. Exploring one of these options is a bit more work than adding an additional, higher-res PNG, but the reward is a very flexible resource: a single, ultra-crisp logo in any view.

New Proposed Tests for YSlow


YSlow is one of my favorite open source projects. It tests web pages against a list of web performance best practices, and it can be run in a number of ways: as a browser plugin, from the command line, and as a bookmarklet on mobile devices. Also, it can be entirely customized for our needs; we can set the weights of tests to match our standards for a specific product, and we can add our own tests.

YSlow identifies our biggest wins; it tells us what we should improve first. We get lost in the details of our craft and YSlow helps us see the forest for the tress. It should be in every web developer’s toolbox, and included in a product’s deployment process to catch performance regressions. Here’s how you can add YSlow (with Phantomjs + Jenkins) to your continuous integration pipeline.

But the reality is that we don’t use it and most web sites suck in very basic ways. (A good web developer can look at almost any source code and immediately identify many things that can be improved.) Therefore I think we should champion YSlow in the web development community; we should use it and contribute to it.

Web standards evolve, mobile explodes, and we reconsider the way we do web development every day. Common mistakes are a moving target, and our best practices change. Occasionally we discover a new best practice.

It’s easy to think of things that might be added to YSlow. Here’s a quick list:

  • Progressive jpegs are used, instead of interlaced. (possibly with FileReader:
  • @import avoided
  • JavaScript functions are not declared twice—indicates duplicate code
  • IDs are unique
  • suspiciously nested tables: indicates tables were used for layout
  • document.write() avoided (in JSLint?)
  • suspicious number of small images used: collect small images in a sprite, use an icon font, or leverage CSS for presentation.
  • Split Components Across Domains (why couldn’t this be added?)

Better tooling for web developers

(UPDATE: Here’s the evolution of this topic from Paul Irish. Excellent developer tools are being developed all the time. Paul Irish on Web Application Development Workflow)

Here’s a great video collecting ways to be efficient by Paul Irish. He’s promoting something called Yeoman which is a web dev bootstrapping project.

Highlights include:

  • LiveReload (changing a file on the desktop and the browser refreshing for you (!!!)
  • Inline JavaScript linting with Sublime
  • SourceUrls for compiled coffeescript in developer tools
  • Many ways to test: in browser, on command line, post push, in the cloud for every device….

Yeoman does a ton of stuff, although there are other ways to accomplish those same tasks: compress images, auto-update external libraries, minification

Sublime Text 2 alone is a huge leap forward as far as tooling goes. I just started using it and I don’t know how I ever lived without it.

With ZenCoding you type:


and it becomes

<div class=”test-zen”>


The video has a huge amount of “stuff.” Adopting these tools and changing one’s habits takes effort, but doing so is definitely a level up.

JavaScript is hardly ever your web performance bottleneck

I’ve noticed that it’s common for web developers to charge ahead with the assumption that JavaScript is making their web application slow. While poorly-tuned JavaScript might contribute to performance issues, most of the time it’s minor and distracting developers from bigger, simpler wins.

Make sure you check off all of the web performance best practices before performance-tuning your JavaScript; serve everything gzipped, avoid redirects, fully optimize images (smushit), include JavaScript at the bottom of the page and definitely after CSS, combine and minify css/js…etc.

Here’s the original Steve Souders list of best practices and an extended web performance best practices list from Yahoo.

Also install and use Google Page Speed Insights in your browser. Google has an ulterior motive for helping you make your site faster, so you can rely on that advice.

You can also use FrontendTest as an additional weighted web performance audit.

If you’re working on a JavaScript framework or very commonly used plugin, like JQuery or something, that many people use, well then go ahead and tune your JavaScript. Are you John Resig, for example? Probably not. Please use web performance best practices to make your site faster.

Another Responsive Résumé Template

I’ve been wanting to share the HTML5 responsive résumé I built from scratch, but I hemmed and hawed thinking “Who even codes HTML resumes anymore? Don’t people just fill in their LinkedIn profile?” But hang on! It IS important. If you are a web developer and you want an awesome job at some super cool startup, then your resume should look good, even on a phone, and your source code should be HTML5 and marked up with semantic value.

And just as importantly, if you’re an employer, you probably want to view source on a web developer’s résumé.

I was validated by A List Apart when they published A Case for Responsive Resumes and instad of thinking “Oh, well, it’s been done”, I’m finally sharing mine also, because there can never be enough responsive résumé templates.

You can download the files from github like this:

-> mkdir resume
-> git clone resume

Here’s my live responsive resume.

Here’s a link to the template that you would customize: template.html

To customize the template, simply replace whatever appears in braces — eg. {Your Name} — with your information.

Here’s an example desktop screenshot:
Responsive resume example desktop view

And here’s an example phone screenshot:
Responsive resume example mobile view


Replace images with CSS gradients for striped backgrounds

One of the easiest and most effective ways of speeding up a web site is to replace background images with CSS3. Currently I’m exploring, and trying to have a very good understanding off, all the ways we can use CSS3 to create layouts instead of resorting to using images that create http requests and slow down pages, especially on mobile devices.

The site I happen to be working on has three different backgrounds with vertical stripes. Figuring out how to replace the images it currently uses with CSS is a big win, provided that the size of the CSS required to create these backgrounds is not prohibitively large. (Background images tile and can be very small files — it’s the http request for the image that is more expensive in terms of performance.) In the case of stripes, the CSS is small.

So how do we make striped backgrounds with CSS? The place I looked for and found the answer is Lea Verou’s CSS3 Patterns Gallery. This gallery blows my mind with the possibilities of how to use CSS3 gradients to make backgrounds. What I’m doing in this example is relatively very easy; the gallery includes plaid, hearts, checkerboards and many other cool patterns.

As far as I can tell, there is no easy way to copy the cross-browser CSS from the gallery. Therefore I’ll provide it here, and show you how to take thick gray lines and create other colors and widths.

Here’s Lea’s vertical stripes background and the code to create it:

.verticalStripes {	
	background-color: gray;
	background-size: 50px;
	background-image: -webkit-linear-gradient(0, transparent 50%, rgba(255, 255, 255, .5) 50%);
	background-image: -moz-linear-gradient(0px 50%, transparent 50%, rgba(255, 255, 255, 0.5) 50%);
	background-image: -ms-linear-gradient(0, transparent 50%, rgba(255, 255, 255, .5) 50%);
	background-image: -o-linear-gradient(0, transparent 50%, rgba(255, 255, 255, .5) 50%);	

The backgrounds I need to re-create are blueish with very thin, subtle lines. Here’s a screenshot of one of the replaced backgrounds with the code.

.verticalStripes {	
	background-color: #99d0d4;
	background-size: 10px;
	background-image: -webkit-linear-gradient(0, transparent 90%, rgba(255, 255, 255, .25) 50%);
	background-image: -moz-linear-gradient(0px 50%, transparent 90%, rgba(255, 255, 255, 0.25) 50%);
	background-image: -ms-linear-gradient(0, transparent 90%, rgba(255, 255, 255, .25) 50%);
	background-image: -o-linear-gradient(0, transparent 90%, rgba(255, 255, 255, .25) 50%);		

It’s easy to take these examples and create variations. Here we are taking one color, and putting a transparent sheet of another color on top, shifted X percent. In the blue stripes example, the total width of the repeating background is 10px and the part of it that is overlapped with transparent white is 10% or 1px. We could replace 90% with 9px if we wish, but using a percentage here may be more maintainable.

What if we want two different colors, not a color and a shade of the same color? We can just take our transparent sheet and put another color, not white, on top of it. Here I’ll make red and purple stripes using red as a base color and blue as the overlay.

.verticalStripes {	
	background-color: #ff3300;
	background-size: 50px;
	background-image: -webkit-linear-gradient(0, transparent 50%, rgba(0, 0, 255, .5) 50%);
	background-image: -moz-linear-gradient(0px 50%, transparent 50%, rgba(0, 0, 255, 0.5) 50%);
	background-image: -ms-linear-gradient(0, transparent 50%, rgba(0, 0, 255, .5) 50%);
	background-image: -o-linear-gradient(0, transparent 50%, rgba(0, 0, 255, .5) 50%);	


As you can see this is very flexible. I’d challenge you to find a striped background that can’t be replaced with CSS. If you want red and green stripes, you might need to find another solution, like a background image. But if you want red and green stripes — the idea alone gives me a headache — you could be deliberately punishing your user anyway, and you might further torture them with a slow page.

File under: big wins.

I Heart My Robot:

Woohoo! I made the leap from web developer to entrepreneur.

I’ve created a web app for testing front-end code that I’m hoping I can one day soon call “The most comprehensive web site testing tool.”

I think it may already be the most comprehensive tool — READ: it tests a bunch of random things — but before I call anything I want to make sure that it works very well.

It’s different than any web site testing tool I know about. I doesn’t just spit out a bunch of line numbers with errors and warnings. It looks at your site holistically, gathers issues, sorts them, and delivers a report telling you what you should address first, and why it matters.

In this way it’s more of a hand-holding experience. I imagine it to be like a robot from an old sci-fi movie. It loves the flawed human captain of the ship, and it wants to deliver the best advice, based on data, in a soothing artificial voice that very hardly syncs with a pulsing red light. I will call the robot FET.

Please use it, it’s free and helpful: FrontendTest.

A Nice Call to Action Button

We are replacing our large image buttons with markup. Yay! I think what our designer came up with is quite nice, and easy to build with CSS3, so I’m sharing it.

Sample Button

Here is the CSS:

.button2012 {
   border: 1px solid #c95d00;
   background: #fa962f;
   background: -webkit-gradient(linear, left top, left bottom, from(#fa962f), to(#ee7106));
   background: -webkit-linear-gradient(top, #fa962f, #ee7106);
   background: -moz-linear-gradient(top, #fa962f, #ee7106);
   background: -ms-linear-gradient(top, #fa962f, #ee7106);
   background: -o-linear-gradient(top, #fa962f, #ee7106);
   padding: 5px 20px;
   -webkit-border-radius: 6px;
   -moz-border-radius: 6px;
   border-radius: 6px;
   text-shadow: rgba(20,20,20,.6) 0 1px 0;
   color: white;
   font-size: 18pt;
   font-weight: bold;
   text-decoration: none;
   vertical-align: middle;
   cursor: pointer;
.button2012:hover, .button2012:active {
   background: #ee7106;

You can make the button and the hover any color you want, of course, although A/B tests have shown that red buttons convert better.