9 ms·

Apple's new Objective-C to Javascript Bridge

160 points by micheljansen 13y ago

marcuswestin 13y ago
A fast objc/javascript bridge that works on iOS and OSX today: https://github.com/marcuswestin/WebViewJavascriptBridge https://github.com/marcuswestin/WebViewJavascriptBridge
apike 13y ago
My guess is that this would be fast enough to build almost any Mac app and many iOS apps. The bigger question for me is, how gross would it be to deal with the "Objective-C-ness" of the Cocoa APIs through JavaScript?
- Millennium 13y ago
  That depends on the state of the bridge. Previous language bridges by Apple have generally bridged the gaps pretty well, with the main "Objective-C" relic being really, really long method names. That said, all of the bridges I've seen were to classical-OO languages. It is possible that Cocoa won't translate as well to prototypal-OO languages like JavaScript. It will be interesting to see how Apple navigates that paradigm shift.
  - wwweston 13y ago
    > all of the bridges I've seen were to classical-OO languages. It is possible that Cocoa won't translate as well to prototypal-OO languages like JavaScript. This has already been done with Mozilla's Rhino (JavaScript or Java) and it turns out the be pretty easy to work with Java classes in that context.
  - dottrap 13y ago
    JSCocoa has been there, done that. They even have optional Objective-J support.
- nglevin 13y ago
  Functionally, this appears to be identical to JavaScriptCore's longstanding C bridge [1]. If Objective-C isn't your preference, there's nothing stopping you from calling into the C bridge from C++ or just plain C. On iOS, developers have had to compile their own version of JavaScriptCore to use this API. That's the basis for HTML5 game engines like Impact [2], and some HTML5-to-Objective-C middleware platforms. Unfortunately, until Apple says otherwise, this version of JSC is still subject to Apple's App Store review guidelines [3]. Thanks to guideline 2.8, you can't have your app, running JSC, execute any JavaScript that doesn't ship within the bundle of your app. I'd like to see that rule change, someday. Exposing this Objective-C API in a future iOS release isn't going to change the status quo. [1] - http://developer.apple.com/library/mac/#documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/_index.html http://developer.apple.com/library/mac/#documentation/Carbon... [2] - http://impactjs.com http://impactjs.com [3] - https://developer.apple.com/appstore/guidelines.html https://developer.apple.com/appstore/guidelines.html
  - apike 13y ago
    All good points. The big difference with the bridge going to Objective-C, though, is that I believe it is now possible to build a native UI by calling right from JavaScript to Objective-C. Impact is interesting for games and canvas-like rendering, but what I'd love is to be able to build the models and controllers of a highly performant, native-UI iOS app using JavaScript and UIKit. Sort of like Appcelerator with a layer removed.
    - nglevin 13y ago
      That's fair. This does save one ugly, extra step that I didn't mention, which would be to call into the Objective-C runtime's C API [1] to dispatch messages and introspect Objective-C classes. Should make it easier for developers to build their own middleware platform without getting too deep into reams of C boilerplate. [1] - https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html https://developer.apple.com/library/ios/#documentation/Cocoa...
  - pi18n 13y ago
    You should be able to to run code downloaded as part of IAP also. But this is one of the major things I wish they would change, and also one of the major reasons I'll be switching to Android.
- gsnedders 13y ago
  On iOS it won't be that quick: you don't get anything more than the JS interpreter, as you cannot allocate any executable memory on iOS, so any JITing compiler is out of the question.
  - udp 13y ago
    Wouldn't this be exempt from that limitation, with the JavaScript engine being distributed as part of iOS itself?
    - gsnedders 13y ago
      No, it applies per process: whether or not it came from a dynamically linked library distributed as part of the system is irrelevant. This is why UIWebView is slower outside of Safari.
      - pi18n 13y ago
        They might be moving towards some kind of XPC service so you can talk to a JIT through a Mach port. Speculation is my own, derived from: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/ http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-...
- deleted 13y ago
  [deleted]
- jfb 13y ago
  It's important to remember that Apple shipped both the Ruby and Python Objective-C bridges in ~10.5 era OS X. You can (and I have) written OS X native software in Python; it wasn't super pretty, but the concepts mapped across reasonably well. So I wouldn't take this as necessarily the sign of a shift in anything.
  - dottrap 13y ago
    Also, people at Apple like Objective-C and its Smalltalk influences. For those of us who've been in the NeXT/Apple ecosystem a long time, it's clear that employees at Apple see Ruby as more interesting than say Javascript because of the Smalltalk influences. If any shift were to occur, money is on Ruby. But Apple likes Objective-C and no shift seems likely and we also saw what happened with MacRuby and the author leaving to do RubyMotion.
    - jfb 13y ago
      And they've invested a lot in the tooling and environment. It's not like they're just running a stock gcc toolchain; they've put a lot of very smart people on very hard problems in the language space.
      - dottrap 13y ago
        Agreed. And another problem is that all these interpreted languages are terrible at exploiting parallelism which is a problem as we get more processor cores. They were able to solve this in C by inventing Blocks and GCD.
  - Moto7451 13y ago
    They used to have a Java bridge as well[1]. WebObjects moved from Objective C to Java at some point in the early '00s. [1]http://cocoadevcentral.com/articles/000024.php http://cocoadevcentral.com/articles/000024.php
zumbojo 13y ago
The "Siracusa County" reference refers to this Hypercritical episode: http://5by5.tv/hypercritical/15 http://5by5.tv/hypercritical/15
- pooriaazimi 13y ago
  Completely off-topic, but those (who like me, liked Hypercritical very much, but aren't active on Twitter to learn these things there), Siracusa has a new show here: http://atp.fm http://atp.fm It's not as good as Hypercritical, but is better than nothing!
1qaz2wsx3edc 13y ago
So with this marriage of Objective-C and JavaScript: How much longer until we can develop native applications without Objective-C entirely? A polygot/trans compiler for xcode would make me melt.
- 286c8cb04bda 13y ago
  > How much longer until we can develop native applications without Objective-C entirely? You already can -- Lisp: Nu Ruby: MacRuby/RubyMotion Basic: Objective-Basic
  - dottrap 13y ago
    Python: PyObjC Lua: LuaCocoa, LuaWax, TLC JavaScript: JSCocoa Perl: CamelBones More: http://cocoadev.com/wiki/CocoaBridges http://cocoadev.com/wiki/CocoaBridges
- vor_ 13y ago
  I don't understand the recurring drive people have for trying to write native applications without Objective-C. The various bridges and other glue projects never feel complete or as well-integrated with the system frameworks.
untog 13y ago
The future is arriving- slowly. Hopefully soon we will be able to make the core of our apps cross-platform by leveraging languages like Javascript, and only resorting to platform-specific code for UI layers. Here's hoping.
- kybernetyk 13y ago
  Uhm, why 'soon'? Just write the core of your application in C++ and marry said core with platform specific languages for UI code.
  - untog 13y ago
    C++ is a lot less accessible than JavaScript, though.
  - marknutter 13y ago
    Because C++ doesn't run in the browser
- gte910h 13y ago
  You can do this now with Xamarin's stack
jbverschoor 13y ago
How does this compare to cocos2d/zynga's JSB? The JavaScript Bridge
- robterrell 13y ago
  Cocos2d uses SpiderMonkey, not JavaScriptCore.
skw 13y ago
Thank god, obj-c is horrendous... I'm not sure what the point of using JS would be over something like MacRuby/RubyMotion...
- apike 13y ago
  Well for one, modern JavaScript engines are considerably faster than Ruby.
  - deleted 13y ago
    [deleted]
- seivan 13y ago
  You would be missing out on cool stuff like Protocols :)
tyilo 13y ago
You can already use this with cycript on a jailbroken iPhone: http://www.cycript.org/ http://www.cycript.org/
seivan 13y ago
great for people wanting to script games and don't want to get into LUA :)
- stcredzero 13y ago
  > great for people wanting to script games and don't want to get into LUA :) Beware of people who are portraying themselves as "savvy" yet don't know how to spell Lua.
  - seivan 13y ago
    Wow...
    - stcredzero 13y ago
      Beware of people who make "Wow" conclusions on very little data.
      - deleted 13y ago
        [deleted]
kybernetyk 13y ago
> The most interesting possiblility would be that this is the start of Apple’s evolution away from Objective-C into promoting a higher-level language for their platform The thing is: Why would they want to transform away? As it is now Obj-C is pretty sane. The memory management is now a non-brainer so that even people who come from managed languages can grasp it. GCD is great for concurrency. And using C and C++ based 3rd party libraries is trivial. The existing developer base is fine with Obj-C. So maybe Apple wants to attract new developers? But why now? If they really wanted to attract new developers to their platform they would have chosen a different language for the iPhone SDK back when they released it first. But nowadays Apple's platforms have more than enough developers. Also: Why JavaScript? JS itself is a terrible language with many inconsistencies and is unfit for larger projects - which most native applications are. There are far better and saner languages to base a new SDK upon.
- seivan 13y ago
  I agree, there is something very special about OBJ-C these days. With subscripts, literals and even in the past with Protocols doing service objects were a breeze. GCD is amazing and I use it more than NSOperation for easy quick off stuff. That being said, I can see how this would be useful for gamedevelopers who wanna keep their scripts in JS/CoffeeScript instead of LUA :-)
- jfb 13y ago
  Maybe I've just swallowed the Kool-Aid, but I don't see the putative benefits of Apple's switching platforms. I'm also not clear on how many people there are who a) can write non-trivial software and b) can't learn a C derivative language who c) would actually write software for Apple's platforms. It just seems like a pretty small set. And, if Apple were to switch, why would they pick a language as shitty as Javascript?
  - caycep 13y ago
    But it has Good Parts(tm)!
    - 13y ago
rogerbinns 13y ago
Are the interpreted code download app store rules still in place? ie can an app download additional JS at runtime or does everything still have to bundled?
joebeetee 13y ago
What does this mean for tech like Phonegap/Cordova?
tolmasky 13y ago
This just seems like an evolution of the existing Obj-C/JS bridge (namely, WebScriptObject https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Classes/WebScriptObject_Class/Reference/Reference.html#//apple_ref/doc/c_ref/WebScriptObject https://developer.apple.com/library/mac/#documentation/Cocoa... and WebScripting protocol https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Protocols/WebScripting_Protocol/Reference/Reference.html https://developer.apple.com/library/mac/#documentation/Cocoa... ). The main (very welcome) advancement seems to be that they've pushed this capability down from WebKit into JSCore. Today you can basically already do everything that's being shown in OP I think, you just were required to create an invisible WebView to host your JavaScript environment. You can easily expose classes to WebKit/JSCore (using KVC), and interact with JS objects from ObjC, and arrays, strings, etc. are auto-converted. The WebKit requirement is pretty annoying though, and as V8 has shown us, having a drop dead simple way of throwing JS into an app has some huge benefits.
- nbrooke 13y ago
  Good catch, I hadn't seen that before. It definitely looks like WebScript and the new JavaScriptCore API are strongly related. It's interesting how hard the WebScript stuff is to find without knowing the name, it didn't turn up in any of my Googling when researching the post. The fact that it's a refactoring (even a very nice one, as it seems to be) rather than a brand new API does make it less likely that Apple has any particular future plans for the API, which in turn make much of the speculation in the post even more speculative. I'm going to make an update to the post with a link to WebScript as well as a bit of additional commentary.
- yoda_sl 13y ago
  Totally agree it's more like an evolution, and I doubt it will be exposed on iOS at all, which means the same developer rules will apply and downloaded JS will have to be running inside a UIWebView. The fact is that after thinking about the iOS developer rules and what is currently available in iOS, it's totally doable to write a true Javascript bridge that respect all the requirement from the iOS rules and still let your JS code access all the ObjC runtime, in a totally transparent way aka I am able to write the following: var userName = userNameTextfield.getText(); var helloMsg = "Hello " + userName; messageLabel.setText(helloMsg); The first line will directly get the text value of a UITextField (no callback used here), and it will end up calling directly the 'text' property on the UITextField. So the JS bridge works transparently where JS code call native ObjC code directly (without using callback) and obviously ObjC can directly access the JS side... there are a few gotcha but the full system works beautifully and surprising enough performance are quite good. It took me a few years to come up with the cleanest solution and implementation. I am currently working on integrating such piece of code into some of my apps and have them released on the AppStore. In fact if anyone good in JS is interested I would really appreciate some help to get that bridge off the ground since I truly believe there is a lot of great opportunities with a JS bridge to ObjC that respect all iOS rules. My contact info are my HN profile. Edit: minor typo fixed
chaostheory 13y ago
I never had a big problem with Obj-C. It felt like any other language other than having to manually manage memory. The problem I struggled with was Cocoa as a whole. It may no longer be the case but not too long ago, there was a lack of consistency between the different APIs / SDKs. Most would written and accessed with Obj-C. A few would still be in Ansi-C. For someone who isn't a C expert, this just killed me. Does this bridge help fix that?
- kenrikm 13y ago
  Yeah, like the iOS contacts API. I really like Objective C. (I better since I write it full time, lol)
  - chaostheory 13y ago
    Geez that's still a problem? They really need to change that.
stcredzero 13y ago
Cue the typical and tiresome language-wars snark. (And time to burn some karma.) This kind of behavior is often just a shallow and distinctly anti-intellectual "irrational jingoism." If you read between the lines, so much of it just comes down to "I don't like X. I don't understand X. Doing X in the programming I do wouldn't work. It just must be bad." That's so often just about outward signs. Programming is complicated, and the fields of programming and Computer Science are vast. If you're not aware of how miniscule a sliver of the whole thing you command, odds are you're just another unwitting Dunning Krueger victim. Don't judge a language by what you find strange. Don't judge a language just because it wouldn't suit what you do. Figure out what makes it powerful and why it works. Until you do that, please just shut up and don't add to the noise.
dottrap 13y ago
This has already been done by JSCocoa. http://inexdo.com/JSCocoa http://inexdo.com/JSCocoa It's only interesting because Apple is officially doing it themselves.
dottrap 13y ago
This will probably be Mac-only. It will not appear on iOS unless Apple also ships BridgeSupport on iOS. BridgeSupport is needed for binding all the Obj-C parts that don't have introspection capabilities (like the C parts). This is how most of the other full feature bridges work, PyObjC, RubyCocoa/MacRuby, LuaCocoa. Otherwise you are hamstrung anytime you need to deal with something like a C struct (e.g. NSPoint).
- nglevin 13y ago
  As I recall, BridgeSupport created indexes to C symbols, enumerations and functions by producing XML files [1] that corresponded to C APIs like CoreGraphics, and code you produced yourself. You don't necessarily need BridgeSupport to call out to Objective-C. Speaking of BridgeSupport, does anybody know where the most recent source code for that project went? It seems to have been removed from Apple's Mac OS Forge after Laurent Sansonetti left Apple. A shame. [1] - For example, http://merbist.com/2011/02/19/bridgesupport-build/ http://merbist.com/2011/02/19/bridgesupport-build/ . The chapter referenced from O'Reilly's excellent MacRuby book does a better job of explaining the whole process.
  - dottrap 13y ago
    BridgeSupport also supplies .dylibs containing inline functions/macros that don't have symbols/linkage in the main framework. While it is possible to workaround the lack of BridgeSupport, if Apple doesn't supply it, most developers are not going to go through the effort of using it. And if Apple doesn't supply it on iOS, they aren't going to make life nice for developers doing this (continue bans on dynamic libraries for loading the .dylib containing missing symbols, on mprotect which is horribly useful for things like subclassing and block generation and JIT). I don't know where the source went. I'm sad to hear that. If you find a copy, let me know.
    - nglevin 13y ago
      You may be in luck, sir or ma'am. It looks like the one man army behind Mobiruby found a copy; https://github.com/mobiruby/BridgeSupport https://github.com/mobiruby/BridgeSupport Which he found from a really neat looking archive for popular open source projects, at that. Bookmarking. http://code.metager.de/source/ http://code.metager.de/source/ Just made a few fixes to get the BridgeSupport framework to compile on 10.8. Might issue a pull request.
vor_ 13y ago
> The most interesting possiblility would be that this is the start of Apple’s evolution away from Objective-C into promoting a higher-level language for their platform That seems like an enormous leap of speculation.
TheZenPsycho 13y ago
Every HN post that happens to mention Javascript: "Javascript is so shitty though!" "I agree!" "Javascript isn't so shitty once you get used to it" "It's like lisp!" "No it isn't. Javascript is terrible and everyone who likes it is a moron" "No they aren't!" "YES THEY ARE" I don't know, should we expect more from the discourse here than just rehashing the same argument over and over again?

160 points by micheljansen 13y ago

A fast objc/javascript bridge that works on iOS and OSX today: https://github.com/marcuswestin/WebViewJavascriptBridge https://github.com/marcuswestin/WebViewJavascriptBridge

apike 13y ago

My guess is that this would be fast enough to build almost any Mac app and many iOS apps. The bigger question for me is, how gross would it be to deal with the "Objective-C-ness" of the Cocoa APIs through JavaScript?

Millennium 13y ago
That depends on the state of the bridge. Previous language bridges by Apple have generally bridged the gaps pretty well, with the main "Objective-C" relic being really, really long method names. That said, all of the bridges I've seen were to classical-OO languages. It is possible that Cocoa won't translate as well to prototypal-OO languages like JavaScript. It will be interesting to see how Apple navigates that paradigm shift.
- wwweston 13y ago
  > all of the bridges I've seen were to classical-OO languages. It is possible that Cocoa won't translate as well to prototypal-OO languages like JavaScript. This has already been done with Mozilla's Rhino (JavaScript or Java) and it turns out the be pretty easy to work with Java classes in that context.
- dottrap 13y ago
  JSCocoa has been there, done that. They even have optional Objective-J support.
nglevin 13y ago
Functionally, this appears to be identical to JavaScriptCore's longstanding C bridge [1]. If Objective-C isn't your preference, there's nothing stopping you from calling into the C bridge from C++ or just plain C. On iOS, developers have had to compile their own version of JavaScriptCore to use this API. That's the basis for HTML5 game engines like Impact [2], and some HTML5-to-Objective-C middleware platforms. Unfortunately, until Apple says otherwise, this version of JSC is still subject to Apple's App Store review guidelines [3]. Thanks to guideline 2.8, you can't have your app, running JSC, execute any JavaScript that doesn't ship within the bundle of your app. I'd like to see that rule change, someday. Exposing this Objective-C API in a future iOS release isn't going to change the status quo. [1] - http://developer.apple.com/library/mac/#documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/_index.html http://developer.apple.com/library/mac/#documentation/Carbon... [2] - http://impactjs.com http://impactjs.com [3] - https://developer.apple.com/appstore/guidelines.html https://developer.apple.com/appstore/guidelines.html
- apike 13y ago
  All good points. The big difference with the bridge going to Objective-C, though, is that I believe it is now possible to build a native UI by calling right from JavaScript to Objective-C. Impact is interesting for games and canvas-like rendering, but what I'd love is to be able to build the models and controllers of a highly performant, native-UI iOS app using JavaScript and UIKit. Sort of like Appcelerator with a layer removed.
  - nglevin 13y ago
    That's fair. This does save one ugly, extra step that I didn't mention, which would be to call into the Objective-C runtime's C API [1] to dispatch messages and introspect Objective-C classes. Should make it easier for developers to build their own middleware platform without getting too deep into reams of C boilerplate. [1] - https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html https://developer.apple.com/library/ios/#documentation/Cocoa...
- pi18n 13y ago
  You should be able to to run code downloaded as part of IAP also. But this is one of the major things I wish they would change, and also one of the major reasons I'll be switching to Android.
gsnedders 13y ago
On iOS it won't be that quick: you don't get anything more than the JS interpreter, as you cannot allocate any executable memory on iOS, so any JITing compiler is out of the question.
- udp 13y ago
  Wouldn't this be exempt from that limitation, with the JavaScript engine being distributed as part of iOS itself?
  - gsnedders 13y ago
    No, it applies per process: whether or not it came from a dynamically linked library distributed as part of the system is irrelevant. This is why UIWebView is slower outside of Safari.
    - pi18n 13y ago
      They might be moving towards some kind of XPC service so you can talk to a JIT through a Mach port. Speculation is my own, derived from: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/ http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-...
deleted 13y ago
[deleted]
jfb 13y ago
It's important to remember that Apple shipped both the Ruby and Python Objective-C bridges in ~10.5 era OS X. You can (and I have) written OS X native software in Python; it wasn't super pretty, but the concepts mapped across reasonably well. So I wouldn't take this as necessarily the sign of a shift in anything.
- dottrap 13y ago
  Also, people at Apple like Objective-C and its Smalltalk influences. For those of us who've been in the NeXT/Apple ecosystem a long time, it's clear that employees at Apple see Ruby as more interesting than say Javascript because of the Smalltalk influences. If any shift were to occur, money is on Ruby. But Apple likes Objective-C and no shift seems likely and we also saw what happened with MacRuby and the author leaving to do RubyMotion.
  - jfb 13y ago
    And they've invested a lot in the tooling and environment. It's not like they're just running a stock gcc toolchain; they've put a lot of very smart people on very hard problems in the language space.
    - dottrap 13y ago
      Agreed. And another problem is that all these interpreted languages are terrible at exploiting parallelism which is a problem as we get more processor cores. They were able to solve this in C by inventing Blocks and GCD.
- Moto7451 13y ago
  They used to have a Java bridge as well[1]. WebObjects moved from Objective C to Java at some point in the early '00s. [1]http://cocoadevcentral.com/articles/000024.php http://cocoadevcentral.com/articles/000024.php

zumbojo 13y ago

The "Siracusa County" reference refers to this Hypercritical episode: http://5by5.tv/hypercritical/15 http://5by5.tv/hypercritical/15

pooriaazimi 13y ago
Completely off-topic, but those (who like me, liked Hypercritical very much, but aren't active on Twitter to learn these things there), Siracusa has a new show here: http://atp.fm http://atp.fm It's not as good as Hypercritical, but is better than nothing!

1qaz2wsx3edc 13y ago

So with this marriage of Objective-C and JavaScript: How much longer until we can develop native applications without Objective-C entirely? A polygot/trans compiler for xcode would make me melt.

286c8cb04bda 13y ago
> How much longer until we can develop native applications without Objective-C entirely? You already can -- Lisp: Nu Ruby: MacRuby/RubyMotion Basic: Objective-Basic
- dottrap 13y ago
  Python: PyObjC Lua: LuaCocoa, LuaWax, TLC JavaScript: JSCocoa Perl: CamelBones More: http://cocoadev.com/wiki/CocoaBridges http://cocoadev.com/wiki/CocoaBridges
vor_ 13y ago
I don't understand the recurring drive people have for trying to write native applications without Objective-C. The various bridges and other glue projects never feel complete or as well-integrated with the system frameworks.

untog 13y ago

The future is arriving- slowly. Hopefully soon we will be able to make the core of our apps cross-platform by leveraging languages like Javascript, and only resorting to platform-specific code for UI layers. Here's hoping.

kybernetyk 13y ago
Uhm, why 'soon'? Just write the core of your application in C++ and marry said core with platform specific languages for UI code.
- untog 13y ago
  C++ is a lot less accessible than JavaScript, though.
- marknutter 13y ago
  Because C++ doesn't run in the browser
gte910h 13y ago
You can do this now with Xamarin's stack

jbverschoor 13y ago

How does this compare to cocos2d/zynga's JSB? The JavaScript Bridge

robterrell 13y ago
Cocos2d uses SpiderMonkey, not JavaScriptCore.

skw 13y ago

Thank god, obj-c is horrendous... I'm not sure what the point of using JS would be over something like MacRuby/RubyMotion...

apike 13y ago
Well for one, modern JavaScript engines are considerably faster than Ruby.
- deleted 13y ago
  [deleted]
seivan 13y ago
You would be missing out on cool stuff like Protocols :)

tyilo 13y ago

You can already use this with cycript on a jailbroken iPhone: http://www.cycript.org/ http://www.cycript.org/

seivan 13y ago

great for people wanting to script games and don't want to get into LUA :)

stcredzero 13y ago
> great for people wanting to script games and don't want to get into LUA :) Beware of people who are portraying themselves as "savvy" yet don't know how to spell Lua.
- seivan 13y ago
  Wow...
  - stcredzero 13y ago
    Beware of people who make "Wow" conclusions on very little data.
    - deleted 13y ago
      [deleted]

kybernetyk 13y ago

> The most interesting possiblility would be that this is the start of Apple’s evolution away from Objective-C into promoting a higher-level language for their platform The thing is: Why would they want to transform away? As it is now Obj-C is pretty sane. The memory management is now a non-brainer so that even people who come from managed languages can grasp it. GCD is great for concurrency. And using C and C++ based 3rd party libraries is trivial. The existing developer base is fine with Obj-C. So maybe Apple wants to attract new developers? But why now? If they really wanted to attract new developers to their platform they would have chosen a different language for the iPhone SDK back when they released it first. But nowadays Apple's platforms have more than enough developers. Also: Why JavaScript? JS itself is a terrible language with many inconsistencies and is unfit for larger projects - which most native applications are. There are far better and saner languages to base a new SDK upon.

seivan 13y ago
I agree, there is something very special about OBJ-C these days. With subscripts, literals and even in the past with Protocols doing service objects were a breeze. GCD is amazing and I use it more than NSOperation for easy quick off stuff. That being said, I can see how this would be useful for gamedevelopers who wanna keep their scripts in JS/CoffeeScript instead of LUA :-)
jfb 13y ago
Maybe I've just swallowed the Kool-Aid, but I don't see the putative benefits of Apple's switching platforms. I'm also not clear on how many people there are who a) can write non-trivial software and b) can't learn a C derivative language who c) would actually write software for Apple's platforms. It just seems like a pretty small set. And, if Apple were to switch, why would they pick a language as shitty as Javascript?
- caycep 13y ago
  But it has Good Parts(tm)!
  - 13y ago

rogerbinns 13y ago

Are the interpreted code download app store rules still in place? ie can an app download additional JS at runtime or does everything still have to bundled?

joebeetee 13y ago

What does this mean for tech like Phonegap/Cordova?

tolmasky 13y ago

This just seems like an evolution of the existing Obj-C/JS bridge (namely, WebScriptObject https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Classes/WebScriptObject_Class/Reference/Reference.html#//apple_ref/doc/c_ref/WebScriptObject https://developer.apple.com/library/mac/#documentation/Cocoa... and WebScripting protocol https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Protocols/WebScripting_Protocol/Reference/Reference.html https://developer.apple.com/library/mac/#documentation/Cocoa... ). The main (very welcome) advancement seems to be that they've pushed this capability down from WebKit into JSCore. Today you can basically already do everything that's being shown in OP I think, you just were required to create an invisible WebView to host your JavaScript environment. You can easily expose classes to WebKit/JSCore (using KVC), and interact with JS objects from ObjC, and arrays, strings, etc. are auto-converted. The WebKit requirement is pretty annoying though, and as V8 has shown us, having a drop dead simple way of throwing JS into an app has some huge benefits.

nbrooke 13y ago
Good catch, I hadn't seen that before. It definitely looks like WebScript and the new JavaScriptCore API are strongly related. It's interesting how hard the WebScript stuff is to find without knowing the name, it didn't turn up in any of my Googling when researching the post. The fact that it's a refactoring (even a very nice one, as it seems to be) rather than a brand new API does make it less likely that Apple has any particular future plans for the API, which in turn make much of the speculation in the post even more speculative. I'm going to make an update to the post with a link to WebScript as well as a bit of additional commentary.
yoda_sl 13y ago
Totally agree it's more like an evolution, and I doubt it will be exposed on iOS at all, which means the same developer rules will apply and downloaded JS will have to be running inside a UIWebView. The fact is that after thinking about the iOS developer rules and what is currently available in iOS, it's totally doable to write a true Javascript bridge that respect all the requirement from the iOS rules and still let your JS code access all the ObjC runtime, in a totally transparent way aka I am able to write the following: var userName = userNameTextfield.getText(); var helloMsg = "Hello " + userName; messageLabel.setText(helloMsg); The first line will directly get the text value of a UITextField (no callback used here), and it will end up calling directly the 'text' property on the UITextField. So the JS bridge works transparently where JS code call native ObjC code directly (without using callback) and obviously ObjC can directly access the JS side... there are a few gotcha but the full system works beautifully and surprising enough performance are quite good. It took me a few years to come up with the cleanest solution and implementation. I am currently working on integrating such piece of code into some of my apps and have them released on the AppStore. In fact if anyone good in JS is interested I would really appreciate some help to get that bridge off the ground since I truly believe there is a lot of great opportunities with a JS bridge to ObjC that respect all iOS rules. My contact info are my HN profile. Edit: minor typo fixed

chaostheory 13y ago

I never had a big problem with Obj-C. It felt like any other language other than having to manually manage memory. The problem I struggled with was Cocoa as a whole. It may no longer be the case but not too long ago, there was a lack of consistency between the different APIs / SDKs. Most would written and accessed with Obj-C. A few would still be in Ansi-C. For someone who isn't a C expert, this just killed me. Does this bridge help fix that?

kenrikm 13y ago
Yeah, like the iOS contacts API. I really like Objective C. (I better since I write it full time, lol)
- chaostheory 13y ago
  Geez that's still a problem? They really need to change that.

stcredzero 13y ago

Cue the typical and tiresome language-wars snark. (And time to burn some karma.) This kind of behavior is often just a shallow and distinctly anti-intellectual "irrational jingoism." If you read between the lines, so much of it just comes down to "I don't like X. I don't understand X. Doing X in the programming I do wouldn't work. It just must be bad." That's so often just about outward signs. Programming is complicated, and the fields of programming and Computer Science are vast. If you're not aware of how miniscule a sliver of the whole thing you command, odds are you're just another unwitting Dunning Krueger victim. Don't judge a language by what you find strange. Don't judge a language just because it wouldn't suit what you do. Figure out what makes it powerful and why it works. Until you do that, please just shut up and don't add to the noise.

dottrap 13y ago

This has already been done by JSCocoa. http://inexdo.com/JSCocoa http://inexdo.com/JSCocoa It's only interesting because Apple is officially doing it themselves.

dottrap 13y ago

This will probably be Mac-only. It will not appear on iOS unless Apple also ships BridgeSupport on iOS. BridgeSupport is needed for binding all the Obj-C parts that don't have introspection capabilities (like the C parts). This is how most of the other full feature bridges work, PyObjC, RubyCocoa/MacRuby, LuaCocoa. Otherwise you are hamstrung anytime you need to deal with something like a C struct (e.g. NSPoint).

nglevin 13y ago
As I recall, BridgeSupport created indexes to C symbols, enumerations and functions by producing XML files [1] that corresponded to C APIs like CoreGraphics, and code you produced yourself. You don't necessarily need BridgeSupport to call out to Objective-C. Speaking of BridgeSupport, does anybody know where the most recent source code for that project went? It seems to have been removed from Apple's Mac OS Forge after Laurent Sansonetti left Apple. A shame. [1] - For example, http://merbist.com/2011/02/19/bridgesupport-build/ http://merbist.com/2011/02/19/bridgesupport-build/ . The chapter referenced from O'Reilly's excellent MacRuby book does a better job of explaining the whole process.
- dottrap 13y ago
  BridgeSupport also supplies .dylibs containing inline functions/macros that don't have symbols/linkage in the main framework. While it is possible to workaround the lack of BridgeSupport, if Apple doesn't supply it, most developers are not going to go through the effort of using it. And if Apple doesn't supply it on iOS, they aren't going to make life nice for developers doing this (continue bans on dynamic libraries for loading the .dylib containing missing symbols, on mprotect which is horribly useful for things like subclassing and block generation and JIT). I don't know where the source went. I'm sad to hear that. If you find a copy, let me know.
  - nglevin 13y ago
    You may be in luck, sir or ma'am. It looks like the one man army behind Mobiruby found a copy; https://github.com/mobiruby/BridgeSupport https://github.com/mobiruby/BridgeSupport Which he found from a really neat looking archive for popular open source projects, at that. Bookmarking. http://code.metager.de/source/ http://code.metager.de/source/ Just made a few fixes to get the BridgeSupport framework to compile on 10.8. Might issue a pull request.

vor_ 13y ago

> The most interesting possiblility would be that this is the start of Apple’s evolution away from Objective-C into promoting a higher-level language for their platform That seems like an enormous leap of speculation.

TheZenPsycho 13y ago

Every HN post that happens to mention Javascript: "Javascript is so shitty though!" "I agree!" "Javascript isn't so shitty once you get used to it" "It's like lisp!" "No it isn't. Javascript is terrible and everyone who likes it is a moron" "No they aren't!" "YES THEY ARE" I don't know, should we expect more from the discourse here than just rehashing the same argument over and over again?