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

Comments

v2.0

[Methlin]

Does it have 33% more bugs than v1.5?

Re:v2.0

[hedwards]

That was basically my thought. JavaScript has sucked so badly for so long.

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

It definitely looks like a step in the right direction, but until I don't have to choose between worrying about browser specifics or being overly limited, I'll remain skeptical.

Re:v2.0

[snl2587]

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

[RCanine]

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

[smittyoneeach]

That depends. http://en.wikipedia.org/wiki/ECMA_Script 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

[TheWanderingHermit]

I'll go even farther. JavaScript has not only always sucked, but should be replaced with something closer to a real language.

I'd love to see JavaScript outdated or made obsolete by a real language each browser could understand.

Re:v2.0

[Anonymous Coward]

A poor workman blames his tools. DOM incompatibilities will exist even if every browser supported a "real" language (maybe you should just stick to internet explorer and VBScript).

Re:v2.0

[Anonymous Coward]

Javascript is the one language which has been fscked up more by Microsoft than any other. I love working with Javascript *proper*, but the problem you come across all the time is that you have to defer to the lowest common denominator because the most common language platform (Internet exploder) sucks UNBELIEVABLY!!! It makes me sick to see M$ harping on about CSS and Acid2 in IE's 7&8 when their javascript implementation is as slow, old and crap now as it has been for the last 5 years (at least).

Re:v2.0

[Garridan]

You haven't tried to support Konqueror and Opera, have you?

Re:v2.0

[bnenning]

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:v2.0

[TheWanderingHermit]

I see. Rather than talk about the subject, you'd rather focus on ad hominem attacks.

You have no idea whether or not I'm a good programmer, so you have no qualifications to make that judgement.

And, incidentally, I was not focusing on the incompatibilities, but it's interesting you assume so.

In the past 6 years I've taught myself 6-8 languages that didn't even exist when I used to program in 6502 Assembler. It's been enough to create a small business that sustains itself on 2 hours of work a week and still provides a nice steady income.

My first program written to go on clients' computers produced a total of 6 (actually 5, depending on what you count) bugs over 18 months before it was replaced with v. 2.0, which has produced 1 or 2 bugs since mid 2005.

So, obviously, since I can make a good living on my software and can produce code with relatively few bugs, you've got to be right and I've got to be a poor workman...

JavaScript is just plain weak. It should have been replaced with something with something more powerful years ago.

Re:v2.0

[Millennium]

You have no idea whether or not I'm a good programmer, so you have no qualifications to make that judgement.

Given that your main objection to JavaScript seems to be that you refuse to learn the paradigms it espouses, I think that's plenty of evidence right there. Just because you don't understand a language does not make it weak.

Re:v2.0

[TheWanderingHermit]

Given that your main objection to JavaScript seems to be that you refuse to learn the paradigms it espouses

Quote the part in either of my posts where I state that is my main objection.

I didn't.

I never gave or stated any specific objections to JavaScript. I (thankfully) haven't had to use it in 4 years

Yet, somehow, someone seems to think I did, and you seem quite eager to take that misunderstanding and use it as an excuse to make judgements about someone you don't know.

While you're at it, do you want to go trolling with any other observations about me that have absolutely no basis in fact?

Re:v2.0

[Anonymous Coward]

My goodness!

Microsoft is one of the best companies ever! How dare you make fun of them and that nice Mr. Gates!
And that Mr. Ballmer could write rings of Javascript code around you, you silly effete Linux whiney!

Why don't you buy a nice Dell or Compaq now and see how a REAALY GREAT system such as Vista works!
You will be pleasantly surprised, I think!
It will easily outperform your silly little Linsux machine!

Re:v2.0

[Gewalt]

While you're at it, do you want to go trolling with any other observations about me that have absolutely no basis in fact?

Well, since you asked: Sure! Why not!

For starters there's your hair. YOU ARE NOT MARGE SIMPSON! That look does not work for you.

Re:v2.0

[AKAImBatman]

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

[TheWanderingHermit]

Shows you what you know. I've been a dead ringer for Homer for the past 3 years!

I only wear the blue wig when...

Well, you really don't need to know anything about that!

Re:v2.0

[AKAImBatman]

You have no idea whether or not I'm a good programmer, so you have no qualifications to make that judgement.

Oh? It seemed pretty obvious to me:

JavaScript has not only always sucked, but should be replaced with something closer to a real language.

(Emphasis mine.)

Javascript is a "real language". If you were as good of a coder as you claim to be, you never would have made such a silly statement.

Re:v2.0

[ShieldW0lf]

The prototyping nature of JavaScript makes it a lot more practical to use running JavaScript to write new JavaScript that will be running in the same process, which is something that has been put to good effect by a lot of people. Class based objects don't seem quite as useful for the tasks JavaScript is meant to do.

And what the hell is wrong with primitives, anyways? Everything doesn't need to be an object.

Re:v2.0

[jlarocco]

JavaScript is just plain weak. It should have been replaced with something with something more powerful years ago.

What features of a "real language" does Javascript lack? Can you give an example of something you could write in C/C++/Java/Ruby/Perl/Smalltalk/C#/Lisp/Fortran that couldn't be written in Javascript?

Re:v2.0

[Wolfier]

I never gave or stated any specific objections to JavaScript. I (thankfully) haven't had to use it in 4 years

Sounds like not having used a language in 4 years will somehow give you authority to judge its merits.

Re:v2.0

[snl2587]

I never sais that was how I code (spaghetti code and all). I learned it the old way: from a giant 400 manual starting with the most basic structured code and ending with entirely compliant scripts. And so when I have a preference (and am not merely modifying existing code) I write it relatively structured.

I like this statement, though:

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

Sounds like you missed my point entirely. I can code it fine. You can code it fine. Many people can code Javascript just fine. But the fact remains that the majority can't or just don't want to, and the fact the Javascript makes it easy to be non-compliant means that part of the blame lies on the language.

Re:v2.0

[Anonymous Coward]

JavaScript has changed that much in 4 years has it?

Didn't think so.

No one has actually bothered to reply to WanderingHermit yet in any real sense, I see. I must be reading SlashDot!

Re:v2.0

[Haeleth]

I'd love to see JavaScript outdated or made obsolete by a real language each browser could understand.

So, uh, did you bother to cast your eyes over TFA at all, or are you just trolling here? The whole point of TFA is that JavaScript 2.0 will have most of the features people complained were missing from JavaScript 1.0, like classes, constants, namespaces, libraries, optional type checking, and (to keep the FP types who already liked JS happy) even some more lovely FP features like union types.

JavaScript will be made obsolete by something that people like you, who never bothered to understand JavaScript, will consider a "real" language. Your wish is coming true. But the general tone of your post implies that your mind is not exactly open to considering anything that has the "JavaScript" name attached to it, which is a shame.

Re:v2.0

[Haeleth]

JavaScript has changed that much in 4 years has it?

Well... yes, actually. The language itself is the same, but the way it's used, the libraries and techniques, have changed beyond all recognition.

Didn't think so.

You know, when you don't know the answer to a question, it's generally considered better to wait for someone else to answer it, instead of rushing on and getting it wrong.

But even if the JS world hadn't moved on, even if nothing had changed in the slightest, WanderingHermit would still not be in a position to judge whether or not JS sucks on any objective level. There's this thing we humans have called "memory", which is imperfect, and after a gap of four years is pretty unreliable, particularly when we're thinking about something we have a strong emotional reaction to.

No one has actually bothered to reply to WanderingHermit yet in any real sense, I see. I must be reading SlashDot!

I would dispute that you're reading it. You may be looking at the pictures, but I see no evidence that you're able to comprehend the text.

Re:v2.0

[Haeleth]

Can you give an example of something you could write in C/C++/Java/Ruby/Perl/Smalltalk/C#/Lisp/Fortran that couldn't be written in Javascript?

Here's some C++ code that can't be written in Javascript:

int main() {
    return *(int*)0;
}

Re:v2.0

[pdbaby]

Insightful? What? In the old days of the web the whole javascript / dynamic html nonsense was a mess. But modern javascript/html interaction is much more sensible.

It might surprise you to learn this but javascript is actually quite a nice language -- I'm a Real Programmer(TM) and I've been dabbling with a bit of javascript recently for UIs to our tooling -- and the only thing dragging it down is DOM's uglyness (and, frankly, life's too short to try to learn the stupid inconsistencies between Firefox, Safari and IE). However there are solutions: a library called jQuery makes working with the browser rediculously easy: it abstracts away various inconsistencies for you (and also makes the syntax nice and elegant/compact).

A nice example is setting CSS properties - with jQuery you simply use: $("p.showable").css("font-weight", "bold").show("slow"); this code selects all paragraphs with the "showable" class, makes their contents bold and fades them into view (if they're not already visible)

Debugging isn't as bad as you'd think, either thanks to Firebug. And AJAXy things can make a page much more useful - we update a log viewer based on the restrictions specified (eg. from machine X,Y or Z, from application B, log level >= INFO) which makes it at least as useful as ssh+tail :-)

Re:v2.0

[AlXtreme]

Netscape published an excellent guide to the language 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?

Just a quick "thanks!" from someone who has for far too long equated JavaScript with voodoo-programming and thus wouldn't touch it with a 10-foot pole. Finally a proper guide for developers who want to wrap their head around this misunderstood language.

Pity it took me 10 years to find it, but I'll admit I wasn't searching for something that would let me make sense of JS.

Re:v2.0

[arudloff]

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

The real issue with writing objects in javascript is that there really isn't much reason -- unless you want your code to be a 300k download on your skimpy little webpage.

In javascript's case, it's actually detrimental to be a purist. #1 rule for writing javascript -- cut to the chase.

Re:v2.0

[jeillah]

You could say the same thing about PHP...

Re:v2.0

[TheWanderingHermit]

I keep forgetting just how many people on /. are, for some reason, so literal, they have a serious problem with the concept of hyperbole.

Re:v2.0

[The End Of Days]

The real issue with writing objects in javascript is that there really isn't much reason -- unless you want your code to be a 300k download on your skimpy little webpage. This sentence exposes that you are one of the 99% of people who don't actually understand how to use the language.

Re:v2.0

[magi]

I've only met one other person IRL who even knew how to code Javascript properly. That's one reason not to use JavaScript. If you want to code browser stuff, use GWT, at least as much as you can. There are 100 times more good Java programmers as there are JavaScript programmers.

And if you're doing Ajax, use IT Mill Toolkit to develop the application as server-side and let the framework handle the Ajax and client-side stuff, and only code any custom client-side stuff with GWT (or with JavaScript if you really need to).

Re:v2.0

[Achoi77]

...But the fact remains that the majority can't or just don't want to, and the fact the Javascript makes it easy to be non-compliant means that part of the blame lies on the language.

So I've been trying to wrap my head around this statement. I'm not too sure what it means. Am I supposed to be angry at javascript because it's ease of use causes terrible code to appear in the world because Joe Sixpack thought he was a js coder by looking up examples in the internet? Or is it more of an elitist coder mentality, like a secret javascript club where Joe Sixpack should not be allowed in?

Re:v2.0

[hobbit]

It might surprise you to learn this but javascript is actually quite a nice language -- I'm a Real Programmer(TM) I'm guessing what you mean by "Real" is "C++" -- surely no-one else would call JavaScript a nice language. I mean, if all browsers supported Ruby and Python it would quickly die a death.

Unless of course you're a Real Basic programmer -- that would also make sense ;)

Re:v2.0

[Zontar The Mindless]

And what the hell is wrong with primitives, anyways? Everything doesn't need to be an object. Maybe not, but in JavaScript, everything is an object - including what most people think are "primitives".

Number.prototype.sqrt = function() {
    return Math.sqrt(this.valueOf());
}

alert( (2).sqrt() );

Re:v2.0

[Ambidisastrous]

Part of the Zen of Python is: "Errors should never pass silently. Unless explicitly silenced." So, for example, there are some kinds of type coercion that Python will throw a noisy exception for, even when a human reader would probably be able to figure out what the code was intended to do -- like adding an integer to a string. That's part of the appeal of statically typed languages like Java -- some ambiguities won't even compile, so it's impossible to let those particular errors go into production.

Like HTML (and unlike XHTML), Javascript tries to limp along as much as possible when it encounters ambiguous code. So the expression "You collected " + bugs + " bugs.", where bugs is an integer, will turn bugs into a string and concatenate the strings. In C, adding an integer to a character will increase the ASCII value of the character by the amount of the integer ('a'+5 -> 'f'), so we can see that adding integers and strings is an ambiguous and therefore error-prone process. Tons of websites, even high-profile ones, have lots of errors in their Javascript passing silently, and they work anyway.

Given how the Web works, that's probably the right decision for Javascript. It fits with the idea of graceful degradation. You shouldn't be angry at Javascript at all. But this leniency does mean that just because a script runs, doesn't mean it's not full of errors. And just because you can build a website that uses client-side Javascript, doesn't mean you know the language well enough to build a reliable server-side app in it.

But given that history of C#, Java, C++, and any other popular programming language, I disagree that the leniency in Javascript's spec is the main cause of the low signal-to-noise ratio in Javascript programmers. Really, I think it's just because everyone has access to a Javascript interpreter in their browser, and disciplined programmers are a tiny subset of "everyone."

Re:v2.0

[somethinghollow]

I suggest watching Douglas Crockford's JS trilogy on YUI Theater.

Re:v2.0

[Anonymous Coward]

a library called jQuery makes working with the browser rediculously easy

It's too bad it doesn't make it ridiculously easy, because then that phrase would actually mean something.

Meh.

[Anonymous Coward]

Not really exciting.

I've been playing around with Silverlight though, now THAT's where the future lies. You get the majority of the .NET framework on the client side. Doesn't get much better than that.

Re:Meh.

[Timothy Brownawell]

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.

[Anonymous Coward]

What about the 5% of us that don't use Microsoft?

Re:Meh.

[Embedded2004]

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

[netsavior]

it works 95% of the time, every time.

Re:Meh.

[rbanffy]

"The main problem is that given MicroSoft's history, I'm not sure I trust it."

Having known Microsoft since the early 80s, I can tell you I won't.

Re:Meh.

[shutdown -p now]

Insofar C# and CLI are ISO standards, aren't those at least guaranteed to be free of any patent minefields?

Re:Meh.

[Tangent128]

If I recall right, no. ISO only requires patents be licensable on "reasonable terms" or something like that. Now, W3C standards are required to be patent-unencumbered.

Yes

[Anonymous Coward]

Yes, we are nerds. But do you really have to rub it in?

Sounds awesome,

[elloGov]

but what about more meaningful(detailed) errors?

Re:Sounds awesome,

[cheater512]

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:Sounds awesome,

[Achoi77]

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

Error console seems to be something underutilized, my coworkers are always asking why their script is broke, I just pop the console open and the answer is shown in red letters.

Oh yeah, and I believe IE has something similar too, I have it on my machine at work, if an error pops up, the tool leads straight to the offending line. Maybe this is it? I can't remember - and I'm not going to fire up IE on my home machine to find out.

Ignore the previous sentence, looks like I found it:

Script debugging is turned off by default you can enable it by going to:
Tools->Internet Options...->Advanced->Disable Script Debugging
Prior to XPSP2 the above will turn script debugging on for all applications that host the WebBrowser control (Outlook for example).
On XPSP2 we've split the option into two:
Tools->Internet Options...->Advanced->Disable Script Debugging (Internet Explorer)
Tools->Internet Options...->Advanced->Disable Script Debugging (Other)

As a side note, I don't recall a time when I've had script errors in IE that I didn't have in FF. Most of the time I'm dealing with the occasional strange CSS inheritance behavior that IE loves so much.

Re:Sounds awesome,

[BobDigiDigi]

To get Script debugging in IE v8 you need _MS Works installed, I think. With IE8 beta, you get some developer toolbar with some handy css debuggin, and an actual Javascript debugger.

Re:Sounds awesome,

[Anonymous Coward]

When I used to script IE5 and IE6 all JS errors were trapped by Visual Studio - does that not happen any more?

Re:Sounds awesome,

[shutdown -p now]

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

Actually, it's quite the opposite these days. With IE and VS2008, you get a full-fledged IDE to debug JavaScript, complete with code and data breakpoints, step-through, watch windows with fancy visualizers for various data structures etc. Not to mention nifty code completion with type inference in VS2008, though that is not exactly a debugger feature.

Ugh

[TheRaven64]

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

[mrbluze]

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

[Curien]

Javascript has always had overloaded operators. Or do you really think that string concatenation and arithmetic are similar operations?

Re:Ugh

[MikeBabcock]

Wake me up when JavaScript isn't taking the same bad trip down bloat ware lane that VisualBasic did back in the day.

Re:Ugh

[Paradise Pete]

Javascript has always had overloaded operators. Or do you really think that string concatenation and arithmetic are similar operations?

User-defined overloading, obviously. And it's considered by some to be a bad idea.

Re:Ugh

[Curien]

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

[Paradise Pete]

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.

He said guaranteed, not could, which carries quite a different meaning. But go ahead and post your thoughts there. Perhaps he might expand on it.

Re:Ugh

[SanityInAnarchy]

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

[Curien]

He said the feature is "guaranteed to be misused". This has two possible meanings:
1. The feature will be misused every single time. There is NO POSSIBLE correct use.
2. The feature will be misused at least once.

Meaning 1 is completely indefensible, and the author doesn't even make an effort at substantiating it. He provides exactly one example of misuse. Chances that meaning 1 were intended: slim to none.

Meaning 2, on the other hand, actually fits with the rest of the article.

As the number of uses of a feature increases, the chance of a misusable feature actually being misused approaches unity. Therefore, any feature which CAN be misused, WILL be misused eventually. QED.

Keep 'em coming. We're on a roll.

Re:Ugh

[mortonda]

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

Re:Ugh

[free space]

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

I'm interested! Care to point to any patricular papers? Thanks in advance.

Re:Ugh

[Paradise Pete]

Never mind. It's clear that it's important to you that you need to find a way to interpret things in such a way as that somehow you are not wrong. I'll bet that comes up a lot in your life.

Re:Ugh

[Curien]

It's better than resorting to insults when you can't come up with a cogent argument.

Re:Ugh

[TheRaven64]

This one was published in 2005, so it's a bit later, but it's still worth reading.

Re:Ugh

[odourpreventer]

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

Why would

print("astring" + "anotherstring" + "thirdstring");

be better than

cout << "astring" << "anotherstring" << "thirdstring";

?

Semantically, they're both equally bad.

Re:Ugh

[odourpreventer]

And it's considered by some to be a bad idea.

If you'd bothered to read the comments on that page, you would've seen plenty of examples why operator overloading is a good thing.

It's amusing seeing Java fanbois whining about operator overloading being a "bad idea", since Java is already riddled with shitty implementations. Just look at containers, for example.

Re:Ugh

[modmans2ndcoming]

huh? you mean Javascript and VBscript are different?

Re:Ugh

[nuzak]

> introducing classes into a prototype-based language just doesn't make sense.

That's fine, sounds to me like they're throwing away the prototype part. Bastards.

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

Yes, because of course that's mandatory. God forbid that anyone be allowed to express a thought not approved of for the original datatypes hardwired into the language. Seriously, do you actually consider this argument valid? I guarantee the people actually designing languages and actually, you know, accomplishing something don't.

Re:Ugh

[mrbluze]

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

[mfnickster]

print("astring" + "anotherstring" + "thirdstring");

be better than

cout << "astring" << "anotherstring" << "thirdstring";

Well, for one thing, 'print' is a verb instead of a noun. Also '+' is often used as shorthand for 'and' in English, so it's probably semantically clearer and more intuitive.

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.

Re:Ugh

[Anonymous Coward]

Just look at containers, for example.

You mean the ones that are nearly a copy of C++ STL data structures? Moron.

Re:Ugh

[OoSync]

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

[jonberling]

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. These features are going to be included in C+++

Re:Ugh

[zoips]

The prototype paradigm is cool. I like Io for that reason. Javascript, on the other hand, has always been, and forever will be a language that couldn't figure out what the fuck it wanted to do. Its implementation of prototypes is broken and all but useless except in emulating C++ style OOP. The saving grace is that Brandon Eich was intelligent enough to allow expando (I'm sometimes surprised he didn't go with the broken prototypes and also disallow expando), which goes only a short ways towards fixing the problem.

I like Javascript, it's definitely one of my favorite languages (if more interpreters correctly implemented tail recursion it'd be incredible), but it was just never quite right. Kinda like some sort of premature idiot savant or something, I'm not sure...

Re:Ugh

[Anonymous Coward]

It looks to me like you're supporting his point.

Re:Ugh

[xero314]

I just wanted to say that I am glad to see that I am not alone in realizing that these proposed changes to JS are certainly not for the better.

JavaScript is a very powerful language that got almost everything about OO correct. Everything is an Object, and should remain that way. Packages are Objects, functions are Objects, Constructors are objects. Objects can inherit from Objects, no need for clunky class hierarchies. Ducktyping is more powerful and more applicable to real world modeling that static typing.

Constants are ok but unnecessary, while the program units will actually and some useful functionality. Sadly it looks like this update is not going to bring a heck of a lot to JS, except bloat and massive performance penalties.

Re:Ugh

[m0n5t3r]

These features are going to be included in C+++

a.k.a. Perl 6? :P

Re:Ugh

[odourpreventer]

You mean the ones that are nearly a copy of C++ STL data structures? Moron.

Copies? Have you ever used them? Java containers are nothing like C++ ones. Two obvious problems are:

1. Each Java container has a different interface.
2. Element manipulation is a pain, and for large structures easily breaks memory management.

You would know this if you knew anything about programming the languages. But I guess name calling is easier.

Re:Ugh

[Peaker]

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.

Re:Ugh

[Anonymous Coward]

Hmmm... If you ask me, I think those guys at the Newton project never heard of MVC. Their basic argument is "The behaviour of each UI component is very unique, hence classes are of little use".

Well duh - yes, the behaviours of the various areas and parts of the UI are unique - that's why we encapsulate them into "Actions" and they are the "Controller" Layer. You'll notice that in NO OO MVC code actions have any kind of inheritance relationships between them. The logic of the "delete customer" action and that of the "change font" action share almost nothing (if you ignore the framework part), in much the same way that the data logic of the customer model and that of the product model share almost nothing (again, ignore the framework).

I think they kind of missed something there.

Re:Ugh

[TheGratefulNet]

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

and if I ever see that in PRODUCTION code, I'd fire you.

this isn't school, kiddies; in the real world you write code to be UNDERSTOOD and not 'figured out' via quizzes and challenges to show how much c-manual you swallowed.

my god; if people think that writing code LIKE THAT is a good thing, I'm ashamed of what 'programmers' we are putting out these days.

yes, you can form any weird thing in any language, but SHOULD YOU?

I know its a bit OT but when I see things that take more than a few seconds to understand, I raise a red flag. I would not pass an OK on a code review that used such insane design that NEEDED to use confusing features of a language.

if the code can't pass the '3am test' (can it be understood and supported/patched late at night if an important customer escalated a support call...) then I don't want it in my production code base. KISS is something I find sadly missing from today's programmers. very sad that they feel they have to use such complicated code. (reminds me of when c++ first took off and it seemed like EVERYONE wanted to *force* the idea of inheritance and operator overloading on their code, like it was some kind of new toy or something).

Re:Ugh

[fimbulvetr]

Whoa man, chill out. He's just illustrating the syntactical mess of c. He's made this clear. He never advocated using it.

Re:Ugh

[TheGratefulNet]

the thing that triggered my comment was the fact that MANY people seem to think that programming is a 'contest' to try to write the most confusing, tricky or 'showy' code.

I recently had some interviews that emphasized that, too; it was a contest during the interview and I walked away shaking my head in disbelief that many younger programmers seem to think that 'macho programming' is a good idea ;(

I run into this enough (during code reading) and just had to comment on this disturbing practice. school is school; but in the real world, we should 'write code that is supportable' and that's exactly the opposite of what they seem to be teaching in schools these days.

Re:Ugh

[searlea]

You know it's Brendan right? Not Brandon as you wrote three times.

Re:Ugh

[epine]

Operator overloading? Great, now you can enjoy C++ style code, where left shift and print are the same command. I never get this particular pot-shot at the C++ language. This issue has bitten me exactly ... never ... times.

If C++ wanted to be liked, it would have long ago redefined the integral left-shift and right-shift operators to some other syntax, leaving operator<< and operator>> to become widely known as "get" and "put", which is how the majority of objects tend to employ these operators, leaving you to whimper:

Operator overloading? Great, now you can enjoy C++ style code, where put() and put() are the same command. Does it matter to my point whether you spell "put" as put() or "operator<<"?

Far more to the point is whether you prefer a pure prefix language over a mixed prefix/infix language. Infix notation seems to enjoy a certain staying power. I've never seen a paper in pure mathematics where the equations are expressed in RPN. It might have something to do with the human brain having a limited and unreliable parse stack. If I could read Lisp like the Rain Man I'd abolish infix notation in a heart beat.

Instead of being liked, C++ resolutely persists with its dreadfully uncool attribute of not breaking existing code. To this end, it egregiously overloads the same infix operator for integers and iostreams. Scandalous! AltaVista might have been Google, but some programmer there mistyped a statement intended to strip some bits off a long integer, causing their month-long internet spider to fail with the output "42" on the console, and the rest is history.

The most heavily overloaded operator in generic style C++ is operator<, which establishes an ordering relationship which, among other things, makes the use of ordered containers possible (e.g. any container implemented on top of a red-black tree). Oh the horror of keeping all those overloaded operators straight in my mind.

My favorite example of operator overloading comes not from C++, but the Unix command line. There are many tools that define the commands "exit" and "quit" where one saves and the other doesn't, not always in the same correspondence.

If I assembled a list of C++ language defects, eliminating operator overloading would be point #1000, and I would probably conclude the facility makes a positive contribution to code quality, given a certain amount of progress in human factors concerning the binding of bad names to outrageous semantics. No useful language can eliminate poor human judgment. Of all the silver bullets, the goal of eliminating poor human judgment has to rank as the stupidest of them all.

We already have a good name for tasks involving no human judgment: it's called a "program" and you run it on a computer.

Re:Ugh

[Anonymous Coward]

You misread a comment, big deal. It's no reason to act like an idiot.

Re:Ugh

[mfnickster]

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

and if I ever see that in PRODUCTION code, I'd fire you.
this isn't school, kiddies; in the real world you write code to be UNDERSTOOD and not 'figured out' via quizzes and challenges to show how much c-manual you swallowed.

Just out of curiosity, what would be a clear, understandable, and maintainable way of declaring a function in C 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..?

:)

Re:Ugh

[Curien]

I know exactly what TheRaven64 *meant*. But what he meant isn't what he *said*. What he actually said was wrong, and I commented on it.

Re:Ugh

[ioshhdflwuegfh]

That's all fine, notwithstanding one remark:

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 :-) Actually, they're whirlpool (@) and big money ($)

Re:Ugh

[Profane MuthaFucka]

I never get this particular pot-shot at the C++ language. This issue has bitten me exactly ... never ... times.

Back in the day, and that means the early 90's, the stream classes were used far more often than they are today. They were badly documented and generally a mess to use.

I just got bit by some old code the other day. If you're using an ostrstream, they're not null terminated. It says "str" which leads you to believe you're dealing with strings. But, you're not. ostrstream a; a "123"; writes exactly three bytes into memory, not 4 as you would expect if you were dealing with a string. Later, when you try to strlen the thing, it dies a horrible death. The str() function doesn't return a pointer to a string. It shouldn't be called str() then, right?

That's just one little thing. The old stream libs are full of traps like that, which is why you see people only really using iostream to print things to stdout and stderr, but revert to the good old trusty C functions with civilized semantics and decent naming to write and read files.

Re:Ugh

[Anonymous Coward]

Wow that's an ugly mess. Anyone who writes code like that gets what they deserve.
Here's how I would declare that type in a real program (if someone held a gun to my head and forced me to maintain that exact same signature):

typedef char lame_array[SIZE];
typedef lame_array *(*return_fn) (void);
typedef void (*input_fn) (int);
typedef return_fn (*lame_fn) (input_fn);

Re:Ugh

[Anonymous Coward]

Use typedef several times in preparation.

Re:Ugh

[Anonymous Coward]

You're just a little bundle of insecurities, aren't you?

Re:Ugh

[hobbit]

Grand-parent gave an example of built-in operator overloading C++'s usage of the left shift operator as a stream manipulator is actually a feature of the standard library, not the language.

Re:Ugh

[Anonymous Coward]

Quite right. C++ containers are a load of shite too.

Re:Ugh

[Curien]

Yeah, I guess you're just a better person than me.

Re:Ugh

[Curien]

The C++ language spec doesn't make that distinction. The standard library is part of the language.

You could just as well say that is really the stream insertion operator, and that its use with integers is the overload. Only historical accident lends any credence to one view over the other.

Re:Ugh

[theCoder]

You're right that ostrstream is a nasty class. Which is why if I always replace it with ostringstream if possible. The latter class is much more predictable, and ostringstream::str() returns a std::string, which is easy to use. In the product I work on (at work), streams are used quite often, especially when converting a non-string to a string.

The bitshift operator overloading for streams is annoying from a purist point of view, but it works pretty well. And there really weren't any other better operators to co-opt.

My biggest complaint with C++ streams is that the ifstream and ofstream classes construct with const char* instead of with std::string. So, if I have a string containing the file to open, I have to call .c_str() on it to open the file. A minor inconvenience, but it would be nice if a string constructor was there.

Re:Ugh

[Anonymous Coward]

Each Java container has a different interface.

Congratulations on proving you're a moron.

Lists ~= List interface
Maps ~= Map inteface
Sets ~= Set interface

The Java interfaces are then implemented by different data structures. e.g. An ArrayList, a HashList, a HashMap, a SortedMap, etc.

In other words, they all implement the same interface for the same type of data storage.

Moron.

Re:Ugh

[odourpreventer]

Congratulations on proving you're a moron.

OK, let me clarify: For STL containers, the developers tried to make the interfaces generic and intuitive. operator[] can be expected to behave in a certain way for the containers that implement it, for example. Method names and implementations are common across all containers, where applicable.

This is something that Java containers lack. But of course, to fully appreciate the ramifications of this, you need to have used them for a while.

But what do I know, I only have a Master of Science in Human-Computer Interaction.

Re:Ugh

[ioshhdflwuegfh]

Why would
print("astring" + "anotherstring" + "thirdstring");
be better than
cout << "astring" << "anotherstring" << "thirdstring";
? That's easy: the latter allows strings to be sent down the stream immediately, with no wait/need for concatenation.

Re:Ugh

[hobbit]

That's not true. You have to include (unless having your hand held by Visual Studio or similar). You don't have to include !

$ cat > test.cpp
int main(int argc, char **argv)
{
    cout << "Hello, world!" << endl;
    return 0;
}
$ gcc test.cpp
test.cpp: In function 'int main(int, char**)':
test.cpp:3: error: 'cout' was not declared in this scope
test.cpp:3: error: 'endl' was not declared in this scope
$

The only reason gcc didn't complain about the << operator was that it parsed it as the bit-shifting operator.

Re:Ugh

[Curien]

You have to include (unless having your hand held by Visual Studio or similar). You don't have to include !

So what?

Re:Ugh

[hobbit]

Well, if you don't understand it by now, I doubt anything I can say is going to make any difference.

Re:Ugh

[Anonymous Coward]

Well, if you don't understand it by now, I doubt anything I can say is going to make any difference.

Pretty much every thread with Curien ends that way.

Cross-Browser

[Anonymous Coward]

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?

Re:Cross-Browser

[Curien]

Your comments are nice and all, but what I really want is coders who actually understand the difference between a language and a run-time environment.

I write CLI programs in Javascript, you insensitive clod!

Re:Cross-Browser

[Anonymous Coward]

Yo! You might want to think b4 posting:

Javascript != DOM

sorry buddy but you win a sign today...

Re:Cross-Browser

[stephanruby]

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? An (almost) universal metalanguage that generates the right Javascript/Actionscript/Neko scripts for different environments.

Re:Cross-Browser

[Daengbo]

Why? You just made my brain bleed!

Re:Cross-Browser

[Hao Wu]

You're not still developing for Netscape 4 are you? I get more serious problems with different CSS versions than any Javascript issues.

Not defending it, but why were "layers" so different than the now standard "z-index"? People were strangely hostile to them.

Re:Cross-Browser

[Curien]

Because by default, Windows 2K/XP comes with three scripting languages: cmd.exe (useful, but not COM-enabled), VBScript, and Javascript (well, technically it's "JScript", which is Microsoft's embraced and extended version of Javascript). I'd sooner scratch out my eyes than use VBScript for anything longer than five lines, so Javascript it is.

For example, some corporate environments think that disabling all the programs in system32 to be a "security feature"... which means you can't do things like fix corrupt registry entries in your own HKCU hive! So I wrote a command-line registry editor (similar to reg.exe) in Javascript+WSH+WMI. I also used it to write a little utility that basically replicated the remote installation feature of SMS. Except mine doesn't break all the fucking time on networks that aren't always up (SMS server was separated from all the clients by a TACLANE that's only brought up as-needed).

Oh, and I wrote a DB app in Javascript that just happened to use a browser for a GUI (but there was no webserver middle-ware). Again, mostly because I loathe anything VB-related (such as VBA usually used to script Access). See http://www.kuro5hin.org/story/2005/7/14/13942/7643.

Re:Cross-Browser

[rthomanek]

FYI, cmd.exe is not a scripting language; it is more of a "macro language". The result is there are funny (not always so) side effects where you have nested scopes (try nested loops for example). In fact, cmd.exe is one of the most brain-dead "languages" I've ever seen, full of ugly hacks (see FOR syntax for example).

Re:Cross-Browser

[Curien]

The result is there [in cmd.exe] are funny (not always so) side effects where you have nested scopes (try nested loops for example).

Look up setlocal. You have to make a separate script for each scope, but you pretty much have to make a separate script for the body of loops anyway.

Just because you don't like it doesn't mean it's not really a scripting language. Check out, for example, the scripts in BCD.

Re:Cross-Browser

[Anonymous Coward]

Amen! Which environment do you use? We pretty much had to develop our own, since the only debuggers we could find were for browsers, which is totally not what we need... /c

Re:Cross-Browser

[fimbulvetr]

So I wrote a command-line registry editor (similar to reg.exe) in Javascript+WSH+WMI. I also used it to write a little utility that basically replicated the remote installation feature of SMS. Except mine doesn't break all the fucking time on networks that aren't always up (SMS server was separated from all the clients by a TACLANE that's only brought up as-needed).

Oh, and I wrote a DB app in Javascript that just happened to use a browser for a GUI (but there was no webserver middle-ware). Again, mostly because I loathe anything VB-related (such as VBA usually used to script Access). See http://www.kuro5hin.org/story/2005/7/14/13942/7643 [kuro5hin.org].


Wouldn't it be more satisfying to smash your head in with a rock than program WSH/WMI?

Re:Cross-Browser

[Curien]

Nah, I don't mind it, so long as I don't use VBScript.

JavaScript 2.0, Meet NoScript 2.0

[imtheguru]

... soon.

Re:JavaScript 2.0, Meet NoScript 2.0

[electrosoccertux]

This just made me think of how annoying it was for noscript to update every single day it seems (well having to deal with it on 3 machines and multiple OS installs on each doesn't help), almost just to make that darn tab open up after update and direct me to the noscript page (so I can click ads maybe for revenue? Who knows).

You can disable that new tab that gets opened after every update by opening a new tab to about:config and searching for

noscript.firstrunredirection and setting to false.

Just wanted to put that out there in case nobody thought of searching the about:config for something to let you turn off that pesky new tab every time it updates.

Re:JavaScript 2.0, Meet NoScript 2.0

[Anonymous Coward]

Thanks for the tip! Long ago, I got really annoyed by that new tab opening after every update, so much that I added noscript.net to my host file (127.0.0.0 noscript.net)
(The update comes from Mozilla addons site)

Re:JavaScript 2.0, Meet NoScript 2.0

[WK2]

Thanks for that. I never really thought the redirection was that bad, but it certainly isn't helpful and wastes bandwidth, so I disabled it. If you don't like updating extensions so often, here is a setting for you:

extensions.update.interval

It is measured in seconds (no kidding), and by default, looks to update extensions every single day. I set mine to 15 days. There is also:

extensions.update.notifyUser

If you set this to false, extensions will be updated silently.

Firefox has a whole slew of undocumented settings.

Javascript

[Anonymous Coward]

alert("keep it simple");

Re:Javascript

[Hal_Porter]

Shouldn't you be using multiple inheritance, operator overloading, enclosures and so on? Outsourcing is a serious threat.

JavaScript changing into Java

[Frans Faase]

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.

Re:JavaScript changing into Java

[mgiuca]

Well I think that the language of the client-side web should not be a programming language at all, but a Virtual Machine / bytecode. That way, there could be many source languages all compiling to the "web virtual machine". (Like Java - but it should be as powerful as JavaScript, eg. have full access to the DOM).

So I think if JavaScript is moving towards being a compiled language, that's a good thing. It means that one day, we'll have Python code compiling to a "web client bytecode" file, and then Python, or any other language of your choice, can take the place of JavaScript on the web.

javascript or DOM/etc.?

[Animaether]

just curious.. are you referring to actual differences in how javascript is handled, or in how things like DOM access/structure (page layout scripting and such) are handled per browser?

The latter having nothing to do with the actual javascript syntax, semantics... i.e. the language

As long as I got my Framework

[DigitalisAkujin]

As long as I can keep using Prototype as a framework I'll be happy.

As for specific features. I'm looking forward to cleaner and easier to manager asyncronous AJAX. While the client requesting from server has been well thought out, the server sending to the client is still very patchy and not particularly easy to develop for.

It would be nice if I could create socket connections with AJAX to say IRC but still go over HTTP proxy.

I'd also like to see AJAX file uploads that don't have to run through Flash. I think FF3 supports this already.

Re:As long as I got my Framework

[SeanTobin]

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

Re:As long as I got my Framework

[DigitalisAkujin]

Oh sorry I forgot to mention. Ability to track the status of the file upload would be a requirement. At the moment Flash is the only thing that supports it.

Re:As long as I got my Framework

[Anonymous Coward]

Using an iframe doesn't count as ajax, by any stretch of the imagination.

Re:As long as I got my Framework

[larry bagina]

you can track the status.

Use a perl (or some other language that handles everything manually*) script to receive the upload submission and write it to disk in a known location with a known name*. A second script can then compare the file size as it's uploading. Somewhat ugly

* PHP won't work since file uploading is handled behind the scenes.
** this may involve storing statistics in a database, manipulating session data, etc.

Re:As long as I got my Framework

[Anonymous Coward]

asyncronous AJAX

Maybe you should use synchronous AJAX instead. Oh, wait...

Re:As long as I got my Framework

[kjamez]

fwiw, file upload w/ jquery is nothing special. Any dhtml toolkit can do it. js2/emca is nothing that hasn't been discussed to no end already, and I miss how bringing jQuery into this even deserves a FYI.

Re:As long as I got my Framework

[jsebrech]

Use a perl (or some other language that handles everything manually*) script to receive the upload submission and write it to disk in a known location with a known name*. A second script can then compare the file size as it's uploading. Somewhat ugly

* PHP won't work since file uploading is handled behind the scenes.

PHP 5.2 and up allows you to track file uploading using much the same approach as perl (two scripts).
See http://www.ibm.com/developerworks/library/os-php-v525/index.html

Re:As long as I got my Framework

[Tolkien]

To be fair, the person who originally coined the term AJAX never even intended it as an acronym, just another buzz word. "Asynchronous AJAX" although logically redundant, could still be accurate without being technically redundant.

P.S. for the source of my info, read Heads-Up AJAX. :)

Re:As long as I got my Framework

[foniksonik]

Flash needs a server side script to do file uploads.

You can do the same with javascript and say PHP for example using an AJAX method, with an oncomplete type event triggered in javascript from the ajax response.

Here is a Jquery plugin demo that supports this (displaying an alert with file info in the demo but you can do more with it):

Ajax File Upload with JQuery

Re:As long as I got my Framework

[foniksonik]

This one has a progress bar to show you status of the upload

Javascript 2.0, usable by 2015...

[curunir]

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.

Re:Javascript 2.0, usable by 2015...

[Anonymous Coward]

How dare you make so much sense?!

Re:Javascript 2.0, usable by 2015...

[cmburns69]

What you wish WAS available for previous versions of IE. PerlScript was one scripting language that made use of the technology. The technology behind it has been deprecated in favor of .NET. The technology is available, but your users won't (or aren't allowed) to download the plugin just to see your site. At least with the lowest-common-denominator strategy we have now, you can build fairly robust sites. I fear the world you describe where I have to ask my users to install my specific language plugin before my site will work.

Re:Javascript 2.0, usable by 2015...

[maxume]

Mozilla has a project underway to make a plug-in run javascript 2.0 inside of IE:

http://wiki.mozilla.org/Tamarin:ScreamingMonkey

Re:Javascript 2.0, usable by 2015...

[Anonymous Coward]

IE 7 support will be necessary until at least 2012

... and then the world will be destroyed by an ancient Mayan god, rendering support unnecessary.

Re:Javascript 2.0, usable by 2015...

[AttillaTheNun]

Any reason this couldn't be done today (at least for Firefox)? I'm not too familiar with the Firefox architecture - could one write a Python interpreter plug-in, for example, that would have sufficient integration with the browser to replace Javascript?

All it would take is one example to set the bar for others to follow.

Re:Javascript 2.0, usable by 2015...

[tknd]

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.

I'm afraid of this idea. Partly because it reminds me of Java applets and Flash.

Re:Javascript 2.0, usable by 2015...

[VGPowerlord]

Wait, wait, wait, you're advocating that an indeterminate number of possibly incompatible versions of an indeterminate number of interpreters would be less messy that the six or so versions of one interpreter we have now?

Thanks, but no thanks.

Here's the short list of potential problems with that:

1. Each interpreter needs a partial or complete standard library.
   
2. Each interpreter needs to be sandboxed or have potentially dangerous functions modified or removed.
   
3. Each interpreter needs to have DOM support added to it.
   
4. Each browser needs a way of adding media types for supported scripting engines.
   
5. For that matter, each scripting engine needs an IANA assigned media type if it doesn't already have one. Java, Perl, PHP, Python, and Ruby are all missing from the application media type list.
   

I'm sure I can list more if I stopped to think about it.

Re:Javascript 2.0, usable by 2015...

[Hatta]

How about we push all the code execution back onto the server where it belongs?

Re:Javascript 2.0, usable by 2015...

[metachimp]

How would a server know how to appropriately position an element on a page if all the processing was put back on the server?

Re:Javascript 2.0, usable by 2015...

[eugene259]

The whole set of internet technologies is a mess. There are multiple competing standards for everything. I like the plugin idea but apart from that you are just stating the obvious, the mass uptake does lag behind the new tech but we don't just stop because of that do we?

Re:Javascript 2.0, usable by 2015...

[Hatta]

Write good device independant HTML/CSS and let the browser decide where things go.

Re:Javascript 2.0, usable by 2015...

[noiseusse]

http://wiki.mozilla.org/Tamarin:ScreamingMonkey

Re:Javascript 2.0, usable by 2015...

[jsebrech]

How about we push all the code execution back onto the server where it belongs?

That approach doesn't scale. You need massive server resources to generate all page layout on the server as you scale up the complexity of web applications. Telling people to push things to the server is telling them to not move past the complexity of web 1.0 applications.

Re:Javascript 2.0, usable by 2015...

[Anonymous Coward]

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.

Rot. Comments like yours end up being a self-fulfilling prophecy. W2K is in extended support, Opera and Fx3 work fine.

By the time JavaScript 2.0 is available in nearly all browsers you find in the wild

Not "all browsers you find in the wild" support script in any form. If you're targeting maximum audience, script should be used only to enhance the user experience.

That way, a website can trigger the user to update to the latest version of the language spec

Why didn't anyone else think of that?

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)

No it shouldn't, what is wrong with you people? Note I removed Java/Groovy because (as I suspect you well know):

• Applets already run in browsers via a plugin
  
• GWT lets you write in java and generates javascript.
  

You can generate javascript from any language and authoring server-side code in javascript is trivial. Then there's Haxe, Lazlo and friends which target the exact none-problem you highlight. You might as well be arguing that every desktop application should be able to load it's own ISA.

Re:Javascript 2.0, usable by 2015...

[Anonymous Coward]

My tip is to take a look at Adobe Flex 3.

Produces powerful cross platform consistent RIA's via the Flash 9 plugin.

Browsers will never be consistent and developing RIA's based on Javascript/AJAX are a nightmare unless you have vast resources and expertise at your disposal.

Seriously trying to be helpful here and not trolling for responses from Flash critics.

Re:Javascript 2.0, usable by 2015...

[anomalous cohort]

we should be pushing browser makers to allow scripting to be installed via plug-ins rather than being native to the browser

This sounds like an advertisement for Silverlight or Flash. ASAIK, Silverlight is supposed to support many languages including VB.NET, C#, Python, and Ruby.

No thank you. The scripting engine should be native to the web browser. The last thing I want is to author a page that requires a 10 MB download and where every HTML DOM manipulation requires a cross-apartment threading call.

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 reason why adoption is slow is because the current system, though not perfect, works. IMHO, there is no compelling reason to replace the script engines in the current crop of web browsers.

wouldn't it be easier to use Ruby for the client-side scripting as well as the server-side?

Not to me. My brain is big enough to know and work in more than one language. Actually, I prefer that the client side and the server side programming languages are different. I am less likely to confuse my server side coding from my client side coding. It is a common mistake to do that. For example, expecting a server side variable to be available to client side code without any additional coding.

why won't javascript die already?

[spiffmastercow]

Okay, look... Javascript isn't horrible for static pages. But sometime in the mid to late 90's the server side of things started taking a lot more importance, and javascript was not really suited to deal with this. Sure, it could be hacked to work. We now even have standard methods for implementing this horrible solution in ways that only occasionally make web developers want to pull their hair out. But really, when I think about what's involved in web programming, we have: 1.) A markup language for the layout of the pages (XML, HTML, DHTML, etc.) 2.) A language to manipulate that markup on the client side (javascript) 3.) A language to manipulate that markup (and the client language code) on the server side (PHP, ASP.NET, Ruby, etc.) 4.) (usually) a database language (SQL) Can't we eliminate at least one of those? I really feel like we should have the same language running on the server as on the client. I personally would prefer python, but I don't really care what language it is. I'm just tired of the inconsistency.

Re:why won't javascript die already?

[Anonymous Coward]

I really feel like we should have the same language running on the server as on the client. I personally would prefer python, but I don't really care what language it is. I'm just tired of the inconsistency.

Time for a slashdot car analogy.

On the roads, we have motorbikes, cars and 18 wheeler trucks. I don't care which one we all use, as long as we eliminate 2. I'm tired of the inconsistency.

The fact of the matter is SQL would suck at manipulating the dom on the client. Javascript would suck as a language to query a database. Server side scripting (php, python etc) could be hacked to natively query a database or manipulate the browsers dom, but it would be ugly AND require support from every browser. I hardly think IE is likely to natively support python.

We have different tools for different jobs, this is for a reason.

Re:why won't javascript die already?

[Lennie]

Yes you can, it's the database. :-)

Re:why won't javascript die already?

[ramone1234]

While it's hard to disagree that python would be ideal for both client-side and server-side, I think you probably realize that realistically that's not going to happen anytime soon. With that said, there certainly is the possibility to use javascript on both ends, via server-side options like jaxer ( http://www.aptana.com/jaxer ), helma ( http://dev.helma.org/ ), or maybe even JScript.net if you're stuck on windows.

I think you'll find that this latest version (2.0) of javascript is very pythonic, with its array comprehensions that are a lot like Python's list comprehensions.

As an aside, you're not still writing SQL queries are you? Almost every web dev platform out there has that abstracted nowadays... SQLAlchemy is a great choice for python...

Re:why won't javascript die already?

[Kashra]

Servers and clients do different things with the data. It makes sense that different languages would be employed on either side.

Re:why won't javascript die already?

[modmans2ndcoming]

Sounds like you need a good healthy dose of Silverlight 2.0

Re:why won't javascript die already?

[spiffmastercow]

Sadly, I am still writing SQL. The company I work for needs a lot of custom reports that don't fit neatly into the ORM model everyone keeps pushing for. That, plus I have to deal with a legacy database developed by someone who apparently never heard of normalization. I've dealt a little with LINQ (I'm stuck with MS, unfortunately), and it works great for some things, but the static typing can really get in the way of what I want to do sometimes, and it completely prevents me from being able to develop dynamically generated reports. It's great for creating new records or making mass changes in the database that aren't easily handled by an update query though.

I'll take a look at javascript 2.0 though.. I'm just concerned it's going to be the same issue as its always been with javascript, where I have th write 3 different versions of the same code to deal with different browsers.

"Program Units" - potential for misuse

[willy_me]

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

[smallfries]

This would be a complete non-problem. If you could inject a malicious script then you could replace the original rather than a script downloaded on demand. It's not secure against a man-in-the-middle because downloading and running non-authenticated scripts off the web is not secure anyway. Given that you could hijack the original script, why try and hijack one of the sub-units?

Re:"Program Units" - potential for misuse

[willy_me]

If scripts are brought together from different hosts this could be a problem. Or how about scripts from a local page that reference a foreign host. What happens if the host is compromised in the future?

I realize that when used properly, this is probably not an issue - hence "misuse" in the title. But the language should be designed such that it does not promote dangerous code. We are talking about running code from a remote host - that can always result in problems.

My first thought is that allowing for "signed" scripts could be a good idea. How about only allowing "unsigned" scripts that originate from the same host?

There are lots of potential problems and solutions to "Program Units". I was just hoping someone more knowledgeable on the subject would provide some thoughts on the issues.

Re:"Program Units" - potential for misuse

[rbanffy]

"how does JavaScript 2.0 protect against this?"

I would guess the first implementations will not allow code to be downloaded from a site/tree other than the one the page belongs to.

Re:"Program Units" - potential for misuse

[Bogtha]

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:"Program Units" - potential for misuse

[Maxmin]

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?

You're talking about signed scripts, something not very commonly used. Something about being endlessly prompted to approve your browser's verification of the script's authenticity, or some crazy shit like that.

Point is, however, you're talking about a vulnerability that's in the network. Any protocol or script or program sent over the 'net is vulnerable, unless signed, and even that can be faked. A hacked DNS server at your ISP could redirect you to a phishing site when you visit your bank's website. Or, Verizon could redirect your negatory DNS lookups to one of their spam servers.

... one could easily inject malicious X ... how does language/protocol/client Y protect against this?

See? So, the question you have to ask is, how common are MITM attacks? I don't know the answer, but it seems more likely that your bank or ISP or online retailer is going to "lose" a few million financial identities to hackers, than you'd fall victim to a silently-inserted malicious script.

But who knows? Web browser security is notoriously tissue-thin, so we all have risk profiles with non-zero p, and the MITM attack could come along any vector- flash, HTML, HTTP, DNS, SMTP, etc.

Look at all the malware out there, a far more tangible problem; downloaded by unwitting noobs, busily building networks of zombie spam bots or whatever. MITM seems a more risky technology investment for the digital conman, with the penalties of being traced and caught. Kind of amazing that malware authors aren't chased down the same way hackers are. Maybe I don't watch enought television - missed when Prezzie Bush signed the anti-malware bill into law.

Re:"Program Units" - potential for misuse

[Anonymous Coward]

How do we know a script is safe? We don't.

That's why I keep javascript turned off.

And avoid sites that use it.

Re:"Program Units" - potential for misuse

[jsebrech]

Javascript 2 deals with this the same way as javascript 1:

http://www.mozilla.org/projects/security/components/same-origin.html

js should be shot

[tute666]

Yet another example of buggy/horrible technology which has prevailed due to backwards compatibility. The future should be browsers that can be extended with various scripting languages.

Is writing Evil Javascript still supported?

[billstewart]

I've really disliked Javascript since Netscape 2.0 or thereabouts. The problem isn't that you can't write perfectly good safe Javascript; it apparently works quite well for some things. The problem is that unlike Java, you can also write Evil Javascript, and you can also write Broken CPU-sucking Javascript. So if I leave Javascript turned on, because there are sites that require me to use their Javascript to do the things I want to do there, my browser's open to Evil Javascript on other sites, plus there's enough Bad Javascript out there that after I've done enough browsing, Firefox is burning most of my CPU on leftover broken cruft that I have to kill it.

Yes, I'm aware of NoScript and similar add-ons, and I'm happily using them. That helps, but there's still too much bad and ugly stuff out there to be happy about anything good that JS can do.

Re:Is writing Evil Javascript still supported?

[Bill, Shooter of Bul]

Sorry I don't have mod points. Its just scary to ready other people's javascript on sites. I respect the google app level of javascript, but it seems like js is used far too often to do add nothing to the usability of a site.

Re:Is writing Evil Javascript still supported?

[ubernostrum]

The problem is that unlike Java, you can also write Evil Javascript, and you can also write Broken CPU-sucking Javascript.

I took that as a challenge, and in just under a minute I had an implementation of the naive (exponential performance) Fibonacci algorithm in Java, and told it to spit out the first 1000 Fibonacci numbers. It's sucking CPU like there's no tomorrow. Were you under the impression that Java couldn't do that?

Re:Is writing Evil Javascript still supported?

[Curien]

[U]nlike Java [emphasis added], you can also write Evil Javascript, and you can also write Broken CPU-sucking Javascript.

That's different from Java... how?

Re:Is writing Evil Javascript still supported?

[Moridineas]

So if I leave Javascript turned on, because there are sites that require me to use their Javascript to do the things I want to do there, my browser's open to Evil Javascript on other sites, plus there's enough Bad Javascript out there that after I've done enough browsing, Firefox is burning most of my CPU on leftover broken cruft that I have to kill it. This never happens to me. There are obviously a lot of people out there who feel like you do (and use NoScript, etc) but I've never really gotten it. Where are these websites which kill your browser or do otherwise unwanted things? Is it that huge a problem?

(I use Safari more than Firefox, and while it's improved vastly in its latest versions, Safari has traditionally sucked both speed and correctness with javascript in comparison with FF)

Re:Is writing Evil Javascript still supported?

[multipartmixed]

I don't know what browser you're using, but CPU-sucking javascript should get stopped in its tracks by firefox. When the branch callback counter hits some magical number, you should get an alert that says something like "the script you are running sucks ass. abort or continue?"

Re:Is writing Evil Javascript still supported?

[Anonymous Coward]

Use Opera (like I am) - yes, a few sites are broken, but Opera allows per-site settings, like cookies, javascript on or off, etc. It's really awesome and I can't understand why anyone would use anything else (except for a few broken sites...)

Re:Is writing Evil Javascript still supported?

[billstewart]

[U]nlike Java [emphasis added], you can also write Evil Javascript, and you can also write Broken CPU-sucking Javascript.
That's different from Java... how? That's different from Java because Java has a security model to prevent this, and most implementations do a pretty good job of not breaking it. Occasionally there's been an implementation bug, which has gotten fixed, but AFAIK (as of a few years ago, when I last paid attention to Java), the security model itself was still solid. No surprise, because that was one of Gosling's objectives in writing it. Javascript has bits of security tacked on the side, but that's about it.

Yuck.

[Tabithy]

Making javascript more like java is not what I would consider an improvement.

Re:Yuck.

[Anonymous Coward]

Well you obviously don't understand the value in taking the worst of two worlds and mashing them together into something that will make the stablest browser crack at the seams. oh the horror.

looks nice but...

[WoollyMittens]

I know I'll be coding for the "vast minority" of people still using Internet Explorer 6 while refusing to upgrade for the best part of this decade. Why do people buy a new mobile phone every year, but keep the same browser they got with their computer back in the late 90's?

Things to come...

[fahrbot-bot]

... 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'm predicting "NoScript 2.0" :-)

I think thats the point.

[Bill, Shooter of Bul]

Most javascript is written by developers that are not using self like languages on the back end. Making the two more similar should allow more developers to write more complex javascript.

And in my book having more javascript is the huge step backwards.

Don't forget about ECMAScript and Actionscript!

[jinushaun]

For those who didn't RTFA, it should be noted that Javascript 2.0 is actually ECMAScript 4.0 (ES4). Even if IE9 and FF4 supported ES4 completely, we'll still have to develop for the legacy browsers! Oy vey! Such is the life of a front-end web developer!

That being said, Flash Actionscript 3.0 (available now) includes many of the new features found in ES4 such as real classes. The next version of Actionscript will most likely be ES4-compliant.

Notable features in ES4 include:
- Classes and interfaces
- Generics
- Packages and namespaces
- Compile-time type checking
- Constants
- Operator overloading
- Record types (i.e., structs or light-weight classes)
- Typed arrays and hash maps
- Iterators
- Exceptions

More info: http://www.ecmascript.org/es4/spec/overview.pdf

Re:Don't forget about ECMAScript and Actionscript!

[modmans2ndcoming]

Flash actionscript is an abysmal joke.

JavaScript changing into Python

[xant]

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.

Re:JavaScript changing into Python

[nuzak]

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

Unless you're talking about PyPy, it won't. It sure doesn't in 3.0, which added type annotations that only work on functions and methods. And these annotations? They don't actually do anything at all.

Re:JavaScript changing into Python

[TrnsltLife]

I'll lay my cards on the table and say that I think Java makes programming laborious and unpleasant

That's why there's Groovy. It makes working with Java pleasant and easy.

Re:JavaScript changing into Python

[xant]

I remember seeing plans for Python 3.1 that included using those annotations to do just-in-time compiling and other performance-type stuffs. However, I'll admit I'm too lazy to go find the reference.

Or as James Gosling is supposed to have said...

[weston]

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

The functional/prototype hybrid in Javascript was a little odd and hard to get used to, but once I did, I've found I like it better than a Class model. Interface/implementation works for me too, but especially in Javascript, I never feel like I really need that fancy keywords to get that done.

There's an awful lot of serious work in the Java community, but I sometimes feel like a lot of *common* practices have evolved because people condensed "best practices" into a formula without disseminating the principles behind them, and it's ended up becoming a lot of busywork. Now it's filtering out to languages like PHP and Javascript that apparently want to grow up to be like Java.

I take some comfort in the fact that there will almost certainly have to be a backward compatibility layer for a long time. And I like the idea of units and constants and namespaces. But I'm not sure this is Javascript anymore, and I'm pretty certain it's not a step forward for the language.

Re:Or as James Gosling is supposed to have said...

[kbro]

Gosling never said that. He said that as a joke. See http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html?page=16

What he did say is that the use of the 'extension' keyword should be avoided.

Re:Or as James Gosling is supposed to have said...

[weston]

I think I understand this -- Holub's article is actually the way I was exposed to the quote in the first place. And while Gosling's remark was somewhat tongue-in-cheek, I don't think he was entirely kidding.

The problem is that classes tend to encourage type hierarchies and implementation inheritance... and thus the use of extends, which is part of the new JS spec. Especially when combined with standard OO instruction these days -- implementation inheritance is one of first things typically mentioned in your average course or latest book explaining OOP.

The interesting thing is that with dynamic typing and prototype inheritance, half the agility issues Holub mentions in that piece go away.

I'm actually not looking forward to this

[fatalGlory]

I think that this new revamped javascript might really cause me some irritation down the track. I'm all for cleaning up javascript a little, but OOP? Does it really need it? I guess there might be a place for it with AJAX apps, but most javascript work is for really simple little functions like checking form input before submitting - and it has been great for that.

For so long, I've been recommending to people who want to learn to program to start with javascript because it is syntactically lenient and has a very quick learning curve (if you know even a little HTML). I'd say leave Java's jobs to Java. Javascript has an entirely different purpose IMHO.

Re:I'm actually not looking forward to this

[TheRaven64]

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.

Bleah. Classes.

[argent]

I agree with Gosling. Classes are an unnecessary abstraction layer. Why shouldn't you be able to inherit from any object?

Re:Bleah. Classes.

[jsebrech]

I agree with Gosling. Classes are an unnecessary abstraction layer. Why shouldn't you be able to inherit from any object?

Gosling's argument against classes is that they encourage implementation inheritance, instead of interface inheritance.

Javascript lacks interface inheritance, and that's what makes it weak.

IMHO, inheriting the implementation from an object buys you nothing of value because well-structured code simply doesn't need it.

Re:Bleah. Classes.

[shutdown -p now]

Gosling's argument against classes is that they encourage implementation inheritance, instead of interface inheritance.

Gosling has never argued against classes as such, he argued against "extends", which is, indeed, implementation inheritance. But it is still within the realm of class-based object model. JS is in an entirely different language family, prototype-based OOP.

IMHO, inheriting the implementation from an object buys you nothing of value because well-structured code simply doesn't need it.

"Well-structured" is a subjective term. There is a certain mentality associated with every language (or rather, the programming model it represents) which has its own definition. Well-structured Java is not well-structured Lisp, and vice versa; and well-structured JavaScript is rather different from both of those.

Re:Bleah. Classes.

[argent]

Javascript has a plethora of flaws, many of which (like the procedural syntax) are faithfully preserved in Javascript 2. That doesn't mean that it should inherit bad designs from other languages in the process of fixing its flaws.

Standards rule

[heroine]

Instead of writing specs in essay form & expecting someone else to translate them into software, why can't these guys just write the spec in the form of the software to actually implement it and then rely on someone else to optimize it?

class keyword

[essence]

Why is there so many people surprised about the class keyword finally being implemented? I remember reading the reserved words for javascript way back in the 90's and seeing class in there. I always wondered how long it would take to be implemented. Here is a list of javascript reserved words.

Re:class keyword

[multipartmixed]

Quite a few of those were reserved because they were Java reserved words, and they didn't know how Java and Livescript were going to "merge". It's just a happy coincidence that class was in there.

IIRC, IIUC, AFAIK, etc.

It should all die..

[Chrono11901]

HTML,JS,CSS,PHP,ect...

Right now web 2.0 is the Frankenstein of codeing.
-php to get dynamic data
-html to see the page
-css to make it look pritty
-javascript to alter a current page

So for me to update a section of a page without doing a complete reload need to... create a call in javascript that grab the html from a new page that is created by php, then we use javascript again to inject it into the html tag we want.

From the geeky side it seems cool... but for someone who develops web 2.0 pages, it would be nice if one standard framework would be developed that encompassed all these things. So that coding "Web 2.0" pages would be cleaner, easier, simpler, and more efficient.

Re:It should all die..

[jjohnson]

If you had one standard framework, there'd be other, competing, one-standard-frameworks, and you'd be stuck choosing which one has the most market share, and then complaining about how that other one-standard-framework has a feature you wish you had.

The dog's lunch that is web coding is the reason that Web 2.0 has virtually 100% penetration (yes, at a cost in complexity and reliability). All those pieces are interchangeable (ASP/JSP instead of PHP, flash instead of HTML/CSS), so no company can get a lock on any of it, and you can pick from the buffet only what you want if you're not offering the full 2.0 experience.

It's definitely a tradeoff against having a nice clean development environment, but really, what you've got IS the one standard framework with a lot of choices in it, and no competition unless Silverlight (improbably) succeeds.

compile-time checking

[wralias]

From TFA:

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

Awesome. JavaScript needs constants - it's the big missing piece as far as types. And I personally love static type checking. Waaaay easier to debug... As someone who does hardcore "OOP" in JavaScript, I'm excited by the prospect of these changes, even if they are years away from being implemented by all browsers.

xss 2.0

[Heembo]

Ah cool! Cross Site Scripting and site defacement 2.0!

Great.

[multi io]

This looks like a weird combination of the "second system effect" (introduce a Java-like class system because supposedly that's what people want now), fixing what wasn't broken (introduce a Java-like class system to a language that didn't need it), not fixing what was broken (the strange constructor function/"this" semantics), and, inventively, breaking what wasn't broken (operator overloading). There's also a tiny bit of actual fixing what was broken (namespace system), but I don't think that that will save the day :-P

Interesting evolution

[Anonymous Coward]

As an "old timer", I find it both fascinating and horrifying to watch the evolution of static web pages into "rich applications", shoehorned into the request/response model with a crazy wobbling mass of server-side languages, client-side language(s), browser plug-ins, HTML, DOM, CSS, JSON, XML... God knows what else. It's like GUI and client/server programming didn't exist before and they are trying to reinvent in the most illogical way possible.

Is it humanly possible to make this any more complicated, brittle, or insecure?

Don't answer that... I'm sure somebody's working on it.

Re:Interesting evolution

[Bluesman]

I think the same thing, except that I really, really like the whole write-the-interface-as-a-document-then-manipulate-it style of GUI programming.

Compared to writing applications with some GUI toolkit, web programming is a piece of cake. It seems like the right way to do things...if only the scripting portion were a bit more advanced.

Imagine if javascript had a facility for opening sockets and writing files - developing an app with that system would be a dream.

Re:Interesting evolution

[shutdown -p now]

Is it humanly possible to make this any more complicated, brittle, or insecure? Don't answer that... I'm sure somebody's working on it.

Yeah. It's a framework built on top of everything you've listed, attempting to hide all the complexity by pretending it wasn't ever there. It's called ASP.NET. There are others like it, but I've yet to see one which had a "page lifecycle" consisting of more than 10 steps (marked by raised events, each of which can, and occasionally should, be subscribed to, depending on what exactly you're trying to do).

Flex

[microbox]

I tried Silverlight, lots of features, bloaty and complex.

Flex is pretty clean, fast, and the language is great. Lots of pretty stuff, as well as lots of scope to create great platforms.

Screw Silverlight. Why muck around with unnecessary complexity and vendor locking. Flex is comparatively elegant and simple. Just my opinion for having used both.

Java 2.0 is not better...

[Anonymous Coward]

Umm, This actually stuptifys Java,, Making it easier for people to use.. And in the process limits us real programmers.. Personally I would like to see it more customizable..

Here's the link to the real info.

[Animats]

First, ignore the ad for the blog and go directly to the language specification.

I read through that and winced. It's one of those backwards compatible hacks that makes a language ugly. Current Javascript has a class implementation based on copying a base object, but no real class abstraction. This follows the model in Self. Most other object oriented languages (C++, Python, Java) have explicit class declarations. Javascript 2.0 adds class declarations without throwing out the old mechanism. This is a mess. I understand why they were forced to that decision, but it's still a mess.

The trend continues. They threw in most of the things Python 3K has and current Javascript doesn't: type annotations, generators, and packages, and namespaces. There's type checking, but it's optional for now. (This is like the transition from K&R C to ANSI C). Java-type interfaces where thrown in. At least they didn't add templates. It's a collection of features in search of a design.

In the end, we get something that's like a mixture of Java and Python.

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

[imbaczek]

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.

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

[Anonymous Coward]

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. {
        var first: T, second: T
        }
        type Box. = { value: T }
        function f.( x:T ): T ... The goggles, they do nothing!

Adoption

[driftingwalrus]

Given the current state of standards adherence in modern web browsers, I think we can look forward to this being broadly implemented somewhere around third quarter of 2116.

And I am really, truly depressed about...

[Secret Rabbit]

... how IE will completely fuck everything up ruining everything for everyone that has to support that raging piece of crap.

Examples of CPU-sucking Javascript

[billstewart]

Under WinXP, open the Task Manager to show CPU and memory consumption, minimize it, take Firefox 2.x to fark.com, open all the news article links in tabs, then close all of them (but leave the main page open.) Most of the time you'll not only have well over 100MB of RAM still in use, but you'll have your CPU smoking as well.

Re:Examples of CPU-sucking Javascript

[Moridineas]

So when I open 30+ tabs I should be surprised that my CPU is chugging and firefox is sucking ram? And I'm supposed to blame javascript? I dunno..

Re:Examples of CPU-sucking Javascript

[pbaer]

Only because you're using firefox, I've had 113+ tabs open in Opera without my cpu chugging. Of course it still uses substantial ram, but the browser and other programs remain snappy and there's no obvious memory leaks.

Re:Examples of CPU-sucking Javascript

[StrawberryFrog]

So when I open 30+ tabs I should be surprised that my CPU is chugging and firefox is sucking ram? And I'm supposed to blame javascript?

Well, yes you should. It doesn't take any CPU at all to not render the html on the 29+ tabs that aren't currently being shown.

Re:Examples of CPU-sucking Javascript

[Moridineas]

Well, yes you should. It doesn't take any CPU at all to not render the html on the 29+ tabs that aren't currently being shown. I should think it certainly does take up CPU time to have lots of simultaneous network connections downloading data, parsing or not, loading them into memory, etc. Additionally, most people expect that when you click a background tab that's finished downloading that it shows up instantly. Not saying there's no room for optimization, but i think you're minimizing what's going on.

Re:Examples of CPU-sucking Javascript

[billstewart]

While they're downloading and rendering, I've got no problem with Firefox needing to use the CPU. But five minutes later, or an hour later, they shouldn't be using CPU time to maintain that. And especially after you've closed the tabs, they shouldn't be burning CPU time.

duck-typing

[garutnivore]

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.

This is all nice and well until someone misses the fact that a function which was expecting an array was expecting a specific kind of array. Something which has [] and size() and/or length() methods could be a regular old array in which elements are indexed by number and which iterates over elements in order of their numerical index. Or it could be an hash table which iterates over elements in an order appearing arbitrary from outside the implementation of the table. Then if the function expects a certain order of iteration, you're screwed.

At this point someone will interject "testing! testing!". Okay, but when using significant software written by third parties in python or Ruby or similar languages I've experienced several cases of exceptions being raised because one part of the software passed an unexpected object to another part. So I guess the testing did not catch that, now, did it?

I've written software used in a production environment (i.e. the business depended on the software working well) in both python and Java. So I'm used to both duck-typing and the strict kind of typing Java does. I don't think one is better than the other in any kind of absolute sense (i.e. irrespective of context). For scripting, I almost always use python. For bigger apps, it depends.

Re:duck-typing

[SanityInAnarchy]

This is all nice and well until someone misses the fact that a function which was expecting an array was expecting a specific kind of array.

That's an argument against duck typing, not necessarily against operator overloading.

At this point someone will interject "testing! testing!". Okay, but when using significant software written by third parties in python or Ruby or similar languages I've experienced several cases of exceptions being raised because one part of the software passed an unexpected object to another part. So I guess the testing did not catch that, now, did it?

I don't know. You haven't provided nearly enough information.

Were these exceptions raised in production? (One way testing catches problems like this is through exceptions.) Is it the kind of thing which was able to sleep for five years or so, and then make the production site blow up? Or is it something that you see with routine Q&A on a staging server?

How complete was the test coverage? Was a code coverage tool used? Which one?

Was the development driven by the tests, or were tests added as an afterthought?

I don't think one is better than the other in any kind of absolute sense (i.e. irrespective of context).

Fair enough.

Here's what I think: Strict typing is a specific kind of unit test. It's pervasive, and maybe helpful, but you need unit tests anyway.

And just as strict typing won't catch every kind of typing mistake you could make, unit tests won't catch every kind of bug you might have. However, strict typing also makes your code more verbose -- and there are other things about Java which also tend to make code verbose. Wasn't there a study done somewhere which showed that bugs per line of code stays constant across languages? That seems to be an argument for whichever language is the least verbose.

Ugh-One Topology to rule them all.

[Anonymous Coward]

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

Hey! If it's good enough for mathmaticians then it's good enough for you guys.

Dead in the water.

[sproketboy]

JavaScript 2.0 is neat but M$ ain't gonna support it so it's basically dead in the water. Sucks butt...

Can't resist

[piotr.illichosky]

This is JAVAAAAAAA! Sorry, can't resist

Integer types! Slashdotted! Dojo?

[ggpauly]

int, uint, long - now we can deal with currencies. I never understood the lack of explicit integer types in js. What was the idea behind that?

Also, the TFA link to the ECMA site is down and does not go to an authoritative document anyway. Try http://www.ecmascript.org/es4/spec/overview.pdf

How will this affect libraries such as Dojo? My first thought is that browser support will be even more complex and make libraries more necessary.

And all I wanted is getters and setters...

[srijon]

The JavaScript 2.0 standard has been floating around for a long time now, it's old news. Flash's ActionScript has already moved well beyond JS2. Yet in browser land, support for JS2 remains blotchy, and will for the foreseeable future.

The sad part is all I wanted was -one- component from JS2: getters/setters. With that, you can go a long way in hiding the differences between browsers, by adding appropriate getters/setters.

FireFox supports getters/setters now, so does Safari, even the iPhone! But IE7? Haha.

Re:And all I wanted is getters and setters...

[Achoi77]

Flash's ActionScript has already moved well beyond JS2.

what are you talking about? Adobe made Actionscript 3 with the intent on it complying to the ECMA-266 4th Ed specifications. You know, ECMAscript 4th ed, probably more commonly known to the general public is JS2. Or are you talking about the different set of standard libraries that each implementation uses?

The sad part is all I wanted was -one- component from JS2: getters/setters. With that, you can go a long way in hiding the differences between browsers, by adding appropriate getters/setters.
FireFox supports getters/setters now, so does Safari, even the iPhone! But IE7? Haha.

lol, what are you talking about? Are you talking about implementing getters and setters in an object? You can do that right now, in IE6, or any browser that supports EMCAscript 3ed. But that's not what it sounds like you are talking about. It's like somewhere you got your buzzword lingo confused. Or are you just intentionally trying to spread fud - that doesn't even make sense?

Re:And all I wanted is getters and setters...

[Anonymous Coward]

He is presumably talking about Mozilla's proprietary __defineGetter__, __defineSetter__ extensions, which are NOT part of 262-3.

pam_faildelay

[Non-Huffable Kitten]

It is measured in seconds (no kidding) Better than the delay when you mistype your password on linux, which is set in frigging microseconds ;)

(man pam_faildelay if you want to know how to set this). Why does this default to several seconds anyway? At a less annoying 100ms delay, it's still 345946 years to find a (uniformly picked) 8-letter, 62 chars password.

Re:pam_faildelay

[Anonymous Coward]

It is measured in seconds (no kidding) Better than the delay when you mistype your password on linux, which is set in frigging microseconds ;)

(man pam_faildelay if you want to know how to set this). Why does this default to several seconds anyway? At a less annoying 100ms delay, it's still 345946 years to find a (uniformly picked) 8-letter, 62 chars password. just l2type n00b imo rofl u suxx0r5 kthxbai shifttt1111111111111111

Is VBScript better?

[walterbyrd]

And: can VBScript be implemented on non-Microsoft platforms?

Can't browse /. without javascript!

[Anonymous Coward]

No script is bad because you dodge google ads.
Web2.0 sites make javascript *part* of the page content, so with noscript you cannot view the content.
Web2.0 powered by the mozilla hype engine.

slashdot is part of this. With javascript disabled and as an AC you have to click once to bring up the "old interface" and a second time to view the -1 comments of the fellow trolls. But the article is not visible in this mode. Go figure....

already working on it

[HeroreV]

ScreamingMonkey seems to be what you're looking for.

ScreamingMonkey is the project to add script-engine integration glue to Tamarin, so that it can handle
    <script type="application/ecmascript;version=4">
and
    <script type="application/javascript;version=2">
tags in other browsers, starting with IE (using ActiveScript interfaces).

Doesn't single-type/prototype moot this?

[weston]

Javascript lacks interface inheritance, and that's what makes it weak.

Near as I can tell, the single-type/prototype nature of objects in the language sortof moots the need to define interfaces for the interpreter ahead of time. That leaves interface inheritance completely up to the programmer, which means that it's as weak as the programmer's ability to keep that straight.

Javascript is dead, all hail Java!

[cowwoc2001]

In a surprising twist, Java applets are making a comeback: https://jdk6.dev.java.net/6uNea.html
Instant startup, improved stability and deployment. Deployment rates estimated at 85-90% of all clients.

Sure

[Peaker]

I agree and I'd typedef that as well, but you missed the point.

I used a ridiculously complicated example in order to show that C's syntax is over-complicated. So over-complicated that long-time C programmers do not understand it.
I suggested a simple replacement which would be capable of simplifying it.

It simplifies very complicated examples by a lot, and simple examples by a little.

MOD PARENT UP

[Anonymous Coward]

Parent is modded as funny, but should be modded as insightful. I'm a fan of akaimbatman, but for whatever reason, he and his ilk get off on putting others down over the most trivial of points - JavaScript's legitimacy (and the OP's familiarity with it) being one. No one is questioning JavaScript's place in the web world, or its Turing-completeness or what have you. But it is NOT on the same level as C++/C#/Ruby/Lisp/Whatever - and to state otherwise is fucking ridiculously naive and shows signs of insecurity in ones discipline.

JavaScript is inherently limited by its platform, development history and distribution model. It has no concept of threading, I/O, low-level memory management and garbage collection, sockets or graphics library. So those of us who do need these features get annoyed by those who dismiss them and place JavaScript on an equal plane with other development environments and platforms.

But that's not even my main issue with JavaScript. JavaScript's implementations across the browser board are usually incompatible with one another in fundamental ways (see fun topics like "multi-browser event bubbling", "XmlHttpRequest" and DOM-traversal and you'll find almost all solutions involve writing different blocks of code for different browsers.) That's not to say platform compatibility isn't an issue with other languages and environments, but these issues are front and center for any kind of large JavaScript "app".

I can't be bothered to rant about the other points, but I think I got my point across. JavaScript is what it is - and God bless it for that. But the snarky attitude akaimbatman took to the OP for not being familiar with JavaScript's intimacies is the exact attitude that tends to draw the eye-rolling from other developers on different platforms.

Browser VM

[Isvara]

Clearly Javascript works well for some people, and less well for others. All depends on your experience and background. What I'd really like to have is a choice of language. If, instead of interpreting scripts, browsers standardised on a bytecode, we could write in whatever language had a suitable bytecode compiler. It's sort of possible now, with compilers like PyPy and HaXe being able to output Javascript, but that's still a hack with unnecessary overhead and makes debugging more difficult. This isn't the same as having a Java VM in the browser, of course -- AFAIK, there's no standard way for Java applets to access the DOM, and it's more heavyweight anyway.