That’s right kids, I’m speaking at the 6th International AJAX World RIA Conference & Expo! I’ll be giving a session on server-side javascript, and how it will make your life better, your apps cooler, and your friends jealous!

Read the full entry for details on the session, but here’s a little introductory overview (for the sake of not re-writing everything, I have just copied and pasted the announcement)…

Server-side JavaScript (SSJS) is growing in popularity fast since developers realize it can drastically simplify Web app creation by letting you use using the same technology stack on both the client and the server. While server-side JavaScript is not new - it was a part of Netscape’s vision 10 years ago - times have significantly changed with 10x faster hardware and networks, making that original vision for the Web now a reality.

In this session delegates will learn how to:

• Overcome common hurdles and pitfalls of client-side only JavaScript development.
• Speed up development time by cutting out extra server-side code and processing scripts that are no longer necessary.
• Clean up your code base by reducing (or even eliminating) the number of languages needed to leverage to accomplish common tasks (i.e. Why bother with server-side PHP scripts to fetch database results when you can do it all in JavaScript on the server? Why mess with Curl to fetch content that your JavaScript code can grab in one line?)

(more…)

One of the coolest things about developing ajax-enabled applications and sites is the level of interactivity that you can bring to your users. And perhaps one of the most crucial aspects of this process is adding activity indicators to your site. While a lot of ajax requests can be very fast, it’s still important to let your users know that something is happening. All too often I see people forgetting to add these indicators, purposefully omitting them because there wasn’t a good place to include them in the design, or implementing them poorly. One of the biggest omissions that I see is with live searches and auto-completion widgets, but not without good reason. Activity indicators can break up a good layout, as they can require a fair amount of page real estate. They’re also a major pain to incorporate into your apps, as you often end up writing a lot of redundant code to display and hide different indicators on different pages or parts of a page.

So, what can we do about these problems? Well, if you’re using prototype as a part of your framework, you can register global indicator functions. These get executed when there are active requests, and when the requests complete. However, there’s another dilemma with this method too: Where do you place a indicator that can potentially appear often and keep it from being obtrusive, or, even worse, not being seen as it’s placed outside of the content that’s currently in view? I had to tackle that issue this week while starting development on a new project at work. I wanted to create an indicator that would be in the same place on every page, and that I never had to write extra code to use. View a demo of the solution here.

The solution, in hindsight, seems very obvious and I can’t believe that I hadn’t come up with it earlier: Place a div that spans the entire width of the window at the bottom of the window and make it stick there when the user scrolled. Then use scriptaculous, or moo.fx (whichever you prefer) to show/hide the indicator when ajax requests were made/completed respectively. So how did I do it? Read on…
(more…)