
Apple's new Objective-C to Javascript Bridge - micheljansen
http://www.steamclock.com/blog/2013/05/apple-objective-c-javascript-bridge/
======
kybernetyk
> 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.

~~~
jfb
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_?

~~~
zackbloom
Closures + Lexical Scoping + Prototypical Inheritance makes for a pretty great
language IMHO.

~~~
ldh
Those things are indeed nice, but they can't defend against the other
insanities that come in the box with them.

~~~
gcr
Only a subset of Javascript is useful, just like how only a subset of C++ is
useful, just like how only a subset of Objective-C is useful, just like how
only a subset of Haskell is useful, ...

~~~
yen223
Wasn't there a saying: "90% of everything is crap"?

------
tolmasky
This just seems like an evolution of the existing Obj-C/JS bridge (namely,
WebScriptObject
[https://developer.apple.com/library/mac/#documentation/Cocoa...](https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Classes/WebScriptObject_Class/Reference/Reference.html#//apple_ref/doc/c_ref/WebScriptObject)
and WebScripting protocol
[https://developer.apple.com/library/mac/#documentation/Cocoa...](https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Protocols/WebScripting_Protocol/Reference/Reference.html)
).

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.

~~~
yoda_sl
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

~~~
orta
I accepted a pod to cocoapods recently that does most of what you're after:
<https://github.com/marcuswestin/WebViewJavascriptBridge>

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

~~~
nglevin
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...](http://developer.apple.com/library/mac/#documentation/Carbon/Reference/WebKit_JavaScriptCore_Ref/_index.html)

[2] - <http://impactjs.com>

[3] - <https://developer.apple.com/appstore/guidelines.html>

~~~
apike
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
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...](https://developer.apple.com/library/ios/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html)

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

~~~
pooriaazimi
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!

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

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

------
dottrap
This has already been done by JSCocoa. <http://inexdo.com/JSCocoa>

It's only interesting because Apple is officially doing it themselves.

------
chaostheory
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
Yeah, like the iOS contacts API. I really like Objective C. (I better since I
write it full time, lol)

~~~
chaostheory
Geez that's still a problem? They really need to change that.

------
dottrap
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
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/> . The
chapter referenced from O'Reilly's excellent MacRuby book does a better job of
explaining the whole process.

~~~
dottrap
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
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>

Which he found from a really neat looking archive for popular open source
projects, at that. Bookmarking.

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

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

------
joebeetee
What does this mean for tech like Phonegap/Cordova?

------
1qaz2wsx3edc
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
_> 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
Python: PyObjC

Lua: LuaCocoa, LuaWax, TLC

JavaScript: JSCocoa

Perl: CamelBones

More: <http://cocoadev.com/wiki/CocoaBridges>

------
untog
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
Uhm, why 'soon'? Just write the core of your application in C++ and marry said
core with platform specific languages for UI code.

~~~
untog
C++ is a lot less accessible than JavaScript, though.

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

~~~
robterrell
Cocos2d uses SpiderMonkey, not JavaScriptCore.

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

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

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

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

~~~
stcredzero
_> 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
Wow...

~~~
stcredzero
Beware of people who make "Wow" conclusions on very little data.

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

~~~
apike
Well for one, modern JavaScript engines are considerably faster than Ruby.

