Good job for shipping, however this project and others like it (e.g. RubyMotion) set off alarm bells for me personally.
I think the same arguments that people have against CoffeeScript apply here - it's not possible to use CoffeeScript without knowing JavaScript, and in this case it's not possible to use JavaScript without understanding the Objective-C ecosystem. At this point, this is Objective-C with a different syntax, it's not really JavaScript. Existing documentation, blog posts, stackoverflow answers etc use Objective-C, so the programmer will have to do a lot of translation in their heads. If I have to learn all the Objective-C / Cocoa APIs anyway, what am I gaining by using a different syntax?
Many people chose CoffeeScript, RubyMotion, and so on, because they address very real problems in the existing toolchain.
With RubyMotion, you gain the ability to work from the command line.
Cupertino (https://github.com/nomad/cupertino) gives you a chunk of that for pure Objective C, but with RubyMotion, I can build an app and deploy it to my iPhone without having to touch Xcode.[1]
Thats a big bonus in my book. I've got a great toolchain on the command line, and don't much care to have to change nearly every aspect of my working environment because Apple wants everybody to use their all-singing, all-dancing tool.
Being able to reuse a bunch of business logic across mobile and web is also a plus.
[1] If anybody wants to share resources on doing this in pure ObjC, I'm very interested.
It's more a matter of what language you're comfortable in.
An analogy: I'm playing with Opal (Ruby in the browser) right now and am greatly impressed. Sure, I know JavaScript - I just don't like it. I write in it regularly and still make howlers every time I do.
I'm more productive in Ruby, and that's where Opal scores for me. In this case I'm sure there are people who are more productive in JavaScript than Swift... even though the notion of anyone being productive in JS boggles me personally.
Thanks for the feedback! At this point writing a serious Cocoa app would require using the frameworks directly.
I think would be awesome if there was a way to implement native Cocoa apps with JS frameworks like Ember or Backbone. It might require some plugins but if done correctly could be interesting and maybe useful.
It may be possible convert official documentation and examples to use JS syntax. This could remove the context switch to Objective-C syntax.
can't you just imagine that a lot of people think that ruby is far more suitable/productive/readable to write applications than ObjC/Swift ? It's not just about learning this or that...
Concerning the translations you are talking about, it's completely trivial if you think the right way and don't just try to copy/paste things all the time. It's about objects, methods, interfaces, whatever the examples are written in...
Most people who choose this kind of thing are not experienced with the transpilation target, they're $language developers who want to avoid learning a new $language. But of course the main challenge when learning a new language is learning the standard libraries / eco-system, and these things don't help at all with that, they obscure it.
Another problem is that they never solve the impedance mismatch, idiomatic JS does not map cleanly to idiomatic ObjC, you end up with code that is idiomatic in neither.
"If I have to learn all the Objective-C / Cocoa APIs anyway" and "who want to avoid learning a new $language"...
Still not the issue, sure some people want to avoid to learn more, but that's not people we are interested in, those people wouldn't learn anything anyways... As you said, if you want to be very good yes you have to learn all the tools. So for good developers it's not about learning this or that, it's about learning both, and choosing the one you think is the best to write a full application.
", idiomatic JS does not map cleanly to idiomatic ObjC, you end up with code that is idiomatic in neither."
Sure, you end up with idiomatic RubyMotion. Is that an issue ?
The advantage here is that you can take a common JS codebase, abstract the platform APIs that you use out, and run it on the web and iOS. The platform layer developers will probably need to understand Cocoa and iOS well, but the other application developers might not need to so much.
Assuming the transpilation is complete and bug free. Otherwise the transpiler's ability dictates what your common code base can do. You're not able to use the full power of the language, but instead are using a less expressive subset.
For example, if your web app is using JS prototypes, and those don't work on the iOS platform (I don't know if Cupertino.js supports this or not, just an example) you're going to have (major?) refactoring to do and all of the application developers are forced to conform.
If you instead decide to run the app's JS in the interpreter, now we're simply talking about a hybrid app (like PhoneGap).
Currently some aspects of prototype inheritance are implemented. One day Cupertino.js should support an ECMA standard http://www.ecmascript.org - the Javascript spec that most web browsers implement. Once this is finished it would have "full" support of the language, minus any vendor added functionality.
I think porting apps might require some refactoring around the UI layer or adding functionality that is only exposed by native frameworks. It may be interesting to look into supporting hybrid web frameworks in the future :)
Yes, once Cupertino becomes more ECMA compliant, we will see the release of specific JavaScript frameworks targeting the creation of Cocoa apps. Kudos for Cupertino.js!
This project is awesome. Why? Because, if it succeeds, it means that a huge amount of open-source, hackable JavaScript written for the open web has another way[1] into a proprietary runtime. Depending on how the cross compilation occurs, it could avoid a lot of the inevitable performance degradation PhoneGap imposes.
My enthusiasm is muted, however, with the knowledge of how young this project is. There's a lot of work to do - implementing javascript platform methods (e.g. String.subtr(), etc) alone will be a lot of work.
I'd also be curious to know how the author will be able to deal with meta-programming in general, and eval() in particular.
[1] The other way is via WebView and/or something like PhoneGap[2]
I can recognize the hack value, but having a hard time imagining why would I use it for something else than a hack value. If I wanted to develop, lets say, an iOS app natively - I'd chose Obj-C (which I don't know good enough, so I'd need to learn a little) or I'd use Swift (because it's a higher abstraction level, I like FP, etc). If I'm good with a non-native implementation, I'd use Cordova, Phonegap, etc.
In my limited understanding, JS and ObjC have almost the same level of abstraction, so I do not quite understand what value this compiler brings to a real life project.
And as @phpnode says, you still have to learn a lot of ObjC anyways.
What is the advantage of this over exposing Cocoa Apis to Javascript (ala JSTalk)? Seems like a lot of work to get parity with basic features like gc and standard lib (not to mention putting the onus on yourself to keep updating it as new ecmadcripts are released).
The advantage that comes to kind is that in theory if this is coffeescript-esque than libraries written in Cupertino is should be "usable" by objective-c? I haven't seen what the outputted code looks like though so I have no idea if it'll be as seamless as coffeescript <--> js.
The name reminded me of http://www.cappuccino-project.org/ but it's not really the same thing; Cappuccino adds Objective-C-like method dispatch to javascript (they call it Objective-J) and lets you use Interface Builder to create your UI.
I think the same arguments that people have against CoffeeScript apply here - it's not possible to use CoffeeScript without knowing JavaScript, and in this case it's not possible to use JavaScript without understanding the Objective-C ecosystem. At this point, this is Objective-C with a different syntax, it's not really JavaScript. Existing documentation, blog posts, stackoverflow answers etc use Objective-C, so the programmer will have to do a lot of translation in their heads. If I have to learn all the Objective-C / Cocoa APIs anyway, what am I gaining by using a different syntax?