You Know You Should Use JavaScript When…

You know you should use JavaScript when the task cannot be accomplished with any other technology.

That's what Doug suggested when I asked him for a nicer spin on a something that was going through my head:

JavaScript: If it can be done in another language, it should be done in another language.

That just sounds so negative, which is definitely not what I'm getting at here. But I am trying to make a point. JavaScript is capable of doing taks that can also be accomplished in other languages. JavaScript is also capable of doing things that cannot be done in any other language. Some examples are probably in order.

Form Validation

You can validate a form with JavaScript. You can create a great user experience doing it this way, but of coures you'd be dumb not to validate all the inputs again with a server side language before processing them. If you are going to pick one or the other, go server side. If it can be done with another language, use the other language.

Inserting Content

I just had a circumstance where I needed to load in a block of dynamic navigation onto the homepage of a site that was created by a CMS in a subdirectory of the site. Ideally, this navigation would be created in a file that could be server-side-included on the homepage and anywhere else that needed it. Long story short, I couldn't make it happen. Instead, I used jQuery load function to grab the block. Works great, unless you don't/can't use JavaScript. If it can be done with another language, use the other language.

In a similar vein, the whole concept of AJAX is generally regarded as a hack. It is a way to simulate two-way communication in a technology built for one-way delivery. When something new comes along that more naturally accommodates two way browser-server communication, AJAX is gone. If it can be done with another language, use the other language.

Styling

JavaScript is capable of applying styling to elements on the page. That's also the job of CSS. Having a bunch of styling information in the JavaScript muddies the water. It makes the JavaScript harder to read, and styling updates more difficult to track down. If it can be done with another language, use the other language.

One of the major reasons JavaScript libraries are popular is because they open up some awesome design possibilities. You can fade things in and out, animate sizes and positions, and do it with smoothness and style. But these things are design related, not (usually) functionality related. Hence, we are seeing CSS starting to accommodate doing these same exact things. I would argue CSS is the appropriate place for this, rather than the somewhat hacky "rapidly altering the DOM" technique JavaScript libraries use. If it can be done with another language, use the other language.

When TO Use

Alright enough don't-use cases. There are many more circumstances where using JavaScript is the only option. How about events? JavaScript is the only language available for having your website communicate with the browser and watch for events: clicks, double clicks, mouse enters, mouse exits, key presses, browser window sizing... the list goes on. If you need access to those events, you are in JavaScript territory.

Am I right? Is this narrow minded thinking?

Share On

Comments

No, that is most definatly NOT narrow minded.
The way I work is as follows, my basic design philosofy is that a website should degrade gracefully completly under all circumstances:

1) I design the page in HTML. It should look good, accessible and logical.
2) I write the PHP scripts/functionality I need.
At this point the site should be fully functional to everybody.
3) I style the page with CSS.
4) I write the JavaScript I need.

Step 4 may overwrite some CSS or PHP but that’s ok, since it will fall-back to that functionality if javascript is disabled.
The same applies to CSS, if it is disabled, the pages are still viewable, readable and functional.
Everything in CSS and js is “added candy” to me.
Rarely I stray from this workflow (but sometimes one cannot help it). So it is not a set rule, but I do try to live by it.

“JavaScript is capable of applying styling to elements on the page. That’s also the job of CSS. Having a bunch of styling information in the JavaScript muddies the water.”

Here, you are correct.
However, when you say:
“One of the major reasons JavaScript libraries are popular is because they open up some awesome design possibilities. You can fade things in and out, animate sizes and positions, and do it with smoothness and style.”

You disagree with:
“If it can be done with another language, use the other language.”

It might muddy the water, but there is no real way of out of things if you want to have a cutting edge design right now…

You are definitely right!
I think JavaScript gets overused too frequently and libraries are often too code heavy for page download times. Mootools for example is a heavy framework that a website visitor will typically download for one simple animation that could be done much simpler. But if you have to use JavaScript, you should put it in an external file and take the cluttered code off the page.

You make some valid points, but I’m going to have to take a different stance here (respectfully).

I agree that relying on JavaScript to perform the main operations of your application is the wrong thing to do.

I love using JavaScript. I think it’s an amazing and excellent language. If you use it unobtrusively, it becomes an amazing set of tools. (Even Ruby on Rails utilizes some JavaScript for some of its built-in functionality).

When I think of using JavaScript, I think of using it in conjunction with my main code. It’s there if the user has JavaScript enabled to enhance my site, not to perform its main functionality.

Client-side validation is a convenience for your user to not have to wait for the entire page to refresh to see they missed something, and you’d have to repopulate their fields if you didn’t want them to lose the data (or have the state saved in .NET which has a ton of overhead).

A good example is in John Resig’s book Pro JavaScript Techniques, where he describes having an image gallery set up. The image links pop the image up in a modal window to view; however, the page gracefully degrades for users with no JavaScript.

Using unobtrusive JavaScript, you can have all your scripts in a separate file, so your main page isn’t muddied at all. Using event delegation, you can append the modal window functionality to all your image links.

In summary, I would say that this post is good and you made some good points, but I think you’re looking at it the wrong way.

I don’t disagree with any of this, so I’m not sure how our stances differ.

In the modal example. The desire is to have a modal popup window of an image. JavaScript is the ONLY way to do that, so of course you use it. Making it degrade nicely is of course ideal, but using JavaScript is a requirement for the whole modal concept.

I think the statement “if it can be done in another language, use the other language” somewhat conflicts with the idea of graceful degradation and what Matthew is pointing out. For instance, form validation can be done solely on the server side, but the best alternative currently is server and client side validation. That way you have all the benefits of a cleaner and more responsive ui if js is enabled while still being able to fall-back on server side validation if it isn’t. The “use another language if possible” statement implies that you always should choose a js alternative if one is available and leave it at that. Graceful degradation on the other hand implies “enhance the experience with js, just make sure it is still functional without”.

Another problem that needs highlighting is that too often programmers use JavaScript without giving due thought to what would happen if JavaScript cannot run (e.g., the user has turned off JS).

When JS use is unavoidable, that’s one thing, but using it when there are alternatives available, without providing fallbacks (especially for functionality critical to correct operation) is just bad design.

Yes, Right you should use javascript when you need but if you say form validation can be done with php, right but when complex form you should use both javascript and php, because in complex form a small javascript can save your and your user’s bandwidth. Am I right?

@Hitesh: You should rely on PHP to validate your forms, but you can use Javascript to make the form easier to use and prettier (this could include an extra layer of client-side validation). But I am sure you still want your form to validate completely even if javascript is disabled, right?

I tend to agree. Thankfully you don’t go into evangelism… too often recently I’ve seen people stuck on “do that with CSS, not with JavaScript!” and getting all uppity about it.

Personally I think that if it looks good and works good with JavaScript, I don’t mind using it. I usually turn off JavaScript to see if it degrades gracefully, but there have been times that I’ve used it even when not.

On my personal site, I’m probably going to get rid of a lot of JavaScript (it’s currently using a slider that doesn’t serve much of a purpose to be frank); but on the corporate site of the company I work for, if the customers don’t have JavaScript enabled, they probably are never going to be on our site anyhow–we make Java Applets that are loaded by JavaScript. ;-)

Good article Chris. I think the failure to recognize your premise will become *more* of a problem as the Javascript libraries develop. The temptation to do everything with one language will be strong if we do not build a good understanding of the place each piece of technology has on a website (CSS/PHP/etc).

However, on super dynamic web applications, I think its OK for javascript to pull much of the weight that we traditionally put on the server side languages. That being said, the difference between a web app that solves a business need and a public website targeting a huge range of users is immense.

What you present here is definitely the rule that should be broken only in very specific, calculated use cases… not the other way around.

Whilst I agree with your premise, we need to work out how to educate the clients as well.

I can’t be that specific thanks to an NDA, but I’m building a web-application that in its first incarnation was almost all PHP and MySQL wrapped in a bit of HTML and CSS of course. I had about 10 lines of javascript for some client-side form validation.

Then the client started getting specific about the design content. Suddenly there’s buttons to click, things that hide or display, live updating of various bits of content… the JavaScript has grown from a nice small file to a monster (although it’s still smaller than loading jQuery).

It’s possible if I coded in Ruby or Python I could go back and write it that way, but the PHP/Javascript match-up is doing the job.

It’s fine to say don’t don’t do this if you have another choice, and for sites where I have the control I don’t. I agree with you. But until we educate the clients to not ask for the twiddles, JavaScript and/or AJAX is all too often the best solution to hand.

As much as I don’t like to over complicate my code anymore then it is, I think that javascript is a must for just about every web project. Unless you are trying to save a lot of time, money and the user experience is not a high priority; Always use javascript. Keep in mind though, when doing so that your page will still load as rapidly as it did with out javascript.

Nice article. In my work, I use Javascript to help the user confirm what they should be doing (like form validation) but I always back it up with PHP or whatever server-side language I’m using. To me, Javascript is mostly for looks, not functionality and especially not security.

This might be too “elementary” of a statement but a simple “slider” can be done in flash but I despise flash so the “if it can be done in another language…” statement is disagreeable in this instance. Is it wrong to NOT use flash here? (If so, I’ll be doing it wrong).

I disagree. Proper use of flash can have thousand times more effect on the user than plain old html. Not just video or audio, (in case of audio, have you seen Yahoo Media Player? It’s completely with no flash!) but animation. And web apps! Flex is the most powerful I’ve ever seen.

I (and many other web savvy) users block flash by default. Using it for any kind of actual content to me is absurd (bar the regular uses e.g. video/audio). I’ve seen sites that use flash for navigation(?!), needless to say, I did not return to that site again.

I 100% agree with this. I do work on a PowerPC Mac sometimes. It’s very good for using Photoshop, it flies on it. My 1.0GHz G4 runs faster than my 2.8GHz Dual-Core AMD Athlon. I won’t go into why, since it’s a long topic…

But!, the flash player for PowerPC Mac is TERRIBLE. It’s incredibly slow, and any site I go to that uses sIFR crashes Safari.

I love that people like Flash, and that’s great. I’m a Flex Developer in my spare time, but I do believe that it is only good for niche websites (where you are 99% sure of your target audience or internal development) or wrap it in AIR and drop it on the desktop.

If there’s a home-grown alternative to JS, use that. If your clients can use Javascript instead of Flash, which can be done in 90% of the cases, use that.

I can produce a Javascript (frameworkified) alternative for most of the features that flash has.

Very interesting, a philosophy I like to incorporate into my projects is to “use the right tool for the job at hand.”

I would much rather combine HTML with CSS to achieve effects because it’s lighter and users are less likely to have either disabled (if it’s even possible to have those other technologies disabled).

When it comes to forms, a server-side language is the way to go. Not only will people always get the server-side end of things, you have less security holes to worry about.

JavaScript scripting can cause heavy load times on web pages as well, I always think it’s best to use the technology with moderation and to realize the blurred line between functionality and style when using JS or CSS.

If I can get away with relying on HTML/CSS/PHP, then that’s the route I take. I want accessibility for my visitors, being pretty should come after. Naturally it only makes sense to make sure JS doesn’t hamper your website. Use it for enhancement, not core functionality that would break if a user didn’t have it.

For the form validation, you have to put your validation logic in the backend anyway. For whatever reason. For example, to build a secure app. the malicious user can easily bypass your frontend validation and post invalid data by plain http post. also, if you are build something big, you might possible have different frontend, webpage, desktop app, java webstart etc. the validation will be part of logic and has to be done in backend.

so backend validation is enough? absolutely NOT! To get a nice user experience, really couldn’t think any reason why we dont do the validation in the frontend. no matter how nice you did for the serverside validation (keep all entered data and highlight the error fields etc), it takes your user 2 seconds to see the results, by not mentioning some sites will lost all captured information.

javascript validation, it just a such small effort but with great gain. :)

This is great post, Chris. JavaScript shouldn’t hold application features. Maybe effects and animations are good candidates for using JavaScript. Another area JavaScript (jQuery) is useful is rapid prototyping :)

I totally agree with you. However I disagree with some comments in regards to avoiding JS frameworks. (I used to be one of them) You have to face the fact that this is where the web is heading and I am very sure that JS Frameworks will soon be directly included into browsers or cached for all websites (You can do this today by using the Google projects link for instance). Also good compression and use of distributed content networks help speed up the site. Size and distribution of these frameworks still needs attention, but it’s the way forward. I can’t live without them as they open up a new world of better usability (And backwards compatibility for that matter!)

I’m going to take the opposite approach with regard to “if the user has javascript disabled” and the whole graceful degradation thing.

Um….2001 called – it wants its graceful degradation back.

Seriously, how many people are surfing today’s web without javascript? Every browser on earth supports it out of the box – even mobile browsers – no downloads or plugins required (like flash). Also, letting javascript do some of the work takes the load off the server. My site uses some CMS and a lot of php includes – and it’s taxing on the server. (I understand there’s memcache and the like)

The frameworks – I use jQuery – handle a lot of browser-related issues nicely, and have simplified writing JS code to the point it’s almost fun!

JS used to be seen as a fancy-pants way of doing flashy, but unnecessary things. That’s no longer the case. JS handles a lot of the workload on a lot of sites these days, making pages look and act much more professional.

As far as AJAX being a hack – well what isn’t a hack? It has changed the web completely and works incredibly well. Again, the frameworks make it a 3rd grade level task these days – simple as can be. Love it.

I think the arguments for graceful degradation and avoiding javascript sound dated to me. Yes, graceful degradation will open your site to the absolute widest range of users – but are you supporting users without a mouse? Users without good eyesight? Users without a monitor (ok, I’m gettin crazy) – but you see my point.

I might use the argument “avoid using Flash” in place of avoiding javascript. Nobody seems to worry about avoiding flash, when today there are a lot of things you can do with jQuery or one of the other libraries instead. I agree with Jeremy – javascript frameworks are the way forward.

As an owner of such an old phone you can’t really expect the get a full web browsing experience. Only since the Opera mobile 9.5 and the iPhone browser came along mobile phones really get used for browsing. You can’t support every old phone, how would we otherwise ever progress?

On most cases, at least with my usual audience, maybe 1 in a 1000 will not have JavaScript enabled, or have a very old browser. Also, most of them have relatively new computers, which would have no problem with client side processing.

That said, I usually have no problems at using jQuery/JavaScript if it’s easier, even if I could do it in another language.

JavaScript is all about the user experience (UE, UI, UX, UIE…). It should not be relied upon for anything, but rather should be used to enhance the user’s experience. Think of it like the thermometer embedded in the rearview mirror of a luxury car. It’s a nice thing to have, but it doesn’t help the car run.

I guess if you’re building sites for people using IE5 or an 8 year old mobile phone, then you got me. You win – can’t count on javascript. Otherwise, I would really love to know WHY you guys feel you should never use javascript unless absolutely necessary. I keep hearing “don’t use it” and “don’t count on it” – but not why.

Every modern browser has supported it for many years now – and it’s no longer just a language for “useless UI stuff” – it has grown tremendously in recent years and the libraries are pushing the limits even further – and with cross-browser abstraction even.

Are you really going to decide what programming languages and techniques you’re going to use based on the fact that 1 out of 1000 visitors is using a browser from like pre-2001 or has javascript disabled? Really?

I mean, hey – to each his own. But the “only for UI enhancement” argument just seems totally dated to me. I think we’re way past that now.

Like stated above, there are a lot more UA-types out there than just browsers. But even so, it si not about “don’t use it”, it is about “use it wisely”. Most javascript programs that do something other than UI-stuff can be done in PHP or ASP. So why not use that?
Javascript has it’s uses, even for non-UI stuff. But using it should never break the page…that’s the whole issue. And that page may be viewed by a phone, a palm-top, a braille-reader, a screanreader a bot, a…etc. etc. Do they all have javascript? NO.

– Have Java script enabled
– Use broadband connections
– IE 5? Who uses it on my website?
– IE 6, my scripts works without pain on IE 6.
– Liked the changes made on the website using javascript: accordion and simple hide and show options to clean up the interface.
– Lightbox’s improves user experience, reduces server requests.
– The site is still usable for those “aliens” with JavaScript disabled. ;D

Form Validation:
should be done using a mix of server and client side validations. Is about a efficiency, why SPAM the server with simple petitions to validate simple things that can be validated on the client side such telephone numbers, ZIP codes? Let the Advanced Validation be done by the server.

Styling:

I use JS to reassigning css classes to the content.
CSS are defined on the css files. But it lets the user to change the way the content is being displayed ( switch the position of the content.. play with the css on the fly). Customizable interfaces are almost a Must on some type of communities and websites.

Example: gmail, facebook

Inserting Content:
Well, if this the only way… then use JS & Ajax.
If using JS/ajax is a benefit, and it reduces the server load, OK, use JS.

Javascript is not a sin on web design/dev (well implemented) if it not makes your website bloated like the Homers Simpson’s (Mr X) ;D.

I totally disagree with this statement: “In a similar vein, the whole concept of AJAX is generally regarded as a hack. It is a way to simulate two-way communication in a technology built for one-way delivery. When something new comes along that more naturally accommodates two way browser-server communication, AJAX is gone.”

AJAX is the browser-implemented technology that supports two-way communication (without a new page load – you could always do this with simple request/response that is the core of HTTP). If you want two-way communication and don’t want to use AJAX, you can use Flash or i-frames. Now that’s a hack.

Absolutely agree. Ajax doesn’t need to be used, but it IS the current 2-way communication… and to be honest, it works well. If your server side responses come up fast enough, ajax can be an integral part of your website, and with either js or a js lib, like Dojo(I’m a fan), can be seamless and cool looking for a user.

Some of the people “for” graceful degradation (at least one comment in this post, and countless thousands elsewhere) have argued that JS should be used for FX/eye candy.

What the…?

JavaScript is a programming language, not an FX editor. Just because wicked-cool libraries like jQuery and MooTools specialize it (ab)using JavaScript for previously tricky DOM manipulation doesn’t mean that the purpose of JavaScript is for FX.

Whether or not you think that a site should gracefully degrade, etc., is one thing. But don’t hold that opinion because of a misunderstanding of JavaScript!

I partially agree. Javascript isn’t only for FX and eye candy. However, any technology in this world is what the end user (in this case the web developer) makes of it. They decide “what Javascript is”. So if the branch uses Javascript only for FX and eye candy, that’s what it is, not what the engineers wanted it to be several years ago.

There aren’t any super practical alternatives, no. And I’m not saying AJAX is bad. I think it works pretty well and It’s very cool, but it’s definitely a hack, I’m not kidding at all about that. A hack in terms of “we managed to shoehorn this in pretty effectively”, not a hack in terms of “we really shouldn’t be using this. If we could start all over writing all the different web protocols and languages, you can bet the two-way communication stuff would be wildly different.

Yeah, we managed to shoehorn AJAX in pretty well – kinda like how we shoehorned in tables, CSS support, the DOM, etc. Maybe it was “shoehorned in” because it wasn’t in the first HTML RFC or maybe it was the natural progression of the technology.

A lot of things would be different if we started writing this whole thing over from scratch. Javascript and CSS support would be at the top of the list. We wouldn’t have to deal with cross-browser issues, IE conditional comments, table-based designs… but we have to play the hand we’re dealt.

I think that for most situations you make a valid point. Client and server side languages are designed to serve a certain purpose by principal and will be most efficient that way.

It is however not about what engineers made up years back, but what the users / clients demand. If your client wants an online personality with a great accessible site, gracefull degradation is the way to go. There are other situations though.

If your client needs a powerfull back-end they only use within the company, you can be more creative. Server load is a huge factor in a systems performance, so if there is stuff you can do client side, it’s worth looking into. Using a “modern browser” (thanks google!) and having javascript enabled can just be a spec of the system. Since your end-user is your client, this is totally valid.

It’s really important to look what the end-users demands are, that’s the only way you can optimize usability / functionality for them.

I think part of the issue here is the difference between building static web pages with some eye candy vs web apps. If I’m creating a top ten list with a couple of div’s that can show or hide with javascript, then fine – it’s easy to let it degrade gracefully.

But if I’m building a complex, AJAX-based web app – how on earth is that going to degrade gracefully without writing 50 times the amount of code? It would be absurd to try to build a dynamic, interactive, and cutting-edge web app like a mashup using multiple API’s – say Google Maps, facebook, and Twitter on one page along with storing and retrieving dynamic data to and from your database – and have it degrade gracefully. Have fun with that!!!

So to say “not having javascript enabled should never break the page” is not reasonable at all. To say “don’t let javascript break your online magazine article” is fine – but if you’re writing pages that never rely on javascript, you’re not building intricate web apps – you’re building mostly static pages with some eye candy. Huge difference.

I’m not saying it isn’t possible to make it happen – I’m saying how many resources can you commit to handling the 2 out of 1000 people who aren’t using javascript these days?

I don’t think anybody would disagree with the fact that you cannot always discard javascript. And you shouldn’t.
Ok, I partially agree with you, but perhaps we should make a better distinction between web design and web development. Personally I am a web designer, and as such I have very little to do with web-apps. Besides, to me a web-app has very little to do with web-pages. A web-page is a page with information whereas a web-app is an application that works on the internet.
Having said that, I can program in both javascript and php, and there is very little one cannot do in javascript what can also be done in php. And it isn’t 50 times the amount of code. It may be less pretty, but it functions the same. So in that respect javascript -to me at least- is still a “prettifying language”.

Lastly, just to make myself clear. I am by no means an evangelist for this, I use javascript quite a lot actually, but that doesn’t mean I don’t ALSO make sure my pages still work without them. (apart from the odd occasion where a client doesn’t give a sh*t and wants “cutting edge” stuff (whatever that may be)).

This is a great point. It’s hard to argue this stuff while being theoretical, that’s why examples are important.

I agree it’s a whole different ballpack when writing a major application. You make the choice early this thing is going to lean on JavaScript heavily, that’s fine. You made that choice because it makes the most sense because of your resources or expertise or practicality or whatever else. That makes it the “only choice”

I personally am a huge fan and active promoter of Progressive Enhancement and Graceful Degradation as I’m a bit of a usability nut and I’m a firm believer that catering using basic principals can make design and development so much simpler in the long run.

However, the browser has in a way gone full circle in what it’s used for, it was originally an interface for handling simply HTTP and other protocols, then as ‘web design’ and ‘web sites’ kicked off it became about serving ‘pages’.

Now, coding effective HTTP requests is a lot easier and as Brett says I think it is very important to define things like web ‘Apps’ as being very different to web ‘Pages’, a blind person wouldn’t insist on having a way to use Photoshop!

Great post, I agree. With the rise in popularity of libraries jQuery and Mootools, many are switching to using javascript TOO much, especially when it’s not intended. I love these libraries and the added functionality they have to offer, but javascript, especially being browser-based, is not meant for hugely dynamic web scripts.

What would you say is “meant for” hugely dynamic web scripts if not javascript? What is javascript’s “intended use?”

If you’re building a web app and you have a mashup using multiple API’s, and you’re generating, saving, creating, and displaying content with your own database and moving data between different websites based on user input and changing conditions at the same time – like real-time display of several different driver’s GPS data from their mobile phones while plotting changes to their courses on a Google map, live chat, streaming video, a “who is logged in” function – all in real time – how would you gather and display all of that data in real time without relying on javascript and AJAX? You gonna reload your entire web page every single time the data changes (every 1-2 seconds)? How are you gonna even use the javascript APIs that obtain GPS data and manipulate the Google map while allowing the page to degrade gracefully?

I would love to know how one of these old-school thinking “javascript is only for cutesy eye candy and should never be relied upon” people would build the app I’m building while allowing it to degrade gracefully and still fulfill its mission and give a good user experience.

The point is, the browser is indeed becoming the operating system and will interact with the user completely within web apps. Browsers are not just for displaying text and images for clients to read any longer.

I should just stay quiet and let everyone that thinks like it’s 2001 shackle themselves by avoiding javascript while myself and other forward-thinking developers build web apps that can’t be done any other way – but I enjoy the discussions – they teach me a lot in the end.

I agree with most points made here. I think the abuse of javascript libraries is worth commenting on.

Those libraries are being abused, and I am starting to fear the whole DHTML era all over again. I am still trying to forget those awful animations.

It seems that the arguments for javascript aren’t taking business applications into consideration. I can guarantee that a business paying good money for a website wants that website to work under any circumstance.

I agree with you in part. I don’t think any business wants to know their site doesn’t work somewhere. However, the more people you want to include in your support, the larger the cost and time of the project becomes. It think it is important, especially in business cases, that you outline just what should and should not be supported (or who should and should not).

1. Yeah, you should always validate on the server side. That kinda goes without saying if you want good data. However, JS is useful for quick validation feedback without a server roundtrip to give the user quick signals about whether their input is useful. Example: if you validate an “email” field when a user blurs it, you can highlight it in red if it’s a non-valid email. This cuts down on bad form submits. JS form validation should always supplement server side validation.

2. Ajax is not really a “hack”, it’s a tool that should be used when it’s appropriate to request page content without a full page load.

An example: on a site I work on there is a menu in every page that is hidden until a user rolls over a menu item. The content in the menu comes from a slow webservice. I don’t want to slow down every page load by forcing every user to wait for the Webservice, so I only request that content if the user invokes that menu. Good usage of AJAX.

That being said, I see a lot of developers making AJAX requests when they simply could have their additional content hidden in the page and just shown when appropriate.

3. Yes! JS should not apply styling. A pattern I use a lot is to have JS apply a class and keep the rules in the stylesheet with all my static content rules. That way you don’t have to go hunting for styling in your scripts, it’s all just in your CSS.

Try this in the new YUI 3, it’s amazingly easy.

This comment thread is closed. If you have important information to share, you can always contact me.

Treehouse is where you go to learn HTML, CSS, and how to build iOS apps. It's a complete education in modern web and app technology, designed to get you ready for a hot new job or to kickstart your own business.

The Lodge is a member login only area with access to video training on how to build websites from scratch using the best modern tools.

How many people touch the CSS in your current main project?

What now? I have some ideas for you.

Go explore CodePen!

As a front end designer and developer, you should have an account on CodePen so you can save your snippets, present your ideas, and engage with the rest other front end folk. I'd encourage you to go PRO as well, to unlock the full power of CodePen.

Get the newsletter!

You should sign up for the CSS-Tricks newsletter. It's a clean copy of all the blog posts each week, combined together, right to your inbox. If email isn't your thing, there is an RSS feed, iTunes, and lots of other ways to subscribe.

Listen to ShopTalk!

Subscribe to The Lodge!

The Lodge is a members-only, ad-free video learning area here on CSS-Tricks. Just like the free screencasts, but organized into four large complete series. Membership is also the #1 best way to support CSS-Tricks.

We can do the real footer now.

Site Links

Colophon

CSS-Tricks* is created, written by, and maintained by Chris Coyier. It is built on WordPress, hosted by MediaTemple, and the assets are served by MaxCDN. The fonts are Source Sans and Source Code Pro. It is made possible by viewers like you who subscribe to The Lodge and through advertising for products and services I like.