[phpnode]

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?

[donw]

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.

[Doctor_Fegg]

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.

[jermar]

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.

[flyingbeaver]

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...

[phpnode]

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.

some clichés apply here:

"You can write fortran in any language"

"There are no silver bullets"

[flyingbeaver]

"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 ?

[spankalee]

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.

[e28eta]

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).

[jermar]

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 :)

[chris-l]

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!