Comments on jMar's Blog: Web 2.0, Meet JavaScript 2.0

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

2012-02-06T07:31:04.404-08:00

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?

Interesting that so many here are upset by the for...

2010-09-22T07:01:39.668-07:00

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!

hmmm....I just found this page and it's commen...

2010-03-05T06:57:19.779-08:00

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

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

http://www.polyglotinc.com/articles.html
http://www.existentialprogramming.com/

I think the very most important thing that we need...

2009-01-11T17:43:00.000-08:00

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.

If you can't write Java this is a welcome addition...

2008-09-18T23:47:00.000-07:00

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

Honestly, I started anonymous out of pure laziness...

2008-07-25T09:29:00.000-07:00

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
Let me first say that I do enjoy a "...

2008-07-25T08:06:00.000-07:00

@Anonymous
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 jmar777@gmail.com.

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

2008-07-25T07:36:00.000-07:00

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

@Anonymous
Well as you pointed out in your own ...

2008-07-24T14:53:00.000-07:00

@Anonymous
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.

Sure, if you can honestly write compiled script be...

2008-07-24T14:15:00.000-07:00

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.

@Anonymous
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.

Fourthly,
- 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.

Ok, I can't sit here and watch this anymore. The d...

2008-07-24T12:32:00.000-07:00

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.

@Anonymous
I believe all the chatter about typi...

2008-07-24T10:51:00.000-07:00

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

all this talk about strict typing.... I may be bli...

2008-07-24T10:31:00.000-07:00

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.

@Gavin
I certainly agree with you on some of th...

2008-05-07T06:18:00.000-07:00

@Gavin
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.

To anyone who's posted here about how good it is J...

2008-05-06T16:49:00.000-07:00

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.

It's very clear that a lot of the posters here...

2008-05-06T16:44:00.000-07:00

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.

I'd sure like to see a more object oriented ap...

2008-03-28T19:03:00.000-07:00

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

@Random Thoughts
Getting browsers and developer...

2008-03-25T09:45:00.000-07:00

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

Great overview!

I am so happy that JavaScri...

2008-03-25T02:51:00.000-07:00

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

Well, i think this is really going to be a good im...

2008-03-25T02:49:00.000-07:00

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.

@Everyone
Thanks for allllll the input - appare...

2008-03-24T07:10:00.000-07:00

@Everyone
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!

One feature I would really like to see in JavaScri...

2008-03-23T17:18:00.000-07:00

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.

ditto what the guy above this said. I don't see an...

2008-03-22T22:50:00.000-07:00

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.

I've written plenty of javascript and ajax and for...

2008-03-22T18:24:00.000-07:00

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.