JavaScript

Brendan Eich: We Don`t Need Google Native Client

JavaScript founder Brendan Eich expressed his skepticism concerning Google Native Client. Speaking late last month at the O'Reilly Fluent Conference in San Francisco, Eich explained that JavaScript could easily serve the same needs that Native Client is being designed to fill – and JavaScript already boasts wider vendor support than Native Client could hope for.

JavaScript founder Brendan Eich expressed his skepticism concerning Google Native Client. Speaking late last month at the O'Reilly Fluent Conference in San Francisco, Eich explained that JavaScript could easily serve the same needs that Native Client is being designed to fill – and JavaScript already boasts wider vendor support than Native Client could hope for.

Eich was at the conference in part to promote ECMAScript 6, the next upgrade to the official JavaScript specification. Google's Native Client, an open source solution, is designed to run portable native code securely in a browser. JavaScript has been doing this ever since it was first created, 17 years ago. What's more, JavaScript is widely supported by browser vendors such as Apple, Microsoft, and Mozilla. Google might find it difficult to get such widespread support for Native Client; the search giant also makes Chrome, a competing web browser.

In his talk, Eich noted JavaScript's accessibility and its benefits, such as memory safety. Perhaps in response to Native Client's “double sandbox,” Eich pointed out that “JavaScript can sandbox, too. We don't need Native Client.”

Native Client offers the ability to use a module written in a language supported by a Native Client compiler; with options currently including languages like C and C++, programmers who prefer these languages gain the kind of portability one could get from JavaScript. In response, Eich cited the Low Level JavaScript project. This project provides developers with a C-like type system with manual memory management and memory safety. Low Level JavaScript compiles to JavaScript.

So what will ECMAScript 6 offer users? While it isn't meant to change the language too much, Eich noted that it will be better for applications, libraries, and code generators. He emphasized that there was no intention to change JavaScript into Java. But JavaScript developers can look forward to string interpolation, the use of default values instead of undefined values, indexing of objects via another object, and elimination of the arguments object.

Code generator capabilities will also be added to JavaScript; Eich said that “I think we're finally ready for it.” Looking even further ahead, past ECMAScript 6 and still in the research phase, is parallel JavaScript, for data and task parallelism. Eich is delighted that “people are using it [JavaScript] in ways I couldn't foresee.” That's not bad for a language so close to completing its second decade of active use by developers.

DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.