5 ms·

We already have this. Node.js. So I'm confused as to why we need another language which is like JS but not really, that compiles to Node (which it doesn't, but

by Animus7 14y ago

We already have this. Node.js. So I'm confused as to why we need another language which is like JS but not really, that compiles to Node (which it doesn't, but the author wants to give it a shot). Sharing server and client stuff in Node is already trivial. So are RPC's (dnode) and realtime streaming (socket.io). And for the sake of security/perf, this separation works very well. Not to detract from the accomplishments here -- the type inference looks awesome, and I started off as a "compilers guy". But... why?

andrewflnr 14y ago
I guess so that it's laid out as a single app, instead of two apps in the same language that communicate.
mononcqc 14y ago
Opa was actually there way before node.js. Let's mirror that comment to node, then. Also 'real time' as mentioned in the context of socket.io, or more generally node.js, is not real time at all. It's just live. Real time has a precise meaning already.
douglasisshiny 14y ago
I think an integrated, cohesive language/framework is very tempting. The biggest thing holding back this language is the AGPL.
_delirium 14y ago
Node doesn't let you write a single app that automatically gets split between server and client, afaik. Opa's killer feature, if it works, is automatically determining the data boundary, splitting code to client-run and server-run portions, and generating the appropriate AJAX calls to communicate between them.
mabdt 14y ago
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. How does this all sound to you?
- nemoniac 14y ago
  These are all potential wins. However, having tried the tour and the example code, a concern is the memory usage on the client side. Even for simple examples, it's very high. Prohibitively high for mobile usage. Would you care to comment on this? Is it something that can be improved upon in future versions or is it inherent to the approach?
  - hbbio 14y ago
    Currently, we did not work a lot on reducing the size of the generated JavaScript code nor the memory usage. There are definitely huge potential gains in that space, and we planned to focus on this once we have the Node.js backend: Benefits will be doubled.

by Animus7 14y ago

andrewflnr 14y ago

I guess so that it's laid out as a single app, instead of two apps in the same language that communicate.

mononcqc 14y ago

Opa was actually there way before node.js. Let's mirror that comment to node, then. Also 'real time' as mentioned in the context of socket.io, or more generally node.js, is not real time at all. It's just live. Real time has a precise meaning already.

douglasisshiny 14y ago

I think an integrated, cohesive language/framework is very tempting. The biggest thing holding back this language is the AGPL.

_delirium 14y ago

Node doesn't let you write a single app that automatically gets split between server and client, afaik. Opa's killer feature, if it works, is automatically determining the data boundary, splitting code to client-run and server-run portions, and generating the appropriate AJAX calls to communicate between them.

mabdt 14y ago

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. How does this all sound to you?

nemoniac 14y ago
These are all potential wins. However, having tried the tour and the example code, a concern is the memory usage on the client side. Even for simple examples, it's very high. Prohibitively high for mobile usage. Would you care to comment on this? Is it something that can be improved upon in future versions or is it inherent to the approach?
- hbbio 14y ago
  Currently, we did not work a lot on reducing the size of the generated JavaScript code nor the memory usage. There are definitely huge potential gains in that space, and we planned to focus on this once we have the Node.js backend: Benefits will be doubled.