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

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

[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

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

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?

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.

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

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

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

[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

[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

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