Web 2.0, Meet JavaScript 2.0

Jeremy Martin writes "Well I suppose it's an undeniable fact about us programmer-types — every now and then we just can't help but get excited about something really nerdy. For me right now, that is definitely JavaScript 2.0. I was just taking a look at the proposed specifications and I am really, truly excited about what we have coming."

Ugh

Introducing classes for all of the Java programmers who can't understand a Self-like language. Great addition. Fixing the constructor syntax would have been nice, but introducing classes into a prototype-based language just doesn't make sense. Traits objects already do the same thing and a prototype style is much better suited to JavaScript's primary role, namely defining interfaces (look at some of the papers published by the Newton team in the '90s).

Operator overloading? Great, now you can enjoy C++ style code, where left shift and print are the same command.

All of the proposed changes are a step backwards. JavaScript is currently a language with great, clean, semantics and slightly ugly syntax. They want to make the semantics less clean and the syntax even more horrendous.

Re:Ugh

All of the proposed changes are a step backwards. JavaScript is currently a language with great, clean, semantics and slightly ugly syntax. They want to make the semantics less clean and the syntax even more horrendous.

But wait until Sunday and we'll hear that Javascript 2.0 has arisen and all the stains of previous imperfect languages will be taken away.

Re:Ugh

If that means Java will be thrown into the fiery pit, count me in!

Not sure how far we can stretch this analogy before being cut down by lightning, but I'd hazard to guess that Java followers will be forced underground for, I dunno, a couple of hundred years until finally the Bill Gates of the day embraces it and, under the influence of his Javascripting wife, enforces Javascript throughout the civilized world, with all its imperfections. Eventually, several thousand clockcycle-years later there will be an adjustment to Javascript such that any negative references to Javascript 1.0 will be removed and the world will be doomed to relive all the crap that went before.

Re:Ugh

Introducing classes for all of the Java programmers who can't understand a Self-like language.

I do agree with you there -- we don't need classes. And if we did, we could implement them, in JavaScript.

Operator overloading? Great, now you can enjoy C++ style code, where left shift and print are the same command.

If you really, really want to, then yes. But that it can be abused doesn't strike me as a serious reason for not including it.

I had a problem awhile ago. It was developing for HD-DVD, meaning we didn't have full JavaScript -- meaning I couldn't, say, extend Array. Even if I could, I'm not sure how much better I could make this... I had created a control for displaying a scrolling menu of widgets of some kind. The point is, the control itself shouldn't care about what those widgets are, or even that it's operating on something that's actually an array. It would've been nice to let it work with an array for now, knowing I could always roll something that pretends to be an array later.

Instead, what I ended up doing was wrapping the Array in a monstrosity which contained methods like getValue(), setValue(), etc. It was hideously ugly, but it would tend to work, and would even automatically wrap an Array if needed.

But it's ugly hacks like that which drove me away from Java in the first place. I'd rather duck-type it properly, like I do in Ruby. If it claims to have a working [] operator, and has methods like size() or length(), either it's an array, or it's pretending to be one, so treat it like an array.

Re:Ugh

Introducing classes for all of the Java programmers who can't understand a Self-like language...introducing classes into a prototype-based language just doesn't make sense.

Wrong!

The justification for classes in a prototype-based language is to use type safety properties in library and infrastructure code. Read enough from Brandon Eich and Douglas Crockford and you realize there are strict limitations on what safety properties can be guaranteed by current JS. At least, providing such properties is convoluted and error prone. Classes help provide needed structure for places that JS cannot hope to provide solutions today.

For example, I have a suspicion that Brandon is really attempting to replace the the Mozilla DOM code (C++) with JS2 code. This would simplify the interaction of the garbage collectors (some of those "memory leaks" everyone fusses about, ESPECIALLY in IE) and other infrastructure code.

Classes in JS2 are NOT about needed to emulate Java, so much as it is about providing tools to write robust libraries. Want more proof: MS Silverlight and Adobe Air are both based around JS2-like enhanced scripting languages. Those products make extensive use of the type safety properties brought by classes. This is also Brandon's main complaint against MS ATM. MS is promoting proprietary products with a JS2-like language, but stonewalling support for an open standard (with a robust reference implementation). Think about that for a minute: JS2-like languages are shipping today. Why can't we have a public standard for everyone else to use? Prototypes stay useful, though. MS incorporated extention methods in .NET 3.5, which have much the flavor of prototypes (when combined with generics) in a class-based language. Classes also bring some performance improvements, but that seems to be a secondary concern.

So, we have classes to build robust libraries and prototypes to glue them together with random code. Best of both worlds.

Finally, JS2 is 95% backwards compatible with JS1. The missing 5% is due to clarification of murky parts of JS1 and fixing a few issues everyone complains about. This also obliterates the need for multiple implementations of JS1 and JS2. The JS2 engine can take care of code, old and new. Even with class-based programming and you can "route around" classes using prototypes to extend functionality if you don't need the safety properties (most web code, but not libraries).

Re:Ugh

User-defined overloading, obviously.

Grand-parent gave an example of built-in operator overloading, not user-defined operator overloading. So no, it isn't "obvious" that he means user-defined operator overloading.

From the linked-to article:
Features that are guaranteed to be misused should be eliminated.

What a load of utter bollocks! Show me a feature that cannot be misused, and I'll show you a feature that isn't terribly useful.

If you dont know the difference between a group, a ring, and a field, you have no business overloading operators.

What an arrogant asshole! That's as non-sensical as an assertion that only parents have any business creating class hierarchies.

Re:Ugh

Now, if anyone can tell me why C's indirection operator is the same as 'multiply', and its address operator is the same as bitwise AND?

I always thought it would make more sense to use '$' = 'value of' and '@' = 'address of' for these.

To be fair, "$" and "@" meant currency and apple pie back in that day :-)

I think that by far C's main syntatic problem is using a prefix operator for pointer types and pointer dereferences, when the other type operators (arrays and functions) are postfixes. Because of this mistake, virtually all C programmers to this day, do not fully understand C's declaration syntax.

For example, to declare a function that takes a pointer to a void function(int) as an argument, and returns a pointer to a function(void) that returns a pointer to an array[SIZE] of chars, you would have to write:

char (*(*func(void (*func)(int)))(void))[SIZE];

It also means we have to write:

m->x

because:
(*m).x is required with a prefix operator, and is hard to type.

There are few C programmers who can read that first example. Now lets try a Pointer-as-postfix syntax for the same thing. We shall not use * as a postfix operator, because it would make the expression: "a * - b" ambiguous ("a*(-b)" or "(a*)-b"?). Instead, let us use your suggestion, and make "$" the postfix type operator, and dereference operator, and see the consequences. Lets also put the base-type after the expression instead of before it, and see what happens to the above declaration:

func(function$(int) void)$(void)$[SIZE] char

Note that this simply reads left-to-right now (because we removed the mishmash of prefix/postfix operators), and there is no need for parenthesis to denote precedence, just functions.

The "->" syntax is no longer needed, as like in Pascal, we can have:

m$.x

which clearly means: dereference m and then get the x member.

JavaScript 2.0, Meet NoScript 2.0

... soon.

JavaScript changing into Java

I am getting the impression that JavaScript 2.0 is slowly heading into the direction of Java by adding all those new features. I would not be surprised if the next step will be "pre-compiled" script modules, just like the Java .class files. Adding features to an already existing language is not always making a language better.

JavaScript changing into Python

Actually, if you consider Python to be the opposite of Java (and I very nearly do), just the opposite is happening. Because Javascript is changing into Python, and this makes me happy.

There are indeed many Java-y features being added, such as "use unit" and classes, but these are also Python features. The one feature I saw from the article that looked distinctly Java-ish was static type checking at compile time, and Python will have something similar by the time JS 2.0 is generally usable (i.e. both are optional).

Features in nearer-term versions of JS are even more obviously Pythonic, though. Generators and tuple unpacking, for example.

I'll lay my cards on the table and say that I think Java makes programming laborious and unpleasant, and Python does just the opposite. These features don't seem to make JS any more programmer-unfriendly, and they add a lot, so I'm looking forward to Pythonic JS 2.0.

Javascript 2.0, usable by 2015...

It's all well and good that there's new language features spec'd out, but JavaScript, at least its most common usage (web client-side) has the distinct disadvantage of lowest-common-denominator. Yes, you have JavaScript 2.0 in all it's less-horrbily-broken splendor, and you may even get Mozilla, Opera, Safari to implement it mostly correctly reasonably soon. Hell, you might even get Microsoft to include a halfway-compliant version in IE 8 or 9 (complete with a few proprietary extensions). But you'll still need to support IE 6 for a year or so and then IE 7 support will be necessary until at least 2012.

By the time JavaScript 2.0 is available in nearly all browsers you find in the wild, there will already be a JavaScipt 4.0 spec out and you'll be able to write this exact comment with the dates and browser versions updated.

The point being that client-side programming is a complete mess right now. Instead of new versions of scripting languages, we should be pushing browser makers to allow scripting to be installed via plug-ins rather than being native to the browser. That way, a website can trigger the user to update to the latest version of the language spec (ala the much-maligned-here flash plugin). That should also allow website authors to use any language, not just JavaScript. After all, if you're developing your site in RoR, wouldn't it be easier to use Ruby for the client-side scripting as well as the server-side? The same would go for Python, Perl, PHP (/me shudders) or even Java/Groovy.

But as long as we are beholden to the browser manufacturers to release updates of their browsers in a timely and compliant manner, we'll be stuck in this cycle where we can't use the latest-and-greatest features until they're no longer latest-and-greatest.

"Program Units" - potential for misuse

Reading the article I found "Program Units" to be interesting. Most importantly, how does the running program know that the downloaded script is safe? At first glance it appears that one could easily inject malicious script via a man in the middle attack. Now I'm sure that the designers have thought about this so my question is, how does JavaScript 2.0 protect against this?

William

Re:"Program Units" - potential for misuse

No, really, there's no new security problem here. Different hosts? How is that different to <script> elements pointing to different hosts today? Compromised hosts? What's different to today?

Browsers have been able to download code from disparate, potentially untrustworthy remote hosts since they first started executing JavaScript. You have not discovered a new problem.

I was just hoping someone more knowledgeable on the subject would provide some thoughts on the issues.

Somebody already did, but you didn't like the answer.

Re:Meh.

The main problem is that given MicroSoft's history, I'm not sure I trust it. Who's to say they won't try to use it to somehow force people to their proprietary stuff?

Re:Meh.

Heh. Silverlight is proprietary in it's entirety is it not? Microsoft hasn't released any patents they hold on .net/C# have they?

Re:As long as I got my Framework

FYI, I've done ajax file uploads using jQuery. Works in IE6/7 and FF2/3. See jQuery [jquery.com] and the jQuery form plugin [malsup.com].

Re:v2.0

That depends. http://en.wikipedia.org/wiki/ECMA_Script [wikipedia.org] is on version four.
To paraphrase Palmerston:

only three people ever understood the Java* numbering schemes: a German professor, who went mad, Prince Albert, who died, and Larry Wall - who, asked to come up with something, promptly wrote a perl script and forgot it.

Re:v2.0

I have a hard time imagining this as something that is actually going to be used in cases where there's another option available.

I can. Javascript makes it really quick to hack together a dynamic page. Sure, it results in spaghetti code and the resulting HTML tends to be out of standard, but people will keep using Javascript as long as it remains so damn easy.

Re:v2.0

So you think you know Javascript, eh? Sounds just like 99% of the candidates I interview.

"On a scale of 1 to 10, how would you rate yourself with Javascript?"

"I'd say about an 8."

"Okay, can you write a simple Javascript object on the whiteboard for me?"

"..."

Lucky for them, I mostly looking for smart people I can train. I've only met one other person IRL who even knew how to code Javascript properly.

Javascript makes it really quick to hack together a dynamic page.

Funny, my Javascript tends to be well structured, object oriented, and reusable.

The #1 problem with Javascript is that everyone "learned" it from cutesy little toolbar/cursor scripts rather than actually learning the language. As a result, it's not immediately obvious to most coders how to use the language. Thus they tend to run into variant typing issues and write a procedural mess of spaghetti code. Which is silly, because Javascript has some of the best features of functional languages like LISP!

Netscape published an excellent guide to the language [mozilla.org] over a decade ago (now maintained by Mozilla.org). I'm going to take a wild guess and say... you've never read it, have you? If you had, you might be bemoaning the lack of good Javascript knowledge in the market rather than placing blame on the language itself. ;-)

Re:v2.0

Stop thinking about JavaScript as a Internet language. JavaScript and HTML rendering engines are all over the place now: Firefox Extensions, Thunderbird/Sunbird/Songbird, Dashboard, Adobe Air, Acrobat, the Wii, the iPhone...updates to JavaScript are not useful for the public Web, but are incredibly useful for highly-targeted platforms.

Re:v2.0

Javascript is a decent language by itself. It's the obtuse DOM and the eleventy billion browser incompatibilities that make it appear to suck; no language could look good under those conditions.

Re:Sounds awesome,

Use the error console in Firefox/Seamonkey. Very specific errors.
Seamonkey even has a javascript debugger.

If your using IE, well then *snigger* your screwed. ;)

Re:Cross-Browser

These new features are nice and all, but what I really want as a Web developer is for a Javascript standard thorough and widespread enough that I can write scripts that work on most browsers without a bunch of hacks to make sure that each browser gets the right code. Anyone have a prognosis on this?

You mean this [haxe.org]? An (almost) universal metalanguage that generates the right Javascript/Actionscript/Neko scripts for different environments.

Re:I'm actually not looking forward to this

Java already has OOP, in the form of a Self-like object model. Self is sufficiently general that you can implement the Smalltalk object model in it very easily. The problem I see with many of these 'improvements' is that they just don't belong in the language. The nice thing about the Self family of languages (of which JavaScript is a member) is that it is really easy to add constructs to them without modifying the language. Classes in JavaScript are basically just traits objects, and can easily be implemented on top of the core language. If you want classes, you can add them yourself in a few lines. Same with generics (trivial in any language with type introspection, but not really needed in languages with dynamic typing).

JavaScript is a language with first-class closures and a rich Self-style object model. The syntax is a bit ugly, but the language is really a joy to work with once you get past the 'it looks like Java' stage.

Re:Here's the link to the real info.

At least they didn't add templates.

They did, sort of.

Parameterized types
A parameterized type is a template for new types and is defined by adding type parameters to class, interface, type, and function definitions:

class Pair.<T> {
var first: T, second: T
}
type Box.<T> = { value: T }
function f.<T>( x:T ): T ...

A parameterized type is instantiated by supplying concrete types for its parameters:

new Pair.<int>(3, 4)
f.<int>(37)
var v: Box.<boolean> = new Box.<boolean>(true)

The predefined types Map, Vector, IteratorType, and ControlInspector (among others) are parameterized.
The parameterized types in ES4 do not allow for type parameter constraints or variance annotations. However, nothing precludes the inclusion of these in a future edition of the language.