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

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.

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.

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.

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

You don't know that.

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.

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

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?

opa --parser classic

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

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

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

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

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

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

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

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.

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