Live data from Hacker News

One Web App = One Language

blog.opalang.org

11–16 of 16 posts

Re: One Web App = One Language

#11
post #2

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 accomplishmen…

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?

Re: One Web App = One Language

#12
post #8
post #6

The innovation here is using the type system to determine whether code should be executed on the client or the server. Contrast this with writing code manually for node and the browser. In this case, though it's all javascript, the programmer must explicitly divide the code for the server and the client. Or contrast with Meteor. Here there is a bit more code sharing, but the programmer still needs to think about clie…

> For example, say my phone needs to grab some data from my laptop, but rather than have the laptop send all the raw data to my phone and have my phone process it, the system figures out that it would be more efficient for my phone to send code to my laptop, have the laptop process the data locally, then send the processed data back to my phone. I've been romanticizing this kind of dynamic client-hopping execution in…

What exactly is the problem you are referring to as unsolvable?

Re: One Web App = One Language

#14
post #11
post #2

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 accomplishmen…

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 :-)…

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?

Re: One Web App = One Language

#15
post #11

Earlier quoted context omitted.

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 :-)…

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?

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.

Re: One Web App = One Language

#16
post #12
post #8

Earlier quoted context omitted.

> For example, say my phone needs to grab some data from my laptop, but rather than have the laptop send all the raw data to my phone and have my phone process it, the system figures out that it would be more efficient for my phone to send code to my laptop, have the laptop process the data locally, then send the processed data back to my phone. I've been romanticizing this kind of dynamic client-hopping execution in…

What exactly is the problem you are referring to as unsolvable?

The problem of deciding where best to execute code.
Post reply on HN