Forgot your password?
typodupeerror
Programming Mozilla The Internet IT Technology

Brendan Eich Discusses the Future of JavaScript 164

Posted by ScuttleMonkey
from the everyone-should-know-a-little-javascript dept.
snydeq writes "JavaScript creator Brendan Eich talks at length about the future of JavaScript, ARAX, disputes with Microsoft, and the Screaming Monkey scripting engine for IE in an interview with InfoWorld's Paul Krill. JavaScript 2, which Mozilla's Eich expects to be available in some form by the end of the year, will 'address programming in the large.' To do that, Eich hopes to improve the integrity of the language without sacrificing flexibility and making JavaScript 'painfully static in a fixed way like Java does.' Eich does not expect Firefox support for JavaScript 2 until at least Version 3.1 of the browser. As for Internet Explorer, Eich explains how Screaming Monkey will help bring JavaScript 2 to IE should Microsoft drag its heels on providing meaningful support."
This discussion has been archived. No new comments can be posted.

Brendan Eich Discusses the Future of JavaScript

Comments Filter:
  • 1-page version (Score:5, Informative)

    by taupin (1047372) on Monday June 23, 2008 @06:54PM (#23910587)
    is here [infoworld.com].
  • Really? (Score:4, Insightful)

    by Goaway (82658) on Monday June 23, 2008 @06:55PM (#23910595) Homepage

    We can't expect support for Javascript 2 in Firefox until the next version? But I want it to magically appear in the current one!

    • Considering Javascript 2 isn't really done until the end of the year, there's no reason it should be in the current version. Remember 3.1 will be a point release not a full release so 6 months away to the next point release isn't unreasonable.
      • by Goaway (82658)

        See, that was one of these "jokes" making fun of the wording of the article.

    • This site [ecmascript4.com] has an example of Javascript 2, and a translator from Javascript 2 to the current version. I really like the type-safety features and the MUCH better way to do OO.

      In response to the parent, in the article they talk about how Microsoft is fixated on 3.1 and not 4. Hence, there is "Project Screaming Monkey" which aims to create a scripting engine for IE that can run Javascript 2 and not depend on Microsoft to support Javascript 2. Then, IE can support Javascript 2 (through the Flash Player - full details in the article). I wonder if it is possible to do something similar for Firefox. Perhaps via a plugin? But I suspect performance would suffer greatly. Or maybe 4->3.1 translator like at ecmascript4.com that would do an "on-the-fly" translation.

      • by weston (16146) * <westonsd@can n c e n t r a l.org> on Monday June 23, 2008 @08:33PM (#23911487) Homepage

        I really like the type-safety features

        Fortunately, the type safety features will be optional.

        and the MUCH better way to do OO.

        This is a matter of opinion, and is definitely contested.

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

        • by Pastis (145655) on Tuesday June 24, 2008 @12:22AM (#23912855)

          > "If you could do Java over again, what would you
          > change?" "I'd leave out classes," he replied.

          "After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible. "

          Not the same as saying that he didn't want java to be OO.

          http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html [javaworld.com]

          • Not the same as saying that he didn't want java to be OO.

            Oh, no, that's not the point at all. The point is this:

            OO != Classes

            And in fact that Classes may not be the ideal way to orient a program around objects. And the bonus point is that the person who implemented what's the arguable current king of OO languages understands this. He's not the only one. The Drupal Devs also have a thing or two to say on the subject [drupal.org].

            I'm very familiar with the Allen Holub article you referenced -- stumbled across it three or four years ago, and it eventually led me to buy Holub's book on patterns [holub.com]. The takeaway point about the hazards of implementation inheritance is one that I think he overstates, but it's absolutely necessary given the way most people learn OO programing these days. Most books and tutorials hammer on extends and necessarily use examples of class hierarchies because it's necessary to teach what all the OO syntax does, but this really isn't what OO programming is about.

            The interesting thing is that Javascript is one of the few popular languages where this is quite clear. There are weak clases, there is no "extends", and therefore very little magic implementation inheritance. You can code up syntax for this, if you like, as many of the major libraries do, which I think illustrates the power of the model and the language, but by and large, the prototype inheritance method means that you're doing interface inheritance or very explicit implementation sharing. This means the pitfalls Holub points out are easier to avoid, and there's many other bonuses. It also unfortunately means a bit extra work in some cases where implementation inheritance is handy and less dangerous, but it's not all that much, and I think the tradeoff is worth it.

            Now, the next version of Javascript will particularly be nice for developers of libraries who have reasons not to trust the developers using what they're producing, because they'll be able to freeze things they can't freeze now with the static typing and class definitions.

            But I'm pretty afraid a prevalent culture that seems to have a fairly narrowly scoped idea of object orientation and "best practices" is going to clap their hands and grab onto the familiar classes as they approach Javascript, rather than really understand the breadth of the language, and in 3-4 years, you'll have newly-minted team leads fresh from their recent readings of Fowler and GoF talking about tortured design patterns using static types and classes when a little sprinkling of dynamic language will do the job.

            Please, allay my fears by not saying "JS2 finally bring real OO programming to Javascript."

            • by MemoryDragon (544441) on Tuesday June 24, 2008 @03:39AM (#23913819)
              Actually I personally saw it always as the weak point javascript of providing class like constructs and no inheritance, instead exposing the virtual method table directly. (Prototype is nothing else) This basically ended in, colliding namespace constructs, different incompatible inheritance constructs by third party libraries etc... You cannot really design big systems without those two constructs, and javascript exactly is moving into that arena without being properly equipped for it.

              In the end javascript is the classical example of a 95% academic language. Looks nice on paper, it is very fast in designing small systems, it is very flexible which makes the academic crowd cheer but fails utterly once you have to design bigger systems because the productivity of the language goes down the toilet due to the fact that vital 5% of the language are missing.
              • instead exposing the virtual method table directly. (Prototype is nothing else)

                Not precisely, since the prototype property also exposes properties, as well as methods. Or, more precisely, methods are properties in javascript, since functions are first-class.

                You cannot really design big systems without those two constructs

                Not at all true. Well, it's tautologically true. You can't design big systems the way that most programmers who currently work on big systems design them in statically-typed explicitly class-based languages. And by some accounts, this turns out to be a huge advantage, because you get a LoC compression similar to what you'd see with Ruby.

                (As for namespaces -- PHP has the same problem, but worse, given that you can't even appropriate static ad-hoc classes as a namespace mechanism. And yet the namespace problem has been more or less practically addressed by conventions, and you can't argue anymore that people aren't building large systems in it.)

                different incompatible inheritance constructs by third party libraries

                It's true composing "extends" implementation inheritance implementations across libraries is likely to get you in trouble. But then again, simply using implementation inheritance can get you in trouble, in C++, in Java. And having to settle on conventions and libraries is not a fatal hit to a project.

                In the end javascript is the classical example of a 95% academic language.

                Acadmic? Why? Because it's functional, or didn't start life with "extends"?

                Javascript's shown itself as quite practical contender in a huge amount of the heavy lifting that's gone on in the RIA space over the last 5 years, and that's not half what's going to happen as it gets traction elsewhere [blogspot.com].

                • Re: (Score:3, Insightful)

                  by MemoryDragon (544441)
                  Actually speaking of php and big systems, I did some heavy typo 3 programming, and I saw the problems which were caused by the simple fact that there were no namespaces. Yes you could do a big system bug look at the mess the entire system (in this case typo3) was in... It took years almost a decade to get typo3 where it is now, and it is still a mess. Calling php as the classical example of namespaces are not helping in designing big systems is like a joke. In the end you even can design big systems even i
                  • Calling php as the classical example of namespaces are not helping in designing big systems is like a joke.

                    That'd be a great point if that where what I'm doing, but it's not. I'm pointing to PHP as an example of a language that's thoroughly handicapped -- there is no natural mechanism for namespaces -- but has developers and projects who've almost entirely skirted the issue by using certain conventions.

                    The moral of the story isn't that PHP is Teh Awesome (it has many, many ugly warts, and even with the inc

            • Oh, no, that's not the point at all. The point is this:

              OO != Classes

              While this is true, this was not the point Gosling was originally trying to make. His was that classes != extends. You can absolutely do away with implementation inheritance, retain classes, and provide some more flexible facilities for code reuse, such as mixins and/or syntactic sugar for aggregation and delegation - see Sather for an example.
          • This depends on the point of view, there was a time between 92 and 2000 when implementation inheritance was seen as the goto of the 90s, due to the strong binding of code it provides. The view has changed somewhat, also due to the fact that without implementation inheritance you have to rely on delegation a lot and you get a huge code bloat. To my knowledge the goto still is an antipattern, implementation inheritance never fully made it onto the anti pattern list and again is an accepted pattern among other
      • by zoips (576749)
        I really like the type-safety features and the MUCH better way to do OO. Javascript never really got prototypes right. I think the looks-like (duck typing) way of doing OO is very nifty, and prototypes (true prototypes like in Io and SELF) is probably one of the best ways of doing it.
    • Re: (Score:3, Funny)

      by Pollardito (781263)
      since the last version prior to 3.0 was 2.0.0.14 [wordpress.com], 3.1 might be further off than it sounds
  • Ow. (Score:4, Funny)

    by taupin (1047372) on Monday June 23, 2008 @06:58PM (#23910637)
    This statement made my mind hurt:

    "[...] use JavaScript as kind of an underlying assembly language [...]"

    • Re: (Score:2, Informative)

      by Anonymous Coward

      It means that the target language of the compiler is JavaScript. In this case, Ruby code, which the browser does not understand, is compiled to JavaScript code, which the browser can run. The association is that normally computer languages are compiled to some sort of assembly language, which is then compiled to object code.

    • Oh, that's nothing. Imagine transparent client-to-server remoting on top of that (i.e., part of the code just runs on the server, and other part is compiled to JS which runs on the client) - now that [live.com] is insanity.
  • by pembo13 (770295) on Monday June 23, 2008 @07:00PM (#23910647) Homepage
    VBScript sucks balls and Javascript is capable of getting the job done.
    • Javascript has the potential to be really useful. Well, it already is. I was at JavaONE earlier this year and I went to a few Javascript sessions. One of the most eye-opening sessions was the one where the presenter described Javascript as a LISP-1 language that just happens to look like C.

      As far as improvement, I think it needs a proper object oriented model (the current one is far too confusing), and also should be friendlier to implementations that require recursion. You can write recursive code in Javascript now, but it's very slow. Iterative solutions are faster.

      • Re: (Score:3, Informative)

        by pembo13 (770295)
        Well iterative solutions are almost always faster across languages.
        • Not to be pedantic, but this isn't strictly true. It's very difficult to even write an iterative solution in, say, Prolog, and you'd probably have to abuse a database to do it, and it almost certainly wouldn't be faster. By contrast, tail-recursive calls tend to be optimized in many implementations so you hit speeds on the order of many iterative constructs in interpreted environments.

          And at the bottom of this issue is the fact that it's an implementation issue, not a language issue. There's no reason for c

          • It's not about the speed of recursion, its about the inevitable memory footprint issue. A loop, while seldom as elegant, doesn't carry the memory overhead of a recursive function which must reach its boundary condition before beginning it's calculations.

            Using a language like LISP or Scheme, you learn to love recursion for its elegance. But when you start trying to apply that love to real world problems you run into significant memory issues, along with a lot of flack from fellow programmers who don't apprec

        • Not true for any algorithm which maintains an internal stack on any modern CPU. Most modern CPUs will have very fast push and pop instructions, often aliased with hidden registers. If you write a recursive implementation, you get to use these. If you write an iterative solution, you don't. If your compiler supports tail call optimisation (most do) then you also get the space usage of an iterative solution.

          Try running some benchmarks before you make general statements in future. In languages which are

      • Re: (Score:2, Informative)

        by JohnnyBGod (1088549)

        You can write recursive code in Javascript now, but it's very slow. Iterative solutions are faster.

        Which means... it's pretty much like every imperative language on the planet?

        • You can write recursive code in Javascript now, but it's very slow. Iterative solutions are faster.

          Which means... it's pretty much like every imperative language on the planet?

          Recursive solutions in other languages are slower than iterative solutions but not by as much as a factor when compared to recursive vs. iterative solutions in Javascript.

          The Javascript interpreter in browsers does not really optimize recursive code. Compare this to other interpreted languages [acm.org] (this paper talks about LISP, and Javascript incidentally, is a LISP-1 language), or compilers. This is why most tips for Javascript optimization talk about removing recursion because of bad performance of recursive code in Javascript.

          So if you're able to optimize for recursion in Javascript 2, it wouldn't impact performance as much as it does now.

          • Re: (Score:3, Interesting)

            by cecom (698048)

            You make be taking this claim that JavaScript is a LISP language a little too far. A couple fundamental things that are missing are macros, tail recursion ... Lastly, and perhaps most importantly, this is not how JavaScript is widely being taught and used.

            • Re: (Score:3, Interesting)

              by vivin (671928)

              It's not a claim:

              JavaScript Programming Language: The language everyone loves to hate [sun.com]

              Javascript and LISP [tech.coop]

              Douglas Crockford's page on Javascript [crockford.com]

              As far as your last point regarding how Javascript is being widely taught and used, all it states is a major problem with the way the language is understood. Just because a language is taught a certain way doesn't mean that the language IS that way. If you delve deeper into Javascript you'll see that it's more like lisp and less like C or Java.

              • Re: (Score:3, Informative)

                by cecom (698048)

                As far as your last point regarding how Javascript is being widely taught and used, all it states is a major problem with the way the language is understood. Just because a language is taught a certain way doesn't mean that the language IS that way. If you delve deeper into Javascript you'll see that it's more like lisp and less like C or Java.

                But I have. If you delve deeper into LISP you will see that calling a language without tail recursion and macros LISP-like is an exaggeration ...

                The links you hav

                • Re: (Score:3, Insightful)

                  by Haeleth (414428)

                  If you delve deeper into LISP you will see that calling a language without tail recursion and macros LISP-like is an exaggeration ...
                  Congratulations: you have come up with a definition of "LISP-like" that excludes both McCarthy's original LISP and ANSI Common Lisp. You must be proud.
                • Re: (Score:3, Informative)

                  by vivin (671928)

                  I'd say a strong case is made for Javascript's "LISPness" even without tail-recursion and macros. I get what you are trying to say, in that LISP != Javascript and that Javascript is not LISP (because it's a language in its own right). But I'd go so far as to say that Javascript has more in common with LISP-like languages than imperative ones. This is why Javascript is used wrongly quite often. In fact, when I realized Javascript was so much like LISP, everything fell into place. I've written LISP code befor

      • Problem with javascript is it looks nice on paper but fails miserably productivitywise in bigger systems. The main issues are, no dedicated namespacing which makes mixing of various libraries a real hell (no worries propotype will fix everything by simple hijacking the dollar operator which then is also used by jquery and others, also it makes huge sense to simply override the array so that other libraries fail....), the other really weak point lies in the way it exposes inheritance. It has semi like class

        • by famebait (450028) on Tuesday June 24, 2008 @03:58AM (#23913895)

          That's what TFA and Javascript 2 is about: JS1 is the way it is because it was meant to be small and simple. Usage has changed and thus requirements, and JS2 is the first opportunity to fix the big things.

          • Yes, I was aware that they are going to fix things, the main issue here is the browsers which still count for 95% of all javascript usages have to standardize. A plugin for the IE is a no go. Applets would work really fine nowadays they cannot be used due to being a plugin, flash only can be used because everyone has flash on his machine, once Microsoft drops the default flash install on a future windows version flash will go the same way applets did. Unfortunately standardizing new language versions is on
            • by jonasj (538692)

              Applets would work really fine nowadays they cannot be used due to being a plugin, flash only can be used because everyone has flash on his machine, once Microsoft drops the default flash install on a future windows version flash will go the same way applets did.
              *What* are you talking about? Flash is not and has never been part of a default Windows install.
        • by tcr (39109)

          no worries propotype will fix everything by simple hijacking the dollar operator which then is also used by jquery and others
           
          jQuery plays nice by letting you disassociate $ by calling jQuery.noConflict(). I like their attitude.
          Not sure about the other libraries.

  • Insightful (Score:4, Interesting)

    by Mensa Babe (675349) * on Monday June 23, 2008 @07:01PM (#23910667) Homepage Journal

    I wholeheartedly agree with Brendan that we should at any cost stop JavaScript [wikipedia.org] in particulat and Ecmascript [wikipedia.org] in general from being as painful as Java [wikipedia.org] in any way possible. However what we should do is not only improving all of the ECMA-262 [ecma-international.org] derivatives but to make a systematical progress towards better flexibility and interoperability of various scripting approaches in the future. Take for example the wonderful project by Mehmet Yavuz Selim Soyturk called PJS [fulladsl.be] which is an important step in the direction to allow the Parrot [parrotcode.org] virtual machine, designed to run Perl, Tcl, Javascript, Ruby, Lua, Scheme, Befunge, Lisp, PHP, Python, Perl 6, APL, Java, .NET, et al., to run on JavaScript, so all of those languages could be used together to enhance your browsing experience on the Web. For this to be even remotely plausible the JavaScript must be as flexible and as fast as possible because it would basically mean running high-level language code compiled to the Parrot intermediate representation (PIR, or IMC), that converted to the Parrot assembly language, assembled, linked, converted to Parrot bytecode and then execuded on the Parrot virtual machine or PVM which would itself be a large JavaScript interpreted script running in a Web browser, running in the operating system... You get the picture. A logical step forward would be to include PVM in all of the major browsers to run the Parrot bytecode natively and efficiently in the browser. There are already plans to include PVM interpreter in Firefox which means it will be available as a viable target for scriping dynamic html pages for all of its derivatives like Camino, Galeon and Konqueror. Hopefully the commercial browsers would follow (the Artistic license is not anti-commercial like GPL so there should be no legal problems with the integration). I really look forward to the future of perfect interoperability when every single Web page could potentially run scripts written in literally dozens of programming languages simultaneously. One day we will experience that synergy thanks to people like Brendan Eich,Mehmet Yavuz Selim Soyturk, Larry Wall, et al. if they only agree to work together on one common solution to the big mess of Web scripts that we have today. Let's all hope they will.

    • Re: (Score:3, Funny)

      You can't spell superior.
      Or use line breaks.
      • Re: (Score:3, Insightful)

        by Red Flayer (890720)
        Don't worry about it. Troll, (s)he is... better ask Surak. Or one of the other sockpuppets.
    • There are already plans to include PVM interpreter in Firefox which means it will be available as a viable target for scriping dynamic html pages for all of its derivatives like Camino, Galeon and Konqueror.
      Just a quick note: Konqeror does not use jecko, the HTML rendering engline ff uses, but KHTML.
    • by jo42 (227475)

      That reads like marketing pablum...

  • by Red Flayer (890720) on Monday June 23, 2008 @07:06PM (#23910719) Journal

    As for Internet Explorer, Eich explains how Screaming Monkey will help bring JavaScript 2 to IE should Microsoft drag its heels on providing meaningful support.
    Maybe it's just me, but I'm curious why he would name it "Screaming Monkey". I could see maybe an allusion to speed ("screaming" is sometimes a term used to describe something going really, really fast so s/Grease/Screaming makes sense, I guess).

    But really I think it shows the understanding Eich has for the thousands of codemonkeys hammering away at JS for IE. I'd be screaming too if I was coding JS for IE.

    On the other hand, I've had the (dis)pleasure of a rollicking night of Victory Golden Monkey followed by a visit from the Beer Monkey [urbandictionary.com]. Waiting for MS to make IE support JS2 might cause an additional night or two like that.

    FWIW, the Beer Monkey usually howls, rather than screams. YMMV... depending on the quantity of Golden Monkeys consumed.
  • synergy with html 5 (Score:5, Interesting)

    by bcrowell (177657) on Monday June 23, 2008 @07:19PM (#23910811) Homepage

    IMO the changes proposed for js 2 aren't very exciting. The biggest problems with js aren't really problems with the language design, they're problems with the lack of standardization in the interface to the browser. I don't see the burning need to make js more oo, more statically typed, or more like java.

    What I think really will be cool is the synergy between js and html 5. Html 5 has lots of good features for doing web apps, including audio, persistent storage, and graphics (canvas, inline svg without xhtml). Most of this is stuff you could have done before using java applets or flash, but now you'll be able to do them using a w3c standard that the vast majority of users will probably end up actually having supported in their browsers.

    • by Actually, I do RTFA (1058596) on Monday June 23, 2008 @09:22PM (#23911811)

      flash, but now you'll be able to do them using a w3c standard that the vast majority of users will probably end up actually having supported in their browsers.

      It may not by a w3c standard, but I'd rather use Flash. The vast majority of end users already have it downloaded, and it really is uniform across browsers/OSes, unlike w3c standards. At least I don't need 5 browsers and 2 boxes to test all the significant combinations.

      Also, thanks to Adobe (probably the only think worth thanking them for) protecting the Flash name, Microsoft cannot do the embrace/extend/extinguish path on the name. HTML, JS, CSS, Microsoft was able to invent alternates for all these w3c standards. Even Java with J++. Not so with Flash.

      So I guess my point is, I'm willing to bet on greater market penetration of Flash, then of w3c compliant browsers.

      • by mkcmkc (197982) on Tuesday June 24, 2008 @12:41AM (#23912965)

        It may not by a w3c standard, but I'd rather use Flash. The vast majority of end users already have it downloaded, and it really is uniform across browsers/OSes, unlike w3c standards. At least I don't need 5 browsers and 2 boxes to test all the significant combinations.
        Well, you don't have to test to be sure that your Flash app probably won't run correctly under Linux, or for users who care about security (and will thus disable it), or for users who've given up after be pummelled with Flash ads, or on platforms that Flash doesn't support.

        Javascript sure has it's problems, but at least their is FLOSS code with which to fix them. With Flash, Adobe can pull the rug out from under you any time they like, as they did with their SVG plugin.

        • by gaspyy (514539)

          Ah, you're so out of time...
          Adobe has Open sourced the SWF file format, the Flex framework (for building .net-style flash apps) and donated the Tamarin (look it up) project to Mozilla. I'd say your worries are unfounded.

          Also, pull the plug on flash? One of their crown jewel? The plugin present on 98% of all computers? You got to be joking. They pulled the plug on SVG because no one wanted it. At the time, Adobe tried SVG as a possible competition to Macromedia (the owners of Flash); in the end, they figured

          • by GeckoX (259575)

            Do you really think we don't know what Flash is capable of?
            This is /., open standards will be chosen above closed technologies every time. Further, Flash has been abused extensively, leaving a bad taste in the mouth for many. 98%? Totally pulled that out of your ass. I can find no data to back that up anywhere, none. Accessibility? Pathetic with Flash.

            Flash has it's uses. Flash will still exist in a JS2/HTML5 world. However, Flash will not supplant these, despite your desire for it to do so.

            I would be shock

          • by jonasj (538692)

            Adobe has Open sourced the SWF file format, the Flex framework (for building .net-style flash apps) and donated the Tamarin (look it up) project to Mozilla. I'd say your worries are unfounded.

            I'm sorry, but I don't think you know what you're talking about.

            They released _some_ documentation for the SWF file format (to say they "open sourced" it is nonsense), but that document were missing large portions necessary to implement the file format, and the information that they did release contained practically nothing that the free software community hadn't already reversed engineered, and the license agreement for their Flash player still contains anti-reverse engineering clauses which obstruct free

        • Well, you don't have to test to be sure that your Flash app probably won't run correctly under Linux, or for users who care about security (and will thus disable it), or for users who've given up after be pummelled with Flash ads, or on platforms that Flash doesn't support.

          Nice way to say "slashdot subscribers" many different ways, so the group can be counted multiple times. Fact is, Flash has something like a 98% install rate. Compare that to the penetration of browsers that can complete the Acid2 test.

    • The burning need comes once you move out of the hello workd and 5 liner domain into real systems design... Sorry to say that...
    • by famebait (450028)

      The biggest problems with js aren't really problems with the language design, they're problems with the lack of standardization in the interface to the browser.

      Not so. It is a problem you run into sooner, certainly, but it can be remedied with libraries, as all the ajax libraries do. The fundamental language design problems, however, are inevitable every time your code grows into a large system with several authors.

      Granted, the need for libraries means your system _does_ grow into that state sooner than strictly necessary, but it's still only a difference in degree. You really do need good support complex systems and multiple libraries.

  • HotRuby (Score:5, Informative)

    by DragonWriter (970822) on Monday June 23, 2008 @07:38PM (#23910995)

    Eich says: "Some of these techniques, like HotRuby, actually translate Ruby into JavaScript."

    HotRuby implements, in JavaScript, a VM that executes Ruby 1.9 bytecode; it does not translate Ruby into JavaScript.

  • JS 2 in FF3.1? (Score:4, Informative)

    by DragonWriter (970822) on Monday June 23, 2008 @07:42PM (#23911025)

    Eich does not expect Firefox support for JavaScript 2 until at least Version 3.1 of the browser.

    That's kind of misleading: What he actually says (from TFA) is "They won't be in Firefox 3. They won't be in probably the 3.1 that we've talked about doing, but they might be in our [nightly] builds, our trunk builds. It'll be like a draft version of the spec, so we might call it JavaScript 1.9 or 1.99. We don't want to get people to confuse it with what becomes the final spec, but we have to be able to test it with real programmers and get usability feedback."

  • by Chris_Jefferson (581445) on Monday June 23, 2008 @07:42PM (#23911037) Homepage
    I really like javascript as a language, independant of webapps. When I recently wanted to embed a scripting language in a C++ program I work on, I seriously considered javascript, as I thought more people would know it than lua and python. There does not however seem to be an easy way to embed javascript in an arbitrary program. Is there some reason it isn't suitable for this kind of thing, or is it just the browser writers embed the javascript too deeply?
    • by Shados (741919)

      Dunno... in Windows there's a billion way to do it, from the Windows Script Host for anything able to use COM components, to CodeDom for managed (.NET) environments, and a bunch of third party solutions.

      Dunno about the *nix world, however.

    • Re: (Score:3, Interesting)

      by larry bagina (561269)
      It's fairly trivial to embed WebScript/kjs. It's not terribly difficult to embed the mozilla/spider monkey interpreter either. It comes with a command-line javascript shell.
    • by JebusIsLord (566856) on Monday June 23, 2008 @09:00PM (#23911663) Homepage

      I've not had a lot of experience with JavaScript, but the whole concept of writing a large application in a prototype-based language seems daunting to me. Probably because I always start with an object diagram, translate that to a class diagram, and then write the classes. What sort of code diagram would you use to describe the high-level object interactions in a javascript app? How does the source code get broken up? (I tend to use 1 file per class).

      • by mollymoo (202721)

        You do pretty much the same thing. It's really not very different, just imagine the class definition and constructor being rolled into one.

        You break up the source code however you like, but you often get many classes in one file because a) JavaScript apps and thus classes tend to be smaller than those in C++ or Java and b) you're usually loading it over HTTP so keeping the number of requests down helps. You can fetch new code and add things (eg. new methods) to objects and "classes" of objects at runtime, w

    • by Chris Burkhardt (613953) <Chris@MrEtc.net> on Monday June 23, 2008 @10:40PM (#23912193) Homepage

      Many of these would probably suit you: List of ECMAScript Engines [wikipedia.org].

      Some helpful documentation:
      How to embed SpiderMonkey in your C/C++ program [mozilla.org] (try Rhino [mozilla.org] for Java apps).

      Although in my opinion Lua is so similar to JavaScript in all the right ways, and is so easily embedded, that it might be a better choice anyway.

    • Re: (Score:3, Interesting)

      by Hank Scorpio (137966)
      I'd recommend checking out the latest version of Qt. (4.4.0 was recently released, and now even includes a WebKit widget.) As of version 4.1, I think, it includes a module called QtScript which is a full JavaScript interpreter that can integrate very easily with your C++ code. You don't have to have a GUI to use Qt -- it is split into several libraries and you can easily omit the GUI libraries, and just use QtScript, if you'd like. Plus it has an excellent API that is a real pleasure to work with. Not
  • Bright future (Score:4, Interesting)

    by steveha (103154) on Monday June 23, 2008 @07:48PM (#23911091) Homepage

    Here's an overview of ECMAScript 4, the new version of JavaScript:

    http://www.ecmascript.org/es4/spec/overview.pdf [ecmascript.org]

    It sure looks to me like they are taking all the coolest stuff from Python and grafting it onto JavaScript.[1] The result will be a language a lot like Python, but with code blocks wrapped in curly braces and no significant whitespace.

    One of the biggest changes will be a class inheritance model much more like Python's. The prototype-based inheritance will still be available, but I for one will be happy to use the new model.

    Already, my favorite features from Python have been grafted on to JavaScript, and are available right now in Firefox 2:

    http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 [mozilla.org]

    Steve Yegge [blogspot.com] has said that he thinks he knows what the "Next Big Language" [blogspot.com] will be. I think he is talking about JavaScript, and I think he may be right.

    steveha

    [1] If you are a fan of some other language, it may look to you like they are grabbing cool things from your language. And far be it from me to argue about which language a feature was "really" borrowed from. Python borrowed much of its cool features from other languages anyway.

    • by quanticle (843097)

      I think he is talking about JavaScript, and I think he may be right.

      Doubt it, and here's why. In the eleventh paragraph, he mentions this:

      JavaScript had Netscape, Sun, and Microsoft (among others).

      This, of course, means that JavaScript is already a big language in his eyes, therefore, it cannot be the next big language.

    • The result will be a language a lot like Python, but with code blocks wrapped in curly braces and no significant whitespace.

      Python's whitespace situation is arguably no different than Javascript's. That is, you need to begin each line with whitespace that shows the indentation of the block in question. If you don't, your code is crap. Python goes a little farther and requires that your code not be crappy in this way.

      Also, non-leading whitespace is not significant in Python.

      • by mkcmkc (197982)
        P.S. It's worth noting that trailing whitespace in Javascript may be significant. In particular, under some circumstances, a trailing end-of-line will be treated as if it were a semi-colon...
    • Here's an overview of ECMAScript 4, the new version of JavaScript:

      http://www.ecmascript.org/es4/spec/overview.pdf [ecmascript.org]

      It sure looks to me like they are taking all the coolest stuff from Python and grafting it onto JavaScript.[1] The result will be a language a lot like Python, but with code blocks wrapped in curly braces and no significant whitespace.

      One of the biggest changes will be a class inheritance model much more like Python's. The prototype-based inheritance will still be available, but I for one will be happy to use the new model.

      Already, my favorite features from Python have been grafted on to JavaScript, and are available right now in Firefox 2:

      http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 [mozilla.org]

      Steve Yegge [blogspot.com] has said that he thinks he knows what the "Next Big Language" [blogspot.com] will be. I think he is talking about JavaScript, and I think he may be right.

      steveha

      [1] If you are a fan of some other language, it may look to you like they are grabbing cool things from your language. And far be it from me to argue about which language a feature was "really" borrowed from. Python borrowed much of its cool features from other languages anyway.

      Actually having real inheritance and still have the access to the virtual method table was there way before python, I dont think python has a single feature which was not copied from other languages. Even the code block feature which most non python users hate (and therefore not touch the language) was there before one way or the other. Not sure if there is even one feature which was invented by Python. Maybe one the language fanboys in public forums promoting their language... Ah no that was invented by t

  • Google Web Toolkit? (Score:5, Interesting)

    by TheNarrator (200498) on Monday June 23, 2008 @07:52PM (#23911111)

    I can't believe nobody brought up GWT (http://code.google.com/webtoolkit/) yet.

    GWT is a system put out by Google whereby you write your code in a subset of Java and then it compiles the Java down to cross-browser compatible speed and size optimized Javascript.

    The implementation of Java is pretty good and includes just about everything you would expect except for threads. It's absolutely effortless to program in compared to hand coded Javascript -- especially for large projects.

    The other benefit is "hosted mode" whereby you run your webapp in a special runtime that lets one use Eclipse's modern interactive debugger to fix bugs in the Java code that gets turned into equivalent Javascript.

    If you want to see a neat demo of what can be done with GWT check out :

    http://www.gpokr.com/ [gpokr.com]

  • ECMAScript 3.1 (Score:3, Interesting)

    by MrMunkey (1039894) on Monday June 23, 2008 @11:13PM (#23912407) Homepage
    Eich talked about some reasons for the 3.1 update to the language. Based on what I've heard from both Doug Crockford and Chris Wilson is that it would be a good idea to fix some of the really big issues in the current version of the language before throwing a new OO model and type system on top of it. It's best to build on a good foundation. There are also concerns about making the engine slower, but I'm waiting to see benchmarks before making my judgement. Personally I like the programming model of JavaScript as it is, but I'm a minimalist when it comes to code.

Mommy, what happens to your files when you die?

Working...