in Uncategorized

Reflecting on Nodejs vs Play

My last post on Play vs Nodejs got a lot of traffic in the last 10 days, but it also opened a number of conversations. Here are the key comments.

  1. Did Nodejs beat Java?

    No way. As my post got retweeted, it was cast as Java winning on V8/Nodejs. That’s not the case. I have no data to make such a claim. Java has its strengths as well as legacy baggage to carry along with it. It would be irresponsible on my part to make such claims based on such a such a test, and I was clear about the conclusions I drew in my post.

  2. Is Groovy the culprit?

    Play uses Groovy as the expression language in templates and hence may have impacted performance of the Play based app. However, given that it was a design choice made by the Play framework to use Groovy for expressions in its out-of-the-box template engine, I think it is fair to use Play’s default template engine for testing.

  3. How about alternative templates?

    Assuming that Groovy is the culprit, how about other template languages like Japid or Mustache?

    Japid claims to be 2-20 times faster than Play’s bult in template engine. But I found several issues with Japid:

    • It is non-intuitive to use. The syntax is a bit arcane to my taste.
    • I did not like the template engine throwing exceptions about the generated Java source and not the HTML view. For a template engine to build HTML, HTML should be the basis for error reporting.
    • I managed to prevent the server from starting and it was not trivial to find out what caused the problem.

    Of course, these are subjective statements, and you may have a different take on Japid. These are also fixable, and as Japid evolves, I’m sure some of these will go away.

    I really wanted Mustache to do well, but however, it did not pass my two-hour test. I was unable to get it up and running in about two hours. I had prior experience with Mustache, but in this particular case, Mustache required some changes to the shape of the JSON data coming from the backend. This app requires some additional mutations to the data before rendering, and Play’s Java extensions made it trivial, but not Mustache. But this is fixable.

In the end, if I were to pick a Java stack for front-end development, I would go with Play over other Java alternatives.

Write a Comment

Comment

  1. Hi,

    The Japid author again. Thanks for taking a look at Japid.

    1. Japid takes two sets of syntax: Play-like and Razor-like (with the back quote syntax). Which one were you referring to? Do you have a specific syntax that goes against your taste? I do want to improve the syntax with user’s input.
    2. can be improved for sure. But Japid is also a generic template system that may be used out of HTML domain.

    3. As I commented on your previous blog, if you take a look at the generated Java code, usually any compile-time errors are easily spotted, as other users have attested, it’s faster to debug views that way.

    I have your sample running in Japid with the classic Play. It’s about 50% better the Play/Groovy system, but is still behind the node.js.

    Then I have Japid running with a customized version of Play now it’s 20% faster than node.js on the render only test. Node.js is a really nice piece of server software all I can say is with some customization and optimization, Play/Japid can match it in the specific performance benchmark.

    I’ll post the code once I have packaged it as a easy download.

  2. I think both Node and Play framework are the coolest things happening in the programming world right now.

    It would be nice with an updated test when the play scala module (with scala template) hits version 1.0.

  3. “In the end, if I were to pick a Java stack for front-end development, I would go with Play over other Java alternatives.”

    What about using play as a base for REST API? Would you use it as well? Without the need to use templating (just xml/json serialization) with nbI/O one could get all the advantages of PLAY architecture.