Forgot your password?
typodupeerror
Programming The Internet IT Technology

Web 2.0, Meet JavaScript 2.0 248

Posted by ScuttleMonkey
from the just-plain-geeked dept.
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."
This discussion has been archived. No new comments can be posted.

Web 2.0, Meet JavaScript 2.0

Comments Filter:
  • Ugh (Score:5, Insightful)

    by TheRaven64 (641858) on Friday March 21, 2008 @06:46PM (#22824756) Journal
    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 (Score:5, Funny)

      by mrbluze (1034940) on Friday March 21, 2008 @07:10PM (#22824976) Journal

      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.

      • by mortonda (5175)
        If that means Java will be thrown into the fiery pit, count me in!
        • Re:Ugh (Score:4, Funny)

          by mrbluze (1034940) on Friday March 21, 2008 @10:31PM (#22826292) Journal

          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.
    • by Curien (267780)
      Javascript has always had overloaded operators. Or do you really think that string concatenation and arithmetic are similar operations?
      • Re: (Score:2, Informative)

        by Paradise Pete (33184)
        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. [elharo.com]

        • Re:Ugh (Score:5, Insightful)

          by Curien (267780) on Friday March 21, 2008 @07:57PM (#22825320)
          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.
        • 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: (Score:3, Insightful)

      by MikeBabcock (65886)
      Wake me up when JavaScript isn't taking the same bad trip down bloat ware lane that VisualBasic did back in the day.
    • 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.
    • Re:Ugh (Score:5, Insightful)

      by SanityInAnarchy (655584) <ninja@slaphack.com> on Friday March 21, 2008 @08:11PM (#22825408) Journal

      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.

    • 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
    • by free space (13714)

      ... 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.
    • 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: (Score:3, Interesting)

        by mfnickster (182520)

        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 '$' = 'v

        • Re:Ugh (Score:5, Interesting)

          by Peaker (72084) <gnupeakerNO@SPAMyahoo.com> on Saturday March 22, 2008 @06:49AM (#22828176) Homepage

          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.
    • by nuzak (959558)
      > 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 gu
    • Re:Ugh (Score:5, Interesting)

      by OoSync (444928) <wellsed@g m a il.com> on Saturday March 22, 2008 @01:10AM (#22827026)
      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).

    • by zoips (576749)
      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
  • Cross-Browser (Score:3, Insightful)

    by Anonymous Coward on Friday March 21, 2008 @06:47PM (#22824762)
    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?
    • 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
    • by Curien (267780)
      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 (Score:5, Informative)

      by stephanruby (542433) on Friday March 21, 2008 @08:16PM (#22825436)

      These new features are nice and all, but what I really want as a Web developer is for a Javascript standard thorough and widespread enough that I can write scripts that work on most browsers without a bunch of hacks to make sure that each browser gets the right code. Anyone have a prognosis on this?
      You mean this [haxe.org]? An (almost) universal metalanguage that generates the right Javascript/Actionscript/Neko scripts for different environments.
    • by Hao Wu (652581)
      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.

  • by imtheguru (625011) on Friday March 21, 2008 @06:49PM (#22824772)
    ... soon.
    • 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 n

      • by WK2 (1072560)
        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 se
  • Javascript (Score:2, Funny)

    by Anonymous Coward
    alert("keep it simple");
  • by Frans Faase (648933) on Friday March 21, 2008 @06:52PM (#22824800) Homepage
    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.
    • by xant (99438) on Friday March 21, 2008 @08:06PM (#22825374) Homepage
      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.
      • by nuzak (959558)
        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.

  • by DigitalisAkujin (846133) on Friday March 21, 2008 @06:55PM (#22824832) Homepage
    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.
    • by SeanTobin (138474) <byrdhuntr@ho[ ]il.com ['tma' in gap]> on Friday March 21, 2008 @07:10PM (#22824978)
      FYI, I've done ajax file uploads using jQuery. Works in IE6/7 and FF2/3. See jQuery [jquery.com] and the jQuery form plugin [malsup.com].
      • 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: (Score:2, Informative)

          by larry bagina (561269)

          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.

      • by kjamez (10960)
        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.

  • by curunir (98273) * on Friday March 21, 2008 @06:58PM (#22824862) Homepage Journal
    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.
    • by cmburns69 (169686)
      What you wish WAS available for previous versions of IE. PerlScript [wikipedia.org] 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
    • Re: (Score:2, Interesting)

      by maxume (22995)
      Mozilla has a project underway to make a plug-in run javascript 2.0 inside of IE:

      http://wiki.mozilla.org/Tamarin:ScreamingMonkey [mozilla.org]
    • 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
      -
    • 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.
    • by tknd (979052)

      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.

    • 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 i
    • by Hatta (162192)
      How about we push all the code execution back onto the server where it belongs?
  • by willy_me (212994) on Friday March 21, 2008 @07:02PM (#22824904)
    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: (Score:3, Insightful)

      by smallfries (601545)
      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?
      • by willy_me (212994)
        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
        • by Bogtha (906264) on Saturday March 22, 2008 @12:40AM (#22826916)

          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.

    • by rbanffy (584143)
      "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: (Score:3, Interesting)

      by Maxmin (921568)

      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 ne

  • by billstewart (78916) on Friday March 21, 2008 @07:08PM (#22824958) Journal
    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.

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

    • by Curien (267780)
      [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?
    • 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?"
  • ... 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 agree with Gosling. Classes are an unnecessary abstraction layer. Why shouldn't you be able to inherit from any object?
    • Re: (Score:3, Informative)

      by jsebrech (525647)
      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.
  • Standards rule (Score:3, Interesting)

    by heroine (1220) on Friday March 21, 2008 @08:52PM (#22825716) Homepage
    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 (Score:3, Insightful)

    by essence (812715) on Friday March 21, 2008 @09:13PM (#22825852) Homepage Journal
    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 [about.com].
    • 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.
  • Ah cool! Cross Site Scripting and site defacement 2.0!
  • 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 sav
  • by 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, brit
  • by Animats (122034) on Saturday March 22, 2008 @01:59AM (#22827176) Homepage

    First, ignore the ad for the blog and go directly to the language specification. [ecmascript.org]

    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.

    • by imbaczek (690596) <imbaczek@@@poczta...fm> on Saturday March 22, 2008 @08:47AM (#22828590) Journal

      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.
  • 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.
  • ... how IE will completely fuck everything up ruining everything for everyone that has to support that raging piece of crap.

Never test for an error condition you don't know how to handle. -- Steinbach

Working...