I already read some post about the why use embedded script language but I want to ask when to use it.

I have implemented an Objective-C / Javascript binding framework which allow me to write Javascript to use any Objective-C classes and methods. I found it very useful for debugging purpose because I can check / modify the internal state of my app at runtime. But I also found I still prefer to write ObjC code instead of JS code when building my app for some reasons:

  • Code completion. If I want to call some UIKit method froom JS, I often have to check the document for its name compare to just type first few letters and let Xcode complete it for me in ObjC.
  • All the benefit of static typed language. ObjC is static typed and dynamic typed language so compiler can do lots type checking for me when possible.
  • Performance?
  • C binding to JS not ready yet (this required to parse header and generate code to expose C function, enum, struct, etc)
  • More natural to write ObjC when dealing with ObjC methods. (e.g. in JS write code like view.setEdit_animated(true, true) compare to ObjC [view setEdit:YES animated:YES]

But I feel I should write more JS code so I can take the benefit scripting language (e.g. replace methods with bug fixes at runtime)

I am not sure which part of my app should be written in JS and which part should be written in ObjC. Any advice?

Also any design pattern can be used for embedded script language?

  • Clarify what you mean in the second part of your question. It's not really related to the first. Yes there are design patterns that can be used. Are you talking about patterns that are useful when using them or building them?
    – user28988
    Sep 6, 2013 at 0:26
  • @WorldEngineer what is the difference between "using them" and "building them"?
    – Bryan Chen
    Sep 6, 2013 at 0:37

1 Answer 1


There are two main benefits of scripting in my opinion:

  • it is usually faster
  • and it is usually faster

The first faster is for JIT compilation and underlying C interpreters that most languages have and the second one is for not needing to recompile your code.

Scripting should be used whenever you want to quickly change behavior without the need of recompilation. So you probably want to script the user interface and just tell it how to connect to the binary code. Writing GUIs in statically typed languages is most likely hard and complex. Most scripting languages are also useful when you want to do things like events or implement simple behavior in certain parts of your application.

The benefit of splitting it is, that you get a program core that is compiled once, and a number of script files that maybe make up your application behavior. So actually there is a third advantage to it: Scripting is usually faster. This time in terms of application development. You just adapt a script file and run your program again, or even change scripts at runtime and the immediately see the results.

One field where applications in native binaries are really faster than scripts is when it comes to hardware interaction and OS calls. Since scripting usually is intended to be cross-platform, you are likely to have to use the native libraries for applications. Scripting languages would have to wrap them, applying a performance penalty. And also Interpreters have their own threading model and garbage collection. If you need control over these facilities, choose native binaries.

  • I already use script to control the appearance of UI (e.g. button color, text font) but other than that use script to actually write GUI code seems hard for me because the API are provided natively. So should I try wrap the API with script interface? (make something like xaml but more scriptable?)
    – Bryan Chen
    Sep 11, 2013 at 11:57
  • The pragmatic answer is: If its unnecessary effort and hard to do, just use what you have and what you are confident with. To "invent" a GUI toolkit from scratch just to make it scriptable seems like a lot overhead.
    – HaMster
    Sep 11, 2013 at 12:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.