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.

European vs American cooking habits and why it matters for programming

Measuring spoons (cc) yukino

Once upon a time I lived a quietish life in Vienna, Austria. I cooked a lot for friends and myself. I really enjoyed it and more importantly I just knew that I’ve learned everything there is about making meals from my friends and family and from what you “just know” about cooking when growing up in Austria.

But guess what? A lot of “it is done like it is done” is just outright wrong, incomplete or could be much better with little tweaks.

Once I got introduced to American-style cooking by my awesome wife Amy Hoy, I’ve learned lots of new stuff and unlearned old things. I’ve come to love things that I, without questioning, considered stupid before.

• American measurement units are really convenient to use when cooking, because they are volume-based instead of weight-based, so you just need measuring cups and spoons instead of a weighing everything. (In Europe, we use volume-based units only for liquids.)
• Even more importantly, measurement units are human-derived instead of being arbitrary set metric units. It sure is convenient to use grams in mathematical formulas, no doubt, but it’s a different story to weigh 75.6g. Just use 5 1/3 tablespoons—so much better.
• There’s a “subculture” of (near-) scientific cooking; most importantly this book: The New Best Recipe. These guys dissect recipes and make them better by iteratively optimizing for best results. I’ve never seen done this by anyone in Austria or Germany. (This is a very important cultural differences, striving to be better versus striving to uphold the current/past state of affairs. Wouldn’t it be great to have even more delicious Strudels and Schnitzels?)
• I’ve learned that cold coffee (even from a day ago) is still decent when you microwave it for a minute.[1] (In Europe, Microwaves are considered evil.)
• Big American fridges, ’nuff said. (People in Austria used to lol about them; now the the same sizes are getting popular there.)
• Eggs that aren’t refrigerated don’t go bad instantly. Amazing. (Once you do refrigerate them, they need to stay refrigerated, however.)

Note: there are many things that Europeans do better—for example the quality of raw ingredients like milk, butter, eggs, and so on is often higher than what you can (easily) get in the US. And I wish I could get my hands on Austrian bread when I’m in the US.

So what this all have to do with programming?

It doesn’t matter if it’s cooking or programming or doing whatever, really—you can learn from other people and how they do things differently from you. Don’t dismiss them outright. Hear what they have to say. Here’s one concrete example for myself that I’ve stumbled upon: I dismissed the meaningful indentation in Python, but later I’ve come to like it in CoffeeScript.

However, if something doesn’t hold up to the claims, or is doing things objectively wrong—it’s OK to be dismissive. It’s good to be opinionated. Just think about it for a second first, and better yet try it out. You might be surprised about what you fall in love with that at first seemed outlandish or stupid to you.

[1] Coffee nerds, kill me now.

Being 5 years ahead

“We have been very lucky to have brought a few revolutionary user interfaces to the market —the mouse, the click wheel, and now Multi-Touch. Each has made possible a revolutionary product, the Mac, the iPod, and now the iPhone. We’re going to build on top of that with software. Software on mobile phones is like baby-software. Today we’re going to show you a software breakthrough. Software that’s 5 years ahead of what’s on any other phone.“
—Steve Jobs, January 9, 2007

That was indeed a very accurate way of putting it, as only now Google is catching up, with Chrome for Android. If you’ve done any serious mobile web development, you know that the built-in Android “browser” is a joke compared to Safari on iOS.

“With Chrome for Android […] you can scroll through web pages as quickly as you can flick your finger.”
—Google Blog, February 7, 2012

Right.

Let it snow! Starring Zepto.js

Here’s a little fun diversion, snowflakes animated with Zepto.js! Works on WebKit-based browsers (Safari/Chrome, iPhones, iPads, Android phone, webOS-based phones, PlayBook etc.), and Firefox, thanks to the new Firefox support in Zepto 0.8.

http://zeptojs.com/let-it-snow/

P.S. Also announcing School of JavaScript, a new site of learning all things JavaScript, with training courses by Amy Hoy and yours truly available for your download pleasure (coming soon, leave your email!).