Javascript vs. C# for an experienced programmer

I’m digging to my first Unity project and wondered about the advantages and disadvantages of Javascript vs. C#. I’m a very experienced C++ and Java programmer so C# doesn’t scare me. I’ve also written javascript. Knowing that, which language should I choose? I’m looking for the most powerful solution but also compatibility, support, etc.

I know this has probably been answered in another thread, so I apologize for repeating.

Thanks,

Brian

None is more powerful than the other – they all use the same library (mono) underneath.

Go with whatever you feel more comfy with.

I’ve gone with a duel system of:

  • for scripts that get attached to objects in my scenes, I use JS as, to me, it looks cleaner (just write the function handler and off ya go)
  • for plugin classes, I use C# as to me it’s cleaner when writing multiple classes and full logic.

I’ve been warned about mixing languages so will pass that along, too. However, Unity compiles different levels of code at different stages. The warning is mixing languages within the same level of compilation. Plugin classes (scripts that you put in your Plugins/ folder) get compiled before the scripts attached to your hierarchy and could care less what the other is coded in. But within your hierarchy I hear it is best to stick to one language.

Thanks for the reply. What about the basic power of javascript vs. C#. I’m not an expert with either, but doesn’t C# offer more OOP functionality (more powerful inheritance, etc.)

– Brian

From what I have seen, C# and javascript both do the same thing. I find javascript is generally better, simpler code, less typing, not having to rename your class to match your file every time you decide to change a !@#$% file name, etc. Also, it seems to be a tweaked jscript.net, basically the javascript version of C#, so google accordingly. With all that said, the choice seems to be left to preference.

Oh, and the docs all have javascript examples. Probably not a problem for you, but it’s something to consider.

Do’h! two other posts in front of me! That’s not nice :wink:

Also, just crossed my mind: Introducing JScript .NET | Microsoft Learn has an introduction to Jscript.net. So far all that code seems to work (well, it looks like it would work anyway…). Some of the specs you’re looking for might be in there.
Now let’s see how many more posts sneak in behind me while I’m typing this :lol:

Libraries aside, C# definitely is more “powerful”. Something may require a bit more typing (but not much!) to do the same thing in JS, but C# offers a lot that JS doesn’t. A few that I use a lot is the ability to define structs, interfaces, static and abstract classes, and the use of anonymous functions/lambda expressions. That isn’t a very exhaustive, but it’s features I use on a daily basis :).

Did anyone ever do an exhaustive comparison?

I did a quick prototype in JS once and it was very nice and quick and clean, but…

As mentioned above C# seems to offer the better toolset. I have to say that there have been abilities here and there that Javascript had which surprised me. Can’t remember anything specific at the moment.

If you are comfortable with Java and C++, I’d say go C#. Just get ready for some casting. :wink:

Missed one: “using”. I just looked into this (I don’t use C#, so I don’t know all of it’s features), and found that “using whatever” Unity doesn’t seem to like.
Also, C# has classes, which javascript appears to not have. But they’re there, and they work (I know, I tried), so that’s disqualified :wink:.

One pro of C# that I didn’t think of earlier is, for MMO’s, how would the server be coded? I would use what I already know: Jscript.net/C# running with mono. Only problem is that Jscript.net was polished by OTEE significantly for Unity. Hence another win for C#.

But all in all, I think Trimmer is right: use javascript for the light stuff, and C# for the technical stuff. A good arrangement would be have the game engine in C# stashed in /plugins (or standard assets, etc), and the fluffier object code in javascript referencing the C#.

Well, I guess I have a C# book to read :?

Javascript uses “import”. Doing “import System.Threading” in JS is like doing “using System.Threading” in C#.

–Eric

Thank you! I was wondering how long it would be until the “spend the time to learn C#” craziness would end. Hmmm… about 25 minutes :lol:

all 3 languages have the same capabilities. The way to get there is a little different but the libraries are always the same.

Javascript only has one difference (a negative one, not positive) and thats dynamic typing, which, if you don’t enforce strict type declaration, has a pretty negative impact on performance.

I say you considered Boo. It is a nice language for the scripting. I tend to use use hashes and list a lot and it has very nice support for them in the syntax. to to deinfe and assign and then get a value back from a hash in boo

someObject , someObjectUsedAsIndex anythingYouWantToStore are any object or base type you want they don’t have to be the same type

aHash = {}
aHash[someObject] = anythingYouWantToStore
returned = aHash[someObjectUsedAsIndex]

It has AFAIK all the high level language constructs as C# but is much lighter on the keyboard. Boo has dynamic typing if you want by declaring the type Duck. I don’t use Duck anymore for Unity scripts. I suspect that Unity’s Javascript is written in Boo since writting DSLs is Boo’s Forte.

I consider dynamic typing a positive, not a negative. It can make things faster and easier to put together, sometimes significantly so. Having to use strictly enforced static typing all the time is a time-waster for me, so I just do things the easiest way possible, and only when scripts are actually done do I use “#pragma strict” and get rid of any dynamic typing that might exist. I don’t even do that for all scripts; if a function is only being called occasionally, it makes essentially zero performance difference whether you’re using dynamic typing or not.

Remember: premature optimization is the root of all evil. :wink:

–Eric

To add to that: I bet for 95% of projects out there, dynamic typing would make no impact on actual end-user speed.

Usually it’s high level algorithms or overall layout that causes slowdown (and of course, some slow graphics routines here or there).

I’ve written 3D graphics apps all in Python using nothing but nifty hashes all dynamically typed without a thought for speed that would make C programmers weep and things run fine. If I could, I’d write everything in Ruby! :slight_smile:

Not to say there are not times for efficient code at all. In fact, games are some thing where, depending on how you’re pushing the system, every millisecond counts. But, this is what you worry about after everything is running and you do some profiling and figure out where your bottlenecks are.

I used to be one of those crazy C/C++ guys that would worry about unrolling loops and if obj++ is faster than ++obj… now I want what allows me to get done what I want done with the least amount of mental code translation.

In summary: use what enables you to finish the project (as this is the true bottleneck for us indie developers) THEN worry about optimizing performance :slight_smile:

/jumps off of soapbox :slight_smile:

Quite agreed…as the project progresses I often end up having to delete or rewrite some code, so any time spent optimizing it first would be completely wasted. It’s also worth remembering that what you’re doing in Unity is game scripting, which is somewhat different than programming an app from scratch; all or most of the hard stuff is already done for you in this case.

–Eric

C#

I’d also tend to say C#.

Although it’s true that a lot of Unity examples are written in javascript, you’ll find much more examples in C# (thanks to XNA) around the net (if you’re looking for some AI/Graphics/…/ functions). And while it’d be quite easy to convert them to javascript, it’s just faster to just be able to copy and modify a script to suit your needs.

Does UnityScript offer conditional compilation based on symbols? Stuff like:

#if SERVER
    // Some very secret server code not meant to go to the clients
#endif

or

#if DEBUG
    // some very extensive debug-logging code
#endif

?

While, coming from Java (not JavaScript :wink: ), at first I didn’t really like conditional compilation (I thought it was “ugly” and not “OO”), I have to say that in many cases, it’s an absolute must. Even in the Java-World, when you do J2ME (Java for mobile devices), you basically can’t live without it if you want any decent support for different devices with different capabilities.

For Unity, I think you can live without it as long as you have only one “target”, but when you do clients, servers, evaluation versions of your games etc., I think it makes a lot of sense to only include the code you really need for the specific build. While you sure shouldn’t use conditional compilation instead of proper OO design, it’s often a very nice complementary feature that actually supports staying with a proper OO design instead of forcing your design to follow “technical stuff” that simply is better solved with conditional compilation.

… and … what about generics? Does Unity JavaScript support that? I think theoretically, it could be since it supports the API … but … does it also support the syntax for it? Generics is another thing I personally could hardly live without… and that’s not about being lazy and not wanting to type cast but about knowing for sure everything is type-safe without having to think too much … and, of course, it’s about elegance :wink:

This is really not about “this language is better” or “the other is better”: Someone who prefers dynamic typing over strict static typing will hardly see an advantage in generics (after all, that’s even more typing). On the other hand, someone who prefers a more explicit and strict language will not see the point in dynamic typing except for very rare cases (it’s not without reason that C# 3.0 or 3.5 does support dynamic typing and in many cases allows writing code that almost looks like JavaScript :wink: ).

Sunny regards,
Jashan

For a java programmer I’d recommend c#.

All unity examples are in “javascript”. (it’s not really javascript, UnityScript would probably be a better name)

However, outside of the unityworld, there is no code available at all in unityjavascript. While there are boatloads and boatloads of c# tutorials/examples/code out there.

There’s better tool support for c# (hello visual studio) as well. And Novell has a substantial amount of people working on improving mono, and its c# compiler. So assuming unity is periodically going to update its embedded mono, the c# you’ll be able to use is going to improve over time. (Current mono already has quite a bit “nicer” c# than what is embedded in unity. (type inference being a big one)).

I’d say unityjavascript makes most sense for getting your feet wet, without making things look too complicated. There’s probably very few things you cannot do in unityjavascript that you can do in c#, so it’s not impossible, just less convenient imho.

Bye, Lucas

I’d add my vote to the C# camp.

I have a background in Java and started with JS as that was the language that the unity folks used in their tutorials, but after a couple of months found that I was losing more time trying to write “elegant” code in JS (that uses such basics such as multi-dimensional arrays) and ended up switching to C#.

In terms of IDE’s Visual Studio is incredible, but I don’t like switching back and forth between Windows and Mac UI’s. So I’m just using the latest version of Unitron that comes with 2.1 and so far I’m pretty happy with it. It has code completion, syntax coloring and the links into the help documentation is pretty decent.