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.
Apologies if this comes across as as a bit off topic at first, but I typically think of 2 types of software developers: tinkerers and makers (this is simplistic thinking, I know, but go with me here...nothing derogatory is meant!).
Tinkerers like to fiddle, muck around and generally like the internals. They do make awesome stuff, though they like the tools just as much as they like the end product. Errors on install or obscure messages are just another reason to dive deep.
Makers are people that like to make things; products and such. They tend to care less about the tools and more about the product they are working on. Errors on install or obscure messages are hurdles that get in the way of building the products.
I'm a maker. Right now I feel the current state of Node and JS is not a great place for makers. Ruby and Python (as examples) are great.
I would like to use Node and JS, though I feel that there is just too much choice right now with no real "winner" and no clear "one way to rule them all".
Perhaps I'm wrong, and I would love to get educated on this b/c reading the tea leaves would suggest that JS/Node can be huge in about 3-5 years, maybe even mainstream. And as a person who likes to be at the forefront of technology, I would love to spend some time with JS/Node right now...but it just seems crazy. As I said, so much choice, no clear direction, too many ways of doing things.
So, the question would be this: if someone like me wants to get started, where do I start? Which web framework should I be using? Coffescript? Deployment?
I've seen Meteor and am intrigued (the fact that the setup instructions don't work on Ubuntu is a HUGE minus, btw...gah! another hurdle).
I am not a fan of errors on install either, and that was the main reason i liked node. Because of incompatible language versions, and somewhat confusing package managers, getting something running with ruby/python was an order of magnitude harder than with node.
Wt is also a framework enabling you to develop web applications without the need to manage client-server communications. It's available as a C++ version and a java version ( http://www.webtoolkit.eu/jwt ) usable with any JVM language (ie including Jruby, Groovy, Jython...).
It has the advantage (compared to Opa) that you can use any database you want.
There's a fallback according to the capabilities of the UA. For example I still can view the content of their website, which is a Wt app, with lynx. You can also do a wget and see what content you get.
I've used Opa sporadically since before the new JS syntax/backend. It's just flat out fun to program with, as the feedback loop is so tight. The only complaint I had was the compiler was a bit ... French -- liable to take an extended lunch break just when you ask it to do some work. It might be faster now. Use a structural type system gives the language a very different feel to other statically typed systems.
Am I alone in thinking that all these javascript "frameworks" are getting out of control? Variety is the spice of life and all, but how about focusing on a single (open source) project, instead of all these fragmented one-offs?
but since I've got to the conclusion, that the more the merrier, if DHH said "we have too many web frameworks, let's just invest in PHP / ASP.NET / Struts / JSP / JSF / Spring MVC" then we wouldn't have had Ruby on Rails.
If John Resig said "we have too many JS frameworks, let me just invest in mootools / dojo toolkit / scriptaculous" then we wouldn't have had jQuery probably (although some were created around the same time, but let's not allow facts to ruin my point")
So the answer, no you are not alone thinking this, but it doesn't matter, people will create more, and we all have to thank them for doing so.
Like in the past, hopefully browser authors and working groups take what is being done in JavaScript frameworks, and makes those tasks easier to implement and platform/browser agnostic.
It is work like this that is the direct reason that web developers today are able to fantastic things in CSS instead of retarded amounts of JavaScript animation and UI programming.
I doubt many of today's developers truly appreciate how amazingly easy it is do stuff like this now:
abstracting away the client/server separation seems like a problem many people want to solve. It's debatable whether it's been solved in the best way we can solve it yet... so I don't see why people should stop trying.
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.