In this article we'll look at using scripting tools and languages in business applications. I am a big proponent of using scripting languages. Personally I use JavaScript very often: Why? Because it's fast, flexible and sexy.

Technically, when I refer to JavaScript I actually mean ECMAScript, but I'll call it JavaScript in this article as it sounds sexier than the official standard ECMAScript.

Fast
There are a couple of aspects to a language being "fast" - there is fast to learn, fast to code, fast to fix, and fast to run. Because JavaScript is a relatively simple language, it's very easy to learn. In fact, most developers have already used it in one of the many environments that are already JavaScript based - obviously the web-browser - but also products from large vendors such as Adobe and Microsoft that are highly JavaScriptable.

JavaScript was initially very popular in web browsers, and much hated, because of its inherent difficulty in debugging. Back in the early days, Netscape's server and many e-commerce products, such as Broadvision and popular environments such as Microsoft ASP, allowed you to code in JavaScript (Microsoft calls it JScript though, as they don't like words that begin with Java). Thankfully, those days are long gone. Today, almost all application servers and CGI scripting languages allow you to use JavaScript as the primary scripting language.

In addition, there is a huge knowledge base of battle-tested code available out there on the Internet and JavaScript is great for the Google Generation. If you do a quick Google search on JavaScript + whatever issue you're trying to solve, most of the time you'll find a ready-made script for it.

Now, I realize that some coders coming from the "good old days" where they coded everything themselves may not like this, but I personally disagree. Google is a key tool in your programming productivity. Yes, it is still important that you understand what you are doing, so don't be like a PHP newbie who starts just pasting random strings of code together and then starts crying on a forum that it doesn't work. However, there's no reason you have to "go it alone" and re-invent the wheel every single time. Get a good understanding of the basics of the language, then start working with it - and don't be afraid to reference other people's work when you need to.

The second area of "fast" - speed of coding - is really self-explanatory: JavaScript takes much less time to code compared to programming languages. Because you write less code, it is also much easier to maintain. Less code is good - less to write, less to debug, less to fix and less to maintain. The ease of the language is really a great thing. All the basic functions (like ifs, whiles, etc.) are very easy to learn, and until you are ready for it, you can avoid from the more complex (and powerful) constructs, including objects, iterations, x dimensional arrays, etc.

In the past, one of the biggest downsides to JavaScript has been the speed of execution. Again, thankfully those days are behind us. Today, if you need to run JavaScript inside an application client-side or application server-side, you can simply compile it to Java classes using, for example, the excellent open source and free Rhino from the Mozilla foundation.

Rhino works so well that Sun even implemented it inside the Java 6 platform. Another side benefit of Rhino is that you can easily jump back and forth between Java and JavaScript. For example, if you already have a great Java class or if a third party offers a Java API, you can seamlessly use both languages in your code. This will not only reduce your time-to-market, but will also greatly increase your productivity through code reuse.

If you are running JavaScript in a web browser, you're potentially opening yourself up to a big security risk. That's because the code is in human-readable form, so it's possible for a savvy end user to potentially modify your business logic and send the code back to the server.

To avoid such a potential security hole, make sure your client-side JavaScript is limited to events in UI processing and stay away from pushing business rules - keep them on the server side. This is especailly important if your application is using AJAX. While AJAX technology allows the pages to be more interactive and responsive to the user - choose a lightweight framework that does most of the "heavy lifting" server side. This keeps your pages fast, secure, and because the logic is running server side - it's much easier to debug.

Using tools like Rhino aren't just for the client - server-side applications can greatly benefit as well. Many times these JavaScript compilers will have good performance and low memory footprint as well. I often see them scaling much better than even native J2EE apps.

Another big problem with client-side JavaScript has always been debugging. Recent research indicated that developers spend over 50 percent of their time in a debugger, so having good debugging tools that are productive and easy to use is key. Fortunately, this need has been addressed by a great open source project in the Eclipse world, with the Dynamic Languages Toolkit (DLTK).

With DLTK, you get a full-blown JavaScript debugger right inside your Eclipse IDE (the most widely used and free IDE on the planet at the moment). The DLTK is a full-featured debugger and allows you to step through code, set breakpoints, watch variables - everything you would expect in a "normal" debugger. DLTK is not only limited to JavaScript, it can also be used to debug other scripting languages as well. You can get all the details at http://www.eclipse.org/dltk.

Flexible
When using a scripting language over a more "traditional" language, you have a much higher degree of flexibility. First, scripting languages are less strict in how you write code, in their variable typing, etc. Second, although JavaScript is object oriented, it allows you to work in a fairly procedural way that can be a great benefit if you come from a more traditional 4GL background. In particular, if you are more of an application developer than a geek who loves to implement the latest design principles, this is very useful and you'll find that you can use your current knowledge to get up and running quickly.

On top of the language's inherent flexibility, JavaScript is cross-platform so you don't have to worry if Windows will continue to dominate or if Linux or Mac will turn out to be the next "big thing" in terms of operating systems. The issue of a non-Windows OS is becoming a bigger and bigger issue.

While only five years ago nearly all businesses were running Windows exclusively, Linux and Mac are now becoming key players. Apple has recently stated that one out of every five computers sold is a Mac, so you definitely want to be able to have your applications run on the Mac platform and increasingly (and server side) on Linux as well. Also, in light of the current economic outlook - being able to truly "write once and run everywhere," while being able to do so with a short learning curve and flexible language - is a strategy worth taking a look at.

I've personally met and talked to hundreds of developers, and based on what I've seen, it really comes down to the old 80/20 rule. Twenty percent of the programmers are simply brilliant and they don't really need languages like JavaScript - they can code in anything; and for the other 80 percent, JavaScript is great - you can get your work done and it's simple. For many years I tried to become productive in C++ (which we were taught in college) but I never got to like it. I then tried Java, and although much better, I still missed raw productivity and found it overly complex to get things done. Once I moved to JavaScript, I found my nirvana - no nonsense and raw productivity coupled with the all the flexibility I need.

Sexy
Scripting languages are sexy! They are easier to learn, attract more young developers and are hip! Many AJAX frameworks allow you create great looking applications or UI additions with very little coding. There are a lot of developers out there who, regardless of the language used to build it, underestimate how important it is for your applications to look great and be simple to use. Many developers give detailed scientific observations about why 800 ugly fields on a screen is better than 10 that look fantastic. Less is very often better, particularly combined with a great look and feel.

A lot of developers have either worked with a 4GL in the past, or are still saddled with one, even today. Most business applications that are around now found their start in FoxPro, Delphi, Clipper, Progress, or even desktop databases like Access.

The reason behind this was simple: people needed to solve a business problem, and they needed to solve it in a short amount of time. Also, they needed to have it do something very specific, and usually it was so small in scope that it "fell off" the list of the IT department. And, as we all know, where there is a need (or perceived need), end users will often just do whatever they can to make something "just work."

Because these users were often either slightly technical, or they had someone in their department (or company) that was, they gravitated toward the 4GLs for their ease-of-use and their ability to (usually) handle all the underlying low-level functionality (windowing, menus, network connections, database connections, memory garbage collection, etc.) automatically.

While this turned out some very useful business applications (and even some vertical market commercial software products), these early, primitive tools often came bound with their own proprietary databases, scripting languages, IDEs, and runtime clients. In addition, they focused on what the application did, rather than how it looked - and only offered primitive user interface objects (buttons, fields, labels, lists).

Because many of these old 4GL tools were created before cheap and plentiful SQL databases, and way before the age of the Internet, there are literally tens of thousands of "ugly" but functional business applications out there that are operating in their own data silos. To make matters worse, a large majority of these 4GL vendors have either abandoned the product altogether, or are trying to "patch" their legacy code with "web" features while running the tightrope of backward compatibility.

In many cases these older applications were written by several different developers over a number of years. Many times there is a lot of redundant, obsolete, or buggy code that simply is left in there just so "nothing will break." To compound matters even more, most of the newer, more modern applications are being written to take advantage of SQL databases, browser-based interfaces, and native clients that don't require a new install on every desktop for every new version, etc.

If you come from a background of the old (and boring) world of 4GLs, coding in a modern language like JavaScript is definitely an upgrade worth making. It's fast, flexible and sexy - and will help to improve your time-to-market, help reduce the ongoing maintenance costs, reduce overall complexity of your code, and put you in a position to keep up with the future changes in business models and technologies over time.