Give the gift of JavaScript! 50% off JavaScript Performance Rocks!

Need a last minute gift for a JavaScripting friend? Or even yourself? My JavaScript Rocks! Performance ebook is now 50% off and available until the end of the year for just $19.95 (a total steal if you ask me!). That includes not 1, not 2, but 3 ebooks, plus our DOM Monster bookmarklet-based performance analyzing tool.

And the best thing is, with digital delivery of the PDF and the bookmarklet, you’ll get it guranteed just in time for Christmas! 🙂

Tip: Put it on a USB stick and add a little ribbon to it!

Grab your copy now at javascriptrocks.com.

Zepto.js v0.3 – bug fix galore, toggleClass, .attr(‘value’), .last, $ fragments (element creation), .undelegate, .die, proxied event objects

Just in time for hack nights during the holidays, Zepto.js v0.3 is now available!

What’s new in this release?

• First off, lots of little bug fixes and enhancements to existing functionality
• .toggleClass
• .attr(‘value’) now returns the value for INPUT elements
• .last
• $ fragments (element creation)
• More event goodness with .undelegate, .die and proxied event objects

A big thank you to all the contributors to this beta release (…and Zepto.js v0.4 is just around the corner for the new year!) 🙂

As always, get the source and contribute on GitHub (at the time of this writing we’re up to 957 watchers and 78 forks, awesome!).

P.S. Want to support Zepto.js development but can’t contribute source code or documentation? There’s a HTML5 Mobile Pro Workshop coming up in January, plus Amy’s and my JavaScript Performance Ebook is on sale (50% off until December 31!). Hint: the ebook and the workshop make great gifts! 🙂

Learn advanced JavaScript and mobile HTML5 in 2011!

Yours truly and Amy have set up new dates for our popular JavaScript Master Class and HTML5 Mobile Pro Workshop, in early 2011.

If you’re fast and book your tickets in December, you can both get a last-minute tax write-off for 2010, and save by taking advantage of the early bird pricing!

We also have plans for two brand-new workshops and a JavaScript learning platform, but more on this later! 🙂

Freelancing? Check out Freelancember!

Are you a freelancer? Amy and I put up a calendar with a new gift every day to make your freelancing life so much better! Check it out at freelancember!

Zepto.js v0.2 — backbone.js compatibility, .unbind, .text, better Ajax

Zepto.js is alive and kicking, and we just pushed version 0.2! Thanks to a contribution from Sam Stephenson of Prototype.js fame, Zepto.js now sports compatibility with Backbone.js, which opens up a bag of awesome possibilities for mobile apps:

Backbone supplies structure to JavaScript-heavy applications by providing models with key-value binding and custom events, collections with a rich API of enumerable functions, views with declarative event handling, and connects it all to your existing application over a RESTful JSON interface

Compatibility was achieved by adding some missing functionality to Zepto, namely a more robust events system, and support for $.fn.text.

Also added in this release is proper support for Ajax calls, with optional JSON encoding. Thanks to Jakub Nešetřil for this contribution!

The best thing is, Zepto.js is still only 2.5k in size when properly minified and gzipped!

Grab the new release from zeptojs.com and stay updated on GitHub and Twitter.

Zepto.js 0.1.1: JS-based inheritance, .load, .is, $(document).ready, $.os

We just pushed the next beta release of Zepto.js, and we’ve added a lot of stuff, and fixed some bugs on the way:

– Switch to JavaScript inheritance-based extension mechanism; this makes Zepto faster and allows plugins to be loaded lazily
– Add .load(url [, callback]) and .load('url #fragment-selector' [, callback]) to load HTML fragments with an Ajax call
– Add $(document).ready(callback) for calling methods when the DOMContentLoaded event fires
– Add .is(selector) for testing if the first element in the Zepto object matches a given selector

For most cases, these work like the corresponding function calls in jQuery.

Also new:

– Add a $.os object for info on which browser/platform is used. For example, on an iPad, $.os.ipad and $.os.ios is true, plus the current iOS version will be found in the $.os.version property

Thanks to the contributors and the community feedback for Zepto.js.

Grab your copy from the Zepto.js homepage or use the source on GitHub.

We’re still early into development of Zepto.js, but got a cool shout out from Ars Technica here (they’re rolling their own micro-framework for their iPad Reader app, but mention Zepto.js as a great option!).

Have you build anything way cool with Zepto.js? We’d love to showcase/link to your demos and apps from the Zepto.js site!

Zepto.js, a jQuery-compatible mobile JavaScript framework in 2K (presentation)

Zepto.js is a JavaScript framework for mobile apps and sites, with a jQuery-compatible syntax (lots of the jQuery API is supported!). The goal is have a 2k library that handles most basic drudge work with a nice API that you might already know so you can concentrate on getting stuff done.

Here’s my presentation from the October 27, 2010 vienna.js meetup!

Links from the presentation:

• Zepto.js mobile JavaScript framework
• Zepto.js project on GitHub
• Aerogel Wikipedia article
• Cute cat picture*

Interesting numbers from the article (library sizes in bytes):

jQuery 1.4.3: 180,477 uncompressed, 77,745 minified, 26,711 minified and gzipped
Prototype 1.7_rc3: 160,122 uncompressed, 86,919 minified, 26,617 minified and gzipped
Zepto.js (2010/10/27): 8,788 uncompressed, 5,816 minified, 2,368 minified and gzipped

These numbers are not strictly comparable, as jQuery and Prototype offer features that are not in Zepto.js, and are not design goals of Zepto.js. But what it adds up to is that Zepto.js is about 10 times smaller than jQuery or Prototype, yet provides a large subset of the features those libraries offer, thanks to all the goodness of advanced JavaScript and new DOM features in mobile WebKit browsers.**

You can also download the slides (PDF, 12MB).

Please do have fun with Zepto and create awesome mobile sites with it (I hear it works great for browser extensions for Chrome and Safari, too!). And, of course, please contribute back! Patches, documentation, demos—everything is very welcome!

Want to hear more about Zepto.js? Check out my Interview on The Changelog show.

Big shout out to Samo Korošec for designing the Zepto.js logo and beta web site! Your mad design skillz rule!

*every presentation needs at least one picture of cute cats
**Prototype is now smaller then jQuery, when did that happen??

The Changelog Interview

Earlier this month I did an interview with The Changelog.

Listen to it to hear my thoughts on script.aculo.us, Prototype.js, vapor.js, Zepto.js and the JavaScript community in general!

The Changelog is a weekly podcast that covers what’s happening in the open source world—and most importantly, it’s super-awesome.

How long should a JavaScript function be?

Writing code the right way is hard to do. To begin with, what’s the right way anyway?

And, what’s a good length for a JavaScript function?

I’d say 5 to 10 lines at maximum. Preferably even shorter than that. JavaScript just wants you to do functional programming. Write lots of functions.

Short functions have lots of advantages:

• Atomic functionality: they do exactly one thing
• Easier to understand when you come back later
• Ideal for unit testing
• Debugging tends to be simpler
• Refactoring is a snap
• Well-suited for closure-pattern APIs
• Chances for code reuse increase

There are two main disadvantages:

• Longer code (all the function(){} blocks)
• A tiny bit slower (lots of function calls)*

Both of these are in almost any case not an issue because good minification and gzipping takes care of code size and can even inline function calls.

Here’s an example where I’ve used really short functions, it’s from my creditcard_js validation library:

var CreditCard = {
  // …more stuff…
  validate: function(number){
    return CreditCard.verifyLuhn10(number)
      && !!CreditCard.type(number)
      && !CreditCard.isTestNumber(number);
  },
  verifyLuhn10: function(number){
    return ($A(CreditCard.strip(number)).reverse().inject(0,function(a,n,index){
      return a + $A((parseInt(n) * [1,2][index%2]).toString())
        .inject(0, function(b,o){ return b + parseInt(o) }) }) % 10 == 0);
  },
  isTestNumber: function(number){
    return CreditCard.TEST_NUMBERS.include(CreditCard.strip(number));
  },
  strip: function(number) {
    return number.gsub(/s/,'');
  },
  type: function(number) {
    for(card in CreditCard.CARDS)
      if(CreditCard['is'+card](number)) return card;
  }
};

Note that many of those functions actually start with return and try to be really concise (if you don’t understand the verifyLuhn10 function, don’t worry!).

At the end of the day, this scientific chart is a good guideline to how many lines of code a function in JavaScript should have:

*Yes it’s slower, academically speaking. But only a tiny weenie little bit. There’s no way this unnoticeable performance loss is going to outweigh the advantages. Just trust me on this, don’t ever prematurely optimize for performance. Save yourself the trouble, and you’ll live happier.

Of course there are no magicals unicorns and no silver bullets for anything in programming. Sometimes, just sometimes you will actually hit a performance issue that requires you to get rid of all your nice little tiny functions and rewrite it to be really long with lots of lines of code. Stick a “it depends” post-it note to your monitor. It really does.

Standards bloat and HTML5

A long time ago, HTML started out as a small prototype language for hypertext. It was based on some previous efforts and it seems like a pragmatic approach to get a real-world hypertext system going as quickly as possible.

So where did things go from there?

This chart shows the number of words in each of HTML’s versions (the first overview “HTML Tags” version is not included, it had roughly 1,500 words).

So is it bloated?

By all means, yes.

• HTML 1.0 — 9,967 words
• HTML 2.0 — 18,880 words
• HTML 3.2 — 15,570 words
• HTML 4.01 — 104,567 words
• HTML5 Draft — 324,969 words

However, it’s good that things are described in much more detail, which, in theory makes it more likely that browsers will act more alike in the future; as long as a feature is implemented, it should be supported as it says in the spec. These documents shifted from being a resource for users of the language to a specification for implementors (browser vendors).

Given that HTML5 is rapidly approaching 400k words it might be a little bit too detailed (for comparison, that’s more than twice the number of words in the New Testament but not quite yet the 560k words of the Lord of the Rings trilogy).

The trouble is, developers and users of HTML can’t read all of this. This is comparable to the ECMAScript specifications, where the spec is unreadable for laymen, but most other resources are too simplistic, partially wrong and always out-of-date (we need a Promote JavaScript for HTML!). HTML is has too many features, too many special cases, too many little quirks, too much of everything.

I wonder if HTML5 will be the web’s finest hour or the beginning of something new—for example, people shifting to using CANVAS or WebGL or some-other-tech to render content, instead of the HTML tag jungle.

It’s here to stay

Whatever the future might hold, I think HTML is here to stay, at least for quite a while. Let’s face it: it’s very flexible and kept up pretty well. We even survived the the doomed XML detour of the early 2000’s (lucky us!).

The HTML5 standard, besides all the bloat, is going in the right direction. For users, it will be more pragmatic, as it doesn’t enforce strict XML syntax, and it makes sure previously unclear concepts are now well-defined (if you want to know what exactly should happen, look into the spec, it’s actually well written).

But of course, the specification will always be late and not reflect what’s actually out there. Not that it matters that much, as we all know HTML5 will be finalized in 2022, three years after the events depicted in Blade Runner. D’oh!