Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 14 of 14

Thread: Javascript 2.0

  1. #1
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts

    Javascript 2.0

    Even more JS goodies, check out this excellent presentation on JS2:
    http://developer.mozilla.org/present...06/javascript/

    What I notice is a lot of Java influence (packages, classes, types), but also Scheme (let()) and even more Ruby/Python stuff ([a,b]=[b,a] to swap, tupled assignment, array slicing via index, etc, as well as the stuff from my JS1.7 post). Also, there is the addition of operator overloading, which is both a Good thing and a Bad thing, depending on how you use it.

  • #2
    Senior Coder A1ien51's Avatar
    Join Date
    Jun 2002
    Location
    Between DC and Baltimore In a Cave
    Posts
    2,717
    Thanks
    1
    Thanked 94 Times in 88 Posts
    Yeah, but as I always say what good will it be? I still have windows 98 with IE 5 hitting my site. Just what I want 2 sets of code! lol

    Eric
    Tech Author [Ajax In Action, JavaScript: Visual Blueprint]

  • #3
    Regular Coder
    Join Date
    Aug 2005
    Posts
    282
    Thanks
    0
    Thanked 0 Times in 0 Posts
    I almost got a bit sick clicking through the presentation.

    Are all these ideas set in stone?
    Is no group of individuals helping to say yes or no to what gets added??

    or, was this just a brainstorm of "what could come to be?"

  • #4
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Quote Originally Posted by KC-Luck
    I almost got a bit sick clicking through the presentation.

    Are all these ideas set in stone?
    Is no group of individuals helping to say yes or no to what gets added??

    or, was this just a brainstorm of "what could come to be?"
    I used arrow keys to work my way through... much nicer than clicking.

    Anyway, that stuff is all encompassed in the current current drafts of the ECMAScript 4 specification. So set in stone.... as much as any draft is I suppose. But you will definitely see all of that stuff in some form in JS2.

  • #5
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Quote Originally Posted by A1ien51
    Yeah, but as I always say what good will it be? I still have windows 98 with IE 5 hitting my site. Just what I want 2 sets of code! lol

    Eric
    If nobody takes the first step, nobody will follow. New features will never be available unless they start somewhere, so "what good will it be" seems to be a silly question. Unless of course, you are happy with the limited toolset that web application developers have today.

  • #6
    Master Coder felgall's Avatar
    Join Date
    Sep 2005
    Location
    Sydney, Australia
    Posts
    6,642
    Thanks
    0
    Thanked 649 Times in 639 Posts
    I think that you will find that server side Javascript using .NET already incorporates much of the JS2.0 specification in what it already supports.
    Stephen
    Learn Modern JavaScript - http://javascriptexample.net/
    Helping others to solve their computer problem at http://www.felgall.com/

    Don't forget to start your JavaScript code with "use strict"; which makes it easier to find errors in your code.

  • #7
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    The slides I linked to discuss that and the latest ActionScript implementation. Ultimately, it seems that they are based on incomplete drafts which aren't compatible with each other and (presumably) the final spec. Though certainly one would expect (hope?) the engines to update when the spec finalizes.

  • #8
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    some Ruby woun't hurt... But classes? It will make the language less flexible, I reckon...
    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

  • #9
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Quote Originally Posted by Kor
    some Ruby woun't hurt... But classes? It will make the language less flexible, I reckon...
    I would agree... but it only makes your code less flexible if you use them.

    Though, it is hard to dismiss the advantages of interfaces and classes when you're dealing with huge codebases that you're seeing nowadays with complex "ajax" web applications, and teams of many individuals all working together to make it work.

    Also, the introduction of namespaces (ala Java) allows an easy way out of the variable-pollution problem that still plagues most script archives (proper closures and anonymous function techniques may be a bit much to ask of the average JS developer, not to mention often being somewhat of a hack in its own right).

  • #10
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    if the implementation would be made by extending the language, well yes, I'll enjoy the club. You are right, the way it is now, javascript is some how limited due to the poor speed (it is about 100x times slower than C++).

    But I am affraid it will not be possible... Frankly, I don't see how javascript could be a compiled and an interpreted language, all the same time...
    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

  • #11
    jkd
    jkd is offline
    Senior Coder jkd's Avatar
    Join Date
    May 2002
    Location
    metro DC
    Posts
    3,163
    Thanks
    1
    Thanked 18 Times in 18 Posts
    Quote Originally Posted by Kor
    if the implementation would be made by extending the language, well yes, I'll enjoy the club. You are right, the way it is now, javascript is some how limited due to the poor speed (it is about 100x times slower than C++).

    But I am affraid it will not be possible... Frankly, I don't see how javascript could be a compiled and an interpreted language, all the same time...
    On the contrary, I don't consider Javascript limited by its speed. Who cares if it is 100x slower than C when generally Javascript is executed as a response to user-interactions; DOM changes happen sufficiently fast as to not let the user notice. Similarly, if you're working with XMLHttpRequest(), almost without fail the latency associated with polling a server will be orders of magnitude larger than the execution time of the actual code.

    Speed is not Javascript's problem (and I doubt the 100x figure you gave for most scenarios).

    Also, don't confuse the introduction of classes and optional strict typing as implying that JS2 can or will be a compiled language. It should still be primarily an interpretted language (just like JS as it is now).

  • #12
    Master Coder
    Join Date
    Feb 2003
    Location
    Umeň, Sweden
    Posts
    5,575
    Thanks
    0
    Thanked 83 Times in 74 Posts
    Quote Originally Posted by A1ien51
    Yeah, but as I always say what good will it be? I still have windows 98 with IE 5 hitting my site. Just what I want 2 sets of code!
    ECMAScript 3 is seven years old. The language has changed absolutely nothing since 1999. What you should be asking yourself isn't what you would want JavaScript 2/ECMAScript 4 for today. The question you should be asking yourself is what language constructs you would like to be able to program with in browsers seven years from now.
    Quote Originally Posted by KC-Luck
    I almost got a bit sick clicking through the presentation.
    Yeah, but the arrow keys worked much better for it.
    Are all these ideas set in stone?
    No. But they are all considered by the ECMAScript TC. I bet most of them will end up in the language in some form or other in the end.
    Is no group of individuals helping to say yes or no to what gets added??
    The ECMA Technical Committee 39, Task Group 1 are the ones in charge. Chair is Brendan Eich of Mozilla. The involved parts in the TG are BEA Systems, IBM, Intel, Macromedia, Mainsoft, Microsoft, Mozilla Foundation.
    or, was this just a brainstorm of "what could come to be?"
    Some things are already decided upon. Anything making it into Mozilla SpiderMonkey is likely decided upon already. We know some things are not yet decided. The TG work isn't public, so it's not entirely clear what is set in stone and what is a floating concept that might be worked into it in some form.
    Quote Originally Posted by felgall
    I think that you will find that server side Javascript using .NET already incorporates much of the JS2.0 specification in what it already supports.
    The earlier ECMAScript 4 draft was was written while the TG was chaired by Waldemar Horwat of Netscape and was taking a different course than that which this current work indicates. Those implementations of the old drafts - ActionScript 3 and JScript.NET - can be considered the largest roadblocks that this current specification will have to get past. Hopefully they will be changed once ECMAScript 4 is a finalised and published standard. But even if they are not, that should not change the ultimate outcome of the current work - that ECMAScript 4 eventually takes over where ECMAScript 3 exists today.
    Quote Originally Posted by Kor
    some Ruby woun't hurt... But classes? It will make the language less flexible, I reckon...
    Yes, and no. First of all, classes are introduced to get around one of the worst problems in the current language - that it's not modular nor secure in the face of inheritance. Currently you need to use closures for private members, you have trouble with class members as opposed to instance members etc. I believe that the prototype inheritance could be fixed to solve these problems without introducing classes, but the next version of ECMAScript WILL have classes, like it or not. Probably because classes is a recognised and well researched concept.

    One of the benefits of classes is that it allows early (strict) binding. That means considerably increased performance and should work very well for compiled code such as JScript.NET and ActionScript as well as for heavy computation tasks such as graphics and audio processing. Think SMIL, SVG, the canvas element, the OpenGL ES API, or audio manipulation in various forms. And it's optional - if you don't need it, don't use it. They won't be removing prototype inheritance just for this. But now you will be able to use classes and early binding if you need them, unlike earlier.
    Quote Originally Posted by jkd
    I would agree... but it only makes your code less flexible if you use them.
    Well, the code does become less flexible, but only in the areas where you decide you can take the reduction in flexibility. How often do you use runtime changing of prototypes? Except for the built-in objects and other host objects, I bet you aren't using it at all. So what do you lose from using classes in your own code? It can even help you, because one of the problems today is that you can't rely on an inherited member to not have been replaced or changed. So, you get library conflicts where they could easily have been avoided - just look at Prototype!
    Though, it is hard to dismiss the advantages of interfaces and classes when you're dealing with huge codebases that you're seeing nowadays with complex "ajax" web applications, and teams of many individuals all working together to make it work.
    Yeah, I can see it being easier. Both for reasons of clarity and reasons of familiarity to the larger body of developers.
    Also, the introduction of namespaces (ala Java) allows an easy way out of the variable-pollution problem that still plagues most script archives (proper closures and anonymous function techniques may be a bit much to ask of the average JS developer, not to mention often being somewhat of a hack in its own right).
    Namespaces/Packages/Modules don't help much compared to anonymous functions and object literals taken together, but it adds at least one huge benefit to either on it's own - export/import mechanisms so that you can easily combine both private mechanisms (wrapping in anonymous functions) and public mechanisms (using object literals) into a single, easily understood functionality.
    Quote Originally Posted by Kor
    if the implementation would be made by extending the language, well yes, I'll enjoy the club.
    There are few incompatible changes planned. Most are extensions of the current language.
    You are right, the way it is now, javascript is some how limited due to the poor speed (it is about 100x times slower than C++).
    Well, most uses of JavaScript won't be helped, because they aren't gated on script execution speed. A minimal part will break. The greatest benefit is that it will allow the language to be used where it's performance today is insufficient. Look at all the various 3D drawing projects that generate BMP or X-pixmaps, draw using DOM elements and CSS, or use Canvas. These language changes will make graphics manipulation from being impractical, cumbersome and slow to being no worse than what you can achieve in other scripting languages, provided good host facilities and libraries (possibly written in JavaScript themselves) are made available.
    But I am affraid it will not be possible... Frankly, I don't see how javascript could be a compiled and an interpreted language, all the same time...
    It already is both at the same time. SpiderMonkey compiles to custom bytecode. JScript.NET and ActionScript are both fully compiled. JScript is, unless I'm mistaken, interpreted from AST. The only thing needed for turning an interpreted language into a compiled language is an engine that bundles the parser and compiler, and allows for mixing old and new compiled code. JIT in Java and .NET allows this, for instance.
    Quote Originally Posted by jkd
    Speed is not Javascript's problem (and I doubt the 100x figure you gave for most scenarios).
    100x is probably true (if not optimistic) for the language runtime itself, though. If you eliminate the host, just built-ins and native JavaScript, compared to C. Most of it's bad speed comes from it's lack of true arrays, from it's use of double precision floats for all numbers, from it's automatic type checking and autocasting, and from the late binding. However, if one single library call from JavaScript takes 100x what it takes in C, and it in C takes 1 Ás, then that is 100 Ás for JavaScript. Which is still very fast compared to what a human might notice. Say this library call takes 100 ms to complete. Then the difference is 100.01 for JS compared to 100.0001 for C. The language the library code is written in, and the complexity of it's functionality, will be what determines the actual percieved speed. However, if you have to do thousand of library calls to fast library functions, then the overhead of JavaScript will add up as compared to C.
    Also, don't confuse the introduction of classes and optional strict typing as implying that JS2 can or will be a compiled language. It should still be primarily an interpretted language (just like JS as it is now).
    Or not. I doubt you can tell which engine is interpreted and which is compiled from the in-browser performance alone. And "compiled" is a little fussy, since we have plenty of bytecode compiled engines.
    Last edited by liorean; 05-27-2006 at 01:04 PM.
    liorean <[lio@wg]>
    Articles: RegEx evolt wsabstract , Named Arguments
    Useful Threads: JavaScript Docs & Refs, FAQ - HTML & CSS Docs, FAQ - XML Doc & Refs
    Moz: JavaScript DOM Interfaces MSDN: JScript DHTML KDE: KJS KHTML Opera: Standards

  • #13
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    so... that is a filtered view of the javascript future, I presume... It is good to know that in avance, really... That means I must keep learning a lot of related stuff all the time to be ready to keep in touch with the what-time-will-bring... ye
    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*

  • #14
    Kor
    Kor is offline
    Red Devil Mod Kor's Avatar
    Join Date
    Apr 2003
    Location
    Bucharest, ROMANIA
    Posts
    8,478
    Thanks
    58
    Thanked 379 Times in 375 Posts
    eeer and... I liked the Javascript anthology small contest (even I saw it too late to come in with).
    http://www.codingforums.com/showthread.php?t=87310
    Frankly, I would like better something like "Javascript trends&future" instead
    KOR
    Offshore programming
    -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •