Skip navigation
Help

John Resig

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

If I had to make a list of the top 10 things I've done in my life that I regret, "writing a book" would definitely be on it. I took on the book project mostly because it was an opportunity to work with a few friends whose company I enjoy. I had no illusions going in about the rapidly diminishing value of technical books in an era of pervasive high speed Internet access, and the book writing process only reinforced those feelings.

In short, do not write a book. You'll put in mountains of effort for precious little reward, tangible or intangible. In the end, all you will have to show for it is an out-of-print dead tree tombstone. The only people who will be impressed by that are the clueless and the irrelevant.

As I see it, for the kind of technical content we're talking about, the online world of bits completely trumps the offline world of atoms:

  • It's forever searchable.
  • You, not your publisher, will own it.
  • It's instantly available to anyone, anywhere in the world.
  • It can be cut and pasted; it can be downloaded; it can even be interactive.
  • It can potentially generate ad revenue for you in perpetuity.

And here's the best part: you can always opt to create a print version of your online content, and instantly get the best of both worlds. But it only makes sense in that order. Writing a book may seem like a worthy goal, but your time will be better spent channeling the massive effort of a book into creating content online. Every weakness I listed above completely melts away if you redirect your effort away from dead trees and spend it on growing a living, breathing website presence online.

A few weeks ago, Hyperink approached me with a concept of packaging the more popular entries on Coding Horror, its "greatest hits" if you will, into an eBook. They seemed to have a good track record doing this with other established bloggers, and I figured it was time to finally practice what I've been preaching all these years. So you can now download Effective Programming: More Than Writing Code for an introductory price of $2.99. It's available in Kindle, iPad, Nook, and PDF formats.

 More Than Writing Code (Jeff Atwood)

I've written about the ongoing tension between bits and atoms recently, and I want to be clear: I am a fan of books. I'm just not necessarily a fan of writing them. I remain deeply cynical about current book publishing models, which feel fundamentally broken to me. No matter the price of the book, outside of J.K. Rowling, you're basically buying the author a drink.

As the author, you can expect to make about a dollar on every copy that sells. The publisher makes several times that, so they make a nice profit with as few as, say, five thousand copies sold. Books that sell ten or fifteen thousand are rare, and considered strong sellers. So let's say you strike gold. After working on your book for a year or more, are you going to be happy with a payday of ten to fifteen grand?

Incidentally, don't expect your royalty check right away. The publisher gets paid first, by the bookstores, and the publisher may then hold on to your money for several months before they part with any of it. Yes, this is legal: it's in the publisher's contract. Not getting paid may be a bummer for you, but it's a great deal for the publisher, since they make interest on the float (all the money they owe to their authors) - which is another profit stream. They'll claim one reason for the delay is the sheer administrative challenge of cutting a check within three months (so many authors to keep track of! so many payments!)... a less ridiculous reason is that they have to wait to see whether bookstores are going to return unsold copies of your book for a full refund.

Here's one real world example. John Resig sold 4,128 copies of Pro Javascript, for which he earned a grand total of $1.87 per book once you factor in his advance. This is a book which still sells for $29.54 on Amazon new.

Resig-book-check

Tellingly, John's second book seems permanently unfinished. It's been listed as "in progress" since 2008. Can't say I blame him. (Update: John explains.)

When I buy books, I want most of that money to go to the author, not the publishing middlemen. I'd like to see a world where books are distributed electronically for very little cost, and almost all the profits go directly to the author. I'm not optimistic this will happen any time soon.

I admire people willing to write books, but I honestly think you have to be a little bit crazy to sit down and pound out an entire book these days. I believe smaller units of work are more realistic for most folks. I had an epic email discussion with Scott Meyers about the merits of technical book publishing versus blogging in 2008, and I don't think either of us budged from our initial positions. But he did launch a blog to document some of his thoughts on the matter, which ended with this post:

My longer-term goal was to engage in a dialogue with people interested in the production of fast software systems such that I could do a better job with the content of [my upcoming book]. Doing that, however, requires that I write up reasonable initial blog posts to spur discussion, and I've found that this is not something I enjoy. To be honest, I view it as overhead. Given a choice between doing background research to learn more about a topic (typically reading something, but possibly also viewing a technical presentation, listening to a technical podcast, or exchanging email with a technical expert) or writing up a blog entry to open discussion, I find myself almost invariably doing the research. One reason for this is that I feel obliged to have done some research before I post, anyway, and I typically find that once I'm done with the research, writing something up as a standalone blog entry is an enterprise that consumes more time than I'm willing to give it. It's typically easier to write the result up in the form of a technical presentation, then give the presentation and get feedback that way.

Overhead? I find this attitude perplexing; the research step is indeed critical, but no less important than writing up your results as a coherent blog entry. If you can't explain the results of your research to others, in writing, in a way they can understand, you don't understand it. And if you aren't willing to publish your research in the form of a simple web page that anyone in the world can visit and potentially learn from, why did you bother doing that research in the first place? Are you really maximizing the value of your keystrokes? More selfishly, you should always finish by writing up your results purely for your own self-improvement, if nothing else. As Steve Yegge once said: "I have many of my best ideas and insights while blogging." Then you can take all that published writing, fold in feedback and comments from the community, add some editorial embellishment on top, and voilà – you have a great book.

Of course, there's no getting around the fact that writing is just plain hard. Seth Godin's advice for authors still stands:

Lower your expectations. The happiest authors are the ones that don't expect much.

Which, I think, is also good life advice in general. Maybe the easiest way to lower your expectations as an author is by attempting to write one or two blog entries a week, keep going as long as you can, and see where that takes you.

[advertisement] What's your next career move? Stack Overflow Careers has the best job listings from great companies, whether you're looking for opportunities at a startup or Fortune 500. You can search our job listings or create a profile and let employers find you.

0
Your rating: None

  

Welcome to the first in a new series of interviews called “How I Work”. These interviews revolve around how thinkers and creators in the Web world design, code, and create. The goal is not to get into the specific nuances of their craft (as that information already exists online), but rather step back and learn a bit about their habits, philosophies, and workflow for producing great work.

Meet Doug Crockford

First up is Douglas Crockford who believes JavaScript might just be the most elegant language ever. Learn why he thinks you should study the history of computer science, the value of reading your code in front of other people, and that jQuery really is a good thing.

Douglas Crockford is known as The JavaScript Guy. He’s famous not only for his O’Reilly book JavaScript: The Good Parts but even more so as the visionary behind the JSON data format as well as the JSLint tool. He was featured in the book Coders at Work for his contributions and philosophies on what JavaScript got right, and what it didn’t.

As a native of Southern California, Doug has the build of a surfer; lean and tall with white hair and a beard. A veteran of Silicon Valley, he’s worked at Atari Labs, founded and worked at numerous software start-ups, was head of technology at Lucas Films and now has the enviable job of being a JavaScript evangelist at Yahoo!.

Douglas Crockford
Image credits go to Eric Miraglia.

Self-taught (as many of the greats are), he says his goal is simply to get more people coding in JavaScript, or any language for that matter. While his day job may be as a JavaScript evangelist, speaking with Doug you get the sense he really is an evangelist for programming in general.

Below is a conversation that took place in Bozeman, Montana prior to a talk at Montana State University. Doug freely shared his thoughts on great programmers, user empathy, and how JSON restored his faith in humanity.

Why do you feel programmers should study the history of Computer Science?

Well, first semester of physics is a history class. You study Galileo and Newton and all their contributions to the field and that gives us the overall view of physics. It’s a really nice place to start.

I wish CS would do that. It doesn’t seem to have enough value in its history and it’s a really amazing history that’s completely neglected. It’s rarely that the best idea won. So, we’ve taken different paths over the years and maybe haven’t realized why.

Ironically, despite the rate of change in technology, we see in the story of software that it takes a generation to retire or die off before we have a critical mass of bright young minds to embrace new ideas.

I think if people were more aware of their history, they could see these patterns more easily.

What were the traits of the weak programmers you’ve seen over your career?

That’s an easy one—lack of curiosity. They were so satisfied with the work that they were doing was good enough (without an understanding of what ‘good’ was) that they didn’t push themselves.

I’m much more impressed with people that are always learning. The brilliant programmers I’ve been around are always learning.

You see so many people get into one language and spend their entire career in that language, and as a result aren’t that great as programmers.

Do you feel that the pain a programmer goes through in learning a language contributes to this unhealthy attachment to using only one language?

My advice to programmers to avoid this trap is to learn lots of different languages. We’re in sort of a language renaissance right now and there are a ton of brilliant languages to learn from.

To learn new languages takes nights and weekends outside of work, and that’s a commitment. The great programmers are the people that are constantly picking a project and diving into it, learning a language that way.

In Coders at Work, you stress the importance of doing code readings with teams. Why do you feel it’s important to present your code in front of other people?

Well, over the years I noticed that there are some terrific programmers out there that are completely content to sit in their cave all day long writing brilliant code. But they don’t interact much with their team, which means it’s a lost opportunity for mentoring other members.

As you know, a lot of coders aren’t the most socially adept animals either.

So, my idea with code reading sessions is to provide a forum where people can come together and read for each other to get them out of their caves. The masters read for the beginners, and vice versa, as a team-building exercise.

The trick for success is to set up rules ahead of time so that nobody is going to get spanked and everyone is respectful in their feedback. It has to be a good learning experience for everyone. You have to be careful with a dysfunctional team, because it can quickly tear apart the group. But I always call the game before it gets that far.

The rules are that it’s about improving the quality of the code that we’re all responsible for, improving the quality of our team, and improving our individual capabilities.

Some people see this as a terrible time sink. Yet, I’ve found by doing this exercise, bugs are caught way ahead of time and you can prevent a team member from going off the tracks. But again, that’s not the goal, it’s about team building.

Over time the masters help pull up the beginners and the overall output from the team gets better.

Are programmers getting better at user empathy?

The best experience I had with empathy was working in marketing support. There were times I would go out into the field and hold hands with the customers and see the consequences firsthand of some of the crap we were delivering to them.

I was shocked when I moved into systems programming and how the programmers actually held the customer in contempt.

I think every programmer should work in customer support for the product they’re delivering.

It’s another case of over-specialization. “I just write the code,” is the response you get and the programmers don’t see it as a chance to improve peoples’ lives.

How much of a language do you need to know?

Virtually every programming language is too big. Language standards have difficulty removing unnecessary features but as users we can choose not to use it.

I would say you can do 100% with knowing 50% of the language.

The language that taught me that lesson the most was JavaScript, because it has more bad parts than good parts. It gave me a very strong motivation for figuring out what are the good parts and what are the bad parts, and what the criteria is for deciding what’s in or out.

And the good parts are just so good. Be sure to watch Doug’s Google Tech talk titled “JavaScript: The Good Parts.”

What approaches would you say a master has versus a beginner?

When I was a journeyman, I was a maximilist. I tried to use the whole language. While I don’t know if I would call myself a master now, I’m certainly a minimalist. I’ve tried to get good at using as little of the language as possible.

I place a lot of value in simplicity and minimalism.

What are your thoughts on jQuery? Some JS enthusiasts feel like it’s letting people off the hook from truly learning JS.

There is some really clever stuff in jQuery and I think John Resig did some very good work there.

I do have a problem with anybody doing anything without understanding what they’re doing. I’m not going to fault jQuery for attracting those sorts of people.

But I do think there are some other AJAX libraries that maybe doing a better job that aren’t quite as accessible. However, I think there is a place for all of these things.

When you were developing JSON was it tough to pull back and not put too much into it?

My design criteria were three things: minimal, contextual, and a subset of JavaScript.

The last constraint was to keep us from going off the rails and inventing new stuff. We had to only use stuff that was in JavaScript, which meant that our unicode handling wasn’t quite right because JS isn’t quite right, which was disappointing. We don’t have proper support for dates because JS didn’t have it. But we can work around both of these.

But it also meant that when somebody proposed, “Hey we should do this crazy thing” we could be like “Nope”. So, we had a really easy criteria for stopping extra features from being added.

One interesting story about leaving things out: as we got closer to releasing JSON I decided to take out the ability to do comments. When translating JSON into other languages, often times the commenting piece was the most complicated part. By taking the commenting out we reduced the complexity of the parsers by half—everything else was just too simple.

One of the best features of JSON is that it’s stable. If your program works now, it will work forever, and that is an attractive thing.

I still get notes from people saying they’ve got great ideas for the next version. But there isn’t going to be a next version. I always say you’re free to invent a new standard and promote it as much as you like.

How did JSON get adopted?

You know, the adoption of JSON sort of restored my faith in humanity because it was a good idea that won out, only because it was a good idea.

It was a case where there were no slick marketing campaigns. In 2001, I started working on it as a way to tie the browsers to the server. At the time, everyone thought XML had to be used or they’d say “that’s a great idea but JSON isn’t a standard”. So, I bought json.org, made a logo, threw up a Web page and it sat out on the Web for three years.

In the meantime, AJAX happened and when it became the way for writing applications JSON was there. There was counter promotion from the XML community, of course.

But when I arrived at Yahoo! some kids at the company started thinking it was okay to start shipping JSON API’s through Web services. And developers found the apps got faster and were easier to write.

It sort of took off from there—no slick campaigns. So a good idea based on simplicity won out for once.

Watch Doug Crockford At Google Speaking On “JavaScript: The Good Parts”

In this presentation from Google Tech Talks, Doug goes over the ideas behind his landmark book, JavaScript: The Good Parts, and dives into the areas of what JavaScript got right and what it didn’t. Learn about the history and common roadblocks programmers run into when developing with this language.

Learn About The JSON Saga

In this video, Doug tells the interesting tale of how JSON was discovered, and sheds some light on how it became a major standard for describing data in an interesting turn of events.

(jvb) (il)

© Jacob Cook for Smashing Magazine, 2012.

0
Your rating: None

Fluid Grids

Early last year, I worked on the redesign of a rather content-heavy website. Design requirements were fairly light: the client asked us to keep the organization’s existing logo and to improve the dense typography and increase legibility. So, early on in the design process, we spent a sizable amount of time planning a well-defined grid for a library of content modules.

Over the past few years, this sort of thinking has become more common. Thanks to the advocacy of Mark Boulton, Khoi Vinh, and others, we’ve seen a resurgence of interest in the typographic grid, and how to use it on the web. And frankly, the idea’s been a smash hit: a million CSS frameworks have bloomed, with sundry tools to complement them, each built to make grid-based design even more accessible to the average designer. And why not? After a few minutes of griddy thinking, the benefits become clear: designers gain a rational, structured framework for organizing content and users gain well-organized, legible sites.

However, our client had one last, heart-stopping requirement: the design had to be fluid and resize with the browser window. Normally, this would cause me to rejoice both noisily and embarrassingly. Fluid layouts are an undervalued commodity in web design. They put control of our designs firmly in the hands of our users and their browsing habits. They’ve also utterly failed to seize the imagination of web designers.

Minimum screen resolution: a little white lie

Instead of exploring the benefits of flexible web design, we rely on a little white lie: “minimum screen resolution.” These three words contain a powerful magic, under the cover of which we churn out fixed-width layout after fixed-width layout, perhaps revisiting a design every few years to “bump up” the width once it’s judged safe enough to do so. “Minimum screen resolution” lets us design for a contrived subset of users who see our design as god and Photoshop intended. These users always browse with a maximized 1024×768 window, and are never running, say, an OLPC laptop, or looking at the web with a monitor that’s more than four years old. If a user doesn’t meet the requirements of “minimum screen resolution,” well, then, it’s the scrollbar for them, isn’t it?

Of course, when I was coding the site, I didn’t have the luxury of writing a diatribe on the evils of fixed-width design. Instead, I was left with a sobering fact: while we’d designed a rather complex grid to serve the client’s content needs, the client—and by extension, the client’s users—was asking for a fluid layout. As almost all of the grid-based designs I could list off at that time were rigidly fixed-width, I was left with a prickly question: how do you create a fluid grid?

As it turns out, it’s simply a matter of context.

0
Your rating: None

Smashing-magazine-advertisement in 45 Fresh Useful JavaScript and jQuery Techniques and Tools
 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools  in 45 Fresh Useful JavaScript and jQuery Techniques and Tools  in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Yes, this is another round-up of fresh and useful Javascript techniques, tools and resources. But don’t close the tab yet, as you might find this one very useful. In this selection we present calendars, forms, buttons, navigation, debugging, optimization and compatibility tables as well as handy resources and tools. We also cover various jQuery-plugins that will help you extend the functionality of your website and improve user experience with ready components or coding solutions.

The last section also covers a number of useful educational resources such as a compilation of useful JavaScript coding practices, a detailed comparison of JavaScript frameworks and general JavaScript programming conventions. We are looking forward to your feedback.

You may be interested in the following related posts:

[Offtopic: by the way, did you know that Smashing Magazine has one of the most influential and popular Twitter accounts? Join our discussions and get updates about useful tools and resources — follow us on Twitter!]

Calendars and Timelines

jDigiClock – Digital Clock (HTC Hero inspired)
jDigiClock is a jQuery plugin inspired from HTC Hero Clock Widget.

Javascript-techniques-82 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

jQuery Sliding Clock v1.1
jQuery transpearant Slider clock with CSS sprites.

Javascript-techniques-67 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Date / Time Picker
Note that this control is not designed to work in IE6; although it will function correctly in most cases, the positioning of the calendar may be way off depending on how your page is styled.

Javascript-techniques-05 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

JavaScript Debugging and Validation Tools

Venkman JavaScript Debugger project page
Venkman is the code name for Mozilla’s JavaScript Debugger. Venkman aims to provide a powerful JavaScript debugging environment for Gecko-based browsers namely Firefox 3.x, the Netscape 7.x series of browsers, Netscape 9.x series, Mozilla Seamonkey 1.x and Mozilla Seamonkey 2.x. It does not include Gecko-based browsers such as K-Meleon 1.x, Galeon 2.x and Netscape 8.x. The debugger is available as an add-on package in XPI format. Venkman JavaScript Debugger has been provided as part of the Mozilla install distribution since October 3rd 2001.

Javascript-techniques-14 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

CompanionJS
Companion.JS (pronounced Companion dot JS or CJS) is a Javascript debugger for IE.

Javascript-techniques-32 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

How to Test your JavaScript Code with QUnit
QUnit is a powerful JavaScript unit testing framework that helps you to debug code. It’s written by members of the jQuery team, and is the official test suite for jQuery. But QUnit is general enough to test any regular JavaScript code, and it’s even able to test server-side JavaScript via some JavaScript engine like Rhino or V8.

Javascript-techniques-44 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

JS Bin – Collaborative JavaScript Debugging
JS Bin is an open source collaborative JavaScript debugging tool.

Javascript-techniques-12 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Forms, Buttons & Navigation

Making a Google Wave History Slider
Here is shown how to create a Google Wave-like history slider. Using it will enable visitors to go back and forth in time to view the changes that take place on a comment thread.

Javascript-techniques-73 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Fancy Radio Buttons With jQuery
Creation of 2 mandatory option sets that a user could choose, while hiding off the radio button inputs and using an anchor links to make it a bit more usable.

Javascript-techniques-62 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Creative Button Animations with Sprites and JQuery
Fading hover effect for which the transition is smoothed with JavaScript, using jQuery library.

Javascript-techniques-83 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Password (un)Masking
JavaScript jQuery that toggles the masking and unmasking of the password field.

Javascript-techniques-68 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

jQuery MagicLine Navigation
These “sliding” style navigation bars have been around a while, and turns out it’s really pretty darn easy. Here are put two examples together.

Javascript-techniques-49 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Fixed Fade Out Menu: A CSS and jQuery Tutorial
The aim is to have a fixed navigation that follows the user when he scrolls, and only subtly showing itself by fading out and becoming almost transparent. When the user hovers over it, the menu then becomes opaque again. Inside of the navigation we will have some links, a search input and a top and bottom button that let the user navigate to the top or the bottom of the page.

Javascript-techniques-52 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

jQuery plugin: Simplest Twitter-like dynamic character count for textareas and input fields
The best way to explain what this plugin does is to mention Twitter. Twitter posts are limited to 140 characters. While typing the Twitter post there is this always present information about how many characters the users have before reaching the limit. The information is not only provided merely by displaying a number, there are different colors applied to certain stages to notify the user about the status.

Sliding Labels v2
Form label keeping the label inline, but sliding it off to the left rather than going away on click.

Javascript-techniques-87 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Ketchup Plugin
Ketchup is a slim jQuery Plugin that validates your forms. It aims to be very flexible and extendable for its appearance and functionality.

Javascript-techniques-84 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Layout tools

jQuery {css}designerGrid Plugin
{css} designerGrid is A jQuery Plugin developed for website interface developers who use the grid system of layout. {css} designerGrid is intended to assist these developers with CSS prototyping.

Javascript-techniques-80 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

css-template-layout
JavaScript (jQuery) implementation of the CSS Template Layout Module

Javascript-techniques-33 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

How to create a fluid grid with jQuery
Grid-based layout is probably the more preferred way to style up a webpage to give it more magazine-like look and feel. This tutorial is about how to use CSS and Javascript to create a fluid grid-based layout (See demo here). The algorithm/procedure used in this tutorial is very simple and straightforward. There are more advanced algorithms out there which can handle multiple scenarios. But the purpose is to understand the basic logic on how to create such layout. So here it goes…

Javascript-techniques-51 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

closure-templates
Closure Templates are a client- and server-side templating system that helps you dynamically build reusable HTML and UI elements. They are easy to learn and customizable to fit your application’s needs. Closure Templates support JavaScript and Java and use a data model and expression syntax that works for either language. You can also use the built-in message support to easily localize your applications.

Javascript-techniques-46 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Useful jQuery Plugins

TipTip jQuery Plugin
TipTip detects the edges of the browser window and will make sure the tooltip stays within the current window size. As a result the tooltip will adjust itself to be displayed above, below, to the left or to the right of the element with TipTip applied to it, depending on what is necessary to stay within the browser window. TipTip is a very lightweight and intelligent custom tooltip jQuery plugin. It uses ZERO images and is completely customizable via CSS. It’s also only 3.5kb minified!

Javascript-techniques-65 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

jQuery Roundabout
Roundabout is a jQuery plugin that converts a structure of static HTML elements into a highly customizable turntable-like interactive area. (And now, not just turntables, but many shapes!)

Javascript-techniques-69 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

jParse – jQuery XML Parse Plugin
jParse is a jQuery plugin that allows you to parse XML that was fetched with the jQuery .ajax method (making it fully customizable).

Javascript-techniques-72 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

jQuery Quicksand plugin
Reorder and filter items with a nice shuffling animation.

Javascript-techniques-48 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

typeQuery, change website typography with jquery
typeQuery gives the flexibility to change the font-family for everything you define with class, id, or tag, this example is referring to the selected item on a select object with id=”tag” and the font-family value at select object with id=”family”: $($("#tag").val()).css("font-family", $("#family").val());

Javascript-techniques-70 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Flip! A jQuery plugin v0.9.9
Flip is a jQuery plugin that will flip easily your elements in four directions.

Javascript-techniques-55 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Data Encryption With JavaScript: jCryption
jCryption is a jQuery plugin for encrypting POST/GET data submitted by forms. It uses public-key algorithm of RSA for the encryption & has a PHP file for handling the decryption of data.

Javascript-techniques-24 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Minimalist jQuery: 11 useful plugins under 4K
jQuery makes our lives easier. So much so that it’s tempting to use it all the time, inadvertently slowing our page load times (cue YSlow and Hammerhead). Combining, compressing, and delivering scripts at the end of your page helps in the HTTP request department. On the file size front, below are jQuery plugins that give solid bang for your performance buck.

Javascript-techniques-79 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Undo/Redo in jQuery
An easy-to-use plugin for adding undo/redo capabilities to a jQuery application. It is based loosely on the Objective-C/Cocoa way of doing things.

Javascript-techniques-81 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

editease
editEase – jQuery CMS | no fuss, no database, no worries

Javascript-techniques-78 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

jsHub
jsHub is a single piece of JavaScript (a “tag”) that can handle reading different sorts of page information and then send them to many different vendors’ products. One piece of code to send to Google Analytics, Omniture SiteCatalyst, WebTrends and Mixpanel. Instead of one piece of JavaScript per vendor, jsHub has a single piece of code (the “hub”) and plugins that know how to translate into the required wire protocol for each vendor. Vendors only maintain the plugin for their product.

Javascript-techniques-22 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Educational JavaScript Resources and Tutorials

Caffeinated Simpleton
JavaScript is an amazing little language, but it’s got some quirks that turn a lot of people off. One of those quirks is this, and how it’s not necessarily what you expect it to be. this isn’t that complicated, but there are very few explanations of how it works on the internet. This article is an attempt to explain how this works and how to use it properly.

Javascript-techniques-07 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

What You Need To Know About JavaScript Scope
This article discusses how JavaScript handles scope and how various JavaScript libraries provide methods for dealing with it and how they smooth out a few bumps. We’ll also look at how you can get back to basics and do some interesting scope wrangling without a library, a useful approach if you’re writing code that needs to stand alone.

Javascript-techniques-25 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Learning Advanced JavaScript
A very nice tutorial to learn JavaScript, containing code and discussion from the upcoming book Secrets of the JavaScript Ninja by John Resig.

Javascript-techniques-30 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Highlight search terms automagically with JavaScript and mark
Script surrounding the search term(s) with the mark element rather than a span, although the class searchword is retained in case you want to style these marks differently from others. In the CSS, the rule article mark is just added to turn it a gentle shade of pink.

10 Really Helpful Traversing Functions in jQuery
With jQuery, selecting HTML elements is laughably easy. But at times, we may wish to further refine the selection, which can be a hassle when the HTML structure is complicated. In this tutorial, we’ll explore ten ways that we can refine and extend a set of wrapped elements that we wish to operate upon.

Javascript-techniques-74 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Using keyboard shortcuts in Javascript
If you want to enhance your web app, Javascript keyboards shortcuts is definitely something to consider. In this article, you’ll learn to use JS keyboard shortcuts, with and without the JQuery framework.

Javascript-techniques-29 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Code Conventions for the JavaScript Programming Language
This is a set of coding conventions and rules for use in JavaScript programming.

Javascript-techniques-31 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

jQuery – Select element cheat sheet
This cheat sheet helps you to find the index of a selected option, set the selected option by value, set the selected option by text, insert a new option before or after another and get the text or value of the selected option.

Javascript-techniques-76 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Compare JavaScript frameworks
Modern Web sites and Web applications tend to rely quite heavily on client-side JavaScript to provide rich interactivity, particularly through the advent of asynchronous HTTP requests that do not require page refreshes to return data or responses from a server-side script or database system. In this article, you will discover how JavaScript frameworks make it easier and faster to create highly interactive and responsive Web sites and Web applications.

Javascript-techniques-77 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Park your Horse, Code Cowboy: Professional JavaScript Workflows, Part 1
In this series, we’ll talk about tools & techniques you can use to cover those No’s, and cut a lot of strife & embarrassment from your JavaScript experience.

Javascript-techniques-47 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

JavaScript Reference examples (example source code)
JavaScript Reference examples, organized by Objects, Properties, Methods & Collections. Some Event Handlers Reference are also available.

Javascript-techniques-20 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

JavaScript best practices
A compilation of best practices and good advice I’ve amassed over the years, much of it learnt the hard way (experimentation and suchlike). Take the advice below to heart and keep it in a part of your brain that has a quick access route so you can apply it without thinking about it. I am sure you will find things to disagree with, and that is a good thing – you should question what you read, and strive to find better solutions. However, I have found that following these principles has made me a more effective developer and allowed other developers to build upon my work more easily.

Javascript-techniques-15 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

wtfjs
JavaScript is a language we love despite it giving us so much to hate. This is a collection of those very special irregularities, inconstancies and just plain painfully unintuitive moments for the language of the web.

Javascript-techniques-41 in 45 Fresh Useful JavaScript and jQuery Techniques and Tools

Related Posts

You may be interested in the following related posts:

Poll

What programming language should we cover in next round-up?surveys

© Smashing Editorial for Smashing Magazine, 2010. | Permalink | 63 comments | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: , ,

0
Your rating: None

AJAX Libraries API

I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.

Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!

At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.

When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:

  • Caching can be done correctly, and once, by us... and developers have to do nothing
  • Gzip works
  • We can serve minified versions
  • The files are hosted by Google which has a distributed CDN at various points around the world, so the files are "close" to the user
  • The servers are fast
  • By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
  • A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.

This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.

Details of what we are launching

You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.

The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.

For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:

PLAIN TEXT
HTML:

  1.  
  2. <script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script>
  3.  

The second way to access the scripts is via the Google AJAX API Loader's google.load() method.

Here is an example using that technique to load and use jQuery for a simple search mashup:

PLAIN TEXT
HTML:

  1.  
  2. <script src="http://www.google.com/jsapi"></script>
  3. <script>
  4.   // Load jQuery
  5.   google.load("jquery", "1");
  6.  
  7.   // on page load complete, fire off a jQuery json-p query
  8.   // against Google web search
  9.   google.setOnLoadCallback(function() {
  10.     $.getJSON("http://ajax.googleapis.com/ajax/services/search/web?q=google&;v=1.0&;callback=?",
  11.  
  12.       // on search completion, process the results
  13.       function (data) {
  14.         if (data.responseDate.results &&
  15.             data.responseDate.results.length>0) {
  16.           renderResults(data.responseDate.results);
  17.         }
  18.       });
  19.     });
  20. </script>
  21.  

You will notice that the version used was just "1". This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.

Specifying a version of "1.8.2" will select the obvious version. This is because a fully specified version was used. Specifying a version of "1.8" would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for "1" will end up loading version 1.9.1.

Note, these versioning semantics work the same way when using google.load and when using direct script urls.

By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the "uncompressed" parameter like so:

PLAIN TEXT
JAVASCRIPT:

  1.  
  2. google.load("jquery", "1.2", {uncompressed:true});
  3.  

Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.

For a full listing of the currently supported libraries, see the documentation.

Here I am, talking about what we are doing in two short slides:

The Future

This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.

If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT'd ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don't have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.

The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.

Acknowledgements

I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don't use our project hosting facilities.

Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.

0
Your rating: None