JavaScript split Bugs: Fixed!

The String.prototype.split method is very handy, so it's a shame that if you use a regular expression as its delimiter, the results can be so wildly different cross-browser that odds are you've just introduced bugs into your code (unless you know precisely what kind of data you're working with and are able to avoid the issues). Here's one example of other people venting about the problems. Following are the inconsistencies cross-browser when using regexes with split:

• Internet Explorer excludes almost all empty values from the resulting array (e.g., when two delimiters appear next to each other in the data, or when a delimiter appears at the start or end of the data). This doesn't make any sense to me, since IE does include empty values when using a string as the delimiter.
• Internet Explorer and Safari do not splice the values of capturing parentheses into the returned array (this functionality can be useful with simple parsers, etc.)
• Firefox does not splice undefined values into the returned array as the result of non-participating capturing groups.
• Internet Explorer, Firefox, and Safari have various additional edge-case bugs where they do not follow the split specification (which is actually quite complex).

http://blog.stevenlevithan.com/archives/cross-browser-split

Jasmine 1.2 released

Jasmine 1.2 has been available, quietly, for a few weeks now. But consider this the official announcement.

This release is relatively minor, but has a lot of things under the hood that will make it easier for us to continue to improve the project. Some highlights:

Core Fixes & Features

• New HTML Runner/Reporter (designed by Sean Durham) is now the default
• An improved toEqual matcher for deep Objects

Gem Fixes & Features

• Detection and support for the Rails Asset Pipeline
• All requests served with no-cache headers, helping out when your browser supports them correctly

Development Fixes

• Catch-up on issues with recent Rubygems and Ruby 1.9.3
• Fixed bugs when developing for Jasmine on Linux
• Moved CI to Travis
• Cleaned up the building/concat of jasmine.js
• Overall better task code, now tested, for building & testing Jasmine

http://pivotallabs.com/users/dwfrank/blog/articles/2144-jasmine-1-2-released

JavaScript Style Guides And Beautifiers

Recommended JavaScript Style Guides

1. Idiomatic.js. This is not only highly recommended and very comprehensive, but is also the style guide we've adopted for several of the projects I'm involved in. It includes contributions by jQuery core contributor Rick Waldron, jsPerf contributor Mathias Bynens and many other experienced JS devs in the community. Not all developers agree 100% with the practices it advocates, but that's the great thing about a forkable style guide – it's easy to adapt to your own needs.
2. jQuery Core Style Guide. Perhaps the most popular style guide modern JS developers are aware of, it is used by the jQuery core team, jQuery UI, QUnit and many other projects. Rick Waldron once again had a hand in this as have Adam Sontag and John Resig, also of jQuery fame.
3. Google JavaScript Style Guide. Written by former Google JavaScript developers such as Robby Walker (Closure Linter), this contains several readability best practices that those from a particularly traditional software engineering background will appreciate. Further comments on it can be found here.
4. Dojo Style Guide Another very comprehensive alternative by the people that brought us the excellent dojo toolkit. Interestingly this guide is based on the structure of the Java programming conventions guide. If you like what you see, you might also appreciate dojo's inline documentation sguide, which remains my favorite style of inline commenting in JS.
5. Aloha Editor JavaScript Style Guide This guide comes from the authors of the relatively non-trivial contentEditable-based Aloha Editor. Whilst it recommends the jQuery style guide, it has some useful (minor) additions such as how they suggest styling AMD modules.
6. Crock's Code Conventions For JavaScript Another good guide, although perhaps not as detailed example-wise as others. I feel this has been superseded by Idiomatic.js, but if you strongly disagree with it or the jQuery core style guide, this is a much recommended fallback.
   
   
   http://addyosmani.com/blog/javascript-style-guides-and-beautifiers

JavaScript Primitive Types vs Reference Types

Swipe.js

Swipe brings content sliding to the mobile web to preserve space and allow for new types of interaction. Many mobile web sliders currently exist but few embody all the rules a slider like this should follow.

1:1 touch movement

1:1 movement, as described above, is about tracking the position of the touch and moving the content exactly how the touch interacts. This interaction is very common in native apps.

Resistant bounds

When Swipe is at the left-most position, sliding any more left will increase the resistance to slide, making it obvious that you have reached the end. This detection/resistance occurs at both left and right bounds.

Rotation/resize adjustment

When a user rotates their device (in turn resizing the browser window), the slider resets to make sure the sliding elements are the right size. This is only necessary for sliders without declared widths.

Variable width containers

Swipe allows you to set a width to the container, which designates the width of each slide element. This is important if you do not want a full width slider (the default).

Scroll prevention

Scroll prevention is one of the most overlooked pieces of mobile sliders. Swipe detects if you’re trying to scroll down the page or slide content left to right.

Library agnostic

Swipe doesn’t rely on any library. Trust me this is a good thing. All you have to do is pass in the container element, set some parameters, and BOOM goes the dynamite– you're all set. You may choose to pass the element to Swipe with a library, but it’s not necessary.

http://swipejs.com/

Differences Between jQuery .bind() vs .live() vs .delegate() vs .on()

Using the Bind Method

The .bind() method registers the type of event and an event handler directly to the DOM element in question. This method has been around the longest and in its day it was a nice abstraction around the various cross-browser issues that existed.

The .bind() method will attach the event handler to all of the anchors that are matched! That is not good. Not only is that expensive to implicitly iterate over all of those items to attach an event handler, but it is also wasteful since it is the same event handler over and over again.

Pros

• This methods works across various browser implementations.
• It is pretty easy and quick to wire-up event handlers.
• The shorthand methods (.click(), .hover(), etc...) make it even easier to wire-up event handlers.
• For a simple ID selector, using .bind() not only wires-up quickly, but also when the event fires the event handler is invoked almost immediately.

Cons

• The method attaches the same event handler to every matched element in the selection.
• It doesn't work for elements added dynamically that matches the same selector.
• There are performance concerns when dealing with a large selection.
• The attachment is done upfront which can have performance issues on page load.

Using the Live Method

The .live() method uses the concept of event delegation to perform its so called "magic". The way you call .live() looks just like how you might call .bind(), which is very convenient. However, under the covers this method works much different. The .live method attaches the event handler to the root level document along with the associated selector and event information. By registering this information on the document it allows one event handler to be used for all events that have bubbled (a.k.a. delegated, propagated) up to it. Once an event has bubbled up to the document jQuery looks at the selector/event metadata to determine which handler it should invoke, if any. This extra work has some impact on performance at the point of user interaction, but the initial register process is fairly speedy. 

The good thing about this code as compared to the .bind() example above is that it is only attaching the event handler once to the document instead of multiple times. This not only is faster, but less wasteful, however, there are many problems with using this method and they are outlined below.

Pros

• There is only one event handler registered instead of the numerous event handlers that could have been registered with the .bind() method.
• The upgrade path from .bind() to .live() is very small. All you have to do is replace "bind" to "live".
• Elements dynamically added to the DOM that match the selector magically work because the real information was registered on the document.
• You can wire-up event handlers before the document ready event helping you utilize possibly unused time.

Cons

• This method is deprecated as of jQuery 1.7 and you should start phasing out its use in your code.
• Chaining is not properly supported using this method.
• The selection that is made is basically thrown away since it is only used to register the event handler on the document.
• Using event.stopPropagation() is no longer helpful because the event has already delegated all the way up to the document.
• Since all selector/event information is attached to the document once an event does occur jQuery has match through its large metadata store using the matchesSelectormethod to determine which event handler to invoke, if any.
• Your events always delegate all the way up to the document. This can affect performance if your DOM is deep.

Using the Delegate Method

The .delegate() method behaves in a similar fashion to the .live() method, but instead of attaching the selector/event information to the document, you can choose where it is anchored. Just like the .live() method, this technique uses event delegation to work correctly. 

If you skipped over the explanation of the .live() method you might want to go back up and read it as I described some of the internal logic that happen.

The .delegate() method is very powerful. The above code will attach the event handler to the unordered list ("#members") along with the selector/event information. This is much more efficient than the .live() method that always attaches the information to the document. In addition a lot of other problematic issues were resolved by introducing the .delegate() method. See the following outline for a detailed list.

Pros

• You have the option of choosing where to attach the selector/event information.
• The selection isn't actually performed up front, but is only used to register onto the root element.
• Chaining is supported correctly.
• jQuery still needs to iterate over the selector/event data to determine a match, but since you can choose where the root is the amount of data to sort through can be much smaller.
• Since this technique uses event delegation, it can work with dynamically added elements to the DOM where the selectors match.
• As long as you delegate against the document you can also wire-up event handlers before the document ready event.

Cons

• Changing from a .bind() to a .delegate() method isn't as straight forward.
• There is still the concern of jQuery having to figure out, using the matchesSelectormethod, which event handler to invoke based on the selector/event information stored at the root element. However, the metadata stored at the root element should be considerably smaller compared to using the .live() method.

Using the On Method

Did you know that the jQuery .bind(), .live(), and .delegate() methods are just one line pass throughs to the new jQuery 1.7 .on() method? The same is true of the .unbind(),.die(), and .undelegate() methods.

Pros

• Brings uniformity to the various event binding methods.
• Simplifies the jQuery code base and removes one level of redirection since the .bind(),.live(), and .delegate() call this method under the covers.
• Still provides all the goodness of the .delegate() method, while still providing support for the .bind() method if you need it.

Cons

• Brings confusion because the behavior changes based on how you call the method.

http://www.elijahmanor.com/2012/02/differences-between-jquery-bind-vs-live.html

Touchy.js

Because some things just need to be touched.

Touchy.js is a simple light-weight (1.15 kb compressed) JavaScript library for dealing with touch events in the browser. With no dependencies, just add the script to your page and start hacking.

https://github.com/jairajs89/Touchy.js

FileWatcher

Synopsis

Currently, there is no cross-platform solution that allows a front-end developer to alter some code (flavor agnostic) and immediately see the result occur in the browser.

This is a poor man's solution to solving that problem half way. The code base has been split up into two halves; a script that watches specific URL's for any content changes and another script which gathers the resources used on the page.

This script is the first half.

How It Works

FileWatcher is a constructor function that keeps a in-object cache of the contents of files. When a file is added to the watcher, it is pushed into a queue.

When a watcher is started, it takes the first item from the queue and fires an XHR or one of its cousins (cross-browser down to IE5.5) to fetch the content of a resource.

If the content has never been seen before, it is added to our cache. If there is a change, trigger the listeners.

Next, the file is added back to the queue to be watched. Then, one second later (or whatever the delay is) the next item is pulled from the queue and the process begins again.

Develop with a hands-free refresh

FileWatcher was initially built with a sister script called ResourceCollector. When these scripts are used together, they allow for webpages to dynamically refresh whenever there is an HTML change and seamlessly update images and CSS.

https://github.com/twolfson/File-Watcher