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

By Andrew C. Oliver, InfoWorld |  Software, insider, JavaScript

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 kiddingJavaScript 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.

The syntax of object literals in JavaScript, JSON (JavaScript Object Notation), is now a language-independent data format and has largely displaced XML for data transmission. Even SOAP/WebServices shops tend to support an alternative JSON syntax. It is terser and far faster to parse in the browser and other clients. Besides, who wants to read SOAP headers anyhow?

Originally published on InfoWorld |  Click here to read the original story.
Join us:






SoftwareWhite Papers & Webcasts

Webcast On Demand

HP DevOps KnowledgeVault

Sponsor: HP

See more White Papers | Webcasts

Answers - Powered by ITworld

ITworld Answers helps you solve problems and share expertise. Ask a question or take a crack at answering the new questions below.

Ask a Question