Hacker News Reader

Comment by eranation | Hacker News Reader

Opa - Gangnam style: http://opalang.org/gangnam.style.html

Jokes aside, this seems like a serious project, and has some sort of connection to OWASP https://www.owasp.org/index.php/Opa

a secure javascript framework? write server side and client side in the same language (anyone said Meteor)? I'm going to try this.

prediction: HN front page posts about opa will exceed posts about Go in the next year.

EDIT: unfortunately, using TypeScript will not work here, seems Opa is generating JavaScript itself. Still interesting in any case.

View on HN

I'd maybe argue that "framework" is a bit of a misnomer - Opa is a programming language based on ML (it was originally called MLState) where the compiler determines/enforces what runs on the client or server. It originally compiled down to native code on the server via OCaml as well as front-end Javascript, until the more recent switch to using Node.js on the backend. A lot of the security benefits it offers likely come from the type system (with type inference), probably similar to building a site in Haskell (compile-time errors on unclean strings, type-safe URLs, etc.).

Along side of this, it includes a slew of libraries and tools for doing things like authentication, interfacing with specific web services, and building websites, which is why it seems they've started to focus on the "framework" aspect.

To your prediction: Nope, Opa is an old thing already. Maybe it was a interesting project when they compiled to native code, but now it's just another way to use node.js.

I would have used it 2 years ago but there seemed to be no easy way to use HTML5 with it. It was fix with XHTML 1.1.

I'm the creator of Opa. When we released Opa in June 2011, it had only a native backend. Most of the feedback we got was to support a standard runtime, which we did when we chose to target Node.js as we already generated JavaScript client code.

Why (now Opa supports HTML5 and the like) do you think native backend is better?

Personally, Node.js+MongoDB is counter to my intended use cases. NoSQL databases are incompatible with my data models. Node.js has limitations in responsiveness, especially for complex (read: data/code-heavy) responses.

It simply doesn't meet my needs, and the community's focus is on improving areas that are completely orthogonal to my needs.

A native backend that is properly threaded and uses, e.g., continuations and thread pools to manage highly concurrent requests is far more preferable compared to Node.js, and proper support for RDBMS and memcached meets my needs better than MongoDB could ever dare dream.

hahah - work time well spent

Reply on news.ycombinator.com