Forgot your password?
typodupeerror
Programming IT

JavaScript Servers Compared 132

Posted by samzenpus
from the taking-them-for-a-spin dept.
snydeq writes "InfoWorld's Peter Wayner test-drives five leading JavaScript servers and finds the results compelling though still a work-in-progress. 'I enjoyed the challenge and stimulation of rethinking everything I know about the server, but I still found myself hesitant to push these new ideas too far or too fast. The speed of experimentation and development is heady and exciting to the open source crowd, but it will probably seem scary to corporate developers who like the long, stable lives of tools from Microsoft or Oracle. Some of these platforms will probably morph three or four times over the next few years, something that won't happen to the good, old JSP standard in the Java world,' Wayner writes in review of Node.js, Jaxer, EJScript, RingoJS, and AppengineJS."
This discussion has been archived. No new comments can be posted.

JavaScript Servers Compared

Comments Filter:
  • by Anonymous Coward on Wednesday May 25, 2011 @04:02PM (#36243186)
    Second post! Would've been first if slashdot had a faster javascript server.
  • Third post (Score:3, Funny)

    by Anonymous Coward on Wednesday May 25, 2011 @04:03PM (#36243196)

    Third post! Would've been first if slashdot had a faster javascript server.

  • First post! (Score:2, Funny)

    by Anonymous Coward

    First post! Good thing slashdot has a fast javascript server.

  • Burn the bible (Score:1, Interesting)

    by Anonymous Coward
  • Or, i dunno... maybe we could use JavaScript to add flexible dynamic scripting to our existing stable Java platforms? ...otherwise what's the point? To use a domain specific language for tasks it wasn't designed for or is very good at?

    Personally, I'd rather use a slow dynamic scripting language to glue the fast compiled language code together, (see: Perl), not write the whole damn server in slow JS.

    Hint: Just use Rino [mozilla.org] and be done with this nonsense.

    • To use a domain specific language for tasks it wasn't designed for or is very good at?

      JavaScript works very well as something it wasnt designed for every time you use GMail, Meebo or any other application that's running within the browser these days.

      • by omfgnosis (963606)

        Why wasn't it designed for those applications? It's a general purpose programming language. Perhaps the browser's APIs (DOM) weren't designed with those applications in mind, but even the first standardization of the DOM (DOM Level 1) APIs could implement most if not all of those applications' features, one way or another (eg. submitting forms to a frame—a feature introduced with JavaScript in Netscape 2—and periodically appending new scripts which contain server data).

        There's a lot of reasons t

      • by BitZtream (692029)

        uhm, thats pretty much EXACTLY what Javascript was intended for ... you do know where it came from ... right?

    • by bmuon (1814306)

      Personally, I'd rather use a slow dynamic scripting language to glue the fast compiled language code together, (see: Perl), not write the whole damn server in slow JS.

      That is the whole idea. Write processor intensive tasks in a fast compiled language (C or whatever) and glue them with a server that is good at handling asynchronous requests. That's what Node.js is about and JavaScript is actually a good fit for it because of closures.

    • by tixxit (1107127)
      Except that JavaScript, today, is not a slow dynamic scripting language. The latest JS engines in IE 9, FF 4, and Chrome are lightning fast. You'll be hard pressed to find a faster dynamically typed scripting language today. Honestly, if you want a fast, dynamically typed, interpreted scripting language, then look no further than JS. Also Rhino IS slow (compared to most other JS interpreters) and has been included with Java by default since Java 6.
      • The Javascript engines in browsers come nowhere close to the runtimes for the mainstream server-side platforms (J2EE, .NET, etc) in performance. It's not always orders of magnitude difference anymore, but one of those runtimes will still reliably be several times faster than the fastest JS engines.
        • Re: (Score:3, Interesting)

          by GreyLurk (35139)

          In terms of numerical computation? Probably. In terms of actual useful web applications, Node.js meets or beats compiled Java in the benchmarks that I've seen, even with the Java Code using esoteric and not commonly used behaviours like Non-Blocking IO: http://www.subbu.org/blog/2011/03/nodejs-vs-play-for-front-end-apps [subbu.org]

          V8 is actually really damn fast.

        • The bottleneck on a dynamic webserver is either network or SQL access times. It does not matter if you have the fastest web server software in assembly when it takes 1,000 ms to access a SQL query to display for a client's browser.

          Static it is a different story, but who besides a small mom pop page uses simply static pages anymore? So this is why Java took off a decade ago while slashdotters scratched their head wondering why could something so slow and slugish could ever scale. It is about SQL

      • by BitZtream (692029)

        Your definition of 'lightning fast' is my definition of 'painfully slow language' even in the new JS engines.

        • I assume you write all your web apps in machine code then?
          • by GreyLurk (35139)

            I prefer my webservers to run purely on ASICs. Sure, updating the web site is a little costly, but I can handle more traffic than Amazon.

        • by tixxit (1107127)
          I guess it wasn't obvious, but I was comparing JS to other dynamically typed scripting languages. I'm also talking in respect to tasks that scripting languages usually tackle. If JS is painfully slow for you, I'm just assuming you are using it for something you probably shouldn't be using ANY scripting language for.
      • Honestly, if you want a fast, dynamically typed, interpreted scripting language, then look no further than JS.

        Honestly? Well, honestly, the more code I write/debug in dynamically-typed interpreted languages, the more I like statically-typed compiled languages (and it has nothing to do with execution speed)

        • by tixxit (1107127)
          My favourite language, by far, is Scala, so don't think I don't know where you are coming from. And, honestly, my favourite dynamic language is Python, though I am using JS on occasion now.
  • by Kenz0r (900338) on Wednesday May 25, 2011 @04:15PM (#36243304) Homepage
    Read the print version of the article in one page:
    http://www.infoworld.com/print/161969 [infoworld.com]
  • by not already in use (972294) on Wednesday May 25, 2011 @04:23PM (#36243408)

    Remember when javascript had a terrible rep? Then people were all like, "No! It's totally awesome! It has first-class functions and prototypal inheritance!" Yeah, you remember. You read all the blogs. You had flashbacks to your not-so-pleasant encounters with javascript while developing client-side web applications. Then, all the sudden, prototypal inheritance became the in-thing, like popped collars. No matter how ugly or ridiculous it looked, you didn't want to be the only one who didn't think it was cool. You started writing gobs of hard to organize, impossible to refactor serverside javascript code. You convinced yourself, somehow, that you saved time by not having to issue some "compile" command. No, it just starts, DYNAMICALLY! What a cool word, dynamic -- like Ugg boots! And like wearing Ugg boots in the summertime, you tortured yourself searching for simple runtime errors. Static checking? Compiling? These are the things of white-collared enterprise folks.

    You are not a white collared enterprise guy. You are a renegade. With a popped-collar. And ugg boots.

    • by cyfer2000 (548592)
      Ever wrote something in Perl?
      • by vlm (69642)

        Ever wrote something in Perl?

        Even Perl, believe it or not, actually has Test::Unit, Test::Simple, Test::Harness, and about eighty zillion logging and debugging systems.

        Javascript, thats got... uh...

        • by timothyf (615594)

          Perl does not have Test::whatever. CPAN has it. And there's nothing preventing anyone from implementing test frameworks in JS. In fact there are already a number of them out there, jsUnit to name an example off the top of my head.

        • Uh... is got https://github.com/joyent/node/wiki/modules [github.com] and that is just for starters
        • Apparently you have never googled for javascript testing [google.com] There's quite a few organized testing and unit frameworks for javascript out there and there are even IDEs that have support for them, such as Intelij IDE [jetbrains.com] and its primarily php/web cousin, PHP Storm. I've use both of them on a regular basis and they both support NodeJS and have have built in javascript debugging/unit testing.
        • by Roachie (2180772)
          Firebug.
        • by Inda (580031)
          ...Microsoft Script Editor.

          You know, even being forced to use it wasn't so bad... for small jobs... in the corporate environment.

          That was about 8 years ago too.

          JS has tools.
      • by lennier (44736)

        Ever wrote something in Perl?

        Only once, and I took fifteen showers afterwards and still felt dirty.

      • by maraist (68387) *
        If you learn the syntax inside and out, perl has some of the most concise verbs I've ever used. 90% of the perl scripts I've written were 1 liners (where a line can exceed 200 characters).

        perl -ne 'chomp; (/start/ ... /end/) && $words{$_}++; END { print join "\n", map { "$_ : $words{$_}" } keys %words }' file.txt
        • If you learn the syntax inside and out, perl has some of the most concise verbs I've ever used. 90% of the perl scripts I've written were 1 liners (where a line can exceed 200 characters). perl -ne 'chomp; (/start/ ... /end/) && $words{$_}++; END { print join "\n", map { "$_ : $words{$_}" } keys %words }' file.txt

          200+ char perl one-liner scripts? That's software engineering for you. Hurray for debuggability and maintainability...

          • by maraist (68387) *
            Do you debug and maintain 'cd'ing directories? How about opening a log file with a text editor? How about debugging your excel file? Why not? Because the input and output are reproducable and they are one-time events. If I'm trying to ask the question - how many log files did this application just produce.. I can
            A) open up a stupid gui and manually count them (if I'm lucky, I can sort by extension - but good luck if they're spanning multiple directories)
            B) I can do a file-system search for *.log files,
    • by tixxit (1107127) on Wednesday May 25, 2011 @04:59PM (#36243844)

      Prototypical inheritance didn't make JS cool, and JS wasn't the reason we hated JS 10 years ago.

      The reason JS was hated so much 10 years ago was because of the DOM. That's it. Every browser had close enough implementations that you thought mucking about with the DOM would be simple... but they were different enough to cause endless headaches and hardcoded hacks to work around all sorts of quirks. Making a simple drop-down menu meant coding everything from scratch, maintaining essentially 3 different versions of the same code for different browsers.

      JS is cool today because of many things.

      The convergence of browser features and DOM implementations towards the standard. Coding JS to work cross browser has definitely gotten easier.

      The proliferation of browser libraries that abstract the browser away from us developers and handle all the little DOM implementation differences for us.

      There is a solid (and growing) set of best practices for client-side programming (eg. progressive enhancement, event-driven programming, etc.). This has dramatically cut down on the amount of time spent (re)writing JS and let's people create better abstractions that work well with JS.

      The functional aspect of JS is definitely nice, and allows for some very concise code (considering) to be written. However, it can also be eschewed for those that are not comfortable with functional programming.

      JS is SIMPLE. In the browser it is single threaded. You don't need to worry about concurrent programming. The language itself is also dead simple, but still very powerful if needed.

      However, I don't think people think prototypical inheritance is really all the grand. It's simple, is what it is and that fits well with JS (simple). When most the original crop of modern JS frameworks came out, the first order of business was to build a more traditional class-based inheritance approach. I know it doesn't fit well with your "renegade" theory, but it's true. People now seem to be getting comfortable with prototypical inheritance, but I don't think you'll find many people willing to extol its virtues.

      Also, JS has first class functions, yes, but so do LOTS of other languages. I'm not sure why you're picking on JS developers for liking some aspects of functional programming.

      • Uhh, I quite like how the module and 'require' patterns work in JS. <-- read: I am extolling their virtues. I am a big fan of quick and dirty object decoration as well (as long as you keep it in the closure). Webworkers do processing in other threads. And V8 has a whole debugging API.

        Never have been entirely sure why people are so quick to pee all over JS. After having done Perl, Python, C# and Actionscript for corporate production as well as private there are benefits to all of them (less so Actionscrip
        • People generally 'pee' over things when they don't understand them or can get their heads around thinking in different ways for different problems. After all single threaded has to worse than multi-threaded, right? I mean why would you want to use Javascript for the 'web', I mean it's not like it's suited... Oh wait. Anyway we should all be using languages that were solely designed for the web, like Java... Oh hang on...
        • by tixxit (1107127)

          I'm not sure what the "module" and "require" patterns have to do with prototypical inheritance. Ruby, Python, and Groovy (for example, there are many others) are all class based and allow metaprogramming and/or "monkey patching," so "dirty object decoration" is not a trait only found with JS.

          Web workers are very restricted. They run in a completely different scope and can merely pass messages to the main UI thread.

          I wasn't peeing on JS. I love Javascript. The only negative thing I mentioned was that prototy

      • You make several good points, I only take exception to one small part.

        JS is SIMPLE. In the browser it is single threaded. You don't need to worry about concurrent programming. The language itself is also dead simple, but still very powerful if needed.

        C (or most any other language) is single threaded too, and you don't have to worry about concurrent programming. That is, until a single thread just isn't good enough anymore and it's time to break out a threading library. Then you have to worry about concur

        • Yes- I agree with you on this. JS is simple but you should always be concerned with handling data asynchro- especially with JS where one frozen or busy thread will bring the whole thing to a halt. <Ballmer>Callbacks, callbacks, callbacks</Ballmer>

          And if anyone is up for some reading this series is pretty nice:
          http://howtonode.org/object-graphs

          As well as 'JavaScript: The Good Parts'- Douglass Crockford
        • by MobyDisk (75490)

          The key difference is that it is not even possible to spawn a thread in a browser. But you are right, that isn't a benefit.

          Single threaded is actually harder - you still have concurrency issues because even simple operations must be done using an asynch event pattern. Multithreading was created because simulating concurrency in a single-threaded app is hard.

        • by tixxit (1107127)
          The difference is that JS can appear to be multi-threaded. For instance, I can set a function to run after a set amount of time (setTimeout). In the browser, this function will be run in the same thread as all the other code and it will be atomic. The same goes for all the UI events and the like. If I wanted to set a timeout in C that would run a function after 1 seconds, while doing some other stuff in the mean time, threads would be what I'd grab for first. However, JS promises to be single threaded, so y
      • JS is SIMPLE.

        Hardly. JS is nuanced. Undefined vs null? == vs ===? Simple in the fact that it doesn't contain crazy "advanced" language constructs like namespaces or imports so you ultimately have to bastardize the ever-loving shit out of other language constructs to accomplish the same thing? Yes, it's simple in the sense that it will let you do almost anything and you will pull your hair out trying to figure out what the hell is going wrong.

        In the browser it is single threaded. You don't need to worry about concurrent programming.

        Well played, sir. Pretend that an inherent limitation is somehow a feature.

        • by tixxit (1107127)

          Hardly. JS is nuanced. Undefined vs null? == vs ===? Simple in the fact that it doesn't contain crazy "advanced" language constructs like namespaces or imports so you ultimately have to bastardize the ever-loving shit out of other language constructs to accomplish the same thing? Yes, it's simple in the sense that it will let you do almost anything and you will pull your hair out trying to figure out what the hell is going wrong.

          Undefined vs. null is nuanced? Hardly. And == vs. ===? Pretty much every language defines a difference between equivalence and object identity, whether its Python (== vs. is), Java (equals vs. ==), or Javascript (== vs. ===). What I meant by simple is that there aren't a whole lot of "extras" in the language. Every language is nuanced to the extent you are describing.

          Well played, sir. Pretend that an inherent limitation is somehow a feature. As if, if I were to choose another language, I would be forced to write multithreaded code.

          It's a design decision, there is no reason they couldn't have allowed threads. Also, it is a design decision that isn't always immediately app

      • by Raenex (947668)

        The reason JS was hated so much 10 years ago was because of the DOM. That's it.

        That's just a lie. The reason people hated it was stated by the parent you replied to. It had the appearance of a toy language if you were coming to it from a language like Java. That's why all the hipsters starting talking about prototype inheritance and first-class functions.

        They're right that those are cool features for a toy language, and you can bend JavaScript to do stuff to get around lacking features, but it's still not a good modern language.

        I don't see what JavaScript has for appeal on the server

      • Outside of the problems of not having namespaces and real inheritance (see my post above where the problems really are, and those are overlooked often from an academic point of view)
        I would not really call javascript that simple once you do bigger systems with it. Then you run into the typical sets of problems of purely dynamic languages that you have to work a lot over unit tests and you have to add a lot of parameter assertions to every function to avoid hidden pitfalls which are caused by no til weak typ

        • by tixxit (1107127)

          Clearly dynamic languages' biggest flaw is that they have no compile time type checking. However, since this is the big demarcation line between static & dynamic languages, I can't really fault dynamic languages here. As always, the right tool for the right job is the best credo for most professions.

          I'd suggest you take a look at Zope if you want to see a good example of a complex application developed in a dynamic language (Python). Zope is built on a rather nice component-oriented architecture which h

          • I have not been talking of not being able to build those systems in dynamic languages, i have done that myself but more along the lines of productivity per day and once you cross a certain loc barrier dynamic languages do not really have an advantage that much anymore.
            The creators of Zope probably would have gotten similar results in a strongly typed language in about the same amount of time.

            • by tixxit (1107127)
              What ifs are great; may be Zope corp could've created Zope in a statically typed language in the same amount of time. Maybe not. I honestly can't say. Zope, like most other well built systems (whether statically or dynamically typed), relies on the loose coupling of smaller, well developed, separate components. What Zope did well was their component oriented architecture. It makes integrating all the different components, and writing new ones, very easy. That said, they did this by building a stronger type
    • by JakeD409 (740143)
      That's a pretty wide net you're casting there. Feel the same way about Python? Ruby? Perl? PHP? Not saying you're wrong (I do think you're wrong, but that's a separate issue); just want to make sure that you have the same problem with all interpreted weakly-typed languages.
    • Heck I earn my living currently with javascript on professional framework level but I still think the language is not cool.
      Namely the lack of namespaces and the lack of real inheritance are my biggest problems.
      And before someone comes you can write those with maps and prototype inheritance just think of this:
      a) Maps are slower than real namespaces and to get a better performance you have to add lookup indices yourself and even then you are not even close to the real thing.

      b) Given that there is no real inhe

  • wow, how is JavaScript on the server side new?

    anyone remember the Netscape FastTrack server, and the LiveWire environment, where LiveScript was used to code both server & client side of a web application. LiveScript being of course the original name of JavaScript. this was back in 1996, merely 15 years ago...

    history seems to repeat itself...

    • We used to call it "SSJS" -- server-side Javascript. Times really have not changed, but why would you expect them to? Despite the superficial changes, the underlying structure of the Internet and the Web has not really changed. We have not really seen much in the way of "revolution" in the past 15 years, just incremental changes (or if you would prefer, "improvements") to the way everything works.
      • Or .jsp, which has been around for quite a long time.

      • really it's not changed. I'd think about that again? Where have you been?
        • I said the underlying structure has not changed much, but that there have been superficial changes. Can you please point out where the underlying structure of the Internet or the Web has undergone a significant change? When last I checked, we are still using IPv4 and we are still using HTTP, and we are still using a client-server model. This most significant change that I can think of is AJAX, and that is not a terribly significant change (it really just means that things people would have done in an app
          • Yes the underlying structure is much the same. But our paradigms have changed a lot. The early web was request response, with very little focus on the client at all. That's changed, there is now far more parity between what happens on the server and client. This is only going to increase. The point is this, if you have a common language (Javascript) that fits the web, very, very well and you have browser vendors implementing features in HTML5 that encourage distributed, real time apps. Together with improv
    • We do remember it. Probably because it was the first line of the article.

    • history seems to repeat itself...

      This [habreffect.ru].

      Don't worry - I'm pretty sure that, 10 years down the line, they'll be touting the addition of static typing to JavaScript as the next big thing to improve productivity etc.

    • Not really. 15 years is a long time in technology.
    • Yup mod parent up.

    • You could use JScript in ASP too. Thankfully I never had to.

      • by GreyLurk (35139)

        Ah,

        It meant I didn't have to bother learning VB in order to write ASP Pages, and it looked a lot closer to the PHP, C and Java I was used to writing.

  • "I'm increasingly convinced this asynchronous callback style of programming is too difficult for most developers to manage," Robinson said. "Without extreme discipline it can easily lead to 'callback hell,' with deeply nested callbacks and complex code to implement logic that would be simple on a synchronous platform." What's next for him? He sees the older framework being rethought and reworked using the best ideas from Node.js. In place of callbacks, he sees ideas like "promises," "co-routines," "actors," and other objects that hang on to the information in the variables for use later. These objects may be easier to juggle than the callbacks.

    Callbacks and promises are not mutually exclusive. In particular, a promise API can be built on top of callbacks. This has been well-understood for a long time in both the Ajax world (e.g. dojo.Deferred [dojotoolkit.org]), and in Node.js development (e.g. node-promise [github.com] module by Kris Zyp). So, I think this critique is a bit unwarranted.

    • Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version, with marker keywords to identify "points of asynchrony" (where the rest of the code path is an implicit continuation, and a closure is generated for it under the hood). Kinda like this [msdn.com] in the (yet upcoming) C# 5.0.

      Good thing i

      • by Animats (122034)

        Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version,

        There's a theoretical argument (presented by a speaker in EE380 at Stanford last spring, but I don't have the ref handy), that the call-with-continuation model is a superior way to deal with concurrent transactions compared to the lock-and-block model. With the call and continuation model, most of the programmer-confusing headaches of real concurrency go away. The amount of state per transaction is low, since you only save what you need. This reduces memory consumption.

        There's something to be said for th

        • There's a theoretical argument (presented by a speaker in EE380 at Stanford last spring, but I don't have the ref handy), that the call-with-continuation model is a superior way to deal with concurrent transactions compared to the lock-and-block model. With the call and continuation model, most of the programmer-confusing headaches of real concurrency go away. The amount of state per transaction is low, since you only save what you need. This reduces memory consumption.

          I thought that's an established wisdom by now? I mean, that's why most server-side frameworks are embracing the continuation model (and most of current JS-on-the-server hype is more about such frameworks, which just happen to be written in JS). You still have code running concurrently there, though - the point is to get it running into much smaller chunks, such that, as soon as one task blocks on something, the thread can be immediately reused for another task.

          It's more than just supporting high load, thoug

  • Too bad that chrome's V8 javascript engine does not support multithreading, thereby making itself unsuitable for server-side scripting.

    (Of course, you can run each script in a separate process, but that is way too expensive)

    • by Guspaz (556486)

      PHP doesn't properly support multithreading. It must also be unsuitable for server-side scripting. And because running each script in a separate process is way too expensive, nobody would ever try to use something like mpm_prefork or fastcgi to get around that limitation. That'd be silly.

  • It seems the author of the article knows little about how real servers use multithreading to reduce latency.

    From the article:

    Node.js is one good solution. It uses only one thread for your server and everything runs within it. When the requests come flying in, Node.js takes them one at a time and hands them to the single function that was specified when the server is invoked.

    Sadly, one of the best javascript engines is V8 (used in google chrome), and it does not support multithreading.

    • one of the supposed benefits of stateless monadic code is that it is somewhat more parallelizable than traditional imperative or stateful OO paradigms.
      Could 'clean' js be marked with annotations and magically threaded behind the scenes by the javascript runtime?

      (above is hearsay - i am not a functional programmer)

      • Nice idea, but although javascript is a functional language, it is not a pure functional language (it has side-effects). This probably makes that a lot more difficult.

  • I've been intrigued by this whole serverside js thing since i started doing a lot of flex and therefore using actionscript a lot.
    Callbacks are so cool :)

    But thing is js is still a mess if you have a lot of code.
    What we really need is server side actionscript to get proper OO syntax, strong typing and namespaces.

    If i ever got that, i'd be a happy camper !

    • by GreyLurk (35139)

      Adobe showed off a demo of this at MAX 2009, so I suspect that they're going to be pushing for it at some point in the near future. AS is annoying though, when you have to switch between AS and C# or Java, and muscle memory throws your type declarations into the wrong syntax.

    • Actually you can build namespaces in javascript not strong typing though, but even then it is still a mess. Namespaces and inheritance constructs cannot be picked up by documentation tools automatically you have to roll them into the doc tools you have at your disposal manually and if you roll this stuff in javascript yourself or via third party lib the performance will never be as good as the real thing.
      To my knowlege a prototype inheritance construct via call and prototype functions like you would get in

  • I'm about 8 years out of date on my web development, but can someone give me a quick rundown on the subject of the article vs. what I know as server side javascript, aka ASP classic?

  • ... optimized animated .gif server so ytmnd.com [ytmnd.com] could load 5GB loops faster.

FORTRAN is a good example of a language which is easier to parse using ad hoc techniques. -- D. Gries [What's good about it? Ed.]

Working...