Show HN: Cupertino.js – A JavaScript to Cocoa compiler and runtime
github.com
github.com
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?
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.
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...
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"
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 ?
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).
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 :)
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.
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.
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]
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.
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.
https://github.com/jerrymarino/cupertinojs/blob/355ea51/cujs...