Apple's new Objective-C to Javascript Bridge
steamclock.com
Apple's new Objective-C to Javascript Bridge
1–10 of 110 posts
Re: Apple's new Objective-C to Javascript Bridge
#2My 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?
Re: Apple's new Objective-C to Javascript Bridge
#3My 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?
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.
Re: Apple's new Objective-C to Javascript Bridge
#4The "Siracusa County" reference refers to this Hypercritical episode: http://5by5.tv/hypercritical/15
Re: Apple's new Objective-C to Javascript Bridge
#5The "Siracusa County" reference refers to this Hypercritical episode: http://5by5.tv/hypercritical/15
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
It's not as good as Hypercritical, but is better than nothing!
Re: Apple's new Objective-C to Javascript Bridge
#6My 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?
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...
[2] - http://impactjs.com
Re: Apple's new Objective-C to Javascript Bridge
#7So 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.
Re: Apple's new Objective-C to Javascript Bridge
#8My 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?
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. Unfor…
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.
Re: Apple's new Objective-C to Javascript Bridge
#9Earlier quoted context omitted.
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. Unfor…
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 l…
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...
Re: Apple's new Objective-C to Javascript Bridge
#10The 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.