Slashdot Mirror


ECMAScript 4.0 Is Dead

TopSpin writes "Brendan Eich, creator of the JavaScript programming language, has announced that ECMA Technical Committee 39 has abandoned the proposed ECMAScript 4.0 language specification in favor of a more limited specification dubbed 'Harmony,' or ECMAScript 3.1. A split has existed among the members of this committee, including Adobe and Microsoft, regarding the future of what most of us know as JavaScript. Adobe had been promulgating their ActionScript 3 language as the next ECMAScript 4.0 proposal. As some point out, the split that has prevented this may be the result of Microsoft's interests. What does the future hold for Mozilla's Tamarin Project, based on Adobe's open source ActionScript virtual machine?"

168 comments

  1. I'll wait for... by jfclavette · · Score: 5, Funny

    ECMA Script 3.11 for workgroups.

    The joke works this time !

    1. Re:I'll wait for... by JebusIsLord · · Score: 0, Troll

      Everytime there is a 3.x in a fucking version #, some asshole thinks this joke will be funny. IT NEVER IS. Slashdot, I love you, but you are NOT COMEDIANS. STOP TRYING.

      --
      Jeremy
    2. Re:I'll wait for... by BPPG · · Score: 1

      I dunno, After going from 4.0 to 3.1, 3.11 sounds more like a step backwards. Or forwards?

      --
      What's the value of information that you don't know?
    3. Re:I'll wait for... by mangu · · Score: 2, Funny

      ECMA Script 3.11 for workgroups.
      The joke works this time !

      Dude, that joke is so 1993!

      The current version is going from 4.0 to 3.5.9

    4. Re:I'll wait for... by Anonymous Coward · · Score: 0

      Well, they should have used EMACS, not ECMAS...

    5. Re:I'll wait for... by Firehed · · Score: 0, Offtopic

      In Soviet Russia, Slashdot stops trying it's jokes on YOU!

      --
      How are sites slashdotted when nobody reads TFAs?
    6. Re:I'll wait for... by Anonymous Coward · · Score: 0

      Yeah, it's almost like 4chan.

    7. Re:I'll wait for... by pragma_x · · Score: 2, Funny

      Slashdot: News for Trolls. Memes that Matter.

  2. ES4 not dead by omfgnosis · · Score: 5, Informative

    It's not dead. There will eventually be a Fourth Edition of ECMAScript, it just isn't the focus now. The ES4 proposal wasn't ever enshrined as the actual Fourth Edition either.

    I was really skeptical about the concessions made by the ES4 side before I listened to some of their rationale; it wasn't so much concessions to the 3.1 side, it was that the things they were dropping didn't adequately solve the problems they were put in to solve.

    There's a great talk about it here: http://openwebpodcast.com/episode-2-brendan-eich-and-arun-ranganathan-on-ecmascript-harmony

    1. Re:ES4 not dead by Yvan256 · · Score: 1

      And it wants to go for a walk.

    2. Re:ES4 not dead by Z00L00K · · Score: 1

      And notice that the adoption of scripting of web pages are slow in order to allow the web pages to be useful even on older browsers.

      Most of the functionality in JavaScript 1.5 is sufficient for what you normally want to do.

      The only problem is that JavaScript/ECMAScript from a language point of view isn't really good. A strongly statically typed script language would have been better since it would have allowed the developers to catch a lot of bugs that now occasionally blows up in the face of the users.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    3. Re:ES4 not dead by Hurricane78 · · Score: 1

      Wrong. It's the other way around: The adoption of new browsers is slow, because if a user hoes not absolutely has to, he's not going to upgrade.
      It's like with making products easier: As soon as you "simplified" (aka. dumbed down) your product so that even the most stupid retard can use it, nature will develop an even bigger idiot to complain how "complicated" an "non-usable" it is.

      My tip: If you wait, they will be extinct anyway. There's no need to support dumbing down, and to annoy more users than you help, when you can just take the warning labels off of everything and let the problem solve itself.

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    4. Re:ES4 not dead by rycamor · · Score: 4, Insightful

      The only problem is that JavaScript/ECMAScript from a language point of view isn't really good. A strongly statically typed script language would have been better since it would have allowed the developers to catch a lot of bugs that now occasionally blows up in the face of the users.

      That would be the worst possible thing to happen to Javascript. I know, I know... let's not get into a religious war over static/dynamic typing. There are valid points for each in different contexts, but a language in Javascript's problem domain is probably one of the worst contexts for static typing.

      Keeping the language small, clean and simple should be the priorities. If you want Java in the browser, well... that's already available.

    5. Re:ES4 not dead by omfgnosis · · Score: 1

      "And notice that the adoption of scripting of web pages are slow in order to allow the web pages to be useful even on older browsers."

      I don't really think that's the case. The adoption was slow because it took a long time for browsers with good support for scripting and the DOM (the API the script interacts with on web pages) to become dominant. Even now, the browsers in the vast majority (IE 6 and IE 7) have terrible and buggy and slow DOM support, and the only saving grace for powerful web appsâ"even nowâ"is that there are really, brilliantly nerdy people who have taken the time to build compatibility layers like Prototype and jQuery.

      "Most of the functionality in JavaScript 1.5 is sufficient for what you normally want to do."

      And if it's not, extending it is not at all difficult.

      "The only problem is that JavaScript/ECMAScript from a language point of view isn't really good."

      Are you kidding? I think it's excellent. I don't agree on the benefits of static typing, and I find AS3 a real pain in the ass to write because of it. I know how to validate the data I'm receiving according to the standards I expect. The reason JS has been so problematic for so many people is because, like PHP, the language attracts a lot of unskilled, untrained developers. That's not a shortcoming of the language, it's just due to placement.

    6. Re:ES4 not dead by omfgnosis · · Score: 1

      Nice to see misanthropy is alive and well. :P

      Evidently the art of UI design isn't a strong point for you. Usability and good UI needn't dumb down an application.

      The way I look at it is, good UI designers can produce two types of applications: easy to use and powerful, or specialized and intended for an audience that will need a UI more complex than for a general audience.

    7. Re:ES4 not dead by Z00L00K · · Score: 1

      Reality is that you when designing an application on an enterprise-scale level have to consider that not every user is running the latest browser.

      I know that for a fact, and that also means that if you don't care about users running IE5.0 or whatnot then you will get toasted by bug reports.

      This is especially true when it comes to governmental organizations as end users. I wouldn't be all surprised to find NT4 clients out in the wild still.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    8. Re:ES4 not dead by Anonymous Coward · · Score: 0

      > That would be the worst possible thing to happen to Javascript.

      Knee-jerk.
      People that have to write JS libraries would most certainly benefit from static typing.

      End-users of those libraries could ignore the typing crud and keep writing untyped code happily.

      (Note that this is not wishful thinking. The ES4 draft implementations out there allow for exactly that.)

      More generally, all the "oh my god this would be such a disruptive language change" arguments are bogus, as the draft is pretty much entirely backward compatible with ES3, in a natural way.

  3. Let's pull a Microsoft by Anonymous Coward · · Score: 0

    Mozilla and Adobe should just go ahead with v4.0, keeping it public so Apple and Opera can use it, too.

    1. Re:Let's pull a Microsoft by omfgnosis · · Score: 2, Insightful

      Why? There's consensus on Harmony.

  4. Harmony is a good name.... by QuietLagoon · · Score: 4, Insightful
    What is needed in the JavaScript world is not more features, but more consistency of implementation across the various browsers.
    .

    It is good to see the standards committee taking a breather from major new features, and instead focusing upon the alignment of behavior of functionality across the various browsers.

    Hopefully, there will be a robust and rigorous compliance test suite as a deliverable of this standards process.

    1. Re:Harmony is a good name.... by Goyuix · · Score: 4, Insightful

      I would disagree (to some degree) that more features are in fact needed. For example, E4X (and a native XML doc object) being standardized in the browsers would be a huge benefit.

      That being said, I think that a lot of the feature bloat going into the proposed v4 was really not all that great. I think this is generally a step in the right direction.

    2. Re:Harmony is a good name.... by omfgnosis · · Score: 5, Informative

      "What is needed in the JavaScript world is not more features, but more consistency of implementation across the various browsers."

      With the exception of a few later-added methods (on Array for example), that's already there. The inconsistency is in the DOM, and that's not something ECMA covers.

    3. Re:Harmony is a good name.... by hedwards · · Score: 4, Insightful

      Quite so, a lack of standardization amongst the implementations has been a serious problem for years. Allowing developers to use the entire spec as is without fear of problems going between browsers would be a huge step forward for JavaScript.

      Perhaps add in a few fixes for annoying parts of the language and similar, but overall if it's just made to be consistent across browsers, that would go a long ways.

    4. Re:Harmony is a good name.... by pembo13 · · Score: 4, Insightful

      I would ask for a safe JSON parser as well as I prefer JSON to XML (which is quickly becoming overused)

      --
      "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
    5. Re:Harmony is a good name.... by bussdriver · · Score: 1

      YES! But the next revision...

      1) They NEED to release a long list of test cases that can be run against implementations.

      2) How about having toString() output JSON? (at least specify exactly what it should output.)

      If anything new:

      Access methods for Object():
          Allows a function to monitor read/write/exec of an object's properties (EXTREMELY useful for client side patching of implementation bugs.)

      A Console object loosely modeled after FireBug with a focus on unit testing. Implementation optional; but no errors if its used.

      Perl level RegExp (look ahead)

      A few of the Mozilla additions

      Hash: an Object without ANY properties, any methods would be 'Class methods' not object methods.

    6. Re:Harmony is a good name.... by TheRaven64 · · Score: 1

      I know of two other projects known as Harmony. One was an attempt to reimplement Qt, to allow KDE to be open source and remove the need for GNOME (Trolltech effectively killed it be releasing Qt under the GPL and removing most of the need for it). The other is an open source J2SE implementation. Harmony sounds like a great name for causing confusion.

      --
      I am TheRaven on Soylent News
    7. Re:Harmony is a good name.... by omfgnosis · · Score: 1

      "2) How about having toString() output JSON? (at least specify exactly what it should output.)"

      Um, shouldn't it output a string representation of the object? Ecma-262 (ECMAScript 3) does specify exactly what it should output:

      15.2.4.2 Object.prototype.toString()
      When the toString method is called, the following steps are taken:
      1. Get the [[Class]] property of this object.
      2. Compute a string value by concatenating the three strings "[object ", Result(1), and "]".
      3. Return Result (2).

      "Allows a function to monitor read/write/exec of an object's properties (EXTREMELY useful for client side patching of implementation bugs.)"

      Why not just patch the properties/methods directly, or write an abstraction? I think the overhead of monitoring would be ridiculous.

      "A Console object loosely modeled after FireBug with a focus on unit testing. Implementation optional; but no errors if its used."

      I think this is better suited for the DOM.

      "Perl level RegExp (look ahead)"

      You had me at (?=RegExp).

      "A few of the Mozilla additions"

      I think most of those are in.

      "Hash: an Object without ANY properties, any methods would be 'Class methods' not object methods."

      Why?

    8. Re:Harmony is a good name.... by omfgnosis · · Score: 1

      I'm with you, but define "safe".

    9. Re:Harmony is a good name.... by nschubach · · Score: 1

      I'd vote for a decent JSON parser for AS that doesn't step through every character one by one to parse the data...(like the one on the JSON page) but that's just a minor gripe of mine.

      --
      Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
    10. Re:Harmony is a good name.... by Phroggy · · Score: 1

      Most implementations of JavaScript allow an extra comma at the end of a list. It's very handy when you've got a long list of stuff that you're rearranging periodically. But once you've finished development and everything works... then you discover that in some browsers, your page doesn't work, because in those browsers, an extra comma at the end of a list is illegal.

      I think Internet Explorer and Opera were the two I had trouble with, while Firefox and Safari worked fine.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    11. Re:Harmony is a good name.... by omfgnosis · · Score: 1

      Well to be fair, and I don't remember which browsers Implement which, but the extra comma is currently invalid.

    12. Re:Harmony is a good name.... by bussdriver · · Score: 1

      toString:

      OK. I didn't read revision 3. toString() is not useful IMHO; JSON would be more intuitive in that it would output source code like strings- serialized. Add serialize() if toString is so important to keep (who uses it??)

      Property Monitoring:
      It is not a big speed issue. Mozilla ALREADY adds something very similar to property monitoring. see "__defineGetter"

      Console Object:
      Javascript exists outside of DOM more so every year. Built in testing (+ unit testing) + debug options (assert, log...) would make it EASIER to javascript between APIs. Furthermore, the implementations can optimize out the Console object if they have debugging features disabled (possible in the 1st pass of parsing if done right.)

      Mozilla Additions:

      ECMAScript 4 I thought was adding the Mozilla additions but I wasn't going to look until it completed and now ECMAScript 4 is dead. (If they ever add class definitions I'll puke.)

      Hash Support:
      Javascript & JSON have typical variable naming limitations; something like this:
      [_\$A-Za-z][A-Za-z0-9_]+
      in addition, Object has properties that are essentially reserved.

      Javascript/JSON objects currently serve as fast and easy hash tables except hash keys are restricted which can cause troubles (mozilla allows violations in most situations.) Built-in hash tables are extremely useful; my suggestion was to simply hack Object down into a Hash to make implementation easy. Yes, I realize this approach means Hash would be a 2nd root object in terms of OOP. Too many OOP religious zealots out there to see this making it... I don't think one could add Functions at this point in time if they were not already built-in.

    13. Re:Harmony is a good name.... by omfgnosis · · Score: 1

      "toString() is not useful IMHO"

      Agreed, but it is defined. I don't think JSON is an appropriate replacement. I'd much prefer to see it perform a recursive toString() on its members, as JSON won't give you a representation of functions and regexes and what have you.

      "Add serialize() if toString is so important to keep (who uses it??)"

      Browser vendors that implement window.console use it. Not that it's useful in any way. I'd like to see it as .serialize() to maintain compatibility in existing implementations.

      On the console, I agree that it's necessary outside the DOM, but adding it to an ECMA standard would mean having to standardize outputs and require any implementation have an output mechanism of some sort.

      "(If they ever add class definitions I'll puke.)"

      I'm pretty sure it's still an anticipated actions, with the 3.1 changes being a prerequisite. Why would you puke?

      "Hash Support:
      Javascript & JSON have typical variable naming limitations; something like this:
      [_\$A-Za-z][A-Za-z0-9_]+
      in addition, Object has properties that are essentially reserved."

      I don't know about the restrictions on Object members and don't have the time to look it up right now but I know that any object literal can take any member name so long as it's properly quoted/escaped. // This will fail:
      var obj = {
              delete: 'foo'
      } // But this will not:
      var obj = {
              'delete': 'foo'
      }

      I don't know what you're asking for that doesn't already exist. Adding a Hash global object won't change the fact that restricted keywords are restricted. Just quote your keys if they're restricted.

      "Too many OOP religious zealots out there to see this making it... I don't think one could add Functions at this point in time if they were not already built-in."

      While I'm not as sensitive to adding optional semantics as some folks, I just would like a good rationale before proceeding.

    14. Re:Harmony is a good name.... by omfgnosis · · Score: 1

      Slashdot ate some of my linebreaks. Slashdot is hungry hungry hippos.

    15. Re:Harmony is a good name.... by bussdriver · · Score: 1

      note: ECMAScript 2 was the last one I read.
      I just assumed they'd add function and regexp to the JSON (so it wouldn't be exactly JSON; however, RegExp in JSON would be nice.)

      Console Object:
      No, implementations would not have to support Console, just be required to ignore the use of it. Detailed specifics of debug output do not need to be specified; just the JS interface to Console.

      Classes and inheritance:

      JS functions well enough without class trees and heavy type conversion. I don't want a typeless Java. (How about just integrating java instead of creating an Objective-C skewed Java?)

      JS is not a compiled language. Without seriously complex client side optimization it will SLOW DOWN. We don't want the kind of overhead that makes javac so darn fast.. Not to mention code bulk will increase as well. There are reasonable methods to get OOP like abilities in JS now (and wonderful scoping abilities.)

      HASH/Object:

      Well, I've run into fun times with violations and collisions with property names over the years. Props like 'constructor' being accessed; which is an Object property. Creating properties is not much use if you can't access them consistently. I escaped stuff, I admit I've not followed the browser issues on this matter for years.

      I suggested Hash simply off the top of my head because there are real problems with Object.

      Now, if they can resolve this problem in the spec and implementations without a Hash I'm all for it. Off the top of my head (again:)

      How about assignment actually replaces the built-in properties on Object? It normally works this way, but built-in stuff (like Object) wasn't 100% '1st class' (or it wasn't years ago... not sure I'll bother to test it again for some time.)

    16. Re:Harmony is a good name.... by bussdriver · · Score: 1

      I meant properties in an instance of Object that are used instead of the inherited properties; which is how it should work everywhere at this point (but like I said I am not wanting to test everything when I just learned avoid the issue all this time.)

    17. Re:Harmony is a good name.... by zobier · · Score: 1

      RegExp & eval == WIN

      --
      Me lost me cookie at the disco.
    18. Re:Harmony is a good name.... by omfgnosis · · Score: 1

      "I just assumed they'd add function and regexp to the JSON (so it wouldn't be exactly JSON; however, RegExp in JSON would be nice.)"

      I think it'd be good for a meta-JSON standard like JSON Schema, but as the JS object literal, of which JSON is a subset. I'd like to see JSON remain a data-only format. Not that I have any sway over it, but that's my preference.

      "No, implementations would not have to support Console, just be required to ignore the use of it. Detailed specifics of debug output do not need to be specified; just the JS interface to Console."

      I won't object to that. Especially because JS doesn't, to my knowledge, include an output function in the core language.

      "JS is not a compiled language. Without seriously complex client side optimization it will SLOW DOWN. We don't want the kind of overhead that makes javac so darn fast.. Not to mention code bulk will increase as well. There are reasonable methods to get OOP like abilities in JS now (and wonderful scoping abilities.)"

      I think this last bit is why both ECMA factions are confident that classes are okay. Moreover, it's been demonstrated that one can coerce Javascript into having class-style inheritance and implementation. I don't think this has much if any overhead in real world use. If the standard implements classes as sugar, as they propose, I can't see the harm. If you don't want it, don't use it. :)

      "Well, I've run into fun times with violations and collisions with property names over the years. Props like 'constructor' being accessed; which is an Object property. Creating properties is not much use if you can't access them consistently. I escaped stuff, I admit I've not followed the browser issues on this matter for years."

      If you can't access it as obj.property, you can access it as obj['property']. I just ran a test of an object literal with a property named with each of the Javascript reserved words, then ran this on it:

      for(var i in test) {
              alert('test.'+i+': '+test[i]);
      }

      (Just to stay sane, I replaced window.alert with console.log in Safari and Firefox.)

      Tested in the following browsers: Safari 3.1.1; Firefox 1, 1.5, 2 and 3; IE 6, 7 and 8b; Opera 9.5. None of them had trouble with it.

      "How about assignment actually replaces the built-in properties on Object?"

      Doesn't it? The following behaves exactly as I'd expect:

      alert({ 'foo': 'bar' }.toString());
      Object.prototype.toString = function() {
              return 'blah';
      };
      alert({ 'zig': 'zag' }.toString());
      alert({ toString: function() { return 'asdf'; } }.toString());

      Or am I misunderstanding what you want to do?

    19. Re:Harmony is a good name.... by Phroggy · · Score: 1

      Well to be fair, and I don't remember which browsers Implement which, but the extra comma is currently invalid.

      Yes, but you said "that's already there" referring to consistency across browsers. The situation is vastly better, but we're not out of the woods yet - JavaScript itself doesn't behave the same way across multiple browsers that are currently in common use (partly because there are some older browsers that are still being used).

      On top of that, we have serious inconsistencies in the DOM - things like, if you put a TR inside a TABLE, Internet Explorer will silently insert a TBODY for you (because surely that must have been what you meant, right?) which means the TR isn't a child of the TABLE (it's a child of the TBODY, which is a child of the TABLE). You're right that ECMA doesn't cover this, but somebody needs to!

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    20. Re:Harmony is a good name.... by omfgnosis · · Score: 1

      Okay. There are, to a small extent, differences in language implementation. A very small extent. The real clusterfuck is in the DOM, not in the language. On that I think we agree.

      As far as the table thing, I think all the "modern" (or Yahoo!'s "grade A" list) browsers assume a thead and tbody for th and td elements outside a thead/tbody respectively, and populate the DOM tree that way.

    21. Re:Harmony is a good name.... by bussdriver · · Score: 1

      Next time I'll try it without workarounds and see how it comes out. thanx for testing it for me.

      I've been doing js since before ecma; which means i am in the habit of working around "supported" features. I don't get back to them all to test them

  5. Another Win for Standards Based Innovation? by Anonymous Coward · · Score: 0

    Another win for standards based "innovation". Let private companies innovate and submit to standards bodies. Otherwise you get crap like this and XHTML 2.0.

  6. Establishing de facto (open source) standard ? by Anonymous Coward · · Score: 0

    It might be (a bit) naive. Maybe Mozilla (along with, say, Google or other companies) should implement a well designed language independent virtual machine for a browser with modern features and ECMA 4.0 spirit ? Along with MSIE bindings. Shipped with Mozilla by default. Open source. Microsoft will have no chance to obstruct this effort. After (successfull) rollout it would be proposed to ECMA as a standard ?

    Just wondering.

    1. Re:Establishing de facto (open source) standard ? by maxume · · Score: 5, Interesting

      The Microsoft stuff in the summary is just trolling. Mozilla and Google are both on board with abandoning the current work called ES4.

      --
      Nerd rage is the funniest rage.
    2. Re:Establishing de facto (open source) standard ? by boorack · · Score: 5, Interesting
      Maybe. Remembering earlier articles about ES4 and political mess about this, I dunno what to think.

      My opinion: I need a modern virtual machine with capabilities comparable with Flash/Silverlight applets and level of integration comparable with javascript engines shipped with browsers. Compatible across browsers. Language independent (I would like to program this in Python) - maybe with some kind of intermediate representation (bytecode?). Capable to run bigger, non-trivial apps. Well designed. Open sourced and not patent encumbered.

      Currently there is nothing satisfying my wishes. Pure javascript has somewhat limited capabilities (especially in multimedia area) and isn't fully compatible across browsers. Flash is proprietary and doesn't work well on some platforms and is just an applet (not well integrated with the browser itself). Silverlight is proprietary and does not work well outside windows. Java applets - along with their bad integration with browser itself and huge startup overhead - are IMO examples of bad design. Any ideas ?

    3. Re:Establishing de facto (open source) standard ? by Stan+Vassilev · · Score: 1

      Mozilla and Google are both on board with abandoning the current work called ES4.

      In particular a very curious choice on Google's part, whose GWT implements Java on browsers.

      The current decision is that we don't need ES4 as we don't need packages, namespaces, classes, early binding and types on a web language.

      Makes you wonder how GWT happened then.

    4. Re:Establishing de facto (open source) standard ? by maxume · · Score: 2, Interesting

      No, no ideas, but ES4 was only going to give you about 1/10 of what you want anyway, so you don't lose all that much here.

      --
      Nerd rage is the funniest rage.
    5. Re:Establishing de facto (open source) standard ? by maxume · · Score: 1

      My impression is that packages, namespaces and classes wouldn't have worked particularly better than the current mess at the same time that they made the language that much bigger.

      --
      Nerd rage is the funniest rage.
    6. Re:Establishing de facto (open source) standard ? by aliquis · · Score: 2, Informative
    7. Re:Establishing de facto (open source) standard ? by Dzonatas · · Score: 3, Insightful

      >The Microsoft stuff in the summary is just trolling

      That is true because MS actually voted for more security of an individual's IP rights than what ECMAScript 4.0 offered. One problem for example, under ES4, is that containers of code may also contain code that is owned by someone that never gave permission to distribute code. ES3.1 is not a solution, but it achieves that some desired advancements without a greater lack of security in a trade-off.

    8. Re:Establishing de facto (open source) standard ? by mabhatter654 · · Score: 1

      isn't that how .dlls have worked for years. Pretty much any dll can call any other one. Isn't that the basis of how things like scrip-o-licous and prototype work, allowing your pages to bind into the common javascript. Javascript is a DOCUMENT scripting language, not designed to keep the user or user agent from knowing or reusing the code.

      Microsoft and Adobe are not being genuine here... the only way to implement what they want is in complied languages... like .net or Flash... gee imagine that.

    9. Re:Establishing de facto (open source) standard ? by Dzonatas · · Score: 1

      Microsoft does realize that only pure compilations are safer, but their take on the situation apropos to this topic was to invent a new language entirely and not either 3.1 or 4.0. What happened is that 4.0 become a buzzword under Web2.0 technology, and so 4.0 was design based on Web2.0 and semantics that are getting quickly outdated. In that regard, it is not like dlls.

    10. Re:Establishing de facto (open source) standard ? by andy9701 · · Score: 2, Interesting

      I haven't looked into SproutCore much, but isn't it just a framework built around JavaScript? If that's the case, how does that solve the multimedia part of the GP's request?

    11. Re:Establishing de facto (open source) standard ? by Kent+Recal · · Score: 1

      What does the zillionth javascript framework have to do with his (legitimate) request?

      Besides sproutcore looks less than impressive, even by javascript metrics. It took ages to load, yet the few available widgets feel sluggish under linux. Oh and ofcourse the layout blows up when changing font-size...

    12. Re:Establishing de facto (open source) standard ? by seanonymous · · Score: 1

      Yes, sproutcore, because mobileMe is such a success.

      Sproutcore is yet another javaScript framework.

    13. Re:Establishing de facto (open source) standard ? by Anonymous Coward · · Score: 0

      call me a nazi, but just a correction: script.aculo.us

    14. Re:Establishing de facto (open source) standard ? by love_encounter_flow · · Score: 1

      i absolutely second the sentiment that what is needed is a sort of CLR (common langugae runtime) / parrot / bytecode machine implementation, on top of which languages can be implemented. that clr could be expressed in some sort of "high level assembler", on top of which language implementors can pour their syntactic icing that essentially makes bytecode accessible and readable. one could even envision some sort of "universally accepted plugins"---code that is identified by a URL, verified by secure digests, and written either in the clr or some platform-specific code according to use. popular plugins could provide services such as displaying certain image formats, playing sounds, or represent widgets, and the user wouldn't have to download them anew for each website (as is already posssible when site A references http://x/foo.png, then when site B references the same image, it may be retrieved from cache). levels of trust could be community-derived and user-configurable, so that some things that have attained a high score in terms of tested use would just load without acknowledgement, while code without that trust level would need explicit consent.

    15. Re:Establishing de facto (open source) standard ? by Anonymous Coward · · Score: 0

      Of course it is (trolling). My first thought when I read it, was that a more accurate description would have been that if this proposal had made it, it would have been the result of Adobe's interests.

      I've always had a feeling that Adobe's DNA contains more predator segments than Microsoft's.

      MS got a tremendous jump start when IBM (with its reputation in the business world) picked them to provide the OS for the PC, and a second shove when IBM said PC clones couldn't use IBM's PC-DOS, forcing everyone who wanted to be compatible directly into MS's hands. If that hadn't happened, Gates & Co might still be selling BASIC interpreters as their principal product today.

      Adobe never had such luck, they had to fight their way up all by themselves.

    16. Re:Establishing de facto (open source) standard ? by try_anything · · Score: 2, Insightful

      I think their primary roles would have been for basic libraries, for generated code such as SOAP bindings, and other code that ordinary web-developers would not write. They would work quite well for that and allow better robustness and possibly better performance (less dynamism -> more JIT compiler optimizations) for core functionality like parsing XML and drawing graphics.

      The only way I can imagine that those features are "unsound for the Web" is that ordinary web developers would not bother to understand and use them.

      Unfortunately, many of the people who write Javascript these days stubbornly identify themselves as non-programmers. They resist learning anything that smacks of a "real" programming language. There could have been an ugly struggle between people trying to force these features on web developers and web developers clinging to Javascript's current free-form dynamism. On the face of it, it might seem that web developers are just lazy to avoid learning a few new language features. It also sounds quite silly for them to say, "I'm a programming idiot; I can't write code," despite slinging around complicated DHTML, CSS, and Javascript. They're obviously intellectually capable of learning and using a "real" programming language for "real" programming.

      I think their basic point is sound, though. The job of writing the Javascript for web pages often falls to the web designers, and they should be allowed to program in a simple and dynamic language that suits their artistic temperaments and lets them focus their minds on their creative specialties. They do have artistic design responsibilities that programmers do not, after all, so it doesn't make sense for them to invest as much time in learning about programming as programmers do.

    17. Re:Establishing de facto (open source) standard ? by TheRaven64 · · Score: 1

      less dynamism -> more JIT compiler optimizations

      Not entirely true. Less dynamism means more static compiler optimisations. It can lead to more JIT optimisations, although those optimisations are often a lot more complicated. (And, yes, I do do research in dynamic language optimisation).

      --
      I am TheRaven on Soylent News
    18. Re:Establishing de facto (open source) standard ? by dn15 · · Score: 1

      Yes, sproutcore, because mobileMe is such a success.

      While there were issues accessing the web interface I think those were the result of back-end problems or server overload. I don't believe the problems they experienced initially were actually inherent to the sproutcore-based webapps.

    19. Re:Establishing de facto (open source) standard ? by Bill,+Shooter+of+Bul · · Score: 1

      I understand your desires, for mine are the same. I think 90% of it would be solved if their was greater native browser support for SVG & SMIL.

      --
      Well.. maybe. Or Maybe not. But Definitely not sort of.
    20. Re:Establishing de facto (open source) standard ? by ropak · · Score: 1

      OpenLaszlo would be much better example since you can 'export' to dhtml or flash if you want. That's theory but... sounds nice.

    21. Re:Establishing de facto (open source) standard ? by Lerc · · Score: 2, Interesting

      I have an idea. I'm working on it.

      My initial idea I laid out here

      Since writing that I became aware of quite a few things also exploring this area. I'm currently putting together a proof-of-concept plugin using vx32.

      It should be possible to make something speedily executable on non-x86 with just a few restrictions and a bit of instruction-metadata.

      Importantly. The spec is much simpler than any existing VM model so an open spec with multiple implementation methods should be quite feasible.

      --
      -- That which does not kill us has made its last mistake.
    22. Re:Establishing de facto (open source) standard ? by Anonymous Coward · · Score: 1, Insightful

      I have to disagree; the summary isn't trolling. Looking behind the scenes it appears that Microsoft wanted to kill it so it wouldn't compete with Silverlight. (Notice how one of the things they said wouldn't be included 3.1 that was included in 4 was namespaces and packages. It was claimed that they weren't good for the web, but oddly they appear in Silverlight.)

      Also, as far as Mozilla and Google being on board-this seems mostly due to the fact that Microsoft almost unilaterally killed 4 claiming they would never support it.

      I'm disappointed. If you've played with AS3(based on an earlier draft of the ES4 spec) it allowed you to code in a more classical OOP fashion, but you still had access to dynamic language features that people love about JavaScript.

      At this point, many, many people have attempted to graft a more traditional OOP framework on to JS(going so far as to abstract the prototype inheritance that exists with JS)-none of them have been completely satisfactory (which is why more keep coming out). The latest one of note was John Resig's which was somewhat decent.

      I am tired of people saying "You can do anything with JS". While JS's dynamic nature makes the simulation of a wide variety of language features possible, it would be far better if some of these were standardized into the language itself instead of having everyone invent hacks for things that would be available in almost any other language. This does not lead to increased productivity or efficiency.

    23. Re:Establishing de facto (open source) standard ? by try_anything · · Score: 1

      I'm tempted to disagree with you, but given your qualifications (and my lack thereof) perhaps I'd better phrase it as a question. If we're just talking about a browser language for the next five to ten years, won't static code be much faster than dynamic code for most if not all of that time? It took Sun years to make Java fast, and it seems like optimizing Javascript would require much more sophisticated techniques that would take even longer to reach users. I'd be very happy to hear I'm wrong, though, because it would make this news much less depressing.

    24. Re:Establishing de facto (open source) standard ? by aliquis · · Score: 1

      I don't see anything about multimedia? I don't know what needs he/she had but I guess animated SVG and video directly in the browser solves some issues.

      Personally I hate flash and kind of all flash apps so..
      As long as no one listen to Adobe I'm quite happy, very obvious that they want it as standard since I guess it's what flash uses, but then people would probably make more flash apps which require their plugin bullshit and well, no thanks.

      Build on top of something open and make it work everywhere without being to heavy on the computer and I'll accept it.

    25. Re:Establishing de facto (open source) standard ? by knorthern+knight · · Score: 2, Informative

      > My opinion: I need a modern virtual machine ==> Java ... check

      > with capabilities comparable with Flash/Silverlight applets ==> Java ... check

      > and level of integration comparable with javascript engines shipped with browsers. ==> Java ... check

      > Compatible across browsers. ==> Java ... check

      > maybe with some kind of intermediate representation (bytecode?). ==> Java ... check

      > Capable to run bigger, non-trivial apps. ==> Java ... check

      > Open sourced and not patent encumbered. ==> Java ... check

      > Currently there is nothing satisfying my wishes.
      Errrr uhmmm, ever heard of Java?

      --

      I'm not repeating myself
      I'm an X window user; I'm an ex-Windows user
    26. Re:Establishing de facto (open source) standard ? by the+entropy · · Score: 1

      > and level of integration comparable with javascript engines shipped with browsers. ==> Java ... check

      how so?

    27. Re:Establishing de facto (open source) standard ? by chrysalis · · Score: 1

      Errrr uhmmm, ever heard of Java?

      Have you ever heard about Haxe ?

      --
      {{.sig}}
    28. Re:Establishing de facto (open source) standard ? by Anonymous Coward · · Score: 0

      Javascript is already a "sort of CLR", one with several implementations. We concatenate and compress javascript for deployment, there's no advantage to sending bytecode over the wire -- that's an implementation detail (spidermonkey/tamarin do use bytecode). Additionally it should be possible to target javascript as an intermediate representation from any scripting language (see haxe etc). Caching of frameworks and off line apps are already being worked on, see noscript and SSP for ideas about security.

      The browser platform is well capable of delivering what GP wants. Sure I'd like to see work on improving DOM performance and adding some variety of coroutines to the javascript spec but these will come in time when the current work on javascript VM's is done and browsers supporting more SVG, canvas(3D) and audio/video elements are commonplace.

    29. Re:Establishing de facto (open source) standard ? by TheRaven64 · · Score: 1
      Self was a highly dynamic language - the object model is almost identical to JavaScript but it also had no static flow-control primitives (as with Smalltalk, all flow control was handled by passing messages with closures as arguments). In the late '90s, Self was running at about the same speed Java is now. Sun hired most of the Self team to work on the JVM.

      The current approach in the Sun JVM actually discards a lot of the static information and uses techniques like type inference to get it back. One thing the Strongtalk team discovered was that run-time type inference gives more accurate results than user-specified type tagging.

      There are a few things that make JavaScript slow. One is the fact that all arithmetic is double precision floating point (a VM can use integer operations, but it has to promote the results to doubles on overflow or on division which results in a remainder. Doing this causes a lot of branches (slow). The other thing is that numbers are objects, so every slot lookup needs a special case to check for this (or you need to waste some memory boxing every number.

      I've recently been working on a Smalltalk compiler which uses an Objective-C runtime library to provide the object model (with the nice side-effect that you can subclass or extend Objective-C objects in Smalltalk and have no overhead from switching between the two languages). Smalltalk has a similar situation with numbers - you have unboxed SmallInts (where the number is stored in the pointer) and everything else is boxed.

      The thing that makes something like Java slower than something like C++ is that C++ resolves the destination of method calls at load time (which is why C++ applications take so very long to start), while Java does it at the time of the call. For short-lived scripts, it might actually be better (in terms of user-perceived speed) not to have the initial delay. There are techniques for improving performance of this, such as polymorphic inline caching (another thing from the Self team). I implemented this in a new Objective-C runtime library designed to be able to support JavaScript and Io as well as ObjC and Smalltalk, and in some little benchmarks got Objective-C messages sends a fraction faster than C++ method calls (still about half the speed of C function calls, but you can combine it with speculative inlining safely now, which means you can inline what C++ calls virtual methods, which you can't in C++ without a fairly radical redesign of the ABI).

      --
      I am TheRaven on Soylent News
    30. Re:Establishing de facto (open source) standard ? by zby · · Score: 1

      Maybe Parrot would fit your wishes? Once it is finished.

    31. Re:Establishing de facto (open source) standard ? by seanonymous · · Score: 1

      There are a great deal of bugs remaining in mobileMe's web interface.

      For instance:
      Open mail in a Safari window, then open mail in another Safari window. When you switch back to the first window, you'll get an error message: The requested action cannot be completed because this folder has been moved or deleted

      Now open iWeb, upload a website to mobileMe, then try to delete it with the web interface. You can't. But notice how, even though the delete button is ghosted out, you can use the keyboard shortcut to access the delete dialog - which doesn't work.

      I have a lot more of these, should I keep going?

      These may not be the fault of the framework, but it doesn't do it any favors.

      Anyway, offering a JavaScript framework as a suggestion for a replacement for JavaScript kinda misses the point.

    32. Re:Establishing de facto (open source) standard ? by dn15 · · Score: 1

      Interesting, thanks for the info. I have a MobileMe account though I rarely use the web interface. I was unaware of these issues.

  7. I'm skeptical by joe+155 · · Score: 2, Funny

    Brendan Eich may claim it to be dead, but I'd really rather wait for Netcraft to confirm it before actually basing any decisions on this news...

    --
    *''I can't believe it's not a hyperlink.''
  8. Scariest Part of the Article by Anonymous Coward · · Score: 0

    What scares me most from reading that article was this part: "In fact The Adobe CEO has stated they are moving their entire application suite in the next 10 years to the Flash platform, so this language spec is serious stuff."

    Our computers are getting faster but we're getting more power hungry applications that don't do much more than what came before. This goes agaisnt the current popularity of small and cheap laptops.

  9. Crockford and Standards by kevin_conaway · · Score: 5, Informative

    I invite everyone to read Douglas Crockford's latest post on the YUI blog entitled: The Only Thing We Have To Fear Is Premature Standardization

    He gives some insight into how ES4 got to where it is today and its impact on standards in general

    1. Re:Crockford and Standards by lysse · · Score: 1, Insightful

      This was the sentence of Crockford's post that really leapt out at me:

      It went off the rails when people started to just make new stuff up.

      That's generally true of standards committees. When they're documenting existing practices and seeking consensus and convergence between them, they're in their element. When they decide they can start inventing, rather than consolidating, they lose the plot altogether...

    2. Re:Crockford and Standards by omfgnosis · · Score: 3, Informative

      That line was about HTML5, which is absolutely ridiculous. The things that the WHATWG and W3C have added to the HTML5 proposal are one or both of the following:
      - formalized semantics already informally in use as classes and ids (like the section and nav tags);
      - behaviors already in use, drastically simplified (like Web Forms 2.0).

      They didn't really "just make new stuff up", they're making the language and environment much more powerful, with real world use in mind. Both types of feature additions make developers' lives easier, behaviors more predictable, and creative and expected uses of HTML beyond simply parsing and displaying more possible. The HTML5 effort is downright fascinating in the amount of good in it.

    3. Re:Crockford and Standards by lysse · · Score: 1, Insightful

      That line was about HTML 5

      If you disagree with Crockford's opinions, the appropriate person to argue with is Crockford. I pulled out a quote to make a general point, one with which Crockford might not even agree, yet you don't seem to be too interested in talking to me.

      Rest assured, the feeling is mutual.

    4. Re:Crockford and Standards by omfgnosis · · Score: 1

      LOL if you don't want to discuss it with me, that's your prerogative, but I was bringing up the context of what you were quoting to make a point about it in specific as relative to your post. If you don't want people to discuss something with you, then probably the best course of action is to not post on public message boards about it.

    5. Re:Crockford and Standards by lysse · · Score: 1

      Yeah, but you weren't discussing anything with me. I could tell that by the lack of reference to the point I was making. You were beating me over the head with your disagreement with Douglas Crockford's assessment of the HTML 5 committee. I'm not interested, sorry.

      Besides, what on earth makes you think I do not see you as a specific individual? I only said I didn't want you to discuss something with me. Have more self-esteem. Believe that you stand out from the crowd. Free your inner snowflake!

    6. Re:Crockford and Standards by omfgnosis · · Score: 1

      "Yeah, but you weren't discussing anything with me."

      Sure I was, I was discussing the context that you took your quote out of. If it wasn't you, who posted it?

      "I could tell that by the lack of reference to the point I was making."

      "That line" was a reference to the line you quoted.

      "You were beating me over the head"

      Sorry if it came across that way, it wasn't intended.

      "with your disagreement with Douglas Crockford's assessment of the HTML 5 committee."

      I was responding to your expressed agreement with him.

      "I'm not interested, sorry."

      I don't care if you're interested. If you don't want me to reply to you, post somewhere private.

      "Besides, what on earth makes you think I do not see you as a specific individual? I only said I didn't want you to discuss something with me. Have more self-esteem. Believe that you stand out from the crowd. Free your inner snowflake!"

      So don't post somewhere I can respond to you.

    7. Re:Crockford and Standards by lysse · · Score: 1

      Yeah, 'cause you clearly are incapable of stepping back from the keyboard yourself.

      Anyway, it now becomes clear that somewhere along the line you misunderstood me, as you demonstrate here:

      I was responding to your expressed agreement with him.

      I expressed no such agreement, save that I thought a particular comment he made about a specific circumstance - whether he was right or wrong to apply it to that circumstance - was generally applicable.

      Do you want to have the last word now?

    8. Re:Crockford and Standards by omfgnosis · · Score: 1

      "Yeah, 'cause you clearly are incapable of stepping back from the keyboard yourself."

      I'm not the one posting to somewhere that allows anyone and everyone to reply then demanding someone stop replying. If you don't want my reply, stop inviting it. You drop it, I'll drop it.

      "I expressed no such agreement"

      You said: "That's generally true of standards committees."

      Shrug.

      "Do you want to have the last word now?"

      I don't care. If you bore me enough I'll lose interest, but if I'm interested I'll respond.

    9. Re:Crockford and Standards by Raenex · · Score: 1

      Please allow me to mediate as a third party: You're being a whiny bitch. If you're going to point to an article as a shiny example everybody should look at, then certainly the surrounding context is fair game for discussion.

    10. Re:Crockford and Standards by lysse · · Score: 1

      I didn't point to the article. The person I first replied to did that. I just read it, and saw a line I agreed with generally, without much thought to its specific context.

      If you're going to try to force your way into a mediatory position, it does help an awful lot to make sure you get your facts straight first.

      (But then, the whole point of mediation is not taking sides, so it's good to see you drank the whole cup of fail this morning.)

    11. Re:Crockford and Standards by Raenex · · Score: 1

      I didn't point to the article. The person I first replied to did that. I just read it, and saw a line I agreed with generally, without much thought to its specific context.

      It's a minor technicality. The fact is you're still being extremely oversensitive because somebody replied with context about a particular line you found insightful. It's a discussion on a public forum. It wasn't a personal attack on you -- get over it.

    12. Re:Crockford and Standards by DanJ_UK · · Score: 1

      Lightning bolt! Lightning bolt!

      --
      - Dan
  10. ECMAscript 4.0 is dead by Daimanta · · Score: 1

    Long live ECMAscript 5.0!

    --
    Knowledge is power. Knowledge shared is power lost.
    1. Re:ECMAscript 4.0 is dead by Anonymous Coward · · Score: 0

      .... NetCraft Confirms it!

  11. Re:Can I just point out by kevin_conaway · · Score: 4, Interesting

    [Can I just point out] That Javascript as a development platform, as it seems to have become, is evil. It's just horrible from an efficiency, performance, security and architectural point of view. It seems to be the future.

    You can point that out, but you'd be wrong. JavaScript hasn't recently "become" anything. The last major revision that all browsers supported was in November 2000.

    It is a beautiful, expressive and quite powerful language that is just now starting to shine after years of being misunderstood by people like you.

  12. What a damn shame by Stan+Vassilev · · Score: 3, Insightful

    Such a damn shame to let ECMAScript edition 4 go in this way.

    The small shame is for Adobe's efforts, who entered the ECMA standards body to contribute, donated the entire engine to Mozilla and plenty of other efforts to get this going. But AS3/Flash will not be affected in a big way from this.

    The web community as a whole will be. That's where the big shame is: for all of us, web developers. I see that packages, namespaces, classes and early binding are out, likely forever.

    Classes are not "sugar", we do need those paradigms when creating bigger applications, because they are more rigid, more readable, more maintainable, understandable. I love lambdas, prototypes and all that, but that's the lower level, the implementation inside a class, inside a package. Those are not interchangable paradigms.

    ES4 and AS3 have managed to add those higher constructs to the language, while maintaining full compatibility with all flexible features of ES3 (the JavaScript currently used in browsers).

    The reasoning behind dropping all constructs appears to be the preconceived notion that JavaScript must exist in the form of disparate text files loosely connected to each other, something that doesn't scale to bigger efforts at all (and which makes Flash much more viable for such deployment), hence packages and early binding are out. What a mistake.

    Who's to say we won't see JAR-like environment where bigger libraries can be compressed together, and some preprocessing can be done to ease the load on the client CPU/bandwidth? I've been praying we get such deployment option soon as a modern web application typically has to download a ton of CSS/JS/image files to build an average GUI nowadays. Why isn't this the focus of ECMA's efforts, but instead the focus is to maintain the status quo and reject us basics that have proven themselves in time to work well in all environments out there.

    If you doubt this would work, look no further than Java/Flash applets distributed over the web in this fashion (and Flash is very widely used nowadays).

    What ECMA has achieved with their decision, is to basically stagnate the browser environment, and empower third-party cross-browser plugins to eat more from the advanced web application market share, because Adobe's Flash, Microsoft's Silverlight are not even thinking of dropping their mature OOP features, just because ECMA said we don't need them.

    1. Re:What a damn shame by DCstewieG · · Score: 2, Informative

      With a good build/deployment script you can combine all of your CSS and JS files together, giving the advantage of better compression and less HTTP requests. If you have it set up in that way, you can split your script into as many files as you want.

      Images are a bit different, you can't do much outside of spriting where you can.

      This is not to say a JAR equivalent wouldn't be preferred, just that there are things you can do today.

    2. Re:What a damn shame by Anonymous Coward · · Score: 1, Informative

      >modern web application typically has to download a ton of CSS/JS/image files

      This is trivial to fix for JS/CSS, either via runtime tool or build system. It takes about 10 minutes to add a servlet to combine and compress JS/CSS files in Java via the JAWR library, for example.

    3. Re:What a damn shame by Anonymous Coward · · Score: 1, Informative

      Classes are not "sugar", we do need those paradigms when creating bigger applications, because they are more rigid, more readable, more maintainable, understandable. I love lambdas, prototypes and all that, but that's the lower level, the implementation inside a class

      Um, that's exactly what "sugar" means: a more readable syntax that hides the implementation details.

      Harmony will have classes -- they will merely be implemented as syntactic sugar on top of lambdas and prototypes, instead of being new constructs altogether. This change is irrelevant from the point of view of anyone other than a language implementor.

    4. Re:What a damn shame by Maian · · Score: 3, Informative

      Seriously, RTFA.

      This thread's title is totally misleading. In fact, the summary is wrong. ES Harmony is NOT ES3.1. And of course, there's the anti-MS slant as usual, but no mention of Yahoo, which was also against ES4. Good ol' /.

      So just in case you're too lazy to read the article, here's a quick summary:

      ES Harmony is just an ES4 that the ES 3.1 guys agreed to work on after ES3.1 is out the door, while the ES4 guys agreed to work together with the ES3.1 guys on ES3.1. So ES Harmony (which could be ES4 or ES5, depending on what they call ES3.1) will still have classes. They will still have integrity. However, there won't be any early binding, since they now just "desugar to lambda-coding + Object.freeze and friends from ES3.1."

      Also, your complaints about web development packaging is out of the scope of ES. It's a browser/HTML issue. Every scripting and styling language on the web suffers the same problem.

    5. Re:What a damn shame by foniksonik · · Score: 1

      You could actually incorporate a sprite building tool into a build/deployment script.

      That would be a very nice addition to any JS UI toolkit.

      It would take all the images (assuming they are of the same type...PNG gets my vote) and put them into a large image sprite... while adjusting all CSS and JS to use the new image.

      Not an easy task i think... but interesting from an optimization POV anyways.

      --
      A fool throws a stone into a well and a thousand sages can not remove it.
    6. Re:What a damn shame by drew · · Score: 1

      I've played around a bit with AS3, and what I've found so far are a lot more annoyances than any useful additions. More importantly, it is not compatible with JS 1.5. In my experience so far, classes are only really "necessary" in so far as people whose first experience with OOP was C++/Java/C# don't seem to be willing to learn anything else. I've worked on many large projects written in JavaScript, and while there are a lot of annoyances that appear in JavaScript in large applications, all of them are easily solvable while still working inside the Prototype structure. Many of them can be worked around now, although in many cases the workarounds shouldn't be necessary. These are the sort of things that I think they should be looking at in a new version of JavaScript. Let's fix the minor annoyances rather than throwing the baby out with the bathwater.

      Private Variables - I know Crockford insists that you can do private variables in JavaScript using closures, but his method doesn't work cleanly with the prototype model of inheritance. Given the choice between private variables and inheritance, I'll choose inheritance every time.

      Namespaces - The current commonly accepted practice of using objects in place namespaces works fine for declaring a namespace, but we need a better way to "import" namespaces than just assigning them to a global variable, a la: "window.foo = myNs.myApp.foo;"

      Accessing "super" methods - In theory, this should be easy to do, but the prototype system as currently implemented has some rather arbitrary built in limitations when accessing the prototype chain that makes this much more awkward than it should be.

      No access to prototypes of built in objects - Why can't I make a new object that inherits from Array? or DomDocument? This one is particularly irritating because there is no good workaround, and while it's not a common problem to run into, when you do need it, you really need it.

      Those are the major annoyances I've dealt with off the top of my head. Recently I've been spending much more time on server side work than client side, so maybe I've forgotten some. Really, though, JavaScript, whether by design or by accident, has a pretty solid base as an OOP language, and I would rather see efforts on cleaning up what's already there than trying adding a whole list of new irritations and inconsistencies to the language, just because "That's how Flash does it."

      As far as a JAR-like deployment, that's easy to do now. There are plenty of JavaScript preprocessors out there that will suck in all your JS source files, and spit out a combined file with extraneous white space and comments removed. GZip compression can be handled transparently by the web server for most browsers. It's an extra step in the deployment process, but then, so is JAR. And depending on your server side environment, you may be able to make it all happen transparently (I've done so with .NET without too much difficulty.) The only real downside is that you can't meaningfully combine JavaScript and CSS, and it doesn't work for images. There are other techniques that you can use to combine images as well, but that's getting into another topic...

      --
      If I don't put anything here, will anyone recognize me anymore?
  13. Re:Can I just point out by Metasquares · · Score: 1

    It's a nice language overall, but OOP in Javascript is a real pain in the neck. I wouldn't mind a more traditional class structure.

  14. for those of you who complain, by circletimessquare · · Score: 0

    as i do, about all the different dhtml and javascript implementations across different browsers, be very scared

    here is a vision of the future where different browsers use different script languages

    its as if internet explorer never decided to support javascript in the mid1990s but still gained massive market share, forcing us in the industry to code for sites in javascript and vbscript

    (shudder)

    --
    intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
    1. Re:for those of you who complain, by Locutus · · Score: 1

      and this should not surprise anyone. Cross platform technologies are a threat to Windows and since over 80% of Microsofts profits come from Windows, cross platform technologies are a threat to them. So don't wonder why Microsoft keeps pushing stuff which only works on Windows or pushes for things which slow down adaption for open standards.

      LoB

      --
      "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
  15. A real pity by shutdown+-p+now · · Score: 4, Insightful
    ES4, as proposed, was destined to become a truly beautiful language, applicable for far more than its present Web scripting role. It was something I was actually looking forward to. And now - they've essentially codified the status of ES as the "Web scripting language", and discarded all the "too hard" stuff from the spec because it didn't fit the role. Which is quite surprising, since, given the popularity of GWT, one would think that ES3 implementations do lack something that people want.

    Oh well; Microsoft scores one here, considering that Silverlight 2.0 will be scriptable using Python and Ruby out of the box.

    By the way, the whole fuss about MS being behind this is pretty stupid and unfounded. MS was actually one to jump on the ES4 bandwagon early, along with Adobe - their early implementation of it was called JScript.NET, first released in 2002 with .NET Framework 1.0, and it does in fact still ship with all versions of .NET, and is an officially supported .NET language. They certainly wouldn't have any trouble extending it to the more recent spec, should it become standard. Now, I guess it will just be quietly dropped in the next version of the framework.

    1. Re:A real pity by Tacvek · · Score: 1

      I agree that packages are not generally useful for the web, but why not keep it as a language feature. Mandate that a parser accept it, but perhaps only mandate that core packages be supported, and that an implementation does not need to provide a means to add additional packages.

      I really don't understand the AS 3.0's "namespace" feature. That looks like access specifiers to me.

      The packages feature sounds more like C++'s namespaces to me. (Although C++ classes are also (effectively) namespaces, to the point that static members of a class look a lot like just items in the namespace of the class [except for the access specifier implications]).

      But the literature makes it sound like the AS 3 namespaces are more than just access specifiers, so I'm not sure what they really are.

      Early binding may not be appropriate for the web, so I have no real idea how that should be handled. Making it completely an option would make porting code between AS 3 implementations potentially much harder than they should be.

      I hope taht instead of killing the ES4 but just basically pause it, to return to it once they have released a 3.1 as a stop-gap measure.

      I just fear that they implement some ES4 style features in 3.1 in a way that is not compatible with ES4.

      --
      Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
    2. Re:A real pity by Anonymous Coward · · Score: 1, Interesting

      ES4, as proposed, was destined to become a truly beautiful language, applicable for far more than its present Web scripting role.

      Barf. What we need is a trim lightweight browser scripting language. You want to write an desktop app, write a bleeding desktop app; don't bloat up javascript.

    3. Re:A real pity by shutdown+-p+now · · Score: 2, Informative

      Barf. What we need is a trim lightweight browser scripting language. You want to write an desktop app, write a bleeding desktop app; don't bloat up javascript.

      JS was never "lightweight" in any sense of the word - neither in terms of language features, nor it terms of performance of typical implementations. If you want a truly lightweight scripting language, designed as such, see Lua.

  16. it's the libraries and frameworks by speedtux · · Score: 2, Insightful

    Any ideas ?

    The problem with Java and the CLR in browsers are mostly with the libraries, not the virtual machines. So, I think the thing to do would be to start with, say, the CLR and develop an open applet environment and browser integration based on it. This environment could even be emulated in Silverlight, allowing things to run without any install on Windows.

    1. Re:it's the libraries and frameworks by Tim+C · · Score: 2, Interesting

      This environment could even be emulated in Silverlight, allowing things to run without any install on Windows.

      Doesn't the CLR (as part of the .Net Framework) ship with Windows as of Vista?

    2. Re:it's the libraries and frameworks by Anonymous Coward · · Score: 0

      Do we get threading?

  17. Why is JavaScript is so popular? Lamda Functions by Anik315 · · Score: 1

    Although JavaScript is not very good as an application language, it can do some really neat things which makes it very interesting to language nerds which is why it is so popular.

    One thing is that functions are also objects which means they can be returned and taken as parameters by other functions. This is called lambda coding. Function pointers do not allow you do to quite the same thing since they can't be dynamically generated and modified. It makes certain kinds of mathematical programming very easy. For instance functions can be dynamically defined to return the derivative function of another function.

    Not many languages allow you to do this. Ruby, Python and Perl, JavaScript and ActionScript all allow lambda coding, but Java, C and C++ don't probably for performance reasons since the runtime environment of the compiled program itself requires a compiler. The latest edition of C Sharp I think does though.

    In any case, since JavaScript allows this it would nice just have a compiled version of JavaScript with lambda coding and classes. I think that's what they are shooting for with Harmony so I'm not really that disappointed with this decision.

  18. Re:Can I just point out by fimbulvetr · · Score: 4, Interesting

    OOP !== Class based OOP

    JS isn't a class based OOP language, it's prototype based OOP language - the two are _very_ different. I can understand why it's a pain in the neck. It's also a pain in the neck to force a square peg into a round hole, but is the blame on the person who made the square peg or on the person whom thinks that the square peg should indeed be able to be put in the round hole?

  19. Re:Can I just point out by Z00L00K · · Score: 1

    I agree that JavaScript/ECMAScript is horrible, but it's what we have.

    At least it's not as horrible as VBScript.

    But I sure would like to have had a language with strong static typing, which in effect would have made it very similar to Java. By doing this we would have had at least some bugs straightened out before deploying to a large number of users.

    The inconsistency between browsers is also a catch, but it could have been a lot worse.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  20. Re:Why is JavaScript is so popular? Lamda Function by Z00L00K · · Score: 2, Interesting

    JavaScript is popular only because it exists in almost every browser since a long time ago. This means that if you code something for a browser in JavaScript you know that it has a reasonable chance to work for the most commonly used browsers.

    The use of JavaScript outside the environment of browsers is very limited, and exists only in specialized applications where it may be useful to have a script language. But then it competes with other script languages like TCL/Tk.

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  21. Re:Can I just point out by Locutus · · Score: 1, Troll

    exactly what Microsoft is doing its best work to cause. Javascript and all the tech in AJAX which allows application-like browser-neutral pages is a massive threat to Microsoft's income.

    I don't know what Microsoft had to do with this but their position on any industry committee is purely to find ways to either stall the project or make sure they have ways to dilute it on Windows. They have no other reason or purpose. IMO.

    LoB

    --
    "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
  22. Ha ha! by Jane+Q.+Public · · Score: 0

    It is an ugly, gutteral, non-expressive, but quite powerful language.

    If you want a beautiful language you would get a lot closer with Ruby. JavaScript is many things, but beautiful or easy to use it ain't.

  23. Re:Can I just point out by Colin+Smith · · Score: 1

    Perhaps you'd like to read my post again.

     

    --
    Deleted
  24. Just another example by Jane+Q.+Public · · Score: 1

    ... of how Microsoft seems to prefer to win through destruction of others rather than production of their own.

    Not that we need another example. How many have we had already? Does anybody doubt?

  25. Re:get some language experts by rycamor · · Score: 1

    Yes, what suckage. Who on earth wants a simple, dynamic, low-cruft language with first-class functions, closures, lambdas and a prototype object system that still manages to look like the C language family? Evil, evil, evil...

    Note: I don't consider myself enough of a language expert to judge your first assertion, but your second assertion makes me strongly suspect the first. That you would claim Brendan Eich has no business being associated with language design doesn't exactly help your case.

  26. Re:Why is JavaScript is so popular? Lamda Function by rycamor · · Score: 2, Insightful

    In my case, I really didn't START to like Javascript until I began to read up on it's functional capabilities.

    I think there is more to Javascript's popularity than what you say. It is actually a fairly nice little language, and hopefully when a few annoyances are cleaned up in version 2.0 it will be used outside the browser more and more. In fact, anyone who has done some serious Mozilla application programming with XUL realizes that there is no reason Javascript must be restrained to a web browser context to be useful.

  27. Re:Can I just point out by Anonymous Coward · · Score: 0

    It is far from expressive. It's full of php-esque issues, such as no namespaces, and a very poor OOP system. Misunderstood, yes. As something it's not, yes. A good solution? No.

  28. JavaFx by thetoadwarrior · · Score: 1

    I'm waiting for Javafx. It looks pretty interesting to be honest.

  29. Re:get some language experts by TheRaven64 · · Score: 1

    Who on earth wants a simple, dynamic, low-cruft language with first-class functions, closures, lambdas and a prototype object system

    Hardly anyone, it seems. Otherwise, how do you account for the popularity of C++?

    --
    I am TheRaven on Soylent News
  30. Oh sweet jesus! by FlyingGuy · · Score: 0, Troll

    Java Script is a really bad joke. Not that there is anything better at hand, but it is utterly and completely in drastic need a of "Lift up the radiator cap, and drive a new one underneath it treatment" and damn soon.

    Right along next to it, is the Document Object Model, yet another thing needing the same treatment,

    .

    And right along with those two is CSS, a good idea gone horribly wrong.

    So what do we do? How do we fix this, how do we build something that everyone can agree on? The short answer is, more then likely we cannot. Why? Because there are to many ego's involved, to many pet languages involved, to many pet methods and styles.

    But with a lot of "We are going to ram this right up your ass, everyones ass, because it will be so clean and functional you won't have a choice but to bend over and take it." attitude AND aptitude we can succeed.

    The idea of DOM is great, because it creates a known method of manipulating the bits and parts of an web page to effect the best possible user experience, but the loosely coupled nature of JS, DOM and CSS just keep making the whole thing just become to overwrought with complexity and errors.

    The way to fix this is IMNSHO is to rebuild it into one entity.

    Wait for it......Ohhh the horor!!!!!. No kids it is not a horror, it is supremely logical. The very notion that you treat a web page as if it was a bit of paper is ludicrous! It is not a peace of paper, it is a digital screen capable of all sorts of neat tricks, and the engine that drives it is superb. The notion of paper needs to be simply left behind, move on, it was a hell of a go, but it is time to grown up, but into what?

    The web browser needs to transform into a sand-boxed window manager. How is that again? A window manger, huh? The idea sits in front of ALL of you every day. The GUI desktop moves things around, arranges windows, covers them up allows them to be moved, adjusts for sizing, everything we desperately try to implement in CSS and DOM but pretty fail to do.

    How do we accomplish this? Well not without a lot of yelling and screaming. But consider this, if you had the same level of control over your your web page presentation as you have over any GUI application, how happy would you be? Personally I would be ecstatic! I mean Wooooo-Whooooooo! Just think of the level of control you would have, you could build perfectly interactive web pages that would vow to your and more importantly, your audiences every whim.

    As a set of verbs and nouns JS is not that bad. I would tweak it a little a little but not much. What I would do though, is make DOM ( or an equivalent name ) be derived from JS instead of having JS simply be able to connect to it, for example, a web page would begin with a call to JS ( or the equivalent name ) MyPage = NewDocument(...) and that would pop open the new page, fresh and clean. After that you start laying out the sections, eg: UpperLeft = MyPage.CreateArea(...) rinse and repeat until you have all your areas defined. At that point, you begin to fill in all the areas by making calls to UpperLeft for things like control's, backgrounds, colors, scrolling text area's and the like. At that point you could then have a successor to CSS be a value passed to UpperLeft that would then style it as you desire.

    This would eliminate some of the biggest problems with CSS, ie: the box model and DIVS freeing you up to really concentrate on the content. In addition there would be a menu model in there. Trying to do menus in CSS is at best a dark art and at worst damn near impossible, depending on what you want to do. How about something like TopMenu = MyPage.New.H[V]menu which could then be fed a very small XML hierarchy ( and by the way, I HATE XML with a passion you can only imagine but in this case it makes sense ) that would populate the menu, it handles the layout of the thing, you simply provide it colors, sizes, content and the OnClick call's

    But this will make web pages WAY to complicated you say

    --
    Hey KID! Yeah you, get the fuck off my lawn!
  31. Re:Why is JavaScript is so popular? Lamda Function by TheRaven64 · · Score: 1

    I think you are confusing a few things. Lambda calculus is a simple universal model of computing invented by Church. A lambda expression can reference variables explicitly inside its scope ('bound') or outside ('unbound'). By performing a beta reduction, you explicitly bind a variable in a lambda expression. This is what the lambda operation in Lisp does.

    It sounds like you are confusing the fact that functions are objects, and the fact that functions are closures. The fact that they are objects lets you pass them as parameters and introspect them. The fact that they are closures allows them to reference variables in their enclosing scope even after the enclosing scope has exited.

    JavaScript is a Self derivative, and Self is a Smalltalk derivative (with Lieberman prototypes instead of classes). All languages in this family have closures as first-class objects, including newer ones like Io. For Ãtoilé, I have written a Smalltalk compiler which generates code ABI-compatible with the GNU Objective-C runtime, which allows us to mix Smalltalk and Objective-C in the same project (actually, in the same object), so we get exactly this advantage from a compiled language (for various other reasons, Smalltalk is still slower than Objective-C).

    --
    I am TheRaven on Soylent News
  32. Re:Why is JavaScript is so popular? Lamda Function by Anonymous Coward · · Score: 2, Interesting

    I think I get what you're saying but the difference between function having closures and functions being objects, but I just intended to point out that unlike JavaScript, Java, C, and C++ don't allow first class functions (which I refer to as lambda functions) though they do allow first class objects and function pointers though

    First class functions and Lambda functions in Lamda calculus are the same thing. I also used the calculation of a derivative using a lambda function as an example which is something from mathematical calculus which may have added to the confusion.

  33. Re:Can I just point out by Anonymous Coward · · Score: 0

    Javascript is half-assed, broken implementation of prototype OOP. Look at Io for a real implementation of the ideas developed by SELF.

  34. Re:Can I just point out by Anonymous Coward · · Score: 0

    What does that have to do with the language? You can write crap programs in all languages. How about you discuss it in more substantial terms like how much time is needed to X in that language? Does it save you keystrokes vs. another language? Does it make the code easier to understand?

  35. Classes are not out of the question. by Tiles · · Score: 3, Informative

    Classes are syntatic sugar. That's what the working group found, when it discovered that most class-centric features can be boiled down to simpler APIs such as .freeze(), .defineProperty(), &c., all of which are being implemented in ES3.1. Classes, then, would only be user interface to what can already be implemented using these features.

    ES-Harmony is about standardizing new features that already work in (three out of four) major browsers, without changing the syntax of the language. Brendan Eich of Mozilla in the Open Web Podcast already discussed how script versioning will allows coders to use different language versions in the future. So syntax changes are not out of the question, they're simply being postponed until after ES3.1.

    Until then, users will still have all the power of classes in their code, just without the ease-of-use of a "class" keyword (which will be a lot easier to implement after ES3.1 is proven and tested).

  36. Re:Can I just point out by labyrinth · · Score: 1

    You do realize that the HTTPRequest object which makes AJAX possible was introduced by Microsoft in the first place?

  37. Re:Can I just point out by Locutus · · Score: 1

    ok, so you are saying that they produced "HTTPRequest object" with the W3C? I doubt that and would figure it was probably originally tied to some Windows-only technology. Even if in the far off chance they did submit this to the W3C, I'd bet that they would take it off the market in a heartbeat if they could.

    And I don't doubt they have some good developers. They, as a business, don't put solutions or customers first so that their shareholders are rewarded. They know their shareholders are rewarded only because they've got Windows in a monopoly position and keeping it there with anti-competitive tricks and methods is what they do and have done.

    If the cure for cancer came out on a Mac or Linux, Microsoft would crush that and the result would be more like a Kleenex for the common cold. IMO.

    LoB

    --
    "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
  38. Stds compliance good for all except lg monopolies by Helldesk+Hound · · Score: 1

    > What is needed in the JavaScript world is not more
    > features, but more consistency of implementation
    > across the various browsers.

    While I agree with you about the need for greater consistency of implementation, I don't expect that will ever happen. Microsoft does not want that to happen; and will do all it can to prevent cross-platform and cross-browser adherence to agreed standards where those standards will reduce its monopoly position - even to the extent of hijacking standardisation processes.

    http://www.consortiuminfo.org/standardsblog/index.php?topic=20071125145019553

    http://www.consortiuminfo.org/standardsblog/index.php?topic=20051116124417686

  39. lobby brain washing by kapouer · · Score: 1

    my god, and nobody asks why slashdot, thereg and others tell us that standards are dead ? The bottom line of this story is about "kill standards, let money be innovative" with crap software. Who the hell cares about standards compliance ? Me ! I'm fed up with writing compatiblity layers ! Human being should be ashamed of its lack of ability to comply with standards ! Please, people, do believe in standards, this is the only way to go next stage. Don't listen to all these pseudo journalists trying to make you feel sad about practical and beautiful solutions. And also don't forget to look at epiphany-webkit, the only browser with 100% acid3 test !

    1. Re:lobby brain washing by Zarf · · Score: 1

      Please, people, do believe in standards, this is the only way to go next stage.

      I believe in standards like I believe in Santa Claus.

      --
      [signature]
  40. Re:No. Fuck you. by omfgnosis · · Score: 1

    What parts of Javascript don't work?

  41. Translation: by Anonymous Coward · · Score: 0

    Scuse me while I build up and then destroy this straw man, followed by a head-first dive into rhetoric.

  42. Re:Can I just point out by Anonymous Coward · · Score: 1, Insightful

    Yeah, it's such a beautiful, expressive, powerful language that I have to use a browser plugin that disables it on all but a minuscule fraction of the websites that I surf. All just so that I can be reasonably certain that if my machine gets compromised through my browser, it won't be because of some bullshit javascript pwnage.

    The only aspect of a language that has anything to do with browser security is its security model. Are you trying to criticize Javascript's security model or are you just against browser scripting in general? If the former, please make a more specific case for how the security model could be improved, and if the latter, please make yourself clear, because it sounds like you have something against Javascript in particular.

  43. Re:Can I just point out by Anonymous Coward · · Score: 0

    It is a beautiful, expressive and quite powerful language that is just now starting to shine after years of being misunderstood by people like you.

    He said that the Javascript platform was "horrible from an efficiency, performance, security and architectural point of view." I think his statement is completely consistent with Javascript being a beautiful, expressive, and powerful language.

    I don't understand why his post was moderated Flamebait, since he's just repeating complaints that you hear every day from web developers, even the ones who like Javascript as a language.

    As for Javascript "becoming" a development platform, he's talking about the recent explosion of rich, highly interactive web applications written in Javascript. It might be based on 2000 vintage technology, but it took a few years for the programming paradigms and cross-browser libraries to emerge.

  44. Re:get some language experts by Watson+Ladd · · Score: 1

    Once you have first-class functions and closures you have a prototype-based object system.

    --
    Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
  45. Re:Can I just point out by rbanffy · · Score: 1

    Why classes? Are they inherently superior to other approaches?

  46. Re:Can I just point out by Anonymous Coward · · Score: 0

    And they've been kicking themselves ever since. If they had let someone else invent it first, they could have come out with an incompatible version and made cross-browser development even harder.

    As it turns out, it wasn't a total loss for Microsoft, since without standardization you have to use browser-specific extensions to acquire an HTTPRequestObject. Still, once you have that HTTPRequestObject, it has the same basic functionality in every browser. Somebody probably got fired from Microsoft for allowing that to happen :-(

  47. ECMA -- ick. by bratwiz · · Score: 1

    ECMA sounds like a bad skin disease... ... I knew this girl once, she wasn't that bad looking, you know, but man did she have ECMA all over... gave me the creeps!

  48. Re:Can I just point out by tkinnun0 · · Score: 1

    You can point that out, but you'd be wrong. JavaScript hasn't recently "become" anything. The last major revision that all browsers supported was in November 2000.

    Try reading the OP's post with some thought. He isn't saying that Javascript has changed, rather it has become the development platform for Web 2.0.

    As for beauty, well, there's lot less ways to do method dispatching using immutable arrays than mutable hashmaps. Simplicity and transparency are closely linked with beauty as well.

  49. Not quite... by Jane+Q.+Public · · Score: 1

    he pointed out that it is a development platform for Web 2.0. There are many web development frameworks that do quite well, with only just enough javascript to support ajax and nothing more.

    Having stated that, it is also true that if you want smooth cross-browser compliance, Flash with actionscript has been the only way to go for quite a while. And given that, then Microsoft might just have shot itself in the foot again, because Flash and actionscript are more consistent cross-browser than JavaScript has EVER been... and Microsoft's competitor Silverlight is -- as usual -- too little too late.

  50. Re:Can I just point out by Metasquares · · Score: 1

    No, just as the Perl 5 model of OOP isn't inherently superior to the class-based approach (or, for that matter, just as OOP isn't inherently superior to other paradigms). They do employ different modes of thought, however, some of which could be easier to use in certain domains. The class-based method also tends to be the more familiar one, for what that's worth.

  51. Re:Why is JavaScript is so popular? Lamda Function by LowlyWorm · · Score: 2, Insightful

    I agree but its not just its functional capabilities. It has a really nice (if limited) syntax. True, it is in many ways just a knockoff of C or C++ but that, to me, is part of its appeal. It is far less cumbersome than either and that makes it fun.

    --
    Time flies like an arrow. Fruit flies like a banana.
  52. Re:get some language experts by speedtux · · Score: 1

    Yes, what suckage. Who on earth wants a simple, dynamic, low-cruft language with first-class functions, closures, lambdas and a prototype object system that still manages to look like the C language family? Evil, evil, evil...

    There have been dozens of such languages around. The hard part is also making it (1) fast, and (2) correct. And JavaScript is neither.

  53. A Security Disaster Waiting to Happen by knorthern+knight · · Score: 1

    > The web browser needs to transform into a sand-boxed window manager.
    > How is that again? A window manger, huh?

    Every time you add power to a scripting language, you invite abuse. Considering how well MS has *NOT* sandboxed stuff inside IE, absolutely the *LAST* thing the web wants/needs is "more powerful" web apps.

    The article at http://www.theregister.co.uk/2008/08/15/webbased_clipboard_hijacking/ describes the latest Flash exploit. It appears to come in via Flash in 3rd-party banner ads. It causes Flash to rewrite the user's clipboard once a second, with a URL to a malware-laced website. The logic is that if you're doing a bunch of cut-n-paste, you may not notice that you've pasted something other than what you've intended. These malware URLs will end up being pasted into people's email messages and web postings.

    This is an "equal opportunity attack". Because Schlockwave-Trash is so ubiquitous, the clipboard-hijacking is affecting all major OS's (Windows and Mac and Linux) and browsers (IE and Firefox and Safari).

    The problem is that Flash is not a mere player. It's a programming environment complete with scripting language (Actionscript). This includes stuff like System.copyToClipboard() It's not a bug, it's a feature. Yet another reason to block Flash. I use the Flashblock extension for Firefox.

    We should send a message loud and clear to web developers...

    You may send *DATA* (including text/pictures/sound/movies etc) to my browser, but *YOU MAY NOT EXECUTE YOUR CODE ON MY MACHINE*!!! If I wanted the Russian Business Network to be able to execute their code on my machine, I'd run Windows and IE with ActiveX enabled.

    --

    I'm not repeating myself
    I'm an X window user; I'm an ex-Windows user
    1. Re:A Security Disaster Waiting to Happen by FlyingGuy · · Score: 1

      Thanks for the reply...

      I think many have missed the point entirely. I in NO way advocate allowing anyone to run ANY code they want to fling onto my machine.

      What I advocate is a more cohesive way ( and ultimately simpler ) way of doing what we are trying to do today with even more security.

      In my example to pop open a new web page the page will deliver text but in the form of a script that can call options built into the browser. This happens now in the form of and all of this stuff has to either be controlled by breaks, and or CSS that is just miserable to deal with. The DIV tag does the same thing as a method called say Document.CreateArea(UperLeft,LowerRight,StyleReference) and everytbing is referenced to the upper left corner of Document. Given a name such invocation such is TopBanner = document.CreateArea(...) then TopBanner now has its own name space within Document and can be referred to as such. Each area has its own location. You can let things flow within an area as they do now, but the backside coding is much simpler since there is no global CSS stack desperately trying to make these things all flow around each other in odd sort of free form ways. Each area can be brought to the front my a mouse click, or minimized even if that is what the designer intends for their layout.

      So what I am advocating is not just letting random code run wild, I am advocating a smarter and simpler way of controlling the appearance and functionality of the web, within the browser space.

      Think of each document that you open being its own VERY sand boxed MDI if you will, but with modern controls like we have in ALL GUI's that allow for more controlled placement of the various elements that we want to see. I mean right now we can float something left or right and text sort of wraps around it. But without the most torturous invocations of some pretty insane CSS we cannot float center and have a picture sitting in the middle of the page and have text flow around it. Now consider that you Document knows where all the various areas are, it would be far simpler for it to wrap text around those elements instead of having to rely on walking the CSS stack, to try an figure out what is where and how its all supposed to render. As I said, CSS is a was a great idea, but it has gone horribly wrong because of the things the DOM model is lacking. One glaring error that has never been corrected is the checkbox in forms. I looked for DAYS to try an figure out a way to fetch back either through a post method or a get method the false condition of a checkbox being checked. And without a hidden field and some silly JS floating around you cannot discover that the user never checked that box!

      There are a LOT of fundamental problems with DOM, JS and CSS that have yet to be addressed and its high time we got with the program.

      --
      Hey KID! Yeah you, get the fuck off my lawn!
    2. Re:A Security Disaster Waiting to Happen by knorthern+knight · · Score: 1

      > I think many have missed the point entirely. I in NO way advocate
      > allowing anyone to run ANY code they want to fling onto my machine.

      I mis-interpreted your statement "The web browser needs to transform into a sand-boxed window manager. How is that again? A window manger, huh? The idea sits in front of ALL of you every day. The GUI desktop moves things around, arranges windows, covers them up allows them to be moved, adjusts for sizing, everything we desperately try to implement in CSS and DOM but pretty fail to do."

      A window manager displays applications, and when you mentioned "sand-boxed", that fit right in. It appears that you were advocating a major re-write of HTML. A few points...

      1) I agree with you that HTML was originally written to emulate static paper. Vint Cerf and co-workers were trying to share documents in read-only mode, and HTML does that quite well, thank you. HTML wass *NOT* written with major interactivity in mind, and that is glaringly obvious. Interactivity hacks on HTML are ugly hacks at best, and open up the end-user to attack (Active-X anyone?).

      2) I think that rather than trying to extend HTML into interactivity, we should admit that it wasn't written with interactivity in mind, and trying to make a steamboat fly is a waste of time and resources.

      3) The basic problem is that a browser won't accomplish a lot of what people want done. Since one-size-does-not-fit-all, there are multiple solutions to the many-faceted problem...

      * a lot of today's form-filling "interactivity" would be done better on a GUI dumb-terminal, or even a VT-100 emulator.

      * a lot of remote work could be done by an internet file system by abstracting it to look like another remote drive. Enable regular word-processossers and spreadsheets to...
      - open up a document on http://bad.example.com/my_docs/letter_to_aunt_jane.doc
      - edit it locally with your word-processor of choice
      - save back to the original file

      * For "heavy-duty interactivity", I suggest inventing a new RIA "Rich Internet Application" API, assigning it a different port (i.e. not 80), and doing all your first-person-shooter-wannabee stuff on that

      * Leave browsers alone to do what browsers do best, i.e display text and images and movies and audio.

      --

      I'm not repeating myself
      I'm an X window user; I'm an ex-Windows user
  54. Re:No. Fuck you. by Lepaca+Kliffoth · · Score: 1

    People who complain about Javascript usually don't really understand anything about it - Activation & Variable, [[scope]], closures etc etc. They try to write a program in traditional OOP fashion and maybe they accidentally form lexical closures and see unexpected behaviour that they interpret as variable visibility issues. Or, they touch one of the many places where JS is incompatible across browsers and become confused. Then they go on some forum to explain in how many ways JS sucks. I wish they just studied the language and took the time to understand it.

  55. Haxe by chrysalis · · Score: 1

    I'd love to see Haxe ( http://www.haxe.org/ ) supersede Ecmascript.

    --
    {{.sig}}
  56. and Harmony is not ES3.1! by spage · · Score: 1

    Original post says

    abandoned the proposed ECMAScript 4.0 language specification in favor of a more limited specification dubbed 'Harmony,' or ECMAScript 3.1.

    That is wrong, ES3.1 is the smaller increment and repair of the current third standard, and "Harmony" is new features beyond that. Doug Crockford, who seemed opposed to much of ES4, wrote:

    Some of the features that were in ES4 were reasonable, so a new project, called Harmony, is starting which will look at adapting the best of ES4 on top of ES3.1.

    TopSpin's summary is pretty crappy!

    --
    =S
    1. Re:and Harmony is not ES3.1! by omfgnosis · · Score: 1

      Um, it is 3.1. Neither had been accepted except as presumed version numbers until that point. Harmony isn't the original 3.1 proposal, but it is what is anticipated to be the 3.1 standard when complete.

  57. schmecmascript by Hognoxious · · Score: 1

    ecmascript schmecmascript already! There's be no fun in web development if you didn't have to try and hack around subtly different incompatible implementations of more-or-less thae same goddam thing.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  58. Re:Can I just point out by Anonymous Coward · · Score: 0

    The blame is on idiots like you who think it's ok to do stupid things. "Hey, hold my beer, watch this." - is a stupid fucking development method for mickey mouse developers like you. "Hur hur hur, I can add this method to a class, have no good encapsulation, and it does something." Thanks, now you've made something difficult to use and that's shittily documented. Fucking asshole JS developers ruining it w/ their php-esque crap.

    Just like a PHP developer. "I'll just jump on the trend of the net being more useful." - and fucking derail it.