Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore

by srijs • 13 years ago

30 14 13 years ago

srijs6• 13 years ago

This is very rough and no IO is supported yet. However, I think it serves well as a proof-of-concept that a lightweight node-compatible interface can be done for mobile apps using javascript.

Tell me what you think! :)

zekenie• 13 years ago

Neat! Is the iOS 7 JavaScriptCore V8? It can't be, though right? Safari?

srijs6• 13 years ago

JavaScriptCore is a cross-platform javascript engine on it's own that is used by default in WebKit browsers (Safari, Mobile Safari, Konqueror, etc.).

The new thing on iOS 7 is that this framework is exposed as a public API you can code against. So you don't have to initialize a heavy-weight WebView just to execute Javascript.

zw• 13 years ago

Safari gets Nitro, Apple's JIT, but historically it has been unavailable to apps (via UIWebView) for security reasons. I'm unsure if the new Objective-C JavaScriptCore API gets Nitro.

robterrell• 13 years ago

IIRC the JIT requires an entitlement that (so far) non-Apple apps can't get, even with iOS 7's JSC.

outside1234• 13 years ago

very nice - keep up the good experimentation!

srijs6• 13 years ago

Thanks :)

eddieh• 13 years ago

This is similar to something I've been wanting to do for quite some time. In contrast to your approach (binding JavaScriptCore at the Objective-C level) I want to start with the JavaScriptCore's command-line interpreter. It's currently a barebones interpreter. I would start by adding some missing primitives to the interpreter getting it closer to the V8 developer console (d8). Then work from there.

Good work though. It's nice to see that I'm not the only person that has thought about a Node-like system built on JSC rather than V8. I wonder if you looked at the source for both V8 and JSC, and then concluded JSC would be much nicer to work with? That's what I did initially.

I wish I had time to pitch in right now...

srijs6• 13 years ago

I did some evaluation a while ago about bundling a Javascript engine with mobile apps on iOS and concluded JSC was way easier to compile and integrate. This is in fact what e.g. Appcelerator Titanium does currently. However, this bundling results in huge binaries, which is not very nice for mobile platforms.

The thing that got me into hacking the prototype was the release of JSC as a public system framework on iOS7, eliminating the need to separately bundle JSC. So its not really a platform preference, I'm just trying to work with what's currently there...

SchizoDuckie• 13 years ago

Can't wait to see where this goes. Looks like an excellent start. Actually, I hope Apple wanted this to happen. Hack on my man, Hack on!

erichocean2• 13 years ago

NOT to integrate libuv

Please reconsider this. Libuv rocks, and without it, well, you don't really have Node. It's not dependent on v8 in any way, so it makes little sense to not use it.

srijs6• 13 years ago

Thanks a bunch for your feedback :)

My initial plan was to provide the node features using Foundation.framework features only. Now, this could turn out to be more boilerplate code than I intended to write and if it does, I'm now pretty sure I'd go with libuv.

I'm not quite sure about using libuv from the start, though. My consideration was that a) this is not targeted at server applications, so you don't necessarily need very high performance and b) libuv is a cross-platform library, while I'm targeting darwin only, so it might be a bit overkill.

Do you have experience with libuv? If so, do you have experience regarding footprint / conciseness? Can you confirm/deny my presumptions?

erichocean2• 13 years ago

Even the non-server parts of Node are, at a low level, mostly implemented with libuv. And obviously, the APIs in libuv map very closely to Node, so there's less of an impedance mis-match between that and the Foundation framework.

I've written quite a bit in both Node, and in libuv directly, as well as against the Foundation APIs (although less these days, because libuv's APIs are just really, really well done). IMO, you'll write less code, with far less errors, if you decide to build on top of libuv, and you won't lose anything that Foundation gives you (they're both wrappers around the underlying Unix APIs anyway...).

http://nikhilm.github.io/uvbook/introduction.html is a nice introduction to libuv. You should be able to make a good decision after browsing through that.

-E

Show HN: Proof-of-concept Node.JS-like interface with iOS 7 JavaScriptCore

Related Stories