Prototype.js vs. underscore.js showdown

I recently ported my little CreditCard.js library from Prototype.js to use underscore.js, as I needed that in a project. Here’s what I’ve found—check out the original Prototype.js version first:

And here’s the same thing, but ported to underscore.js:

A few observations that, needless to say, are opinions, not scientific fact:

• Prototype.js’ direct extensions of built-in prototypes make code cleaner and easier to read
• Sometimes JavaScript-provided APIs like reduce have their arguments in just the wrong order; especially when used with chained method calls.
• Some helper functions, like $w are missing in underscore.js
• curry is more fun than bind, and I don’t need to specify a scope
• Porting is pretty straight-forward, a testament to Prototype.js’ influential role in modern JavaScript

Prototype.js is still awesomesauce, and in many ways the mother of modern JavaScript libraries. I still prefer the syntax over many of the newer libraries. These newer libs have their own advantages, of course, mainly size and modularity. But sometimes I do long for the good old times.

5 compelling reasons why to use semicolons in JavaScript

The trouble with light boxes

These days (actually more like for the last five years), when you’re designing a site and have preview thumbnails/photos/screenshots of things, you’re probably using one of the millions of light box scripts/plugins out there. Light boxes are the new funny mouse trails.

Chances are you’re completely breaking your sites for mobile users.

If you don’t have a mobile site

In case you’re serving the same site to both desktop and mobile users (which for most sites is preferable anyway, Apple does it!), use a light box script that calculates the “center of screen” position once when you open the image. Make sure the button to close the zoomed-in image is always visible.

Don’t use any scripts that recalculate the position on scrolling or window size changes. Users on mobile devices will hate you for it. A lot.

In general, don’t try to be too clever.

If you have a mobile site

The trick is to link to the bigger version of the image directly.

Why? First off, it loads really fast, as only the image has to be transferred and you won’t need any JavaScript at all. Secondly, the user can use gestures to zoom in on the image and by default it’s shown as full-screen as possible. Afterwards the user can just hit the back button to go back to your main content. There’s no need to implement fancy zoom scripts and complicated UI controls; the user already knows how to zoom images on the device.

Zappos does it, so you can too.

Addtionally, don’t bother having “retina” versions and “normal” versions. Just provide one single hi-res image.

It’s better to spend your time on seeing what level of JPEG compression works best for the image you use (if you’re curious, Zappos uses 92 for this particular image—one way to find out is to use identify -verbose filename.jpg | grep "Quality" if you have ImageMagick installed).

Plus, have good toolchain to minimize your images without quality loss, I can’t recommend the ImageOptim tool highly enough for that. I was able to shave off a cool 6% of the file size of the image used on Zappos. Your users will love you for the faster loading images!

Spring JavaScript Performance Special!

There are no excuses to not have fast-loading, delightfully quick websites and apps. With Amy Hoy’s and my JavaScript Performance ebook, you’ll learn about what’s important and where the low-hanging web performance fruit hangs; as well as how to speed up your JavaScript codes—and for a short 4 days (until May 19!) we’re selling it for more than 50% off with code JSSPRING.

Grab your copy now for just $19! $39

Zepto.js in the wild: Typotheque’s Greta Sans Type System Specimen

81 fonts, 1 SVG, 696 lines of JavaScript (no semicolons!), 565 lines of CSS, 74 lines of HTML and Zepto.js in a single 634KB compressed web page. Amazing stuff.

Read up on how it was done.

5 things they told you not to use in JavaScript

Or, don’t trust what “wise” elders tell you.

1. “Don’t rely on automatic semicolon insertion”

Whether you like it or not, whitespace is significant in JavaScript. A linebreak indicates, in most cases, the end of a statement; a semicolon is automatically inserted for you. In order to be able to write properly working code, you need to be aware of the rules of Automatic Semicolon Insertion, regardless if you choose to add semicolons at the end of lines or not.

2. “Never use the with statement”

Short of making runtimes easier to implement, there’s no compelling reason not to use with. Here’s Mozilla’s definition: “(with) extends the scope chain for a statement.”—that’s all there is to it. If a program becomes hard to read or understand by using “with”, you should consider alternatives, but it’s not the with statement’s fault. You can just as easily write perfectly clear JavaScript code that’s easier to understand because you’re using “with”.

Consider the following code:

function testSomething(test){
  test.assert(1==1);
  test.assert(2<;3);
  test.assert('x' == 'y');
};

// vs.

function testSomething(test){ with(test) {
  assert(1==1)
  assert(2<;3)
  assert('x' == 'y')
}}

One of the things that with allows here is to not repeat yourself unnecessarily, which, in my book, is an advantage.

3. “arguments.callee? What, are you crazy? It doesn’t work with strict mode.”

Actually, it’s really convenient to be able to reference the currently called function this way, for example if you want to do a recursive call (as an alternative you can give your function a name). Here’s something fun you can do with it:

alert((function(){return"alert(("+arguments.callee.toString().replace(/s/g,"")+")());";})());

Strict mode is great if you really know what you’re doing, but if you do so, you don’t need to use strict mode (I call it “straight-jacket mode”, personally).

4. “Oh no, but __proto__ is proprietary!!!1!”

Sure, but what does “proprietary” mean anyway? __proto__ is all major JavaScript implementations, except for Internet Explorer. It enables swapping out the prototype of an object without having to copy over each and every property from one object to another.

You’re probably using “proprietary” DOM stuff every day, if you do any kind of browser JavaScript development.

If you’re not targetting runtimes that don’t support it—by all means use it. If you have to support these runtimes later, just change your code to adapt to that. It often boggles the mind how much time is spend on avoiding potential future issues while JavaScript is a dynamic scripting language that is changed and updated as easily as saving a file. Fix problems when you actually have them. Use the time you’ve freed up by not prematurely optimizing and spend it with your family or have a holiday on the beach.

5. “But it will not longer be supported in <;fabled future version of JavaScript>;”

So what? Some committee somewhere is making up future standards, which are subject to change. Code for what works now, not for what may or not may be 10 years hence. For day-to-day programming, there’s no point in restricting yourself in what you can do and how you can do it based on things that might not happen after all.

My recommendation: learn the language, and use it to your liking; and don’t rely or blindly accept what any “wise elders” tell you. Try to do something new and crazy every day. You might not end up using the crazy, but it’s the best way to master JavaScript. Develop your own style that you are comfortable with. Experiment.

Update: Kit Cambridge adds some technical details, explanations and pros and cons.

Writing semicolon-less JavaScript, the for-people-who-want-to-get-stuff-done edition

Semicolons at the end of statements (that is mostly end of lines) in JavaScript are optional. The specification calls this ASI, or “automatic semicolon insertion”, and is a bit obtuse about how exactly it applies (specifications tend to be written that way!).

So here’s the gist of what really matters for real-world JavaScript:

1. At the end of a line, just don’t write a semicolon—it’s useless because JavaScript automatically interprets the line break as the end of the statement
2. If your line starts with ( or [ write a single semicolon before that—otherwise it’s interpreted as a function call or accessing a property (this situation will only rarely, if at all, happen in real-world JavaScript code)

So why would you do that? The answer is simple: it’s not needed. As a programmer, I’m glad about anything a language does for me automatically. I won’t have to think about this extra thing, and personally I find the code more readable as there’s fewer things to read and parse. Parsing and execution speed is the same, it’s not “error correction”, but just a language feature.

And that’s it. (There are some very specialized other cases, which for all intents and purposes are esoteric and academic. You can read up some more on this in Mislav’s excellent article).

Say hello to Zepto.js v1.0 release candidate 1

Zepto.js, the semicolon-free edition! That’s right, we removed all trailing semicolons from the source and tests. They were never needed anyway.

Completely new documentation site

We’ve relaunched the ZeptoJS.com website to be a single-page documentation site—it works great on desktop browsers and as a home screen bookmark on iPads.

New methods:

• clone
• prop
• $.isPlainObject
• $.inArray
• $.trim
• $.proxy

New module:

• “selector.js” with experimental support for jQuery CSS pseudo-selectors such as :visible and :first

Improvements in core:

• added missing methods for Ember.js compatibility
• improved creating DOM fragments from HTML with $()
• enable append & family to accept multiple arguments
• fix $.each context
• fix calling get without index
• fix calling val on empty collection
• using css(property, '') removes the property
• fix filter, is, and closest when operating on nodes that are detached from the document
• remove end & andSelf from core to the new “stack.js” plugin
• exposed important internal Zepto functions through the $.zepto object for
  extending or overriding Zepto functionality.
• data method returns undefined when there is no data
• support camelized names in data method

Apart from improving the basic data method in core, the “data.js” module got improvements as well:

• better jQuery compatibility
• ability to store functions
• new removeData method

Ajax:

• have correct ajaxComplete argument order for JSONP abort and timeout
• JSONP requests that hit a 404 will now correctly invoke the error callback
• add support for dataType: 'jsonp' in $.ajax
• add support for data in $.ajaxJSONP
• HTTP 304 status is treated as success instead of an error
• made load more compatible with jQuery
• allow Content-Type to be set via request headers
• respect Content-Type of the response if dataType isn’t set
• work around Chrome CORS bug when data is empty

Changes in other modules:

• fix animate for edge cases such as when there is an animation within an animated element, and improve handling of transition CSS properties
• new “singleTap” event
• improved “longTap” detection

We also have some more examples in the main repository, plus a completely new README describing how to build, customize and contribute to Zepto; plus fully automated testing using PhantomJS.

The complete diff is here.

Please do report any bugs with v1.0rc1 on the issue tracker.

What’s next?

Work has already started on v1.0rc2, so v1.0 shouldn’t be too far off now. Thanks to all our awesome contributors, we couldn’t have done it without you!

Why I’d like a “license type” setting for GitHub projects

Don’t you just hate it when you find some great piece of code on GitHub and then you realize that somewhere at the end of the README the frightful acronym GPL is ruining your good mood?

I propose to make it easier to find projects with a license you can live (and work) with, and would love to see a “license type” setting in GitHub. The license type would maybe show up as a little flag, ribbon or banner when you browse repositories on GitHub, and would also be available in the API—ideal for projects like MicroJS, where we only include permissively-licensed libraries.

Here’s how that could work like—have a drop down setting on the project settings to choose from a type of license. It’s important to make the distinction that I propose to select the general type of license, not a specific license itself (like “Apache 2.0″).

Personally, I’d group open source licenses into the following buckets:

• Permissive (MIT/BSD/WTF/Apache)
• Restrictive (GPL)*
• Other
• Proprietary (or no license)

The project source code should still include a LICENSE file of some sort of course for the details; and if a project is dual-licensed, you’d specify the most permissive license.

*I have some other adjectives for these types of licenses, which I better not mention in public.

10 apps I’d like to see

1. Email client that only sends and receives email once per day.
2. An app that sets up and updates Xcode and command line developer tools automatically.
3. Screen recording software that’s not weird.
4. A version of pgAdmin that doesn’t look like it’s from 2001.
5. A “keynote” app for live-”watching” Apple Keynotes, pulling content from live-blogging sites.
6. An Android emulator/simulator that is actually usable.
7. An app that automatically cleans up backups stored on S3 or Cloudfiles (with a server-side component and alerts if backups seem to be missing).
8. A clean, usable and fast authorize.net front-end.
9. An app that knows about my apps and web apps, and automatically suggests how I can connect them together (APIs, integrations, etc.), with regular updates.
10. And finally, Safari for Android.