Re:Opa: A new language aiming to make web programming transp...
by Yoric on Sunday August 28, 2011 @04:44AM
(#2933608)
I've never seen the model work before where you "don't even need to think about what's running on the client or server." I like features like sharing code (same language) and easy transport (serializable data structures), but frameworks that blur the client/server distinction usually download all of your code, or none of it, or little snippets on demand, or some other strategy that's worse than a manual distinction.
There are two things here. For prototyping, Opa will automatically decide what goes to the client and what goes to the server. We are very much aware that this may not yield the best performance. So, when you move from prototyping to optimization, using your knowledge of the application security policy, you can add security hints that the compiler will use to optimize client-server placement, knowing that this does not break the policy. And finally, if you want even better control, you can annotate any piece of code to instruct the compiler to place it on the client, or on the server, or both. In any case, the compiler will inform you if the set of constraints you put has no solution.
Tons of dependencies (a personal gripe). Coming from the Java world, where lots of things like reading images are built-in, it's comical to see that Opa requires Java, AND libjpeg and a dozen other things (it doesn't actually run on the JVM I don't think).
I concur that the dependencies are a (minor) annoyance. Just one point: Java is used only to build Opa from source. More precisely, during Opa compilation, we run the (very nice) Java-based Google Closure Compiler as a measure of the quality of our JavaScript libraries. If I recall correctly, that build step is optional, too.
There are two things here. For prototyping, Opa will automatically decide what goes to the client and what goes to the server. We are very much aware that this may not yield the best performance. So, when you move from prototyping to optimization, using your knowledge of the application security policy, you can add security hints that the compiler will use to optimize client-server placement, knowing that this does not break the policy. And finally, if you want even better control, you can annotate any piece of code to instruct the compiler to place it on the client, or on the server, or both. In any case, the compiler will inform you if the set of constraints you put has no solution.
Tons of dependencies (a personal gripe). Coming from the Java world, where lots of things like reading images are built-in, it's comical to see that Opa requires Java, AND libjpeg and a dozen other things (it doesn't actually run on the JVM I don't think).
I concur that the dependencies are a (minor) annoyance. Just one point: Java is used only to build Opa from source. More precisely, during Opa compilation, we run the (very nice) Java-based Google Closure Compiler as a measure of the quality of our JavaScript libraries. If I recall correctly, that build step is optional, too.