Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple's new Objective-C to Javascript Bridge

steamclock.com

Post reply on HN
Print view View original

81–90 of 110 posts

Re: Apple's new Objective-C to Javascript Bridge

#81

Post by to3m »

zackbloom wrote: post #31
jfb wrote: post #26

Earlier quoted context omitted.

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 Javascri…

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

And the global object nonsense alone is enough to make it suck. Throw in the lack of an integer type, the curious `for each' statement, and the oddities surrounding `this', and it really starts to feel like this is the sort of language that over time is going to cause you a lot of heartache. It makes me sad - seriously, do people not expect better from their tools?

The maddening thing is that Javascript could so easily be vastly better, and it wouldn't take all that much. Remove any kind of implicit binding (and this could easily be optional, like Visual BASIC's option strict, or the similar thing in perl) and you'd be about 75% of the way there, in my view.

It would take a bit more to convince me that this kind of language is suitable for larger-scale projects - this based on my experience with pretty much any language that isn't statically typed - but this would at least remove one obvious type of error without impinging too much on what people appear to see as their freedoms.

Re: Apple's new Objective-C to Javascript Bridge

#82

Post by gsnedders »

udp wrote: post #45
gsnedders wrote: post #16

Earlier quoted context omitted.

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.

Wouldn't this be exempt from that limitation, with the JavaScript engine being distributed as part of iOS itself?

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.

Re: Apple's new Objective-C to Javascript Bridge

#83

Post by yoda_sl »

tolmasky wrote: post #38

This just seems like an evolution of the existing Obj-C/JS bridge (namely, WebScriptObject https://developer.apple.com/library/mac/#documentation/Cocoa... and WebScripting protocol 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…

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

Re: Apple's new Objective-C to Javascript Bridge

#84

Post by kcase »

kybernetyk wrote: post #23

> 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++ base…

Rather than this being the start of an evolution away from Objective C (which to me seems both unlikely and terrible), I wonder if it could be the start of an evolution away from AppleScript towards a user-scripting language that is easier to sandbox, more portable, and is familiar to a lot more script writers?

Re: Apple's new Objective-C to Javascript Bridge

#85

Post by ryanpetrich »

yoda_sl wrote: post #83
tolmasky wrote: post #38

This just seems like an evolution of the existing Obj-C/JS bridge (namely, WebScriptObject https://developer.apple.com/library/mac/#documentation/Cocoa... and WebScripting protocol 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…

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…

Synchronous XMLHTTPRequest connected to an NSURLProtocol?

Re: Apple's new Objective-C to Javascript Bridge

#86

Post by u2328 »

jfb wrote: post #39
u2328 wrote: post #34

Earlier quoted context omitted.

Have you ever written any significant amount of JavaScript?

Enough to not want to do any more.

I take that as a "no."

I grew up as a programmer through C++ and Java, and the first time I ever worked on a JavaScript project, I hated it, and I said the same thing about JavaScript as you did. That's because I was thinking like a Java programmer, and not just a programmer. As I worked more and more with JavaScript, I've grown to love. It has it's pitfalls, sure, but there's just so much flexibility in JavaScript than languages like Java or C++. Nowadays, I prefer it to Java or C++. Even for server-side programming. I get the feeling that you don't really know enough to know what you're missing.

Re: Apple's new Objective-C to Javascript Bridge

#88

Post by pi18n »

ldh wrote: post #44
zackbloom wrote: post #31

Earlier quoted context omitted.

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

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

I think this comment would have been better if you had listed some insanities that make Javascript unusable. It doesn't seem objective at the moment. I, for one, honestly cannot think of what you might be referring to, but I only have a passing knowledge of Javascript so I cannot really decide if you are the GP have made the better point.

Re: Apple's new Objective-C to Javascript Bridge

#89

Post by pi18n »

nglevin wrote: post #6
apike wrote: post #2

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?

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…

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.

Re: Apple's new Objective-C to Javascript Bridge

#90

Post by pi18n »

gsnedders wrote: post #82
udp wrote: post #45

Earlier quoted context omitted.

Wouldn't this be exempt from that limitation, with the JavaScript engine being distributed as part of iOS itself?

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.

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

Post reply on HN