Microsoft has just launched a new website called modern.IE that provides a suite of tools to help developers test their websites.
Page Analysis Tool
The website integrates a scanning feature that let's you enter your website's URL and it will analyze its contents against a variety of best practices (not only pertaining to IE, but also general concerns).
The analysis tool checks for things like...
Checks that common JavaScript libraries are up-to-date
Checks if a range of CSS vendor prefixes are used
Checks if Responsive Web Design is used
Checks if Touch browsing has been considered
Checks if you are using Browser detection instead of Feature detection
etc...
The nice thing about the tool is that it not only finds suggestions, but it also recommends ways to resolve the issues it finds. In addition it doesn't just point out IE specific stuff, but also about more generic concepts like using CSS3 vendor prefixes and to consider responsive web design.
Testing Tools
Microsoft understands that not all developers use Windows when they develop and have Internet Explorer easily available in order to test. So, a special 3 month free testing account is available with BrowserStack.
Not only is this a nice tool for Mac or Linux developers, but it is also nice for Windows users to test old version of IE or if you don't have Virtual Machines handy.
You can also install some handy add-ons to Chrome or Firefox to make the testing experience with BrowserStack even better.
In addition, Microsoft is providing free Virtual Machine images for you to use if you want more control. Even though BrowserStack is awesome for a quick sanity check or to run unit tests, if you are trying to debug something having a local VM is optimal in those cases.
A common misunderstanding I see when looking at jQuery code is a lack of understanding about loops.
Most developers seem to grok the .each() method, but that can be both a good and a bad thing.
It is important to know the difference between an Implicit Loop and an Explicit Loop.
Implicit Loops
The following code snippet is something that you would typically see from a jQuery developer. You are probably aware of the "Find something, Do something" mentality of jQuery. The code first queries the DOM for all elements that have the widget class and then jQuery proceeds to implicitly loop over all of the elements matching the query and adds the highlight class.
Explicit Loops
An explicit loop in jQuery is much more obvious. The code for the loop is visible via the .each method. This is pretty straight forward and typically developers understand that there could be performance issues for any code inside the .each loop.
Indications of Confusion
You can start to tell if a developer doesn't realize the different between implicit and explicit loops if you start to see something like the following code snippet.
In this example there is no reason for using the .each method because there was nothing inside of the loop that is unique. A simple implicit loop, like the following snippet, would have been sufficient.
Method Overloads
Knowing about implicit loops also sheds some light of the following situation.
In the following snippet of code jQuery is looping over the matches elements twice (once to change the color and a second time to change the font-size).
If you needed to write code similar to the previous, you could do something like the following instead and use the "overloaded" .css method that takes an object containing the key/value pairs you wish to apply.
It might seem like the above snippet is slower than the following, but when it comes down to it they are about the same speed. I tend to recommend the last snippet as it is cleaner and more flexible down the road as you can pass in a variable containing all your options.
As a side note, it is preferable to use the .addClass() / .removeClass() / .toggleClass() methods instead of the .css() method to manipulate your elements unless you need to change their width/height/position/etc. The output of the .css() method gets attached to the style attribute of your element. The browser is highly optimized to deal with CSS classes and also whoever is maintaining will thank you for using classes instead of hardcoding style in your code.
Conclusion
Although these concepts may seem very basic, I often run across code that doesn't require an .each method. It is helpful knowing some of these under the cover concepts. I hope you found it insightful.
I was recently approached by someone at a .NET User Group about how to get started in HTML5, JavaScript, jQuery, CSS3, etc... The developer's primary background was writing thick client Windows applications. I figured the best place to start is to focus on the bare essentials and then work up to more advanced concepts and resources. I started to respond to the developer in an e-mail, but then I remembered what Scott Hanselman said in a recent post and video ...
"Instead, consider writing a blog post or adding to a wiki with your keystrokes, then emailing the link to the original emailer." --Scott Hanselman
So, I decided to make this blog post for the developer and also for anyone else who may be interested in similar resources.
HTML5
So, it is pretty obvious that you are going to need to learn HTML5 if you are doing to do front-end web development. From my experience most developers regardless of their language of choice know the basics of HTML. What they may or may not know are all the newer semantic tags, cross-browser tricks, and native JavaScript APIs.
There is plenty to learn in HTML5 without getting into the JavaScript APIs just yet. Once you learn JavaScript and feel comfortable in it, that may be the best time to tackle topics such as Geolocation, Web Sockets, Canvas, IndexDB, Web Workers, etc...
Even if you think you know JavaScript it might behoove you to go back and learn it from the beginning. A common danger is that developers think it looks just like their back-end language of choice (C, C++, C#, or Java) that they don't invest time to learn how it is different.
JavaScript is a dynamic and functional language, which is considerably different than C# or Java for example. So, please take your time and pick up the language. If you don't learn it appropriately you will invariably run into barriers down the road due to lack of understanding.
The jQuery library has been around for several years and has catapulted as one of the most used tools in the web developer's belt. The reason for its vast usage is that it solves many of the cross-browser issues that creep up during development. The library is popular for both web developers and web designers. The community around jQuery is amazing and there are tons of jQuery plugins to choose from.
If you find yourself writing more and more JavaScript and jQuery then you may want to consider picking up Backbone.js to help you organize your web application. This library is also a great fit for Single Page Applications (SPA). Backbone.js uses the familiar MVC/MVP concepts of Models, Collections, Views, and Routers. In addition there is a nice Event model, History support, and a Sync mechanism. The community for Backbone.js is also very large and you can find many extensions and plugins to fit your needs.
You may or may not have experience with CSS. Brushing up on CSS concepts would be a good thing. If you already feed proficient at CSS1-2, then you should pick up CSS3 as well. A lot of features have been added recently that is in most modern browsers. There are many things that you can do in CSS3 now where you used to use JavaScript or custom images.
Inevitably you'll need to support browsers that don't support the native feature you are trying to use. Thankfully you can use Feature Detection to determine if the browser you are in implements that feature and if it doesn't then you can provide functionality to mimic that feature (a.k.a. a polyfill or shim).
Instead of implementing a different UI for mobile devices, tablets, and desktop browsers you can use responsive web design techniques to provide one experience that restructures the UI according to its size.
Hopefully the above resources will get you started in your transition to front-end web development. There is a lot to learn, but it is an exciting space that changes frequently. Having a desire to learn is a good trait to have in this field.
If you have any resources that you think I missed please add them in the comments and I'll try to update the lists above if I think they are appropriate.
The following post contains a emotional filled dialog between fictitious front-end developers "Frank Fowler" and "Mike Morris". In this drama filled exchange Frank decides to upgrade his current project to the latest jQuery release.
Sadness
Frank: Ahh man, I just saw that jQuery 1.9 was released. Too bad my current project is still using the 1.8.3 release.
Mike: Ohh bummer, sorry to hear that. I tested out the beta release of 1.9 that came out about a month ago and didn't have any issues.
Frank: Really!?! Sign... I wish I could upgrade. I don't know if I can convince my boss to invest the time to upgrade and staying on an older version makes me a little sad.
Fear
Mike: You might consider upgrading. They've fixed lots of bugs, enhanced CSS3 support, and added several new features.
Frank: I don't know. It is a big project and I don't know if I can risk all the extra testing. I'm glad that it worked out for you, but I may just have to stay on this old version while everybody else upgrades.
Mike: Frank, an upgrade shouldn't be so bad. The jQuery team does a good job outlining the change log and they have over 6000 unit tests to ensure quality over a suite of browsers.
Frank: Yeah, I guess you are right, but it is such a huge project. What if something goes wrong? Surely something will go wrong, right? I'm fearful that I won't be able to figure it out if there is an issue.
Mike: Well, it wouldn't hurt trying would it?
Frank: I guess you are right. Lets go head and give it a try.
Anger
Frank: Okay, I just added a reference to the jQuery CDN for the 1.9 release to my project. Here goes nothing...
Mike: So, how did it go?
Frank: Huh... WHAT!?! Nothing even works anymore! I knew I shouldn't have upgraded.
Mike: Well, what exactly is breaking?
Frank: Like I said, nothing works! What did jQuery do to this release? Are they trying to hurt the development community? The last version worked just fine for me. I don't know if I can trust this project anymore.
Shame
Mike: Now now, lets take a look at this together. Does your application use some of the features that jQuery deprecated?
Frank: What!?! Deprecated? Umm, well I don't know. When did they deprecate features?
Mike: A while back jQuery mentioned they were going to deprecate features like the .live() method and .browser sniffing.
Frank: Ohh, I guess I didn't realize that. Maybe I should have read the blog post release notes more thoroughly :(
Mike: Yeah, even though they deprecated those features jQuery hadn't removed them until the 1.9 release. So, maybe that is why some of your code is broken. I know you used to use .live(). Did you change your .live() to use the new .on() method?
Frank: Yeah, I never did switch to the new .on() method that they added a while back and the application does do some sniffing using the $.browser object. So, I guess that means I won't be able to upgrade to the 1.9 release.
Gladness
Mike: Ohh, no! The jQuery team planning for issues like this so they went ahead and put all of the removed deprecated features into a migration plugin in case you still need it. That way you can use the new stuff without having to immediately refactor your existing code. The idea is that you can slowly refactor as needed.
Frank: Really!?! Wow, that is so easy. Let me guess, that was explained in the release notes too?
Mike: Yep ;) No probably man, it happens. Now don't get me wrong there are some releases where some bugs are introduced in a major release, but they are usually found pretty quickly and a minor release comes out shortly after. However, with this particular issue there was a planned workaround.
Frank: Why looky there, I just applied the migration plugin and now my app is working as expected. Thanks for your help Mike.
Mike: I didn't really do anything, it was the jQuery core members... you should thank them ;)
You may have noticed that the 1.9 version of jQuery was released yesterday. One of the most excited pieces of the version is support for Source Maps!
What are Source Maps?
What is a Source Map? Well, it is a generic way to translate one script format into another. In jQuery's case, it is mapping the minified version of jQuery against the un-minified version. Why would you want to do this? The value is that when you encounter a bug in your production code you can debug against code that doesn't look like a mangled mess!
Another slightly different example of for Source Maps is for CoffeeScript. The official CoffeeScript language doesn't support Source Maps as of yet, but there is a rewrite of the project called CoffeeScript Redux that does support them. That means you can debug through CoffeeScript code in your dev tools and it will map to the underlying JavaScript code. For more information about this check out Ryan Florence's article titled CoffeeScript Source Maps.
Enabling Source Maps in Chrome
In stable release of Google Chrome there is a setting in its dev tools to "Enable source maps". You will need to check this option in order to use this feature.
Mozilla Firefox is working on providing Source Map support, but as of yet Google Chrome is the browser to use for this feature.
Add the Minified jQuery 1.9 to Your Project
The minified version of jQuery 1.9 has a special directive at the bottom that tells Google Chrome what Source Map to use when debugging. The end of the minified file looks like the following...
In order to get the Source Map to work you need to make sure the value of sourceMappingURL exists on your server or locally. If you are using the jQuery CDN then this is already setup for you.
Once you've completed the above steps then using Source Maps is simple. All you have to do is set a break point, like you would normally, and then debug into it.
For example, on the left I set a breakpoint on the addClass statement. Once I debug into that statement I get dropped into the unminfied version of jQuery NOT the minified version that I included!
Browsers have had a "Pretty print" feature for a while which has formatted minifed script files, but Source Maps brings that to a whole new level!
Conclusion
Source Maps are a powerful new feature of Google Chrome and I look forward to it coming to other browsers in the near future. Being able to debug through minified code could make tracking down production bugs a much easier process.
You may have seen the buzz yesterday about the Critical Microsoft Security Hot-fix (MS13-008). The hot-fix applies to a security issue in Internet Explorer versions 6 through 8. Newer version of IE (9 and 10) are not in danger.
Upgrade to IE9-10 Instead
You could apply the above hot-fix to your existing old version of Internet Explorer, but why? Why not go ahead and upgrade to IE9 or IE10?
Not only will you get more features and a faster browser, but you will also be pushing the web forward. Developers will thank you for having one less oldIE browser to support. The nice thing about IE9-10 is that they follow web standards, which means code that is written to follow standards and practices should just work in IE9-10 and other modern browsers.
Note: IE10 is only available as a Preview release on Windows 7 as of now. A full RTM release of IE10 should be released in the near future. Be warned, if you do install IE10 Preview on Win7 it will replace your IE9 browser.
Others are dropping oldIE (IE6-8)
Others are following suite. Google Apps recently decided to drop oldIE a while back and only support IE9+ and other modern browsers.
In addition popular JavaScript libraries like jQuery are now dropping oldIE support in their upcoming 2.0 release. After jQuery dropped oldIE support an interesting realization came about. Here is a quote from the jQuery Blog...
For a long time browser sniffing was the way developers tested for various browsers and as a result used a different API or feature set. You can always manually detect by using the navigator.userAgent, but making sense of it can be difficult considering the vast amount of userAgent combinations. Some libraries were developed to assit the developer in making sense of the userAgent. A detect library can be found from QuirksMode and jQuery also provides the browser object with some sniffing information.
Problems with Browser Sniffing
As you are probably aware, browser sniffing can be problematic and is the reason that some websites don't work properly cross-browser or in new versions of browsers.
A simple example of where a browser sniff can break down is the following code snippet detecting for IE. The code should check if the browser is IE and if the version is 8 or greater.
The code snippet works just fine in versions of IE 1-9, but breaks for IE10 because the regular expression doesn't account for multiple digits.
You can review many of the bad reasons why you shouldn't browser sniff from the following resources
Note: I mentioned above that jQuery has a browser object, but that feature is deprecated and you shouldn't use it anymore. Also the detect script I mentioned above also has a blurb about using object detection instead of browser sniffing.
Use Feature Detection Instead
Feature Detection is the preferred way to determine the functionality of a browser and to respond accordingly and we've seen that technique used in many libraries such as Modernizr and more.
An example of feature detection could look something like the following.
If you are interested in finding out more about Modernizr or on how to make your own feature detections I'd encourage you to check out the following resources
I recently became curious as to when browser sniffing might ever be acceptable. I mean, surely there must be a valid use case even if it isn't pretty. So, I went on a search on Twitter and I also polled some of my close developer friends on their thoughts. The following is a list of my findings.
Valid Use Cases for Browser Sniffing
I've found the following use cases justifiable reasons to use browser sniffing.
Target specific content to platform a such as Mac or Win download. An example may be a Download link for multi-platform systems.
Gather analytic information for marketing purposes. An example may be getting desktop, tablet, and mobile statistics from users.
Determining if a user is on a particular platform in order to pin their application to the user's home or start screen. An example may be an iOS and showing a tooltip to add the mobile app to the home screen.
In some cases Feature Detection isn't sufficient or there is no way to determine a certain state or behavior. In that case browser sniffing may need to be used. An example of this is in the history.js detection in the Modernizr library.
Do you have any other use cases that you've seen or used that you feel are valid reasons to use browser sniffing? I'd be interested in hearing them.
