back to article Mozilla slips SpiderMonkey into Dev Platform of the Future™

Mozilla is building its own version of Node.js – the increasingly popular open source platform for coding server-side applications with JavaScript – moving Node from Google's V8 JavaScript engine to its own SpiderMonkey engine. "We think V8 is great and the fact that Node has become so widely used is a testament to that. But …


This topic is closed for new posts.
  1. Patrick O'Reilly


    I wonder how long it will be until Opera get in on this game. They already have a javascript based server in Unite, so implementing the Node.js API shouldn't be too hard and Presto is lighting fast.

    1. OffBeatMammal

      the fat lady doesn't need to sing

      Opera need to focus on their core browser a heck of a lot more, and not go running off after random science projects.

      with 1% market share and some annoying little bugs hindering adoption and hurting developers (eg for a standards compliant browser they are one of only two - safari is the other - who don't currently support the window.onerror ... as there is a fix checked into WebKit it looks like Safari will get it soon)

  2. Anonymous Coward

    Keep in mind

    That Google heavily funds Mozilla with their search agreement (which is coming to end this year btw, any news on a renewal)

    In the past years this has been steadily over $50 million/year.

    I'm quite sure that buys Google some influence in Mozilla's actions...

  3. Wile E. Veteran

    Whooda thunk it?

    Event-driven code that doesn't wait on one step's completion before processing another.

    I was doing interrupt-driven real-time code in factory-floor applications in the EARLY 1970's and I'm sure it was old hat to the giant telcos long before I took it up. I even used the techniques to make EFFECTIVE user front ends in Visual Basic 1,0 (company's choice, not mine) that never, ever got data inserts AFU with missing fields but were pleasant to use in the process.

    What goes around, comes around and there are a very limited number of paradigms in computing/data processing although there are a near-infinite number of ways to implement them (and mostly f**k them up.

    A nice (but older) tool for generating event-driven programs is "ibero" from imatix corp. Heavier duty tools are available as well..

    Usual disclaimer about only being a satisfied customer applies.

    I'll get my coat, it's still petty cold for us old guys.

  4. Annakan

    It is great to see the worse most unfinished and rushed out langage

    be pushed were he should never even have been considered.

    Javascript is, in its current state, one of the worst langage to do serious development, no packages or modules , poor typing, no namespaces, no threading support, entire langage constructs you should NOT use (for in ..) and such, it is just a rushed out langage that happened to be the only solution to a non existent problem.

    I fully know of all the "function and prototypes" trickery that have been invented to makeshift the missing functionalities, but those ARE hacks. And the fact that everybody has to re-invent them is a sure proof that it should have been in the langage at first.

    All those energies should be dedicated to build a decent modern virtual machine allowing us to use ANY langage we want inside the browser, and with decent development tools.

    But, hey, it is more man hours trowed at debugging bugs that should never have bee there in the first place or building libraries to do what is standard in pretty much every langage designed in the last 20 years ... more money creating false value, and more time lost, project late and such...

    Awesome rationality.

    1. peter 5 Silver badge

      C++ -> javascript

      I've just been exploring whether we should move our C++ app to javascript, and I don't buy your argument. You're right about libraries. And I miss static typing available when a parameter can only ever be an int; but that's the paradigm. Namespaces are there via '.' Debugging is no worse than C++. It *is* irritating to have to do overloading by hand, and even more irritating to have to write 'this' everywhere. But set that against all the issues of building a cross platform C++ GUI app, and I know my recommendation.

      1. OffBeatMammal

        welcome your HTML5 overlords

        with the coming revolution all native apps will be swept away leaving all client UI development (and in many cases entire app development) in javascript in the browser sandbox

        C++, C# and VB will become the new COBOL and we'll all miss them

        Actually, C and C++ might stick around a little longer as someone has to write device drivers ;)

        of course the wrinkle here is things like NaCL (Chrome native run-time) that give the sandbox an injection of C++ but it's a browser specific kludge...

        1. W. Keith Wingate

          So java is already dead then?

          Will the last java guy out the door please remember to do the garbage collection? Oh, and don't forget to tell these guys:

This topic is closed for new posts.

Other stories you might like