The Opa Framework for Javascript • Hacker News Board

Re: The Opa Framework for Javascript

#21

Post by chr1 » Sat, Oct 13, 2012, 11:58 AM UTC

fingerprinter wrote: post #11

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…

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.

Re: The Opa Framework for Javascript

#22

Post by raphinou » Sat, Oct 13, 2012, 12:33 PM UTC

lazyjones wrote: post #20

raphinou wrote: post #17

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. See http://www.webtoolkit.eu , really worth a try!

I wonder how Google indexes pages generated by Wt ... I can't really find any indexable content when looking at the examples HTML source code.

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.

Re: The Opa Framework for Javascript

#23

Post by hbbio » Sat, Oct 13, 2012, 8:54 PM UTC

stesch wrote: post #19

eranation wrote: post #2

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

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?

Re: The Opa Framework for Javascript

#24

Post by greyfade » Thu, Oct 18, 2012, 8:16 AM UTC

hbbio wrote: post #23

stesch wrote: post #19

Earlier quoted context omitted.

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.