Some JavaScript Resources for Web App Developers

I’ve been bookmarking quite a few guides, docs, and other resources, some of which I thought I’d share here. (Oh and when I say “bookmarking”, I mean saving to a text file. I’m so high tech, dude.)

In particular, if you’re developing large-scale JavaScript-driven applications, some of these might be useful for you. Beginners be warned: Most of these are uber-intense, so not for the faint of heart. Nonetheless, I think beginners can still learn a few things despite the high-level of most of this information.

Essential JavaScript Design Patterns (Addy Osmani)
“Design patterns are reusable solutions to commonly occurring problems in software design. They are both exciting and a fascinating topic to explore in any programming language… In this book we will explore applying both classical and modern design patterns to the JavaScript programming language… This book is targeted at professional developers wishing to improve their knowledge of design patterns and how they can be applied to the JavaScript programming language.”

Principles of Writing Consistent, Idiomatic JavaScript (Rick Waldron)
“All code in any code-base should look like a single person typed it, no matter how many people contributed.”

“Part of being a good steward to a successful project is realizing that writing code for yourself is a Bad Idea^™. If thousands of people are using your code, then write your code for maximum clarity, not your personal preference of how to get clever within the spec.”

Developing Backbone.js Applications (Addy Osmani)
“In this book, I will be covering the popular Backbone.js, which I consider the best of the current family of JavaScript architectural frameworks…. The goal of this book is to create an authoritative and centralized repository of information that can help those developing real-world apps with Backbone.”

Writing forward-compatible websites (MDN)
“This page explains how to write websites that do not break when new browser versions are released. This is especially important for intranets and other non-public websites; if we can’t see your code, we can’t see that it broke. It’s not always possible to follow all of these, but following as many of them as possible will help future-proof your website.”

JavaScript Patterns Collection (Shichuan)
“A JavaScript pattern and antipattern collection that covers function patterns, jQuery patterns, jQuery plugin patterns, design patterns, general patterns, literals and constructor patterns, object creation patterns, code reuse patterns, DOM and browser patterns.”

Efficient JavaScript (Mark Wilton-Jones / Opera)
“Traditionally, a Web page would not contain much scripting, or at least, not much that would affect the performance of that Web page. However, as Web pages become more like applications, the performance of scripts is having a bigger effect. With more and more applications being developed using Web technologies, improving the performance of scripts is becoming increasingly important.”

Patterns For Large-Scale JavaScript Application Architecture (Addy Osmani)
“I’m currently a JavaScript and UI developer at AOL helping to plan and write the front-end architecture to our next generation of client-facing applications. As these applications are both complex and often require an architecture that is scalable and highly-reusable, it’s one of my responsibilities to ensure the patterns used to implement such applications are as sustainable as possible.”

Got Any Others?

As usual, Addy Osmani dominates authorship in these types of references. I swear, that guy doesn’t sleep.

If you know of any other higher-level JavaScript resources for assisting in building efficient, scalable web apps, feel free to share them in the comments.

Source : http://www.impressivewebs.com/javascript-resources-web-app-developers

Should the Standard Property Be Omitted for Some CSS3 Features?

As many of us have learned, vendor prefixes are a pain in the butt to maintain, and it’s great that CSS preprocessors and client-side scripts are available to help in this regard.

Although I’ve recommended that the standard property be listed after the vendor-specific lines, for “future-proofing” the code, I’m starting to think that might be bad advice in some circumstances.

Why the Standard Syntax is Included

A typical full-vendor block of CSS3 might look something like this:

.element {
	background-color: red;
	-webkit-transition: background-color linear .8s;
	-moz-transition: background-color linear .8s;
	-o-transition: background-color linear .8s;
	-ms-transition: background-color linear .8s;
	transition: background-color linear .8s;
}

The thinking is that, once the standard property is supported, any vendor line that gets rendered would be overridden by the standard property. I think this is fine when there is at least one browser supporting the standard syntax, and when the spec is a little further along.

What’s Realistic Here?

When I code something that works using the vendor syntax and has no standard syntax support, I’ve tested it, the client has approved it, and unless the client gives me instructions for changes, that behaviour should not change. The same would be true to some extent with a personal project. I’ve seen the effects and interactions, and I’m happy with them.

So why would I want the standard property eventually to take over and override the feature I’m already happy with? In some cases I think this could be riskier than we think. If the implementation of that feature changes when the browser starts supporting the standard syntax, this might cause the feature to work differently than we had originally intended.

As far as I understand, for legacy reasons, new versions of browsers should support vendor syntax pretty much indefinitely. Even if the vendor syntax stops working in far-future versions, that’s not a big deal. You’re probably ensuring there are fallbacks in IE7/8 anyhow, so it’ll be fine.

When to Omit?

I think at this stage there are a few CSS3 features that could be better off without the standard property included after the vendor prefixes. These might include transforms, transitions, keyframe animations, and gradients. And it may be advisable to take this approach for experimental stuff like regions or flexbox (although it’s unlikely anyone is even attempting these latter ones in a real-world project).

If you choose to do this, here are the minimum criteria that would have to be met:

• The property/feature is supported by all major browsers using vendor syntax


• There is no standard support in any browser


• The specification is still in flux (which is usually true if the above two are true)

To me this is a reasonable solution. After all, if you were to use a CSS feature that’s not in any specification (like WebKit-only reflections or text stroke) you probably wouldn’t include the standard syntax. Thus, all CSS features for which the standard property doesn’t work can be treated similarly.

Even if the standard property gains support in one or two browsers, you’ll still have support in those browsers for the vendor syntax. But in that case, you won’t have the problem of the implementation changing and things not looking/behaving as they did with the vendor lines.

In fact, you could do something like this:

.element {
	background-color: red;
	-webkit-transition: background-color linear .8s;
	-moz-transition: background-color linear .8s;
	-o-transition: background-color linear .8s;
	-ms-transition: background-color linear .8s;
	/* transition: background-color linear .8s; */ /* uncomment and test */
}

Notice the commented out standard line, with a note. This would remind you to test the code before you actually allowed the standard property to suddenly just take over everything else. Maybe there are better solutions to this, but this is one option.

Thoughts?

As is often the case on this site, this is an informal suggestion that I’m still not totally sold on. More than likely I’ve neglected to consider certain factors. And that’s on top of the fact that I’m not an expert in spec writing or browser implementation processes.

However, even if I’m way off base here, I hope we can get some expert views on record in the comments so developers can make an informed choice on what will work best.

Source : http://www.impressivewebs.com/standard-property-omitted-css3-features

Alternative Units for CSS3 Rotation Transforms

A typical CSS3 rotate transform, with all the gory vendor details, looks like this:

.example {
	-webkit-transform: rotate(360deg);
	-moz-transform: rotate(360deg);
	-o-transform: rotate(360deg);
	-ms-transform: rotate(360deg);
	transform: rotate(360deg);
}

You’ll notice the unit being used to rotate this example element is the “degrees” unit, declared by appending the string “deg” at the end of the unit value.

But “degrees” isn’t the only unit available when rotating elements with transforms. You can also use other units, namely gradians, radians, and turns.

Gradians (grad)

Gradians (also referred to as “gons” or “grades”) are abbreviated using the string “grad” appended to the unit value. A full circle has 400 gradians, which would be the equivalent to 360 degrees. So converting our example from above to gradians would look like this (vendors omitted for all the rest of the examples):

.example {
	transform: rotate(400grad);
}

Because “400″ is a nice round number, it seems these units would be more intuitive for experimenting or could possibly make on-the-fly calculations a little easier.

Radians (rad)

A radian or “rad” unit is expressed like this:

.example {
	transform: rotate(6.2831853rad);
}

A full circle contains 2π radians. If you know what “π”, or “pi”, means, you’ll know that pi is equal to about 3.14, or more precisely 3.14159265. So that’s exactly half a circle in terms of radians. So we double that and we get 6.2831853rad to get a full circle.

So 6.2831853rad is equal to 400grad which is equal to 360deg. As you can see, radians are not as developer-friendly as gradians or even degrees.

Turns (turn)

A “turn” unit is exactly what it sounds like: One full circle. So the equivalent of what we’ve done above, using turn units, would be:

.example {
	transform: rotate(1turn);
}

So this unit is probably the most intuitive to use because it’s exactly what we want: one “turn” unit equals one full rotation.

Browser Support?

These alternate units (along with degrees) are all part of the angle CSS data type.

From my testing, the latest stable releases of Chrome, Safari, and Opera support all three units. Firefox supports gradians and radians, but not turns. Internet Explorer (tested up to IE10 PP2) doesn’t support any of these.

Update: As pointed out in the comments, the latest IE10PP supports all three units, and so does the latest
aurora build of Firefox.

I’ve created a demo page that rotates boxes on hover using these alternate units:

• View Demo

Source : http://www.impressivewebs.com/alternative-units-css3-rotate-transforms

Linking to jQuery: Always Reference a Specific Version

If you use jQuery, then you probably have something a URL in a <script> tag like this in your source code:

http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js

CDN-hosted. Minified. Specific version. Very good.

Of course, if you’re one of the cool kids, then you might be doing the following, as taken from HTML5 Boilerplate:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="js/jquery-1.7.2.min.js"><\/script>')</script>

This ensures that if an edge-case scenario occurs in which the CDN-hosted jQuery is momentarily down, you fall back to a locally hosted version. And bonus points for the protocol-relative URL.

So all is good. Either of those methods is fine, and the latter is better.

The Wrong Ways

But I get the feeling that a few less experienced jQuery users are referencing jQuery like this:

http://ajax.googleapis.com/ajax/libs/jquery/1.7/jquery.min.js

Notice the less specific version number — “1.7″ instead of “1.7.2″.

Or, even worse:

http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js

Notice the whole version number — “1″ instead of “1.7″ or “1.7.2″.

Or, worst of all:

http://code.jquery.com/jquery-latest.js

Notice no version number, just a plain reference to the “latest” version, whatever that might be.

So why is it wrong to link to jQuery using one of those last three methods? And is it ever right to do that?

What About Development?

The only time you should link to jQuery using one of those three methods is during development or when experimenting. You should never use those methods in production.

In fact, by testing how things work in different point releases, you could find a bug and you’d help the jQuery dev team by reporting this. So there are cases, in development, where using these types of general version references could be handy.

Why Not Drop One or More Decimal Versions?

You’ll notice that if you link to jQuery version 1.7 (with the third decimal digit missing), this will automatically reference the most recent 1.7.x release. And if you link to jQuery version 1, this will take you to the latest 1.x release. Some people feel this is best, because it gives you the latest version.

Sure, it sounds good, and we certainly should want to use the latest version of any piece of code or software. But think about IE6 for a moment. Why was that browser’s market share so high for so long? It was because many enterprise applications were built specifically for that browser, and upgrading to IE7 or later would break those applications.

The same problem could occur if you link to a non-specific jQuery version. If you build your website for jQuery 1.7.2, then, unless you later upgrade your code or do thorough testing, you need to ensure that the site references and uses only the 1.7.2 release and nothing later.

Even from one point release to another, there is the potential for breaking changes. For example, Paul Irish tells me that jQuery’s $.browser property will be deprecated in jQuery 1.8. There are other deprecated features that will stop working in later versions, potentially even small point releases.

Yes, even from 1.7.2 to 1.7.3 there could be a breaking change. Although it’s probably unlikely to happen, the mere possibility is enough to demonstrate that it’s not safe to link to jQuery without referencing a fully-specific version.

What About jquery-latest.js?

Naturally, the same principle applies to this. The jquery-latest.js file that’s hosted on jQuery.com seems to always link to whatever is the latest version. But that file is not even minified. It’s obviously not put there for production-level code.

Any Further Technical Thoughts?

If anyone has any specific examples of changes that may have broken a site or app’s functionality in a point release, or if you have any other technical info on why this isn’t a good idea, please comment.

I’ll be happy to update the article if I’ve misstated anything.

Source : http://www.impressivewebs.com/linking-to-jquery

Dealing With Gray-area Comment Spam

Comment spam is still a problem on many blogs, including this one. Fortunately, WordPress’s Akismet plugin does a great job at filtering out most of the worst offenders.

But there are still some “gray-area” spam comments that I’ve tried to deal with. For me, this less-obvious type of spam has the following three characteristics:

• The comment itself is specific to the material, and might even be helpful to the discussion


• The commenter has used keywords instead of a name in the “name” field


• The name links to a website, usually something to do with the keywords

Generally speaking, if a comment gets through my filters and has nothing of value to add to the discussion, and the commenter uses keywords in the “name” field, I will delete the comment.

But, as indicated above, some comments are actually legitimate comments. Unfortunately, the commenter has chosen to include keywords anyhow (and this is forgetting the fact that pretty much all blogs use “nofollow”, thus negating any benefit those keywords might otherwise get).

My Solution

How should such comments be dealt with? I deal with them by providing the following instructions in the “comment rules” on every comments section on this site:

Please use a real name or alias. Keywords are not allowed in the “name” field. If you use keywords, your comment will be deleted, or your name will be replaced with the alias from your email address.

Generally, I prefer real names in the comments, but not necessarily last names. And I will also accept a business name or alias. But if I feel the comment is still on topic and/or adds something to the discussion, I will allow it to remain, but I’ll replace their “name” with the beginning part of their email address. If their email alias is also just keywords, then I’ll just delete the comment. In a few rare cases, where the comment was quite good and the email address was just keywords, I’ve changed the name to “anonymous”.

Is This Ethical?

So my question about this is a matter of ethics. Maybe it’s even a legal issue, I really don’t know. Do I have the right to alter a person’s contributed content in this way, even if I’m not touching the actual comment content? Sure, I have a right to delete it. But do I have a right to alter what they claim their name is?

On Bruce Lawson’s blog, in the footer, he says: “Comments are copyright their authors…” Is this really the case? Does this mean that every blog should indicate such in this way? So if I’ve altered something in someone’s comment, does that comment no longer qualify as being ‘copyright the comment owner’?

This is an interesting situation that I would be curious to hear some opinions on.

Source : http://www.impressivewebs.com/gray-area-comment-spam