As a member of the Opa team, I can think of at least three problems that Opa solves for you compared to Node.js frameworks.
1) Asynchronous (a.k.a. event driven) programming.
Lightweight threads are a very efficient paradigm but dealing with callbacks manually is cumbersome and is sometimes very difficult to get right. (Exercise: try to code a solver for the "Tower of Hanoi" in Node.js that is really non blocking :-))
The Opa compiler cuts your code into chunks and makes it non-blocking by managing all the callbacks for you. (Technically, Opa compiles functions using a continuation-passing style.)
2) Consistency between code and data (using static types).
Opa features a static type checker with (almost complete) type inference. Programmers can also declare typed MongoDB collections and build typesafe DB queries in the Opa syntax. In the end, consistency between code and data is statically ensured in the entire application (client code, server code, and database queries).
Needless to say, there exist no such things as script code or database code injections in Opa programs :)
3) Transparent protection against XSS attacks.
Most frameworks are based on a templating system that sees XHTML values as a "flat string with holes". In this setup, the problem of choosing the right escaping function at insertion points is called "context sensitivity" and is generally considered very difficult to solve without hints from the programmer.
In Opa (as in Scala) XHTML and XML values are first class tree-based data structures. Inserting a string into a XHTML value will generate an automatic typecast and trigger the proper escaping function by default in a very predictable way.
In the end, I believe that Opa has the potential to be for V8+NodeJS what Scala+(Lift or Play) are to the JVM -- Opa being at the same time arguably simpler to use.
1) Asynchronous (a.k.a. event driven) programming. Lightweight threads are a very efficient paradigm but dealing with callbacks manually is cumbersome and is sometimes very difficult to get right. (Exercise: try to code a solver for the "Tower of Hanoi" in Node.js that is really non blocking :-))
The Opa compiler cuts your code into chunks and makes it non-blocking by managing all the callbacks for you. (Technically, Opa compiles functions using a continuation-passing style.)
2) Consistency between code and data (using static types). Opa features a static type checker with (almost complete) type inference. Programmers can also declare typed MongoDB collections and build typesafe DB queries in the Opa syntax. In the end, consistency between code and data is statically ensured in the entire application (client code, server code, and database queries).
Needless to say, there exist no such things as script code or database code injections in Opa programs :)
3) Transparent protection against XSS attacks. Most frameworks are based on a templating system that sees XHTML values as a "flat string with holes". In this setup, the problem of choosing the right escaping function at insertion points is called "context sensitivity" and is generally considered very difficult to solve without hints from the programmer. In Opa (as in Scala) XHTML and XML values are first class tree-based data structures. Inserting a string into a XHTML value will generate an automatic typecast and trigger the proper escaping function by default in a very predictable way.
In the end, I believe that Opa has the potential to be for V8+NodeJS what Scala+(Lift or Play) are to the JVM -- Opa being at the same time arguably simpler to use.
How does this all sound to you?