5 ms·

CappCon 2011 On the Fringe - Pushing the Web to its Limits

26 points by tolmasky 15y ago

tolmasky 15y ago
Everything they show here is available as open source at: https://github.com/austinsarner/Frappuccino https://github.com/austinsarner/Frappuccino https://github.com/austinsarner/RunKit https://github.com/austinsarner/RunKit
- WingTsun 15y ago
  do you know how run it? I got CPInvalidArgumentException: attempt to insert nil or undefined
DanielRibeiro 15y ago
I can't help but think that Cappuccino, and GWT for that matter, would be much more successful if they decoupled language and toolkit. If objective-j would run on node.js, like Clojure and Coffeescript, it would probably get more traction. And if the toolkits were language agnostic (meaning you could easily write in haxe, coffeescript, clojurescript, or any other language on top of js [1]), it would have a bigger market. I know that Cappuccino and GWT are older than node.js, but it is not too late to change. [1] https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
- deleted 15y ago
  [deleted]
- dstein 15y ago
  I think the bigger problem is Objective-C isn't a desirable programming language to begin with, and therefore another language based on it is even less desirable.
  - justinvoss 15y ago
    That's very much a matter of opinion. Personally, I would rather write Objective-C/J than Javascript.
- 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.
joely 15y ago
Cappuccino really delivers. And you're doing it again here!

26 points by tolmasky 15y ago

Everything they show here is available as open source at: https://github.com/austinsarner/Frappuccino https://github.com/austinsarner/Frappuccino https://github.com/austinsarner/RunKit https://github.com/austinsarner/RunKit

WingTsun 15y ago
do you know how run it? I got CPInvalidArgumentException: attempt to insert nil or undefined

DanielRibeiro 15y ago

I can't help but think that Cappuccino, and GWT for that matter, would be much more successful if they decoupled language and toolkit. If objective-j would run on node.js, like Clojure and Coffeescript, it would probably get more traction. And if the toolkits were language agnostic (meaning you could easily write in haxe, coffeescript, clojurescript, or any other language on top of js [1]), it would have a bigger market. I know that Cappuccino and GWT are older than node.js, but it is not too late to change. [1] https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

deleted 15y ago
[deleted]
dstein 15y ago
I think the bigger problem is Objective-C isn't a desirable programming language to begin with, and therefore another language based on it is even less desirable.
- justinvoss 15y ago
  That's very much a matter of opinion. Personally, I would rather write Objective-C/J than Javascript.
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.

joely 15y ago

Cappuccino really delivers. And you're doing it again here!