5 ms·

JSC was always there for years in WebKit source repository, and anybody could build native JSC engine. Well, it needs some extra works, but there're also some G

by eonil 13y ago

JSC was always there for years in WebKit source repository, and anybody could build native JSC engine. Well, it needs some extra works, but there're also some Github repos from other people. AFAIK, the only difference to Safari was JIT compilation support. Because iOS doesn't allow executing dynamically generated machine code in 3rd-party apps for security reason. Does iOS7 support JIT compilation on JSC embedded in any app? If it supports JIT, that could be a big news, because it means Apple finally allowed dynamically generated code in 3rd-party apps, but I don't think the day will come. And personally, I don't see any benefit from JavaScript apps. If someone claims JS or any third party frameworks are better than Objective-C for iOS app, I would like to ask these things. (could be offensive, but these are actually how I feel from those claims) Does it offer better auto-completion? Does it offer better syntax/semantic/type checks? Does it offer better debugging aid? (like GDB's execution rollback) Does it offer better accessibility to any platform features? Can I use new features immediately? Shouldn't I wait for 3rd party patch? Profiler for device and simulators? How's low-level access? If I have some trouble, how can I fix it without knowledge for lower-level (Cocoa/Darwin)? If I want to use C-based DSL? Is it safe for AppStore approval? What's the benefit of using open language on proprietary platform? I mean, what's better with JS than Objective-C with Xcode? If it can't offer any of those stuffs, it means it's at least 10 times less productive = 10 times more cost. Well, it could make sense JS app for an Android app because ADT is too sucks so some extra wrapper can bring extra productivity. But for iOS, JS stuffs only degrade productivity by extra abstraction, debugging hardness and inferior toolsets.

apaprocki 13y ago
AFAIK they will never allow JIT. It isn't so much banning JIT as it is the kernel providing no way for applications to mark memory pages executable. Marking memory executable is how JIT compilers function, but it also prevents other uses.
- phoboslab 13y ago
  I still have hopes that Apple cares enough and finds a way to whitelist the JSC lib somehow. Not sure exactly how that would work, because permissions to allocate executable memory is given per process on iOS. But I guess they could inspect the call stack to see if the allocating call indeed comes from the built-in JSC lib?
  - apaprocki 13y ago
    Can't predict the future -- but I do not think they will ever do it after talking to @radian at JSConf.EU.
  - dunham 13y ago
    They might be able to support JIT by moving webkit out of process. I believe they do this now with the Mail UI. For more info see: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/
  - mistercow 13y ago
    They could potentially do it with IPC, running the JS engine (or even the entire web view) in a separate process. The question then is whether the communication overhead can be minimized so that it doesn't cancel out the performance benefits of the JIT.
    - eonil 13y ago
      They're doing that for Quartz. But I doubt what will drive Apple to improve JS performance. Because making people to use Objective-C is a lot beneficial to Apple.
      - mistercow 13y ago
        Interesting. If they're doing it for Quartz, then that pretty much answers the overhead question. I suspect you are right that Apple feels very little motivation to improve support for languages and environments that don't lock you into their system. Or at least, they wouldn't have under Jobs. But I don't think it is true that this strategy is actually more beneficial to Apple. Developers want to support multiple platforms, and the least expensive way to do that is often HTML5. That's why PhoneGap is popular, despite the poor JS performance. The extra cost of doing separate apps is ultimately paid not only by third party developers, but by Apple as well. To make a long story short, encouraging a cross platform environment would allow good developers to make higher quality apps. Much as I dislike Apple these days, the difference between iOS and Android is such that I have trouble maintaining a straight face when I hear them compared. They don't need to compete on app availability.
- antimagic 13y ago
  More exactly, the kernel does provide a way for applications to mark memory pages as executable (which is exactly what Safari does, after all), but you need to have the right permissions to use the API, and App Store apps don't have those permissions...
  - edvinbesic 13y ago
    Even more exactly, there are ways but if you use them there is no way to publish on the App Store, because private API. There is no reason not to have JIT or WebGL in a WebView other then apple not wanting you to, even though this was the original vision of the platform.
general_failure 13y ago
Agree with your comment mostly except for the android remark. I found iOS and cocoa terribly hard. Xcode is unusable and honestly the terms used in programming g like first responder are arcane. Android was much more approachable for me and java is quite sane compared to obj c.
- eonil 13y ago
  It seems obvious that we have different linguistic taste. Though I have used Eclipse for a while a few years ago, now I really can't go back to there.
untog 13y ago
I mean, what's better with JS than Objective-C with Xcode? Cross-platform portability, for one. I know it's a long way off, but being able to use JS as a first-class language on all mobile platforms would be a fantastic step forwards.
- eonil 13y ago
  IMO, it would be better to hire another Android developer with saved cost. And why should we step to a language which cannot offer any benefit? Even if it happen, it seems just a huge step backward. For portability, I don't think JS is portable. Because portability doesn't come from a language. It comes from implementations by platform vendors. It's purely up to how platform vendors support the compatible language and feature set implementation. JS itself has nothing special in portability. Though all the browser vendors are supporting JS, it doesn't mean native platform vendors are interested in JS. For the real serious portability, I think the only choice are C/C++ which are the CURRENTLY AVAILABLE de facto portability layer on ANY platform while keeping most of the benefits I mentioned. Including mobiles, desktops, servers, game consoles, embedded devices and even on web-browsers. And also for any new unknown future platforms. C/C++ support is virtually promised due to its superior range of existing portability. And intermixing them with Objective-C is literally natural, and far easier then JS.

by eonil 13y ago

apaprocki 13y ago

AFAIK they will never allow JIT. It isn't so much banning JIT as it is the kernel providing no way for applications to mark memory pages executable. Marking memory executable is how JIT compilers function, but it also prevents other uses.

phoboslab 13y ago
I still have hopes that Apple cares enough and finds a way to whitelist the JSC lib somehow. Not sure exactly how that would work, because permissions to allocate executable memory is given per process on iOS. But I guess they could inspect the call stack to see if the allocating call indeed comes from the built-in JSC lib?
- apaprocki 13y ago
  Can't predict the future -- but I do not think they will ever do it after talking to @radian at JSConf.EU.
- dunham 13y ago
  They might be able to support JIT by moving webkit out of process. I believe they do this now with the Mail UI. For more info see: http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/
- mistercow 13y ago
  They could potentially do it with IPC, running the JS engine (or even the entire web view) in a separate process. The question then is whether the communication overhead can be minimized so that it doesn't cancel out the performance benefits of the JIT.
  - eonil 13y ago
    They're doing that for Quartz. But I doubt what will drive Apple to improve JS performance. Because making people to use Objective-C is a lot beneficial to Apple.
    - mistercow 13y ago
      Interesting. If they're doing it for Quartz, then that pretty much answers the overhead question. I suspect you are right that Apple feels very little motivation to improve support for languages and environments that don't lock you into their system. Or at least, they wouldn't have under Jobs. But I don't think it is true that this strategy is actually more beneficial to Apple. Developers want to support multiple platforms, and the least expensive way to do that is often HTML5. That's why PhoneGap is popular, despite the poor JS performance. The extra cost of doing separate apps is ultimately paid not only by third party developers, but by Apple as well. To make a long story short, encouraging a cross platform environment would allow good developers to make higher quality apps. Much as I dislike Apple these days, the difference between iOS and Android is such that I have trouble maintaining a straight face when I hear them compared. They don't need to compete on app availability.
antimagic 13y ago
More exactly, the kernel does provide a way for applications to mark memory pages as executable (which is exactly what Safari does, after all), but you need to have the right permissions to use the API, and App Store apps don't have those permissions...
- edvinbesic 13y ago
  Even more exactly, there are ways but if you use them there is no way to publish on the App Store, because private API. There is no reason not to have JIT or WebGL in a WebView other then apple not wanting you to, even though this was the original vision of the platform.

general_failure 13y ago

Agree with your comment mostly except for the android remark. I found iOS and cocoa terribly hard. Xcode is unusable and honestly the terms used in programming g like first responder are arcane. Android was much more approachable for me and java is quite sane compared to obj c.

eonil 13y ago
It seems obvious that we have different linguistic taste. Though I have used Eclipse for a while a few years ago, now I really can't go back to there.

untog 13y ago

I mean, what's better with JS than Objective-C with Xcode? Cross-platform portability, for one. I know it's a long way off, but being able to use JS as a first-class language on all mobile platforms would be a fantastic step forwards.

eonil 13y ago
IMO, it would be better to hire another Android developer with saved cost. And why should we step to a language which cannot offer any benefit? Even if it happen, it seems just a huge step backward. For portability, I don't think JS is portable. Because portability doesn't come from a language. It comes from implementations by platform vendors. It's purely up to how platform vendors support the compatible language and feature set implementation. JS itself has nothing special in portability. Though all the browser vendors are supporting JS, it doesn't mean native platform vendors are interested in JS. For the real serious portability, I think the only choice are C/C++ which are the CURRENTLY AVAILABLE de facto portability layer on ANY platform while keeping most of the benefits I mentioned. Including mobiles, desktops, servers, game consoles, embedded devices and even on web-browsers. And also for any new unknown future platforms. C/C++ support is virtually promised due to its superior range of existing portability. And intermixing them with Objective-C is literally natural, and far easier then JS.