3 ms·

Objective-J is decoupled from Cappuccino. It runs completely independently, and even has a command line utility available built on top of Narwhal (a command lin

by boucher 15y ago

Objective-J is decoupled from Cappuccino. It runs completely independently, and even has a command line utility available built on top of Narwhal (a command line JS environment we built before Node was an option). Objective-J should absolutely be made to run on node, and that's being done as part of our rewrite, Objective-J 2.0. As far as the other direction is concerned, you can write code on top of the Cappuccino framework in any language you can get running in the browser. The problem with writing in vanilla JavaScript, as opposed to Objective-J, is just that there are missing features which require the use of fairly obnoxious syntax in JavaScript. A ruby to JavaScript compiler would provide a great language alternative to Objective-J for targeting Cappuccino. In fact, you can build a reasonable subset of ruby on top of Objective-J (see https://github.com/tlrobinson/cappruby https://github.com/tlrobinson/cappruby, ala MacRuby).

DanielRibeiro 15y ago
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/ http://coffeekup.org/ [2] http://blog.heroku.com/archives/2011/8/3/polyglot_platform/ http://blog.heroku.com/archives/2011/8/3/polyglot_platform/
- tlrobinson 15y ago
  Here's one: Objective-C's "forwardInvocation:" functionality (or "method_missing" in Ruby). http://en.wikipedia.org/wiki/Objective-C#Forwarding 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.
  - DanielRibeiro 15y ago
    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_Objects/Object/noSuchMethod https://developer.mozilla.org/en/JavaScript/Reference/Global... [2] http://stackoverflow.com/questions/3811408/node-js-overloading-functions http://stackoverflow.com/questions/3811408/node-js-overloadi... [3] http://yehudakatz.com/2008/08/18/method_missing-in-javascript/ http://yehudakatz.com/2008/08/18/method_missing-in-javascrip... [4] http://akka.io/ http://akka.io/ [5] http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-level-concurrency-with-jruby-and-akka-actors/ http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-l...
    - tlrobinson 15y ago
- lapusta 15y ago
  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.

by boucher 15y ago

DanielRibeiro 15y ago

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/ http://coffeekup.org/ [2] http://blog.heroku.com/archives/2011/8/3/polyglot_platform/ http://blog.heroku.com/archives/2011/8/3/polyglot_platform/

tlrobinson 15y ago
Here's one: Objective-C's "forwardInvocation:" functionality (or "method_missing" in Ruby). http://en.wikipedia.org/wiki/Objective-C#Forwarding 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.
- DanielRibeiro 15y ago
  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_Objects/Object/noSuchMethod https://developer.mozilla.org/en/JavaScript/Reference/Global... [2] http://stackoverflow.com/questions/3811408/node-js-overloading-functions http://stackoverflow.com/questions/3811408/node-js-overloadi... [3] http://yehudakatz.com/2008/08/18/method_missing-in-javascript/ http://yehudakatz.com/2008/08/18/method_missing-in-javascrip... [4] http://akka.io/ http://akka.io/ [5] http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-level-concurrency-with-jruby-and-akka-actors/ http://metaphysicaldeveloper.wordpress.com/2010/12/16/high-l...
  - tlrobinson 15y ago
lapusta 15y ago
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.