Personally, I use Firefox for all my web surfing and only use IE when testing websites. But, I know there are many people out there who prefer IE, or who have to use IE because their IT department requires it. In either case, I came across this article over at lifehacker.com and thought I would pass it on to all of you.
April 2008 Archives
We've been conducting several interviews lately for our programmer position. Though the position doesn't specifically mention it, any Web Application Programmer has to be familiar with Javascript. So, one of the questions I have been asking applicants is if they have ever used a javascript framework. If so, which one have they used, and what made them decide on that specific framework. To my surprise, not one applicant answered that they had used a javascript framework.
Wow. If you aren't using a javascript framework, and you have to do any work with javascript at all, you really should consider giving them a try. But let me back up and start out with explaining what a javascript framework is. A framework is essentially a collection of code (library) you can use to make development easier. If you've ever dealt with javascript before, then you are familiar with how difficult it can be to work with, especially when you need to make sure the code is cross-browser capable. A javascript framework can do some of this "heavy lifting" for you and allow you to focus on the actual code design, instead of having to worry about browser-specific quirks. Essentially, javascript frameworks allows you to be more efficient when coding javascript.
Now, you shouldn't go out and grab a framework and start building a site if you aren't familiar with Javascript. Knowing the underlying language will make your code better, and there's a good chance, that at some point, something is going to break. If you don't understand how the framework works, then it's going to be just about impossible to troubleshoot.
There are numerous javascript frameworks available to choose from (this is NOT a complete list!):
All of them have their strengths and weaknesses. The one you go with should be the one that best fits what you are trying to accomplish, has the feature sets you need, and provides the level of documentation that you require.
But that really doesnt help you decide which one to use now does it? Here are the things that I thought about when researching which framework to use:
1. Does it add code bloat to the user's download?
For some of our projects, the page itself was going to be fairly simple. I didnt want to add a 100K javascript file just to be able to add a nice effect. I wanted the framework to be small enough that the majority of our users would not notice the additional download at all.
2. Will it work with all browsers?
We have to support ALL of the major browsers in use, and a good portion of all of those browsers' various versions. So the framework I chose had to have built-in support for as many browsers as possible.
3. Does it have solid documentation?
I do a lot of php development, and php has some of the best documentation available. In some ways, this has spoiled me when working in other languages. I want to be able to quickly look up a function, see a brief description of its purpose and quickly and easily be able to tell what the function expects and what it will return. I also expect a small code sample of the function in use.
4. Does it support code reuse (is it extensible)?
Part of this is dependent on the developer, but I wanted a framework that easily lends itself to building code classes that can be quickly and efficiently reused.
5. Is it unobtrusive and will it support graceful degradation?
Our sites and applications have to be accessible. This means that there is a good chance that some of our users will be using browsers or other technologies that do not use javascript, or might not have javascript available. So I wanted a framework that didn't require me to litter the HTML with javascript everywhere. I wanted to make sure that if javascript wasn't available, the page would quietly degrade back to pure HTML while still providing the user with all functionality and information necessary.
6. Does it have an active community?
No matter how good you are in a language, at some point, you're going to get stuck. I wanted to make sure that the framework I chose had an active, supportive community behind it where I could get some help if I needed it.
7. Does it play nice with others?
I didn't want a framework that pollutes the global namespace and makes it difficult or impossible to use additional javascript libraries on a page. So the framework needs to use a methodology that encapsulates itself from other script on the page, or provides me a method to allow it to be used with other libraries.
In my next post, I'll discuss which framework I'm using now and how it addressed each of my concerns.
Wow. If you aren't using a javascript framework, and you have to do any work with javascript at all, you really should consider giving them a try. But let me back up and start out with explaining what a javascript framework is. A framework is essentially a collection of code (library) you can use to make development easier. If you've ever dealt with javascript before, then you are familiar with how difficult it can be to work with, especially when you need to make sure the code is cross-browser capable. A javascript framework can do some of this "heavy lifting" for you and allow you to focus on the actual code design, instead of having to worry about browser-specific quirks. Essentially, javascript frameworks allows you to be more efficient when coding javascript.
Now, you shouldn't go out and grab a framework and start building a site if you aren't familiar with Javascript. Knowing the underlying language will make your code better, and there's a good chance, that at some point, something is going to break. If you don't understand how the framework works, then it's going to be just about impossible to troubleshoot.
There are numerous javascript frameworks available to choose from (this is NOT a complete list!):
All of them have their strengths and weaknesses. The one you go with should be the one that best fits what you are trying to accomplish, has the feature sets you need, and provides the level of documentation that you require.
But that really doesnt help you decide which one to use now does it? Here are the things that I thought about when researching which framework to use:
1. Does it add code bloat to the user's download?
For some of our projects, the page itself was going to be fairly simple. I didnt want to add a 100K javascript file just to be able to add a nice effect. I wanted the framework to be small enough that the majority of our users would not notice the additional download at all.
2. Will it work with all browsers?
We have to support ALL of the major browsers in use, and a good portion of all of those browsers' various versions. So the framework I chose had to have built-in support for as many browsers as possible.
3. Does it have solid documentation?
I do a lot of php development, and php has some of the best documentation available. In some ways, this has spoiled me when working in other languages. I want to be able to quickly look up a function, see a brief description of its purpose and quickly and easily be able to tell what the function expects and what it will return. I also expect a small code sample of the function in use.
4. Does it support code reuse (is it extensible)?
Part of this is dependent on the developer, but I wanted a framework that easily lends itself to building code classes that can be quickly and efficiently reused.
5. Is it unobtrusive and will it support graceful degradation?
Our sites and applications have to be accessible. This means that there is a good chance that some of our users will be using browsers or other technologies that do not use javascript, or might not have javascript available. So I wanted a framework that didn't require me to litter the HTML with javascript everywhere. I wanted to make sure that if javascript wasn't available, the page would quietly degrade back to pure HTML while still providing the user with all functionality and information necessary.
6. Does it have an active community?
No matter how good you are in a language, at some point, you're going to get stuck. I wanted to make sure that the framework I chose had an active, supportive community behind it where I could get some help if I needed it.
7. Does it play nice with others?
I didn't want a framework that pollutes the global namespace and makes it difficult or impossible to use additional javascript libraries on a page. So the framework needs to use a methodology that encapsulates itself from other script on the page, or provides me a method to allow it to be used with other libraries.
In my next post, I'll discuss which framework I'm using now and how it addressed each of my concerns.
I often get requests to put audio or video files on Web sites and turn them into “podcasts.” Unfortunately, an audio or video file alone does not a podcast make. I often don’t have the communication skills or the time to easily explain that you need more to make a podcast, so I just put the files up.
Now, thanks to CommonCraft there’s a fun and easy video to explain what podcasting is to anybody. Thanks guys!
More videos explaining other Web technologies at the CommonCraft Show.
Thanks goes to my brother for sending me this.
Design Coding
Today in our Web Developers meeting, I discussed the various online tools that many campus developers have become accustomed to using in the Bengal environment but that are no longer available in the VH-Dev environment, due to the fact that VH-Dev is locked down to campus-only. The two bigs ones are W3C.org's Markup Validation Service, and HiSoftware's Cynthia Says Accessibility checker.
The Division of IT has been very cordial and willing to assist us in regaining access to these tools, as long as we can give them a list of sites we need access to. In addition to these two sites, I suggested that we add the University of Illinois at Urbana-Champaign's Functional Accessibility Evaluator (http://fae.cita.uiuc.edu/). Like Cynthia Says, the non-registered site will only allow you to test one page at a time. However, unlike Cynthia Says, you are not limited to one-check-per-url-per-minute, and once you are registered, the FAE will allow you to evaluate multiple URLS, and allow you to include up to 3 levels deep in your site architecture.
In addition, Illinois at Urbana-Champaign also offers a Firefox add-on version of the FAE (http://firefox.cita.uiuc.edu/) which provides a whole host of tools to check accessibility issues on any page you are viewing, and allows you to test dynamically altered (via Javascript) pages for accessibility issues.
Charlie Triplett suggested we also add Geotek's IE Netrender service (http://ipinfo.info/netrenderer/index.php). The IE Netrender captures a screen shot of what your site looks like in Internet Explorer from version 5.5 through 8 beta 1. This is especially great for those who are developing on a Mac and don't have access to IE, or for those who are on a PC who no longer have access to IE6 and/or don't want to install the beta of IE8. Thanks Charlie!!!
If there are additional tools/services that are unavailable to you in the VH-Dev environment, that you would like to use, please contact me and I'll take it forward to the Division of IT.
I also demo'd the HTML Validator Firefox add-on (http://users.skynet.be/mgueury/mozilla/), which allows you to see, at a glance, how many errors/warnings the page you are currently viewing contains. Viewing the source of the page then lists out all errors/warnings, the line number where the error/warning occurs, why there is an error/warning, and suggests a solution. In my opinion, this is much easier than using the W3c.org Validator as the validation of the page is immediate and doesn't require you to submit the page; it's all local.
I'll also take this moment to (yet again) plug the Firebug add-on for Firefox (http://www.getfirebug.com/). From its javascript debugger, to being able to dynamically alter HTML and CSS, to telling you exactly which CSS rules affect the styling of the element you are inspecting, Firebug is an invaluable tool when trying to track down problems with your web page. While historically it has been a Firefox add-on, there's also an option for using it in Internet Explorer, Opera, Safari, etc.: http://www.getfirebug.com/lite.html
Maybe I should do a demo on Firebug at a future Web Dev meeting. Any interest?
