Category Archives: Uncategorized

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.

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


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.

Relic Source Found

I got a blank page today, and I wondered why. So I looked at the source, and these are the contents:

<!– Redirection Services SJL01WRED05 H1 –>
<frameset rows=’100%, *’ frameborder=no framespacing=0 border=0>
<frame src=”” name=mainwindow frameborder=no framespacing=0 marginheight=0 marginwidth=0></frame>
<frame src=”/?a8734haka8dr781346=true” NAME=a33 frameborder=no framespacing=0 marginheight=0 marginwidth=0></frame>
<h2>Your browser does not support frames.  We recommend upgrading your browser.</h2><br><br>
<center>Click <a href=””>here</a> to enter the site.</center>

Upgrade my browser to support frames?! When could this have been written? Was there a time when frames were a new feature that old browsers didn’t support as opposed to an old features that new browsers do not? Wow.

Seems evil — no title, just frames. Good thing I got a blank page!


Dingbats and Symbols for Web Developers

Here are some nice symbols which you can simply and safely use to decorate web pages. I’ve confirmed these HTML entities work in IE7+, Firefox, Opera, and Webkit.

Instead of showing you all the boring symbols that water down the list making hard to find exciting ones* like poison and snowman, I’ve ordered them not by number, but by how useful I imagine they are for web development, and how “cool” I think they are.

The HTML Entities as well as the translated CSS and JavaScript hex codes are provided for your webdev convenience.

*exciting for a web developer

Glyph HTML CSS JavaScript
&#x2620; \2620 \u2620
&#x2606; \2606 \u2606
&#x2605; \2605 \u2605
&#x2604; \2604 \u2604
&#x2603; \2603 \u2603
&#x2601; \2601 \u2601
&#x262e; \262e \u262e
&#x2600; \2600 \u2600
&#x263E; \263E \u263E
&#x2654; \2654 \u2654
&#x2655; \2655 \u2655
&#x2661; \2661 \u2661
&#x2602; \2602 \u2602
&#x260E; \260E \u260E
&#x260F; \260F \u260F
&#x2614; \2614 \u2614
&#x2619; \2619 \u2619
&#x2618; \2618 \u2618
&#x261C; \261C \u261C
&#x261D; \261D \u261D
&#x261E; \261E \u261E
&#x261F; \261F \u261F
&#x262F; \262F \u262F
&#x2639; \2639 \u2639
&#x263A; \263A \u263A
&#x263B; \263B \u263B
&#x263C; \263C \u263C
&#x266A; \266A \u266A
&#x266B; \266B \u266B
&#x2666; \2666 \u2666
&#x2693; \2693 \u2693
&#x2698; \2698 \u2698
&#x2699; \2699 \u2699
&#x269B; \269B \u269B
&#x26A0; \26A0 \u26A0
&#x26A1; \26A1 \u26A1
&#x2704; \2704 \u2704
&#x2708; \2708 \u2708
&#x270C; \270C \u270C
&#x270D; \270D \u270D
&#x270E; \270E \u270E
&#x2712; \2712 \u2712
&#x2714; \2714 \u2714
&#x2717; \2717 \u2717
&#x271D; \271D \u271D
&#x271E; \271E \u271E
&#x271F; \271F \u271F
&#x2720; \2720 \u2720
&#x2721; \2721 \u2721
&#x2722; \2722 \u2722
&#x2723; \2723 \u2723
&#x2724; \2724 \u2724
&#x2725; \2725 \u2725
&#x2726; \2726 \u2726
&#x2727; \2727 \u2727
&#x2729; \2729 \u2729
&#x272A; \272A \u272A
&#x272B; \272B \u272B
&#x272C; \272C \u272C
&#x272D; \272D \u272D
&#x272E; \272E \u272E
&#x272F; \272F \u272F
&#x2730; \2730 \u2730
&#x2731; \2731 \u2731
&#x2732; \2732 \u2732
&#x2733; \2733 \u2733
&#x2734; \2734 \u2734
&#x2735; \2735 \u2735
&#x2736; \2736 \u2736
&#x2737; \2737 \u2737
&#x2738; \2738 \u2738
&#x2739; \2739 \u2739
&#x273A; \273A \u273A
&#x273B; \273B \u273B
&#x273C; \273C \u273C
&#x273D; \273D \u273D
&#x273E; \273E \u273E
&#x273F; \273F \u273F
&#x2740; \2740 \u2740
&#x2741; \2741 \u2741
&#x2742; \2742 \u2742
&#x2743; \2743 \u2743
&#x2744; \2744 \u2744
&#x2745; \2745 \u2745
&#x2746; \2746 \u2746
&#x2747; \2747 \u2747
&#x2748; \2748 \u2748
&#x2749; \2749 \u2749
&#x274A; \274A \u274A
&#x274B; \274B \u274B
&#x274D; \274D \u274D
&#x275B; \275B \u275B
&#x275C; \275C \u275C
&#x275D; \275D \u275D
&#x275E; \275E \u275E
&#x2776; \2776 \u2776
&#x2777; \2777 \u2777
&#x2778; \2778 \u2778
&#x2779; \2779 \u2779
&#x2780; \2780 \u2780
&#x2781; \2781 \u2781
&#x2782; \2782 \u2782
&#x2783; \2783 \u2783
&#x278A; \278A \u278A
&#x278B; \278B \u278B
&#x278C; \278C \u278C
&#x278D; \278D \u278D
&#x2794; \2794 \u2794
&#x2798; \2798 \u2798
&#x2799; \2799 \u2799
&#x279A; \279A \u279A
&#x279B; \279B \u279B
&#x279C; \279C \u279C
&#x279D; \279D \u279D
&#x279E; \279E \u279E
&#x279F; \279F \u279F
&#x27A0; \27A0 \u27A0
&#x27A1; \27A1 \u27A1
&#x27A2; \27A2 \u27A2
&#x27A3; \27A3 \u27A3
&#x27A4; \27A4 \u27A4
&#x27A5; \27A5 \u27A5
&#x27A6; \27A6 \u27A6
&#x27A7; \27A7 \u27A7
&#x27A8; \27A8 \u27A8
&#x27A9; \27A9 \u27A9
&#x27AA; \27AA \u27AA
&#x27AB; \27AB \u27AB
&#x27AC; \27AC \u27AC
&#x27AD; \27AD \u27AD
&#x27AE; \27AE \u27AE
&#x27AF; \27AF \u27AF
&#x2668; \2668 \u2668
&#x2638; \2638 \u2638
&#x2691; \2691 \u2691
&#x269C; \269C \u269C

Yet another way HTML5 is cleaner

I don’t think I’m a total neat-freak. However, it’s so satisfying to change a doctype such as this: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”  “”>

to the HTML5 version: <!DOCTYPE html>

Looking at the source code of HTML5 evangelists, I’m noticing script tags that look like this: <script>boo();</script>

instead of this: <script type=”text/javascript”>eek();</script>

Isn’t the type attribute required? No longer, and thank goodness. Here’s what the spec says:

The type attribute gives the language of the script or format of the data. If the attribute is present, its value must be a valid MIME type. The charset parameter must not be specified. The default, which is used if the attribute is absent, is “text/javascript”.

This is small, but kinda not so, considering how often we use it. I mean, we’ve been adding the required “type” to our script tags when 99.99% of our scripts have always been text/javascript. In ten years I don’t think I’ve ever included another browser scripting language this way. Now it’s the default as it should be. Nice!