Will the future be written entirely in JavaScript?

No popular language may be as maligned as JavaScript. But its migration to the server side opens the possibility it may become all-pervasive

In 1995, when Netscape was looking for a new brand for its browser-embedded scripting language, the company licensed a variation of the "Java" name from Sun Microsystems. JavaScript was born, creating a mistaken impression (that of JavaScript and Java's close relation) you'll still see some newbs trip over to this day. That shared branding deal would never happen now; the executives at Oracle never watched "Sesame Street" as kids, so they don't share.

As time wore on, Java in the browser withered, and if Google hadn't rescued client-side Java with Android, it would be dead on mobile devices, too. JavaME has always been equal parts technical disaster, marketing faux pas, and dubious value proposition: You want me to pay what to embed that? Meanwhile, JavaScript, despite Microsoft's best efforts to make an incompatible mess out of it, has become the cross-platform language of choice for application developers and platform developers alike.

[ How much do you know about this stalwart developer tool? Find out in InfoWorld's JavaScript IQ test. | Learn how to work smarter, not harder with InfoWorld's roundup of all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]

JavaScript invades the server
Originally a client-side language, JavaScript made quick inroads on the server side. Microsoft offered its JScript fork as an option in Active Server Pages in 1996. In the early part of the last decade, I worked on an Apache project called Cocoon, which was based on XML transformation pipelines. Stefano Mazzocchi, the project's lead and an early mentor of mine, pushed to embed JavaScript into Cocoon as a sort of control language. I thought he was flat-out nuts, but in the end it turned out to be a better idea than developing dynamic websites based on XML pipelines.

Rhino was one of the first embeddable scripting languages for the Java Virtual Machine. While it was originally intended for Netscape's abandoned rewrite of its popular browser in Java, it saw mostly server-side use. This snowball rolled downhill until today, when we have Node.js being adopted throughout the cloud as a language for applications. You know you've hit it big when someone makes a teddy bear parodying your fanboys.

JavaScript? You gotta be kidding
JavaScript has long been derided as a big ugly mess. This is mostly due to the poor browser implementations that are slightly incompatible. Microsoft, I'm mainly talking to you: IE still sucks when it comes to JavaScript. Nonetheless, AJAX -- thanks, Microsoft! -- caused JavaScript to become what a high percentage of modern-looking websites are "mostly" written in.

JQuery became the monster devouring Flash, client-side Java, and most other attempts at client-side browser embedded technologies (read: Silverlight). Meanwhile, Appcelerator, PhoneGap, and other similar frameworks have made cross-platform mobile development a matter of JavaScript programming. Only the most delusional of Apple fanboys actually think they like Objective-C. Uh, the '80s called, and it wants its programming language back.

Meanwhile, Adobe proved with ActionScript -- an implementation based on the "standardized" version of JavaScript called ECMAScript -- that JavaScript doesn't have to suck and you can create decent development tools for it. Unfortunately, Adobe tied ECMAScript to its doomed Flex toolset and weird Flash platform.

1 2 Page
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Join the discussion
Be the first to comment on this article. Our Commenting Policies