New Age JavaScript

rhinojpg.jpgIf you’ve been keeping track of this blog, you might have noticed that I am a big fan of JavaScript. Although you can argue about the fundamental features that a language has, there are several reasons why I
consider JavaScript to be one of the hottest languages out there today
.

A couple of days ago the organization responsible for the new ECMAScript, version 4 (AKA JavaScript 2) have published a revised version of the language overview. Although this is only a proposal, TG1 is no longer accepting more proposals and has started writing the new specs, so this “overview” is pretty much final.

It is no secret that the new version of JavaScript will be heavily influenced by…. no, not Java 🙂 The new JavaScript will be… Pythonic!

Following you can find some of the coolest features of the next big language.

Note: Some of the following features are already part of current JavaScript specs and are also implemented in Firefox 2 (eg. Generators and Iterators).

Type Annotations

Generally speaking types describe run-time values. In the new JavaScript a type annotation can (optionally) be added to a property, to a function parameter, to a function itself (applying to the function’s return value), to a variable, or to an object or array initializer.

Examples:

var x :  String; // declares a string
function  f(a : int, b : String, c : Object) : RetType {
 // arguments are guaranteed to match types
 // return value must convert to or match RetType
}

Classes

Class-based programming is a ubiquitous methodology in the industry. Object-oriented programming as we have known to love it in Java and other languages is supported in ES4 by classes and interfaces. A class describes an object by presenting those properties (fields) of the object that are always present (the fixed properties or fixtures), including variables, constants, and methods. In the JavaScript a class basically defines a named record type derived from another class, or from Object if no supeclass is given, and is immutable.

Example:

class C  extends B {
 function C(m) { mem = m }
 public function getmem() { return mem }
 private var mem : Object
}var c : C =  new C(new Date)

Interfaces

An interface describes a collection of method properties; a class can declare that it implements an interface and then back that up by providing definitions for the

methods in the interface. Then instances of the class also have the type of the interface. In JavaScript an interface is a named record type, possibly derived from another interface, containing only function declarations with no body. A class may implement one or more interfaces

interface I  { function f() }
interface J  { function g(n) }

class C  implements I, J {
 function f() { return "foo" }
 function g(n) { return n+2 }
}

Structural Types

Besides classes and interfaces, types can also be renamed or abbreviated by means of special type definitions, which are helpful in giving names to structural types:

type Q =  {p: int, q: String}
type R =  {p: int, q: String, r: Boolean}
type A =  [int, String, Boolean, Object]
type F =  function (int, String, Boolean): Object
type G =  function (int, Object, Object): Number

Namespaces

Besides the built-ins (public, private, internal, intrinsic) you can declare your own with the namespace directive:

namespace  ns = "synodinos.wordpress.com/"class C {
 public function frob(): int {...}
 public ns function frob(alpha: double): double  { ... }
}

Packages

A package is a value comprised of a package name and two namespaces known as the package-internal and the package-public namespaces. The two namespaces are created by the ECMAScript implementation and are not visible to the program, but the package introduces a block scope in which these two namespaces are both open. The definitions in the package are evaluated in this block scope.

Examples:

//Wrap up  related code in a first-class way
package  org.mozilla.venkman {
 class Debugger { . . . }
 class Inspector { . . . }
 class StackWalker { . . . }
}//Import  names from a package…
import  org.mozilla.venkman.*

//…or  import selectively:
import  org.mozilla.venkman.Inspector

let variables

The let directive introduces bindings into the innermost block object. It is considered as a “better var” because var only introduces bindings into the variable object.

Example:

function f(v1: Vec3, v2: Vec3) {
 if (cross_product_only) {
 	let a1 = v1[0], a2 = v1[1], a3 =  v1[2]
 	let b1 = v2[0], b2 = v2[1], b3 =  v2[2]
 return new Vec3(a2*b3 - a3*b2, a3*b1  - a1*b3, a1*b2 - a2*b1)
 }
 . . .
}

let variables have block scope and in combination with for loops contain an implicit block:

for (let i  = 0; i < n; i++) sum += a[i]
for (let  key in obj) print(key, obj[key])

Here is an example of a block statements using let:

//JS1  idiom:
(function (a, b) {
 var x = b, y = a
 var z = eval(s)
 commit(x, y, z)
})(x, y)//With let much better
let (x = y,  y = x, z) {
 z = eval(s)
 commit(x, y, z)
}

Example of Block Expressions using let:

//In the  JS1 idiom:
return  (function (a, b) {
 var x = b, y = a
 return commit(x, y, eval(s))
})(x, y)
//With let much much better!
return let  (x = y, y = x, z) commit(x, y, eval(s))

Destructuring Assignment

Here are some simple cases of destructuring assignment and bindings:

//Group  assignment and return:
// swap,  rotate, permute in general
[a, b] = [b, a]
[p, q, r] = [q, r, p]//  destructure a triple into fresh vars
var [s, v,  o] = db.getTriple()

//Objects:
let  {'Title': title, 'Height': height, 'Width': width} = jsonResult//for-in  loops:
for (let  [key, {'Title':title, 'FileSize':size}] in dict)
print(key,  title, size)

Iterators

The iterators in the new JavaScript are similar to those in Python:

Example:

let it =  Iterator(["apple", "orange", "banana"])it.next() //returns  [0, "apple"]
it.next() //returns  [1, "orange"]
it.next() //returns  [2, "banana"]
it.next() //throws  StopIteration//The  for-in loop handles StopIteration:
for (let i  in it) print(i)

Generators

When developing code that involves an iterative algorithm (such as iterating over a list, or repeatedly performing computations on the same data set), there are often state variables whose values need to be maintained for the duration of the computation process. Traditionally, you have to use a callback function to obtain the intermediate values of an iterative algorithm. Generators and iterators work together to provide a new, better, way to do this.

A function containing the new keyword yield is a generator: when it is called, it binds its parameters to their values and immediately returns a new generator-iterator object which can be called repeatedly to yield new values:

function  count(n : int) {
 for (let i = 0; i < n; i++)
 yield i
}var gen =  count(10)
gen.next() //returns  0; . . .; gen.next() returns 9
gen.next() //throws  StopIteration
gen.send(value)  //passes value back to yield
gen.throw(exception)  //throws exception from yield

Array Comprehensions

Array comprehensions are a use of generators that provides a convenient way to perform powerful initialization of arrays:

let squares  = [i * i for (i in count(10))]
print(squares)  => "0,1,4,9,...,81"
let  odd_squares = [i * i for (i in count(10)) if (i % 2)]
return [i *  j for (i in it1) for (j in it2) if (i != j)]

Decimal pragma and type

A pragma is a directive that appears at the beginning of a block and its effect is limited to that block only. For doing math you can use the use decimal pragma, which selects a DecimalContext object containing rounding and precision

settings for decimal arithmetic.

//In JS1…
print(79.49  - 35.99) // => 43.4999999999999
//… but  know
{
 use decimal
 print(79.49 - 35.99) // => 43.50
}

In ECMAScript 3 the type double represents a 64-bit IEEE 754 binary
floating-point number. This is needed for backwards compatibility and is suitable for most computations since it takes advantage of the floating-point hardware on current CPUs. In the new version decimal represent a 128-bit IEEE 754r decimal floating-point number and provides base-10 arithmetic to high precision (34 decimal digits) which is is not yet widely implemented in hardware.

11 thoughts on “New Age JavaScript

  1. This is a big step forward 🙂

    I still believe thought that the biggest hinderance with Javascript is the lack of standards. Working around this usually takes time and make the code bloated.

    Technologies like Ajax tend to make things simpler but there’s still a long way to universal acceptance. Even if you look at the job market, JavaScript jobs ads are way less than other client-side technologies. It seems that enterprises trust better the server side than the fat client.

  2. Hi Panos, always nice to hear from you!

    Your response to my post is somewhat stereotypical and to some extend without basis. It is similar to what I hear every time I talk about JavaScript, and I feel it is routed in the early days of DHTML and in some cases to a misconception about the nature of the language.
    You talk about lack of standards when in fact JavaScript is all about standards. Unlike Perl, Python and Ruby (at least today) Javascript actually has a real specification (188 pages of it). Check out “10 reasons why Javascript is the ultimate scripting language”, reason 13.

    If you are concerned about cross-platform web interfaces, it is true that in the past it was hideous. The incompatibilities between browsers made early DHTML hard to code. Even at the beginning of the AJAX era it was hard. The thing is that as time passes by and JavaScript for web front-ends hasn’t gone away, we have witnessed the emergence of frameworks and libraries that provide the developer with layers of abstraction. A good example is Dojo Core and Dijit. With these frameworks it is “easy” to develop, at least to satisfy contemporary expectation (such as poll-driven AJAX). Using these frameworks results in clean and portable code. Even so I must agree with you that if you want to go “cutting-edge” it is still hard. The last few days I’ve been having great trouble making a portable comet-based front-end to work since there is no solid support for that from any framework yet.
    As for AJAX not being of a “universal acceptance” I must disagree with you again. I suppose that while you are reading my answer, there is one or more open tabs in your browser that does AJAX behind your back. Also I bet that one in every 3 sites you visit uses some kind of AJAX. Now compare this with how many sites you visit use Flex or other technologies.

    About the client-side job market, I’m sure that JavaScript isn’t the only way to go. Actually I suppose that Visual Basic and other .NET technologies are preferred for various reasons but you know what: you can code pretty muck any .NET application with JScript.NET 😀

    Finally, regarding the” acceptance of JavaScript in the enterprise”, I will have to take a rain check since I am preparing something in that field, but I need a few months before I am ready to go public. I can only suggest to you that If you want to truly witness the power of this language you must look further than the client GUI. JavaScript is much more than web-development as Java is much more than Applets.

    Cheers!

  3. Hello again Dionysios ,always nice to hear from you too 🙂

    To be honest with you I was kinda expecting this response. For a start I don’t disagree with you that JavaScript is much more than web-development. But you see, the vast majority of people use it just for web development.

    I have orked with JavaScript a lot so I am speaking from personal experience. Last time I used it was about a year and a half ago. We developed a front end, a fully dynamic fat client using JavaScript (or JScript for IE). I experienced several problems testing it with IE, Firefox and Opera (I didn’t even try Safari, although I should have since it’s the only browser who follows the standard fully).

    In general it was working fine but it was the little minor details that were making the difference. And we had to go through all these workarounds in order to resolve them. As you can imagine it wasn’t the best experience.

    But still, the features you present here are a huge asset to the script. Let’s hope that will get the people back to the client (I am a client-side guy myself, despite the fact that I mainly work on the server side) 🙂

    Keep up the good work.

    Panos

  4. Bill Gates here,

    All of this new JavaScript stuff sounds very interesting, but Internet Explorer will _NOT_ be adopting it until 2018 or when Firefox gains more than 50% market share (whichever comes first).

    We are currently struggling to make JScript compliant with web standards as they stand right now, but we are shackled by our support for code written for IE4.

    In the mean time, we are looking for developers that can make IE really “shiny” and Web 2.0 looking. If you have developer skills to write clean, concise, and useful code…. WE NEED YOU! Come work for us and we’ll give you a free copy of MS Front Page!

    [/sarcasm title=”Have a laugh, you’re going to need it if you expect non-Mozilla, non-Opera, & non-WebKit browsers to support this.”]

    —-

    Seriously, I unfortunately think this will flop. Not because it is bad (cause it most certainly isn’t) but because as soon as Firefox and others support it, you’ll try to write some, and it will crash horribly in IE when you try to declare your first typed variable.

  5. Dear Bill,

    As stated in the previous comment, my original post wasn’t about web interfaces. Javascript is much more than that!

    — copy from previous comment —

    I would like to mention that this post is not aimed at browsers and HTML-embedded JavScript. Most of the new features mentioned will either take ages to be implemented by browser vendors or might never be implemented at all.

    — end from previous comment —

    As for browsers I’m just no looking the Google Analytics for http://www.ntua.gr which has about 7000 visits per day:


    IE (in total 77.96%)
    ...6.0 66.19%
    ...7.0 33.37%
    ...5.01 0.15%
    ...5.5 0.15%
    ...5.0 0.14%
    ...4.01 <0.00%
    Firefox 19.92%
    Opera0.72%
    Netscape 0.62%
    Safari 0.38%

    Do you reeeeally have to waste development time for IE 4?

  6. @Panos

    There are several “visions” both regarding the future of JavaScript and the future of the web. To paraphrase Occam’s razor “All things being equal, the simplest solution tends to be the right one”, I feel that Weiqi’s argument that JavaFX Script will reign the next version of the web making the contemporary Javascript-based solutions obsolete, feels very very thin 🙂

Leave a reply to BillGates Cancel reply