Show HN: Cupertino.js – A JavaScript to Cocoa compiler and runtime

https://github.com/jerrymarino/cupertinojs

by jermar • 12 years ago

77 23 12 years ago

github.com

heromat• 12 years ago

https://rbt.asia/g/thread/41920845

phpnode2• 12 years ago

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?

Doctor_Fegg• 12 years ago

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.

flyingbeaver2• 12 years ago

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

phpnode2• 12 years ago

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"

spankalee• 12 years ago

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• 12 years ago

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

donw• 12 years ago

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.

jermar3• 12 years ago

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.

bsimpson• 12 years ago

If you wanted to target the Obj-C runtime, but aren't interested in learning the syntax, wouldn't you just use Swift?

kika• 12 years ago

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.

mwcampbell• 12 years ago

What license is this under?

antoncohen• 12 years ago

https://github.com/jerrymarino/cupertinojs/blob/355ea51/cujs...

delinka• 12 years ago

It is not currently licensed.

jermar3• 12 years ago

There's no license as of now but I'm in the process of adding one. Do you have any suggestions?

idibidiart• 12 years ago

I personally think it's great (... awaiting those down votes)

nmb• 12 years ago

At first I thought this was going to be a Javascript interface to SAT tutoring centers and boba shops.

tolmasky• 12 years ago

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.

ams6110• 12 years ago

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.

javajosh• 12 years ago

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]

[2] http://phonegap.com/

Show HN: Cupertino.js – A JavaScript to Cocoa compiler and runtime

Related Stories