Linked by hbbio on Thu 25th Aug 2011 22:14 UTC
General Development "Opa, a new opensource programming language aiming to make web development transparent has been publicly launched. Opa automatically generates client-side Javascript and handles communication and session control. The ultimate goal of this project is to allow writing distributed web applications using a single programming language to code application logics, database queries and user interfaces. Among existing applications already developed in Opa, some are worth a look. Best place to start is the project homepage which contains extensive documentation while the code of the technology is on GitHub. A programming challenge ends October 17th." This is weird. 'Opa' is the nickname my friends gave me 6 years ago. It's still used more often than my actual name...
Thread beginning with comment 486990
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: What are the benefits?
by henrikmk on Fri 26th Aug 2011 08:09 UTC in reply to "What are the benefits?"
henrikmk
Member since:
2005-07-10

The language REBOL allows similar use in both client and server side applications.

There are big advantages to this as applications become much smaller and cleaner. My own website has no HTML source and so is described in about 50% less code than would normally be used and I can stay entirely within the mindset of REBOL.

But OPA doesn't seem to get rid of HTML, as far as I can tell in the source for the various examples on github.

Perhaps OPA is too stringently designed to be specifically used for this purpose by simply mashing these parts into the language, and it's not pretty.

Reply Parent Score: 3

RE[2]: What are the benefits?
by ndrw on Fri 26th Aug 2011 10:38 in reply to "RE: What are the benefits?"
ndrw Member since:
2009-06-30

Why not simply use the best available "native" toolkits for both server and client side? Is it worth sacrificing all these tools and libraries for some elusive uniformness.

The only reason, I can think of, for using the same language and toolkit for both sides is you can juggle some of the components back and forth during deployment or even in runtime. That seems cool but it is almost always a bad idea in practice.

I'm actually not a web guy but a few years ago there was a lot of discussion about merging development of software and hardware (HDLs) - I don't want to say that this approach has failed - there are people using it. But they do it almost exclusively for verification - unification at the test level and modeling. Implementation still has to be done in a domain specific manner if you want to get competitive results.

Reply Parent Score: 3

RE[3]: What are the benefits?
by Ventajou on Fri 26th Aug 2011 14:54 in reply to "RE[2]: What are the benefits?"
Ventajou Member since:
2006-10-31

I use a tool called Script# that "compiles" c# code into JavaScript. Actually it kind of facelifts JavaScript to look and behave like c# because it doesn't try to hide that you're ultimately writing JS code.

The reason for that? Maintaining a large project with tens of thousands of lines of JavaScript scattered in many files is quite the nightmare. That language is fine for adding blinking stuff on a page real quick but anything medium to large scale will become difficult. Google does that too with their GWT.

Reply Parent Score: 2