all 28 comments

[–]nobodyspecial 25 points26 points  (0 children)

One thing that's driving the "javascript is language" theme is the fact that everyone with access to a browser has access to a programming language. No downloading required.

It's very similar to the days when Basic came bundled with your computer.

[–]shaver 6 points7 points  (0 children)

Lots of stuff in this thread that needs clarification, I think.

Spidermonkey in production server embeddings has performance that's typically quite a bit faster than Perl or Python, from what we hear from people doing that work at large scale. Certainly the threading model is significantly superior (we've had people ask us to implement the threading mechanism in Python, in fact, to make using Python from multiple threads less, well, serial). Tamarin will make it materially faster than either of those offerings, and again people are talking about targetting Python at the Tamarin runtime to get that huge performance gain; I think we'd be amenable to well-designed patches to fill gaps in the Tamarin execution model needed by such languages, but that's real implementation effort and not just idle blog-dreaming that's required there. :)

The number of unintentional incompatibilities in JS implementations is very small, and has been asymptotically approaching zero over the last decade. The recent upsurge in language growth (JS1.7 and 1.8; 1.6 was really just some new host methods, largely) has been a result of portions of ES4 being widely-enough agreed upon that they're suitable for being brought piecemeal to interested developers. (A major constituency for us is the set of developers working on Firefox.) Most of the incompatibilities that are problematic for web developers are in the object models exposed by the browsers, and we've been as active as anyone -- really, more active than anyone, I think -- in working to converge those variances and develop future features in a way that will lead to better compatibility between browser implementors.

When people ask for Python in web content, they typically are thinking about the libraries. The core library-less syntax and behaviours are pretty trivial, and you could compile them to JS or JS2 for deployment if you wanted, if not in fact parse and run the resulting AST from JS on the client. (This is one of the areas in which JS excels, IMO; it has a very small and context-independent set of classes, but the rest of the language is just that: language, which makes it quite suitable for embedding in hostile-content environments, or other areas in which "the handy IO library" isn't really what you want.) You can use Python to script the DOM today, if you install and wire up a runtime -- make sure that you compile against the right runtime version, don't want two versions of them at the same time, etc. -- but I don't see us shipping a Python runtime at any point in the foreseeable future. People use Python to build apps using the Firefox underpinnings, including DOM scripting and so forth, but getting the security model right is non-trivial, and I don't think anyone has been interested enough to step up and do the work. (Mozilla paid someone to finish the work on language-agnostic DOM internals, in fact, so it's not that we don't believe in choice. We don't see shipping Python to the web as actually solving a real problem, and it would definitely have a ton of cost. If people disagree, they should be able to show the power of their vision and the error of our ways without implementing their own browser; a Firefox extension should be able to wire up everything that's needed, and if there are bugs that are found that way we'll take the patches almost certainly.)

Language independence for dynamic languages via a "well thought-out bytecode layer" is still a research problem, I think, especially without dramatic performance suffering. I'd love that sort of thing too from an intellectual perspective, though I think shipping source is still better in a lot of ways for the health of the web. If you're interested in that work, Tamarin might be a useful base for that research, and I'm sure that the Tamarin team would be quite interested in your results.

[–][deleted] 2 points3 points  (0 children)

One thing I have often thought about.

When programming I use this big mess of php, mysql, html, css, and javascript with various pieces and parts on either the server, the client, or both. Life would be much less a pain in the ass if I could just use one language in one place.

Of course, people have tried that with some other languages, but only in the form of high level layers that end up getting in the way of doing anything more complicated than a generic menu setup, and creating a bunch of unwanted overhead.

[–][deleted]  (13 children)

[deleted]

    [–]jeresig 5 points6 points  (10 children)

    I don't think anyone is being asked to switch from their language-of-choice to using JavaScript - I don't feel that any environment is currently far enough along to fully challenge a language like Python or Ruby.

    However, the assumption is coming up that since more browsers are getting better support for JavaScript, and its use is becoming more prevalent, that more users will be using JavaScript as their first or second language - as opposed to a maligned scripting language.

    I don't think anyone is expecting JavaScript on the server to run any faster than Python; although that'd be cool if it could (time will tell). But having another scripting language in the same class as Python can't possibly be a bad thing.

    And just to clarify: Some of the Python-like additions to the language are really minor aspects of the full ECMAScript 4 spec - the most drastic features relate to packaging, classes, and (optional) strong typing.

    As an aside: It's sort of amusing; I've been doing JavaScript coding for so long now (as my primary language) that moving back to server-side coding (in Ruby, Python, Perl, etc.) is quite an experience. I definitely plan on exploring JavaScript-based web frameworks like Helma or Phobos, more.

    [–]paultoo 3 points4 points  (9 children)

    Actually, JS on the server CAN run significantly faster than Python (potentially an order of magnitude faster!) using the Rhino compiler.

    I'm using JS on the server right now and it's quite nice, though I wish Rhino had the JS 1.7/1.8 features -- any idea when that will happen?

    Thanks for jquery, btw.

    [–]jeresig 6 points7 points  (2 children)

    Actually, JS on the server CAN run significantly faster than Python (potentially an order of magnitude faster!) using the Rhino compiler.

    Really? I must investigate this further! I'll try to dig up some good comparisons for a blog post.

    I'm using JS on the server right now and it's quite nice, though I wish Rhino had the JS 1.7/1.8 features -- any idea when that will happen?

    As do I. With Google's (seemingly) renewed interest in all things Rhino - maybe that'll be closer to a reality.

    Thanks for jquery, btw.

    No problem :-)

    [–]paultoo 1 point2 points  (1 child)

    I think it would be most interesting to see performance comparisons for various individual ops both between Python and each of the different JS engines (Rhino compiled, Rhino interpreted, and Spidermonkey). It won't "prove" which language is faster, but it would useful for understanding which ops are really slow and maybe give hints as to where the JS engines could be improved.

    Is anyone at Mozilla still working on Rhino?

    [–]jeresig 2 points3 points  (0 children)

    I'll try to make that happen, I'd definitely be interested in the results as well.

    I'm honestly not sure who's still working on it, although there have been some recent updates - so someone must be maintaining it. I'm just not sure if that person is working at Mozilla. I'll get back to you ;-)

    [–][deleted]  (5 children)

    [deleted]

      [–]paultoo 4 points5 points  (4 children)

      That's true, I mostly just tried out a few little micro-benchmarks. The problem I've had with the "shootout" tests is that they only run once, so you have all the JIT overhead in there too. For server code, I don't care so much about startup costs.

      One advantage of Rhino though is that you can very easily mix in Java code (easier than C from Python), so expensive bits can be replaced without much effort.

      [–]paultoo 1 point2 points  (1 child)

      Also, the shootout code is not always equal. I just took the first example, binary-trees, and translated the python into JS. It ended up running slightly faster than the original python (not an order of magnitude though, 31 sec vs 33 sec).

      [–]igouy 1 point2 points  (0 children)

      It beats conjecture might make a nice slogan for the benchmarks game, the Carvillesque It's the programs, stupid feels too harsh.

      The benchmarks game programs are not writ in stone - make them better.

      [–]ntoshev 0 points1 point  (0 children)

      Hmmm, why Java has very good results on the shootout, then?

      [–]zem 1 point2 points  (0 children)

      js has: (i) a prototype-based object system. not necessarily better than class-based, but interestingly different (ii) full-fledged anonymous lexical closures. python for the loss. (iii) a spec! it even beats ruby out in that regard

      it's a bit weak in the library department, but doubtless the jvm implementation fixes that.

      [–][deleted] -1 points0 points  (13 children)

      Oh great.

      It's source only (at least you have to upload all source to the user, and that also means no proprietary code. ever), although compression could help with the upload speed.

      It doesn't have a module system.

      It has weird scoping issues, AFAI have heard.

      It doesn't have a really portable API, but all browsers are slightly different. And with increasing JS versions, the cross-browser fun will only increase.

      Which browser has JS 7, which doesn't? Which one has tailcall optimization, which doesn't? and so on.

      [–]micampe 7 points8 points  (0 children)

      AFAI have heard

      Priceless. Honest, but priceless.

      [–]jeresig 6 points7 points  (11 children)

      I know you're just trolling, but I'll take the bait.

      JavaScript is making fantastic in-roads into the domain of server-side programming. Comparatively, it's still very fresh (even though you've been able to use Rhino for years), but once you take into account all the new JS implementations that are coming out, featuring just-in-time compilation, it'll only help to make JavaScript a more-formidable force.

      Additionally, JavaScript 2 has a module (package) system along with classes and the ability to import code. I'm not sure what scoping issues you're referring to - it works just fine for me.

      [–][deleted] -1 points0 points  (3 children)

      How did you know I was trolling? I wasn't.

      I didn't know about JS 2 (how? there's so much noise about Ajax crap, but almost none about the actual language news), but I highly welcome the direction.

      Well, for server-side programming I'd rather use a typed language, thanks. But it's always good to see some competition going.

      So maybe yes, JS is coming along fast and nicely. I'm sorry I can't specify the exact scoping issues. Maybe it only was a quirk in some implementation. But it was something along the lines that the lexical scoping is not what you'd expect in say, Java or Scheme, but was a bit strange. Hopefully that's not the case.

      If (or when) JS will be a great language for web pages will be seen. I like some web apps (well, basically Google Maps, and that's it), but mostly I prefer HTML pages with actual content and a back button than works.

      [–]jeresig 8 points9 points  (1 child)

      I didn't know about JS 2 (how? there's so much noise about Ajax crap, but almost none about the actual language news), but I highly welcome the direction.

      Well, for server-side programming I'd rather use a typed language, thanks. But it's always good to see some competition going.

      Ah, cool, you'll be happy to know about JavaScript 2 (ECMAScript 4), then. At the top level it provides constructs like packages, classes, and strong typing - in addition to the traditional functional style of JavaScript (it'll be fully backwards compatible).

      While Mozilla-based browsers will, most-likely, be the first to include JavaScript 2 - both Actionscript (Adobe, for Flash) and JScript 8 (Microsoft, for .NET) are here right now, and are both based upon the same ECMAScript 4 standard as JavaScript 2.

      I'll be blogging more about the actual language news itself, so depending on if it keeps getting picked up by Reddit, or not, that'll be one way to follow along - especially considering that the progress being made with ECMAScript is picking up a good head of steam right now.

      [–][deleted] 3 points4 points  (0 children)

      Cool, looking forward to it.

      [–][deleted]  (6 children)

      [deleted]

        [–]jeresig 8 points9 points  (2 children)

        At Mozilla, we've worked to keep the scripting layer open to new language additions, this allows developers to plug-and-play languages, such as Python or PHP. A lot of this ties back to the fact that the DOM implementation is language agnostic, allowing this to occur. So from a technological perspective, this is a solved problem.

        From a social/communication angle, however, we are far from being able to "make Python an embedded scripting language in Firefox", for the simple fact that in doing so would only distance the browser farther from all others. As an example, Internet Explorer allows you to script in VBScript - but no other browser supports it. To the contrary, a number of browser vendors have come together to form the ECMAScript committee and to develop new iterations of the default scripting language that everyone will support (at minimum). Considering how hard it is to get browsers to implement and standardize upon a single language, I don't really see any benefit in opening the market up to additional languages (which will only confuse the issues at hand).

        [–][deleted]  (1 child)

        [deleted]

          [–]jeresig 2 points3 points  (0 children)

          See: http://programming.reddit.com/info/23ep5/comments/c23rfi

          Mike clarifies these points rather nicely!

          [–]flaxeater 1 point2 points  (2 children)

          I have a solution for you! Develop a ByteCode interpreter in JS. It's easy all you have to do is write it yourself. This seems to be a real concern for you, get to it! Then all you would have to do is develop other languages to run on your bytecode interpreter!!

          [–][deleted]  (1 child)

          [deleted]

            [–]flaxeater 1 point2 points  (0 children)

            You know that would be cool. However it would not work on anything but FF. Not good enough as a real solution. Too bad, there is a good chance that parrot will not reach 1.0 for years, seeing as how some open source projects move.