The Opa Framework for JavaScript | Hacker News Reader

The Opa Framework for JavaScript

opalang.org

58 pointsIgorPartola32 comments

Personally as a web developer I honestly wished this sort of tools started to get more and more traction. I'm getting a tad tired of using "dozens" of different languages and tools/frameworks to get a freaking website up and running by using good practices.

Quite frankly, I think web developers are, among all the IT people, the ones with more fragmented and disposable tools there is. If you look at a Mac developers, all they have is Xcode, that's it, one language, one framework to rule them all. Window developers have .NET. Game developers, they use one language/engine and that's it ! Not saying it's easier in anyway, just saying they don't worry about what tools to pick, they just do it, almost with just one language.

Web developers on the other hand have to work with a back-end and front-end language, deal with front-end JS mvc frameworks, maybe Coffescript instead ? CSS frameworks, or just use SASS ? cross-browsing issues and hacks, picking the right web server, database, VPN or CAP, on top of that you better have a task runner for all those "compiled" JS files and css, and a watcher so it compiles when you update a file..See where this is going ?

Plus web development tools are so volatile to change. Just look at Backbone for instance, last year it was the best thing for JS standalone apps. This year it's Ember... It's freaking insane IMO. So I really wish either OPA or something even more clever to come along and give us a little and let us just worry about building an app and not having to learn dozens of tools every year.

Having options is awesome, but needing to pick lots of options it's frustrating sometimes

Agreed on the first part but who says you have to use this fashionable stuff? The web's underlying parts haven't changed in years so there's nothing wrong with just using, say, pure perl & JS, that is whatever gets the job done.

The web isn't for you. If you want an authority figure telling you what tools to use, those platforms exist but it's not the way the web can or will ever be.

Not saying that. I just wished there wasn't so much fragmentation as there is.

> ... or will ever be.

You don't know that.

The problem is less with the tools, and more with the people using the tools. When picking out a library/framework, you should look at how quickly it's evolving and how young it is. That's not specific to web technologies, that's universal. The just web makes it more prominent.

For example, Pylons/Pyramid, etc.: these frameworks are great and I was evaluating them vs Django a few years ago. Since then the projects have moved on and lots of stuff in them has changed. OTOH, Django code I wrote 4 years ago still functions today with some really minor modifications required to upgrade. No, it's not using class-based views since they weren't available back then, but (aside from a few critical things), I don't get any deprecation warnings.

In other words, when a library promises that it'll be quick to get started with it and that it will make you so much more productive, you are not done evaluating it. The equation is (initial savings - cost of future maintenance).

As far as I'm concerned, there isn't a great and stable UI framework for the frontend that exists today. Dojo is comprehensive but complicated, ExtJS is very nice but you cannot skin it, jQuery UI is unusable.

The other thing that makes this complicated is that JS UI kits need to evolve. There are probably only a handful of good ways to do networking code, but what a good webapp should look like changes constantly. As soon as you can package good design into a library it's no longer good design.

This is one of the reasons why I tend to stay on the lower end of the stack. There you can easily write stable, testable code and libraries tend to provide a stable interface or die quickly.

What you mention on the UI front is why I've been leaning more towards just using a nice base like bootstrap, and building from there. Once you are reliant on a full-featured toolkit, working on edge cases becomes much more complicated, not to mention maintenance and support. Things have been evolving fast since very early on... it's nowhere near as bad as the v4 browser days (IE4 & NN4, not HTML4)... Things will get more diverse, but I do think we will see at least some consolidation and reduction in popularity in the next 5 years, as many apps using the various frameworks start to retire.

Personally, I would like to see jQueryUI's widgets ported to use Bootstrap as a base theme. I think the interfaces for it are decent from the JS side, but the markup leaves little to be desired.

Of course with what you say, there is the <a href="http://xkcd.com/927/">obligatory XKCD reference</a>.

If you really want one toolkit to rule them, you could go with GWT, which is close... there are also up and coming frameworks using NodeJS, MongoDB etc... (like this one, Meteor, and Derby). It really depends... the problem is, "it's complicated"... You have frameworks with very few assumptions like Backbone, and you have frameworks with a LOT of assumptions... you have two-way binding or manual events.

The more "automagic" a framework is, the harder the edge cases get. For me, I've been leaning towards JS on the server, as you at least get rid of a lot of context switching. I know a lot of the guys coming from Ruby and Python tend to favor CoffeeScript, to be honest, other than writing configurations and tests, I don't like it as much.

The really funny thing is that E4X is already a standard, submitted by Mozilla years ago, that would act as an extension to the regexp parsing, and be a good fit for this. Unfortunately, the core V8 guys refuse to support it, and MS likely never would either. So we're stuck with string processing hacks, or abusing the DOM for these types of interactions.

I do like that Opa offers some more natural DB interactions... I think security implications get complicated as well, which is what makes me a bit fearful of these types of frameworks for any serious, public facing applications.

Opa has always treated security very carefully, as it was one of the original project goals. Strong static typing + the original native backend makes Opa one of the best candidates for secure web app. We're not vocal about this, but the company behind Opa has customers in the defense sector (in Europe, PRISM totally unrelated) for this reason.

By security, I mean user permissions... ex: User A can't edit records beloning to User B, but Manager C can see them both, and Admin D can see everything.

Many of these "Simple" frameworks that transparently pass stuff to the client-side forgo roles, accounts and ownership hierarchies.

In Opa, you have too mechanisms that combined provide probably a very high level of security in this sense too: 1) Algebraic constructs, so that the typing system checks properties like permissions automatically 2) Client "guards", aka protected values that can't be transmitted to the client, which Opa checks automatically.

Recently I wrote a less overwhelming pre-compiler that allows you type HTML inline with your Javascript, may be worth a look: http://mxcl.github.io/bs BullScript’s goal is just to make writing JS a little nicer, but not to be some whole new language.

So it's like PHP for JS?

Somewhat silly question... why not write BSC in JS? I mean, this seems like something that would be a natural fit in a NodeJS environment, and tying into NPM similar to CoffeeScript, Less etc.

I don't mean to come across as an ass, just curious. Though, I do think what you are doing could be a natural extension to CoffeeScript itself.

Also, I would suggest having an htmlEncode(variable) by default, I know that htmlEncode isn't a built-in JS method, but you should want to escape html entities.

Yes with hindsight I wish I had written it in JS, but writing the BS compiler was something I wanted to get done fast, and I'm more proficient with Ruby.

BS has the #x{foo} syntax for htmlEncoding, or did you mean that should just be the default?

I didn't notice the #x{foo}, though was thinking that should be the default (safe-first), and if you want unsafe/raw have that be explicit.

It's a real shame they took out the nice terse OCaml syntax to make it look more similar to javascript.

I'm looking forward to writing modern (i.e. web) programs with features stolen from functional languages! And, at the end of the day, more people are more familiar with Java-like syntax, and that's good for adoption.

But can anyone tell me whether the change from ML-like -> Java-like syntax has meant a loss of composability/expressability/any other traditional strengths of FP languages?

There is no loss at all: There are just two parsers for the same Abstract Syntax Tree. After parsing which is the very first step of the compiler, everything is the same. All the features of Opa lie in the ability to analyze the code and generate JS code from the AST.

The OCaml syntax is still available:

opa --parser classic

Indeed, most of the stdlib is implemented using the "classic syntax".

Is this still available? I don't think that's a valid option in the later versions (at least for the last year). There's been some discussion of this on the Opa forums, and it seems that the OCaml-like syntax is gone now. It's a pity, really.

Edit: ah, you're right. It apparently still exists, but the original ML-like syntax is undocumented now.

Some earlier discussions, fwiw:

https://news.ycombinator.com/item?id=4647476

https://news.ycombinator.com/item?id=4142192

I guess they didn't get much traction with "opa language" and now they advertise it as "opa framework for js".

It is odd that they still don't have any SQL database support.

Can't you just use node-mysql or something like that? They broke my heart when they dropped custom runtime (and ML-like syntax) in favor of Node and JS, but it should allow Opa users use Node libraries directly, no?

I like the idea of such a "framework" - it's time to abstract away all the cruft web developers need to write and focus on actual logic. I didn't use Opa or anything similar yet, but I'm keeping an eye on them and will try them at some point.

Have taken a look at http://webtoolkit.eu ?

From their site, they say that "Opa generates and is fully compatible with standard JavaScript code" so it's really no different than preprocessors like CoffeeScript. So the tagline seems acceptably accurate IMO.

And is it really that odd that they've targeted Mongo to start with? Meteor has done the same thing.

Yeah I'm wondering what the differences between this and Meteor is.

http://blog.opalang.org/2012/04/one-web-app-one-language.htm...

As far as I understand, Opa has 2 killer features over Meteor: Type inference and "location inference".

While type inference is nice, I'd still prefer to mark locations explicitly.

Opa has Postgres support.

It requires almost no code change from MongoDB to Postgres, as explained in this blog post: http://www.josetteorama.com/to-sql-from-nosql/

Can I create new HTML elements? I'm not psyched about the kind of syntax in http://hasteb.in/rikuquyaju.xml and would much rather have something like http://hasteb.in/bisilexope.xml

I'm not sure I understand your question. Oh, and this.getChildren() doesn't look very Opa-ish.

Reply on news.ycombinator.com