Comment by DanielRibeiro | Hacker News Reader

Comment by DanielRibeiro | Hacker News Reader

Parent Full thread

Thanks for the comprehensive overview of what is going on cappuccino land.

Regarding the missing features on vanilla JS: it is ok. More powerful languages on top of JS might have them, and having a common ground to compile to would make the toolkit more hospitable to a polyglot environment.

Edit: It is also important to note that Javascript supports metaprogramming as powerful as LISP macros. This is because functions implement toString method. Coffeekup [1] is a beautiful DSL for writing web pages in Coffeescript that uses this feature quite successfully. Therefore I'd really like to see which JS missing features can't be supplanted by AST manipulation, like the one you'd do in Scheme, Clojure or Common Lisp.

GWT had this very same issue: by choosing source code compile, languages like Clojure, Scala, Groovy and JRuby were removed from the ecosystem. Which is really harming for open source projects, where the more people you reach, the more help you get.

Heroku's founder Adam Wiggins wrote a lot about this Polyglot environment a couple of days ago on: Polyglot Platform [2]

[1] http://coffeekup.org/

[2] http://blog.heroku.com/archives/2011/8/3/polyglot_platform/

GWT is only popular because of Java. I'm not that sure if anybody would be interested in using it without the language, because it won't provide any features for regular JS developer. As a Coffeescript developer, do you need any of:

* Static typed language on client-side

* Allow your Java developers to build complex maintainable UI without advanced JS knowledge

* Reuse existing Java code

* Use Java tools (IDE, Unit testing, Build systems)

It's very hard to build a complex JS app, because even guys who develop for web in dynamic languages like PHP, Python or Ruby - usually produce the "callbacked-jquery-unmaintainable-mess" on the front end. There are tools like Backbone which are becoming more and more popular, but learning them and all new JS patterns is more complex then GWT for a regular Java developer. Supporting other JVM languages is also hard task, AFAIR GWT isn't working with JVM bytecode when converting Java to JS. Microsoft tried this way with Volta, but failed.

Cappuccino brings you a rock solid API and a language that makes this API nicely usable (you can use it without Obj-J, but it will look ugly). Look at other popular frameworks: ExtJS, SproutCore - both changed their vision heavily with latest versions. Cappuccino is aimed for Apple/Cocoa minded developers, and Obj-J seems to be the best fit the same way as GWT is for Java.

I really don't see how you can make products like GWT & Cappuccino without their languages, because the reason why they were built were those languages and tight integration in first place. Otherwise they would become yet another library of widgets.

Here's one: Objective-C's "forwardInvocation:" functionality (or "method_missing" in Ruby). http://en.wikipedia.org/wiki/Objective-C#Forwarding

This could be implemented in a JS-to-JS compiler (which is what you're describing) but it would incur an overhead for every JavaScript method call. Since Objective-J has it's own syntax for method dispatching the overhead is only incurred for Objective-J methods, leaving JS methods untouched.

I really like this feature (which actually comes from Smalltalk's doesNotUnderstand:). It is actually supported on firefox[1][2][3] as __noSuchMethod__, but it is non standard, and should not be relied when writing cross platform js.

But then I guess the thread starts getting a bit off track, and I apologize. The point is:

Supporting other languages is good for the framework, and for the community

GWT took the position: Java source only. Cappuccino can take the same position: Objective-j only. It is fine. It is also limiting.

I am always happier when great frameworks support multiple languages, when it opens the doors for more people, instead of shutting down to a smaller community. It helps create greater value to more people, which I'm always for. It does have its costs. In the end, it is a trade-off which the creators and the community have to make.

PS: An example of a framework that does this (written ina more powerful language, supporting a less powerful one) is Akka[4]. It is written in Scala, but its Java interface, while more cumbersome, is so good that I could create a JRuby interface[5] that is even more expressive (thanks to method_missing) than the original one in Scala.

[1] https://developer.mozilla.org/en/JavaScript/Reference/Global...

[2] http://stackoverflow.com/questions/3811408/node-js-overloadi...

[3] http://yehudakatz.com/2008/08/18/method_missing-in-javascrip...

[4] http://akka.io/

[5] http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-l...

I actually agree with you (It's not a coincidence I wrote the CappRuby project mentioned in the boucher's comment).

At some point I'd like to build some nicer pure-JavaScript bindings to the Objective-J runtime which get you 90% of what you get from Objective-J without the OMG-WTF-is-this-new-language reactions.

However, I'm not convinced it will make a big difference. Language style and convention permeate libraries/frameworks, and simple language bindings often results in a sort of "uncanny valley". Can you name any significant frameworks that are more commonly used from an alternative language than the one it was originally written for?

I also agree that making "lower level" bindings can leave the API a bit shady (Akka's[1] Java version is a bit uglier due to lack of Anonymous Functions, which have to be replaced by Interfaces).

About example of frameworks which more popular in another language, I honestly can't think of few other than Akka. I admit is uncommon for frameworks to support its host language (in a multi-language platform), and host languages are usually much more crowded than their sub-language counterparts.

What happens far more frequently is a complete re-implementation on the host language, example: instead of using JRuby on Rails, people migrate to Play framework[2]

Hadoop[3], however, seems to be getting really tracktion from its other language bindings[4], as writing map-reduce tasks in Java is not fun at all.

[1] http://akka.io/

[2] http://www.playframework.org/

[3] http://hadoop.apache.org/

[4] http://pig.apache.org/

Reply on news.ycombinator.com