jMar"s Blog DevSmash Developer Portal

Tuesday, March 18, 2008

Web 2.0, Meet JavaScript 2.0

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.

I suppose it's important to note that these new features are tentative. The specifications documentation for JavaScript 2.0, ECMAScript Edition 4, is currently being developed by TC39. Although it is still a work in progress, an overview of what has currently been proposed can be found here (PDF). As the team expects to have completed the specifications by late fall of this year, we can expect that most of these awesome improvements will remain in the final version.

So without further delay, here's just a few of the many, many upgrades coming JavaScript 2.0's way:


Had to start with this one - it's so big it had to be first. Introducing actual classes and interfaces into the language is likely the most radical change that will come with JavaScript 2.0. Technically speaking, OOP will be nothing new for JavaScript. JavaScript already has objects and even offers full support for inheritance through the prototype chain - however, prototypal inheritance in JavaScript is tricky business and can often produce unexpected results (especially for those accustomed to classical inheritance in languages such as Java and C#).

Not only is JavaScript introducing classes into the language, is is also doing away with primitives altogether. Null and undefined will be the only not true objects in JavaScript 2.0. Duly, classes such as boolean and string will provide wrapper classes for the sake of backwards compatibility.

As far as creating and instantiating a basic "class" goes, the process will be quite similar to using a constructor function, as in earlier versions of JavaScript. Consider the following examples:

/* JavaScript 1.x "Class" Definition*/
function Foo() {
 this.a = "a";
 this.b = "b";
var myFoo = new Foo(); // class instantiation

/* JavaScript 2.0 Class Definition */
class Bar {
 this.a = "a";
 this.b = "b";
var myBar = new Bar(); // class instantiation

That alone hardy seems worth the overhaul, but classes will provide far more flexibility through its many designators and directives (final, dynamic, extends, implements, etc.). Also note that constructor functions can be changed, whereas classes will be bound as constants, and therefore cannot be changed.

Object Oriented Programming has done to programming what relational databases did to persistence - it has dominated. I can't think of a single thing that I would rather see in JavaScript 2.0 than exactly this.

Compile Time Type Checking

JavaScript 2.0 components can request to be compiled in strict mode. This will test the integrity of several key aspects before execution. A partial list of these checks includes:

  • Static type checking
  • Verification that referenced names are known
  • Checks for illegal assignments to constants
  • Insures that comparisons are only made between valid types

Did I Say Constants?

I sure did. For such an obvious directive, constants have been a long time in coming. Previously JavaScript developers have had to use naming conventions to protect their constants, but that is no longer the case in JavaScript 2.0.

/* JavaScript 1.x constant */
var FOO = 'bar';  // look, I'm all upper cases, so pretty please don't change me

/* JavaScript 2.0 constant */
const FOO = 'bar'; // go ahead, try me...

It may take some time to realize some of the side effects of this change, however, since the constant directive will now be applied to some of the existing core JavaScript objects (such as the pointer to an object's prototype).

Operator Overloading

Cause I am, whatever you say I am, if I wasn't, then why would I... never mind. Misuse it, abuse it, do whatever you want with it. Operators are now whatever you want.

Not Null ("!") Operator

Nullability is a concept that is familiar to anyone who's worked with databases, hibernate annotations in Java, or a whole host of other technologies. In short, it allows you to specify whether an entity can be null or not. Consider the following example:

class Person! {
var x = new Person();

var x = null; // throws error

I'll be honest and admit that I wasn't sure if the error gets thrown on assignment, or when you attempt to read. For now, examples in the documentation are sparse, but either way this will be a handy feature. The mechanism that makes this new operator possible is union types (also new). I won't be delving into those in this article, but they would definitely be worth reading up on at the original source.

Real Namespaces

JavaScript developers have long been implementing namespaces by stuffing everything into a single global object. While this is not a bad convention (and it's much better than cluttering the global namespace), the reality is that it abuses the purpose of objects for the sake of simulating pseudo-namespaces. Well, have a guilty conscience no more, because now you have real bonafide namespaces that are actually made for being, well, namespaces.

Program Units

This is a simple addition, but to me it yields great benefits. Program units allow you to bundle up "program fragments" that don't need to be loaded until requested. This ability has all sorts of potential, not excluding bandwidth optimization.

Perhaps more significant, though, this is also a big step towards providing structured, reusable code libraries. Since the units that you reference will be loaded at most once, you now have a mechanism for maintaining elegant code libraries. Consider the following example:

use unit Person "http://mysite/library/classes/Person";
use unit DisplayUtil "http://mysite/library/utils/DisplayUtil";

var bob = new Person();

Even in this short, fanciful example you can see how your code can start to take on a highly organized and logical structure - much like many of the server side languages you may have worked with. Personally, I think this is one of the strongest improvements found in the specifications.


Well, needless to say, JavaScript 2.0 is shaping up to be a devastatingly awesome improvement. The specifications go on for about 40 pages of size 12 font, so I'm not even going to try and provide a complete overview. But as I've said, everything I've mentioned above can be found in the proposed language overview (PDF) - and there's several more goodies to be found in there as well. Thanks for reading!


Jason Henriksen said...

Enhancements to JavaScript are brilliant. I've coded tonnes of JavaScript in my time, but after using GWT I don't think I'll ever go back. If you can't write Java this is a welcome addition, but if you can write java then GWT + VisualBuilder = Massive Productivity.

Anonymous said...

You have an excellent prototypic language with an ugly syntax, why must everything end up looking like fucking c++?

Schley Andrew Kutz said...

I just had a geek-gasm...Can . not . wait!

mr.fruit said...

what about events, etc...

Adam said...

It's gonna be easy to write insecure code with that "unit" fuctionality.

Anonymous said...

Yeah, I have to agree with anon. This doesn't seem like a step forward to me, or particularly like Javascript for that matter. The functional/prototype fusion was a little odd at first, but after getting used to it, I found I actually preferred it over the class system -- and I sure never miss static typing. If this stuff is more than syntactic sugar and compromises the current state of things, this is a regression. And even if it doesn't compromise the underlying functional/prototype nature, it will lead to an increased Javafication of the attached development community, with lots of "best practices" adopted because they're "best practices", not because the principles behind them are understood and applied.

Constants and namespaces and units are all a nice addition, but honestly, if the language has to acquire the baggage of Java to get there, I'm not sure it's worth it.

Q: "If you could do Java over again, what would you change?"
James Gosling: “I'd leave out classes!"

Unknown said...

In my opinion, they aren't really improving the language. There are no significant difference in productivity between OOP and procedural approaches (

And, they aren't really adding something that couldn't be built some other way before.

JavaScript 2.0 won't be the next Ajax revolution. If they really wanted to revolutionize the web, make it safe and easy to create mashups.

JavaScript 2.0 was created by committee, with no real-world application in mind. This is opposed to gears, which evolved from an actual, and practical need.

jamiegau said...

Or start using ActionScript3 if you want to know what its like....
(From my understanding Adobe has donated its Scripting engin in Actionscript3 to open source and it is the back bone of Firefox implementation of JavaScript2)

JavaScript 2 is GREAT news for AJAX because it willbe 10 times faster to execute.

It just blows my mind how one-eyed javascript programmers are.

I program Actionscript3 and Java. JavaScript is labourious.
Hopefully JavaScript 2 for the browser also brings in a standardised DOM etc.

Anyone considering a "sopfistigated" RIA in AJAX is simply a programmer that only knows one language(well)!

Sure it can be done and works reasonable well, but its very hard to implement and super hard to maintain.


Anonymous said...

RE: "Not Null ("!") Operator"

Are you sure that the error is caused by setting a variable to null? It looks to me as if you get the error because you declare it (var x) twice?

In all other programming languages that I know, you can set an object reference to null

Tobia said...

Pleeease, they couldn't be adding more useless crud to this language even if they tried!

This is the language that's going to run on every browser, and instead of adding actually useful stuff like continuations, actual lists, interned symbols, a cleaner syntax, or--Heaven forbid--a macro system, they go and add Java-like OOP, static type checking and a bunch of other useless shit. Unbelievable.

Anonymous said...

Why are all you guys so negative?

If you don't like the language, do not write anything in it.

If you feel your browser becomes "bloated" with this new "shitty language", just turn javascript off .

Good damn, people. Grow up.

Every real programmer out there knows that this is good stuff.

Or maybe you'd rather see VBScript becoming the next standard in your browser, or ActionScript, or any other proprietary language for that matter.

Charlie Elgholm

Anonymous said...

It seems like the good features are being offset by some bad. Strict typing? That seems like a step in the wrong direction as someone who really likes Python, Ruby, Smalltalk and Objective C.

JavaScript has many powerful OO capabilities already, they're just not advertised or known. Using closures you can create function factories, private spaces, private methods... all kinds of stuff.

I'd hate for JS to look like everything else (PHP, Java, C, C#) and I fear that's where they're going.

Anonymous said...

>>Strict typing? That seems like a step in the wrong direction as someone who really likes Python, Ruby, Smalltalk and Objective C.

No, just a step in the *opposite* direction. Not everyone wants a weakly typed language.

Unknown said...

> I'd hate for JS to look like everything else (PHP, Java, C, C#)
> and I fear that's where they're going.

Hell yeah, imagine if the world would become a better place for all those multi-language developers out there.

Javascript 1.x was a fine idea ages ago when performance was prime and bandwidth scarce, but since these days entire 3D engines and office suites are written in JS it's become an anachronistic moloch that direly needed an upgrade to match other languages in approach, just like PHP5 desperately needed its more mature OOP facilities.

I'll be happy if PHP6 and JS2 fully replicate C++'s OOP concepts and borrow lots of its syntax. Because hey, C and C++ didn't survive for 30 years because they were fundamentally bad ideas did they?

Anonymous said...

So, let's see... it'll hit Firefox maybe late this year, but only be usable there by late 2009. Then, it'll be early 2010 before it hits IE, and 2011 by the time we have all figured out all the hacks we have to do to make things work in both...

I think I'll wait before I start jumping up and down in excitement.

Anonymous said...

I'm with James. I'm an Actionscript developer who's gone from procedural to OOP.

Part of the reason I've been reluctant to work more with Javascript is its lack of OOP support. Javascript as it stands now is ad hoc and incredibly laborious.

It's not just a Java thing, it's a serious programming language thing. Part of being a good programmer is learning not to reinvent the wheel, and that's what portable OO libraries can provide.

And strict-typing, while it might seem like a hindrance at first, makes code infinitely more readable.

Given that Javascript now has such an integral role in web development, it's time for it to graduate to a serious language.

Thanks for the post!

Anonymous said...

Here's some context on that James Gosling quote about classes.

Ralph Dratman said...

Jason Henriksen, you refer to VisualBuilder. What is VisualBuilder? Of course I did a Google search, but I'm still not clear what you are referring to.

Thank you.

Anonymous said...

I must say that with all the security exploits in current poorly written JavaScript, I am hardly excited about giving the poor programmer the OO noose and all that entails. I hope if you guys are the good JavaScript programmers you take the time to educate your brethren on proper secure coding techniques.

Anonymous said...

Boo hoo - you don't want it to look like C++? You don't want it to look and operate like the most robust, flexible and widely used language on the planet? Could it be that you're a hack, not a programmer? A true OO approach will make Javascript massively more usable and useful. This is a vital step if the web wants to move forward with the infamous "Web 2.0"....

Unknown said...

Charlie, the same statements have been made by great programmers, very familiar with JavaScript, take Douglas Crockford for example. He's a member of JavaScript 2.0 EMCA committee and Yahoo's chief JavaScript architect.

I would consider him a real programmer, even if the phrase doesn't really mean anything. And, in my opinion, you are probably using it just to be divisive instead of posing a real argument.

Furthermore, saying we either agree with JS 2.0 or a proprietary language as the next standard is simply a false dichotomy.

I live and breath and have invested heavily in JavaScript ( Yet, there are very valid concerns about JavaScript 2.0.

Please provide a logical argument to why these features are a good thing. And, as I showed in my previous comment, saying OOP doesn't actually help anything.

BTW, I do think OOP will help spread JavaScript's adoption even if it won't actually increase programmer productivity. Also, the performance improvements will be nice.

Unknown said...

For myself, it's ironic everyone clamoring about OOP in JavaScipt. I really craved it too, but after a year of doing nothing but programming JavaScript, I feel differently.

Although JS has objects, people really want classes. I think they are a security blanket for developers. Class based development was probably one of the first things most developers learned. When we are scared, it is the first thing we all reach for. JavaScript is the older sibling who takes the blanket away.

But after it's gone, you realize you didn't really need it anyway. JS provides enough security (figuratively in the form of prototyping) where you can get anything done you really need.

BTW, Before my switch to JS, I programmed C++ for 3 years.

Anonymous said...

First of all, all those of us who have programmed and maintained lean and mean but fairly complex code all know what a bugger javascript was to maintain and we had to do all kinds of hacks that we never liked to present to the world wide web.

For those of us developers who felt at easy to do everything quick and dirty, don try javascript 2.0, it will restrict your quick and dirtyness.

Now I have made my point, I want to move on the a more constructive message: E4X, which will be part of Javascript 2.0 and this will make all of our lifes reallly easy.

We know how crap it can be to first make some recursive script that builds xml on and recursively untangle it from the client... Messsssy. E4X makes our lives more easy:

alert( sales.item.(@type == "carrot").@quantity );
alert( sales.@vendor );
for each( var price in sales..@price ) {
alert( price );

Cool isn't it?

Anonymous said...

Lemme see here...

Strict typing: Optional, good thing.

C++ Syntax: Good. More people can use it.

Security: yeah, still a problem.

Units: Boring.

Nullabilty: Boring.

Constants: Boring.

Namespaces: Useful, sort of.

Operator Overloading: Waste of time.

Events: Yeah, what the hell about events?

Debugging: Any new tools for chasing bugs?

final analysis, it's just the latest programing flavor of the moment. It all sounds nice, but it's not going to change much of anything as I see it. It will take a long time to be the defacto standard and people can still use all their older code (and thus older style/proceures) so it's effects won't be felt for years and then will be incremental at best and not revolutionary. Newer code on older browsers will be a problem. Thanks for the effort, incremental improvements are good, but I'll be a late adopter.

Anonymous said...

JavaScript is a mirror that reflects who you are as a programmer, which is why it's the Best Language. Whatever langs you've touched become evident in your JS code, because it doesn't really have an identity of its own. I've written JS in procedural, functional, classical, and prototypal styles.

Now I'm convinced the way to write strong apps in JS is to build up your own library of functions and procedures, and then just structure your application code in JSON. JavaScript has such a horrible built-in vocabulary, it forces you to, as Paul Graham evangelizes, simultaneously munge the language and your application. I call this existential programming (i.e. you grow your lang with experience), as opposed to orthodox programming, where you use somebody else's abstractions.

This 2.0 stuff is mostly irrelevant to me. Classicism seems dull. All I want is decent E4X support.

Anonymous said...

"It's not just a Java thing, it's a serious programming language thing. Part of being a good programmer is learning not to reinvent the wheel, and that's what portable OO libraries can provide."

Actually... a much bigger part of being a good programmer is knowing how to make and use good reusable libraries without being dependent on any one style of programming (procedural, OO, declarative, etc).

Unknown said...

Operator Overloading: Waste of time.

Spoken like someone who's never used ruby or another language with operator overloading. Operators are inherently meaningful, so it's very nice to be able to use them as methods. For example, to concatenate two arrays, you can just define the + operator so that arr1 + arr2 works, instead of arr1.concat(arr2). The former is far more readable and intuitive than the latter.

Jason Henriksen said...

I said visual builder in the generic sense, but the one I use that I really like is GWT Designer.

You can find it here:

It's one of a few software development tools that I've bought and been very please with. It does have it's occasional glitch, but it's easy to use, easy to extend and 'just works'.

Anonymous said...

How about something useful like wait() or sleep()? This is just fluff.

Anonymous said...

Wrap this with an XML compliant class abstraction for declarative layout and component placement, and you've got Adobe Flex, running right now on 98% of web browsers worldwide.

Anonymous said...

I'm sure IE will work just lovely with JS2, seeing how it does so well with it now and ajax, prototype etc etc

Anonymous said...

With new features, javascript doesn't feel like javascript anymore. :p

Anonymous said...

These so called enhancement to JS seem to be more of add ons than enhancements.

Nothing in the new spec brings any new functionality to JS, and, unless they maintain complete backward compatibility, will actually detract from the powerful language that JS is.

Classical Inheritance, inferior to prototypical inheritance on almost all ways.

Static Type checking, good but only as long as the system is capable of continued Duck Typing. Plus it's useless for dynamic types, or runtime inheritance (a benefit of prototypical inheritance ).

Some of the other stuff is ok, but in general this actually makes JS less Object Orient than it currently is. In the current specification, everything is an Object, now they are creating more and more specialized objects.

Anonymous said...

I am much more excited by proposed features like iterators, generators and list comprehensions. In other words, make JavaScript more like Python, not more like C++.

And it's not because I like Python or hate C++. This is because JavaScript is ALREADY a lot like Python: dynamically typed, has closures, etc. Why not concentrate on what has worked so well for Python over the last 17 years?

Other than superficial things like syntax, JavaScript is not so similar to C++ or Java.

But if "security blankets" (excellent observation justin!) like a more conservative class-based object system or static type checking will help with more widespread adoption then perhaps it's a reasonable compromise. I'm just afraid that by providing them a lot of programmers will cling to them too hard to realize the benefits of using a truly dynamic language.


Anonymous said...

Yay for static type checking. This will help keep out bugs.

Anonymous said...


Anonymous said...

This is just a small step in the right direction - the whole concept of using HTML/JavaScript for anything resembling an application is fundamentally flawed; but I am glad to see that if they're not willing to throw it out and start over that at least some improvements are coming.

Anonymous said...

Some people here are truly ignorant at both sides of the discussion.

1. static typing will not make the language less expressible.

2. replacing the prototype-type based system with a class based system is unfortunate. You can actually create any class based system with prototypes (see for example qooxdoo), but not the other way around. But I think this has to do with type checking.

3. The stuff about null and union types. Ha. Author does not know its trade.

The beauty of javascript was the minimalism. It was such a small language, yet so powerfull.

Anonymous said...

> Spoken like someone who's never used ruby or another language with operator overloading. Operators are inherently meaningful, so it's very nice to be able to use them as methods. For example, to concatenate two arrays, you can just define the + operator so that arr1 + arr2 works, instead of arr1.concat(arr2). The former is far more readable and intuitive than the latter.

That is already easily possible in ruby. Ruby is so flexible, I think it is a mix of class-based and prototype-based language.

The problem I have here is that Javascript is only useful for web-apps.
Now, web apps will continue to grow, but anyone here using javascript as a "scripting" language to checkout git stuff and similar?

But this is where I use Ruby. And I use it for EVERYTHING I can get a hold on.

For me I would be happier If i could just use ruby instead of Javascript. Ruby is simply a better language than Javascript will ever become.

By the way, calling Javascript a prototype language is weird. If you want a real prototype language, rather look at Io. Javascript seems very weird and way too specific to the browser world. I'd much rather have the OPTION to choose which language I would use (in this regard, I hope both Python and Ruby will win)

Anonymous said...

Maybe I was missing the point here, when I read the article, and the specification, and then all your comments..

I thought the "new stuff" was all optional - since the engine still needs to be backward compatible.. Am I wrong?

If you doo' like the new OOP "class system", don't use it. Prototyping will still work, right?

If you don't want strong type checking, don't use it. Wasn't it optional?

And to Justin, I'm sorry if I upset you with my last posting. Maybe I'm just stupid and have got this whole thing backwards. After all. I've only been programming Javascript the last 7 years and before that C++.

Btw, I'm not a hysterical fan of OOP. So I won't be using the new class "stuff" in Javascript. But I think the other stuff sounds interesting, even though I see fairly small usage for constants and nullability.

The unit thing however, is very interesting since that would make the clients only download stuff that they use, and I can separate my application logic into smaller and more structured pieces.

And please guys, if you REALLY NEED operator overloading; use it sparsely and with implicit understanding - it's a pain in the *ss coming back to heavily overloaded code a couple of years later trying to debug it.. "You can't do that with a + sign!"... I've been there. =)


Anonymous said...

I've written plenty of javascript and ajax and for me, as a developer, it really doesn't matter if a language is loosely of staticly typed.

Maybe this OOP approach is a good thing...i'm not so sure completely...but what you are going to get is an invitation to write heavier code, more intricate and complicated.

The only thing that matters to me are:

(1) Good software tools (debuggers, IDEs, etc.)

(2) Good performance (good JS engine)

If I have both, I don't care if JS has clases or not.

sonicwind said...

ditto what the guy above this said. I don't see any features mentioned that will make javascript programming easier or add more features. I just had to rewrite a javascript application after finding that under certain circumstances the performance was too slow. Posting back and having java do the processing turned out to be way-way faster. Not to mention the development IDE and debugging features provided. If they're not going to add any real features, they need to have some kind of performance enhancing compile options as wells as script compression.

Anonymous said...

One feature I would really like to see in JavaScript 2.0 is verbatim string literals like C#:

var myDiv = @"<div>Here's my Div</div>";

That way we can type out the markup to be inserted in a nice, easy, readable manner...

As opposed to writing dozens of lines of DOM methods or concatonation to create the markup.

Jeremy Martin said...

Thanks for allllll the input - apparently this got some attention on reddit and slashdot while I was internetless over the weekend.

I guess just to respond to some of the common themes I saw in the comments:

1. Backwards compatibility is one of the chief concerns in JS 2.0 - so if you still prefer doing prototypal inheritance through functions - then why not?

2. To whoever made a comment about adding a sleep() or timeout() - I'll second, third, and fourth that. I guess that's just one of the curses of single-threaded execution.

3. To those who think classes are evil - I don't think I'll be able to agree with you there. I've heard the "extends is evil" argument - and in some cases it could be true. But trying to do "implements" with prototypes is 10 times hackier than doing "extends" - whereas it'll be built in with the new specs.

4. To the guy who thought JS isn't a true prototypal language - I've heard and would agree that JavaScript is best understood as a prototypal language that was made to look sort-of-like a classical language - hence the last decade of confusion.

5. To the operator overloading haters - I'd have to say I'm not a huge fan myself, but in principal I'm all for giving more power to the developers. I don't really think that a language should be designed to protect the developer - if you can't hang yourself, you don't have enough rope.

6. Units are boring? I'm saddened... :p

Anyway, I'm short on time right now, but thanks for the huge response!

Anonymous said...

Well, i think this is really going to be a good improvement. Javascript is, in our days, very used because of web 2.0. With these improvements, i think we will see more friendly scripts, and dare i say, improvement on the execution times as well.

Anonymous said...

Great overview!

I am so happy that JavaScript is starting to look more like a real programming language! It will be good times when JS 2.0 launches.

Do you think that the browsers will be able to recognize it right away?

There will probably be problems for a while because of all the people that will have older versions of the browsers...the worst thing about client side languages, building code for such a large audience...

Jeremy Martin said...

@Random Thoughts
Getting browsers and developers alike to adopt JS 2.0 will be one of those natural obstacles that these types of technologies face. I imagine it'll somewhat resemble the adoption rate of CSS3... ick....

Anonymous said...

I'd sure like to see a more object oriented approach to js programming.  I read John Resig's "Pro JavaScript Techniques" and I understand that js' object capabilities are quite good and quite different from class based oo.  I'd just hate it to keep looking more and more like C++. Come on, C++ never was and never really tried to be a real object system. It just tried to make it easier to build bigger systems in C and correct some oddities while at it (how well it did is a matter of another discussion.)  If you want object orientation, look elsewhere. How ever, and that's the sad part for the purist in all of us, if you want to leverage the familiarity with the syntax and the concepts already gained by millions in programmers, then go ahead and make yet another clone of C++  If you wanna make things right, then keep the good bits already in javascript and maybe pay some attention to objective-c or ruby or (dare I say) Smalltalk

Anonymous said...

It's very clear that a lot of the posters here fall into the VERY large pool of programmers who haven't REALLY got javascript properly yet. There's 'tinkering' in javascript, and then there's REAL programming. Once you get past a certain stage you start to see that there's HUGE potential and some very interesting benefits & impressive techniques in JS's EXISTING OO implementation.

To start with, I felt like these inexperienced noobs. The ones who know php or c well, but don't know javascript well. But as I've learnt more I now see Javascript as something new & exciting over php + c etc. It's model is intruiging.

Anonymous said...

To anyone who's posted here about how good it is Javascript will "get OOP", this just shows your complete incompetency in javascript. It ALREADY IS OOP. If you're not using proper OOP already in javascript - you need to get with the times. The new proposal is 'class based' OOP. Which no doubt good news to the less competent programmers because the existing prototype model is a bit too far out of their comfort zone.

Jeremy Martin said...

I certainly agree with you on some of those points. There is a lot of confusion/ignorance on OOP in JavaScript. I think this is partly due to the simplistic scripts that dominate the online educational resources on JS.

However, despite the power that prototypal inheritance provides, class based OOP is going to be a great gift for even he most competent masters of the current prototypal approach, IMHO. Interfaces, for one, are going to be an excellent tool that is currently impractical to implement.

Personally, I'm curious what the prototype chain of an actual class is going to look like. Presumably it'll point directly back to Object.prototype, but that's just conjecture. It's going to be interesting to have a language that implements both approaches. To my knowledge, that's a first.

Anonymous said...

all this talk about strict typing.... I may be blind, and firefox's "Find" feature may be faulty, but I didn't see one thing in that article that even mentioned allowing typing, nevertheless was using strict typing.

Jeremy Martin said...

I believe all the chatter about typing was in response to the section entitled "Compile Time Type Checking".

Anonymous said...

Ok, I can't sit here and watch this anymore. The documentation being cited that this article is written about is the ECMAScript 4 documentation. It is what languages such as ActionScript 3.0 are based around, and if you search the entire thing, you will find that the word Javascript is mentioned twice, once in the History section to say that Javascript is a language based on the 3rd edition of ECMAScript, and once in a link for a citation. I knew this article struck me as funny from the moment I heard the word compile. Javascript is a non-compiled language by nature, since HTML is not compiled, and as long as HTML is not compiled (a long time, since that's one of the fundamental ideas of HTML) javascript will not be either. The guy writing this article is either not someone that should be writing articles, or a genius that takes joy in hoaxes. I know there will be a lot of angry replies to this, but honestly, search the documentation, see it for yourself. You can't believe everything you read on the internet.

Jeremy Martin said...

Firstly, ECMAScript Edition 4 is the specification for JavaScript 2.0 (the other 14,000 references graciously omitted).

Secondly, you are correct in saying that JavaScript is a non-compiled language. However, even though JavaScript is not compiled down to byte-code, the concept of "compile time" type checking is valid here. If you read up on dynamic execution models, you will find that this term is used all the time for non-compiled languages, in which case it usually refers to catching various errors (e.g., invalid assignmetns) before run time.

Thirdly, You are incorrect in assuming that the non-compiling nature of JavaScript has *anything* to do with HTML.

- I do believe that I have the credentials to speak on this topic
- I certainly do not consider myself a genius
- This post is not a hoax
... so you are wrong on all three counts.

And finally, I put my name behind everything I write. If you're going to come on here and make silly accusations, I would appreciate you doing the same.

Anonymous said...

Sure, if you can honestly write compiled script between a script tag, more power to you, but I don't think that will exactly catch on. If your speaking of using object/embed style idea on compiled code, I would hardly consider that a next generation of javascript, so we're not even going to go into that topic. So i stand by my comment that as long as HTML is not compiled bytecode, Javascript will not be either, they are tied.

Yes, if your talking about something like JIT compiling, yes, many things like error checking could be true. But I wasn't making reference to your specific comments in your article, I was making reference to the very idea that the fundamental nature of Javascript is tied to the fundamental nature of HTML, and compiling to bytecode is not going to happen there.

I'm definitely not going to say that no such thing as Javascript 2.0 is going to happen, and it most likely will have something to do with ECMAScript 4, however...

I do stand by my assertion that your article assumes quite a bit, much more than should be assumed for a large article documenting concrete changes between two versions of a language, especially when backed only by documentation that does not even mention the language version it is supposed to document.

That is the main problem I have with what you are saying, you are backing a language's concrete syntax with documentation that does not even mention it. The very same documentation that implies that that very language would not apply to the actual applications of javascript as non-compiling script that could be written between tags in HTML. Can you blame me for wondering at the validity of that?

What I see in your article is the literal assertions that the syntax you are pointing out will be directly replacing the javascript we see now, and while I would love that, considering my 3 main languages are Java, AS3, and C#, and the OOP nature would make my life wonderful, I see no evidence that that literal reality is happening, and I am pointing out that I in fact I see evidence against it. If that accusation is silly then I guess I'm just too dumb, and you just shouldn't bother justifying yourself to me.

And no, I'm not dumb enough to reveal my identity in a setting where the very person I'm accusing of falsity has total control over the discussion. I have written many award winning articles on multiple languages, and my name was on them, and I successfully defended myself from questioning and accusation, just as I expect you to, but you still have much more convincing to do.

Jeremy Martin said...

Well as you pointed out in your own post, HTML already supports embedding references to compiled code (flash, for example). Provided that the browsers made the DOM API available, there's no reason that JavaScript couldn't be embedded in the same way. I certainly don't think this will happen any time soon, but my point remains that JavaScript does not skip compiling simply because it is used in web browsers.

Perhaps I didn't clarify myself well enough when I described what was meant by "compile time". If you'll re-read my previous comment, you'll see that this is still a valid term to use even when there is no literal byte-code compilation occurring.

I find your dubious outlook on the advent of JavaScript 2.0 perplexing - are you expecting it to come to a screeching halt at 1.9999.... ? And I guarantee you that when it is released, it WILL have something to do with ECMAScript 4, since therein lie the rules for the JS 2.0 interpreter.

As I stated in my article, "it's important to note that these new features are tentative", seeing as the specifications are "still a work in progress." However, as I also stated, TC39 "expects to have completed the specifications by late fall of this year", which would indicate that the feature set is relatively stable.

I am also not making any monumental jumps in stating that these ECMAScript 4 features will show up in JavaScript 2.0. I will now, for the third time, direct you to the source.

I apologize if it appeared that I was dictating the literal syntax for JavaScript 2.0. I made some general assumptions based on the current list of reserved keywords, however I believe most readers have gathered that I was demonstrating functionality, rather than what keys to push.

Regarding your (still) unknown identity - I'm not sure what you're afraid of. I do not have the ability to modify your comments, nor would I if I could. As far as your equally vague accolades - don't bother. Insomuch as you can't trust everything you read online, you can trust even less from dear old "Anonymous".

Now at this point I will apologize for the harsh nature in which I have responded to you. If you read nearly any post on this blog, you will find that I generally receive constructive criticism graciously and gratefully. Your comment, on the other hand, is simply a flame from the anonymity of cyberspace.

Anonymous said...

"a flame from the anonymity of cyberspace."...

very true

My points and the reasons why...

Also very true, and that's really what I'm trying to accomplish here. It has nothing to do with loss, I simply have nothing to gain from revealing myself, right now I could tire from this conversation and walk away at any point without consequence, and I intend to keep it that way. To trust someone based on anything but their points is ridiculous anyway.

If you read a little closer, I did specifically state that I was sure Javascript 2.0 was coming, and said verbatim: "and it most likely will have something to do with ECMAScript 4".

But I remain in the position that I read an article on Javascript 2.0 that held a number of things that made we wonder at the validity of said article, and that after reading the literal documentation cited as the source for the article, I found a specification for ECMAScript 4, a specification I am quite familiar with, that mentions ActionScript, mentions Microsoft JScript, and even mentions it's history as related to Javascript in previous versions of the specifications, but had no mention of any Javascript 2.0. In my mind, even though we all can agree there will be at very least similarities, I view the teaching of the literal ECMAScript 4 specification as teaching Javascript 2.0 as untrue.

Add that to the fact that my familiarity with the ECMAScript 4 lead me to realize that not all of your code was valid ECMAScript 4, such as declaring class properties with the "this" keyword instead of var binding (which in ECMAScript 4 means to call a static property that does not exist, even though in ECMAScript 3 it could declare a class property), and the fact that not one line of your code examples are proper practice of ECMAScript 4 (complete lack of package structure, tying, etc) lead me to further be upset that this article exists, and further question the qualifications of the author that wrote it.

You bring up points about your specific wording using uncertainty, etc. There's validity in that, and I guess that is where we differ. I believe that I still read information that at best was unsure and at worst was completely incorrect, while you simply believe your sharing your thoughts and conclusions and stating uncertainty in them. We will most likely never agree on that.

In light of that, I'm turning the conversation to something with a little more academic value. The idea of compiled bytecode javascript. While as you pointed out, it is perfectly possible. What my point on that subject is is that at that point it fails to fill the spot that javascript currently fills. To me javascript is a scripting language that can be written right into an HTML page. And since HTML is about as far from a scripting language as possible, it therefore fulfills a very important role. My view on that subject is that if Javascript becomes a language that gets compiled to bytecode before runtime, it no longer fills that position, and therefore, even if it bears the name javascript, it no longer fills the same spot in programming that javascript fills.

Jeremy Martin said...

Let me first say that I do enjoy a "lively" discussion. However, I am fairly certain that this has outgrown my comment board. I don't believe these comments add any value to this article or benefit to the readers - and their sizes are in fact becoming an eyesore to this post.

With that said, I would love to take this up off-line - and we could perhaps report the "outcome" back here for any curious minds.

I do need to say that I strongly disagree with your view on anonymity. Accountability and credibility go hand in hand. I can't hold you accountable to what you say, which frees you to say anything you want. However, feel free to contact me (anonymously if you still wish) by email at

Anonymous said...

Honestly, I started anonymous out of pure laziness, I just didn't want to type my name and url, it was only the point where you specifically wanted my identity that I became adamant about not giving it, but this is actually the point where I become glad for it. I've made my point, found incorrect code, questionable statements, etc. Now, instead of having to defend my statements to the point of my own exhaustion, citing examples until I just say the hell with it, I'm simply leaving it as is, those that read this, and see and believe my points will do so as they will, I only needed to make sure that this was all pointed out on this article.

Anonymous said...

If you can't write Java this is a welcome addition, but if you can write java then GWT + VisualBuilder = Massive Productivity.

Anonymous said...

I think the very most important thing that we need is a JavaScript 2.0 to JavaScript 1.0 desugarer that way when JavaScript 2.0 is made people might start using it without MicroSoft or someone similar messing it up.

Bruce Wallace said...

hmmm....I just found this page and it's comments while searching for "existential programming" sounds very familiar...

Too bad, all your readers didn't find my articles and blog back in 2006 and 2007...

Anonymous said...

Interesting that so many here are upset by the forward thinking this represents.

One of the main issues with trying to speed up JS execution is that the language is not strict typed. If the compiler knows the variable type it makes compiling the code much easier and results in faster execution.

In a time when web applicaations are the obvious future of the web, don't we all want a language that allows us to utilise the modern aspects of programming that other languages have had for ages?

This is NOT just a scripting language so you can change the colour of a button or add a new DIV tag to your page, this is a language that you can build an entire game engine in.

Get with the program!

Anonymous said...

class Bar {
this.a = "a";
this.b = "b";

?? That is NOT how ecmascript 4 code looks at all :( this is what ecmascript 4 looks like. Are you sure you know what you're talking about here?