Unity and Javascript

Greetings,

First of all iam not sure if iam posting this to the correct section if not iam sorry . Second i notice that in MonoDevelop editor the auto correction for javascript it doesnt work . Does this mean that Unity is willing to abandon JS ? If that its not the case , can anyone tell me how to enable the auto correction (suggestion). I want an answer to this because as JS programmer i want to focus on one game engine , if Unity is not willing to support the JS in the future plan to move on other game engine.

Thank you for your time.

 

I dont know about getting monoDev to support it, since i use VS and C#, but keep in mind what unity calls javascript, is not real javascript. It is its own langauge that is loosely based on the ecmascript standard but wrapped around the mono/.net toolset

 

If Unity abandons JavaScript it will be the result of the community no longer using it. Last time statistics were given was back in September 2014 and UnityScript was only used by one-fifth of the community. We've lost most of our learning materials for JavaScript and it's becoming far less common in the Scripting section.

https://blogs.unity3d.com/2014/09/03/documentation-unity-scripting-languages-and-you/

Good luck. Last I checked there were no major engines on the market using JavaScript other than Unity. If they abandon JavaScript you're pretty much out of luck. You'll either have to learn a new language or build your own engine from scratch.

I don't recommend the latter by the way. Building your own engine is far more difficult than learning a new language.

 

A programming langauge is just a tool. No point using a hammer for every job when what you need is a drill. Learning multiple languages just lets you grow as a programmer.

 

Yes i know that UniScript it has very simillar syntax with javascript . Does that apply to C# as well? I mean C# use the same syntax in Unity or it has difference ?

 

the C# used in unity, is proper C#, it is just using a older version of mono/.net and it plays fine with 3rd party .net and c# libraries just fine.

 

The syntax is superficially similar between UnityScript and JavaScript. But as soon as you get to doing anything real UnityScript isn't even remotely similar to JavaScript.

UnityScript is a statically typed, class based, OOP language. It has more in common with C# then it does JavaScript.

UnityScript has already been abandoned. Just no one has told the marketing team yet. It currently doesn't cost Unity anything to leave the compiler in. But you can bet it will be dropped in a flash if it ever does become a real expense.

Really? Where are you going to go? No engines support JavaScript.

 

If I remember right, Unity said the main reason their pseudo-JS still exists is because the editor uses it internally and it isn't worth the effort to rewrite those parts yet.

That's as good as dead, if you ask me. But then, I'm heavily biased.

 

It lacks support in 3D game engines, but there are plenty of options in 2D, where Cocos is a big player.

 

This point get's made every single time someone mentions "javascript" in Unity. But until Unity officially changes all their documentation and tutorials and replace "JS" and "Javascript" with "US" and "Unityscript" you cannot blame anyone on this forum for using the term javascript. </rant>

 

Right, we can't blame anyone except the Unity employees that continue to refer to it as "JavaScript" (not all of them do this as you'll notice in this very thread), but that doesn't change the fact that it isn't actual JavaScript. If @Clickys is serious about sticking with JavaScript then he'll have to learn those differences.

http://wiki.unity3d.com/index.php?title=UnityScript_versus_JavaScript

 

No, you can’t. As soon as an iOS update will break things it will be Game Over.

 

UnityScript is actually very similar in syntax to C# so the transition wouldn't be hard and I would highly recommend you move to C# for Unity development. There are many more (and generally better quality) samples and examples and learning resources out there in C# specific to Unity than there are for UnityScript.

UnityScript allows you to be more loose with your typing than C# does, but as a standard practice I'd advise against that as it makes debugging a bit more difficult and code intent much harder to understand at a glance. Method declarations and a few other things are different, but the transition is easy. Let's take a look at some examples.

Typing

Code (csharp):

1.  
2. // Typing in UnityScript
3. var position : Vector3 = Vector3.zero;
4.  
5. //Typing in C#
6. Vector3 position = Vector3.zero
7. //or
8. var position = Vector3.zero //implicitly typed
9.  

Methods with no return type

Code (csharp):

1.  
2. //UnityScript
3. function SomeMethod() {
4.      Debug.Log("This method doesn't return anything");
5. }
6.  
7. //C#
8. void SomeMethod()
9. {
10.      Debug.Log("This method doesn't return anything");
11. }
12.  

Methods with a return type

Code (csharp):

1.  
2. //UnityScript
3. function GetString() : String {
4.      return "this is the string.";
5. }
6.  
7. //C#
8. string GetString()
9. {
10.     return "this is the string";
11. }
12.  

Functions Parameters

Code (csharp):

1.  
2. //UnityScript
3. function AddNumbers(num1 : int, num2 : int) : int {
4.         return num1 + num2;
5. }
6.  
7. //C#
8. int AddNumbers(int num1, int num2)
9. {
10.       return num1 + num2;
11. }
12.  

Generics

Code (csharp):

1.  
2. //UnityScript
3. var strings : List.<String> = new List.<String>();  //notice the "." (period)
4.  
5. //C#
6. List<string> strings = new List<string>();
7. //or
8. var strings = new List<string>(); //implicitly typed
9.  

There are lots more differences, like access modifiers and the like but they're pretty easy to pick up and the real differences between UnityScript and C# are pretty minimal... it's easy to transition from one to the other with a bit of practice and I'd highly recommend making that move.

 

Guess that means when UnityScript gets the axe Boo will be completely removed too?

 

if you wanted to use something like boo, f# or vb you could always compile the assembly yourself in visual studio and drop it in the unity plugins folder.

 

Though the generated IL sometimes differs and may not always be 100% compatible.

 

Since I went straight to C#, I didn't realize Boo and UnityScript were two different things until just now. I've learned to avoid non-standard language lock-in for anything I'm at all serious about. Come to think of it...

Boo ... which is sort-of but not really Python.
UnityScript ... which is sort-of but not really JavaScript.
C# ... which is almost but not really C# v3 let alone C# v6 (or soon, v7).
.NET ... which is sort-of .NET 3.5 but not really, and certainly not 4.6.

Seems like Unity could really crank up their productivity by not reinventing so many wheels. (Yes, I know much of this is finally roadmapped / planned etc.)

 

What's it missing from the C# spec? Obviously it's not C# 6, but it really is C#, not a faux language on top of something else.

It's coming. I've been using .NET 4.6 in the 5.6 beta targetting HoloLens, so far so good.

 

Magic.

Code (csharp):

1. void Update()

 

I was thinking public class + private magic method was the violation ... but I realized I've never actually looked in detail at how the messaging system makes those calls (I prefer .NET delegates, excepting unavoidable handlers like Awake), so I stand corrected. Though it's arguably still reinventing the wheel unnecessarily. (And I get it... simplicity for coding-n00bs...)

Anyway, I was just blasting off a grouchy list before my coffee-levels stabilized my morning mood.

 

That has nothing to do with the C# spec... and it follows it just fine. The magic is just in the way the C++ engine is invoking and marshalling those calls. But the code itself is still just good old C# / .NET and IL (or IL2CPP depending on your output target).

 

I'd tend to agree a bit there. This was based on an existing system, but what I think would be better, or more clear from a pure OOP standpoint was if those methods existed as public (or even protected) virtual methods on the base MonoBehaviour class and they were overridden in a proper inheritance manner, but the system that's there works.

 

Make a file on your desktop (TXT) and call it something like

Whatever.js

Make sure it has .js not .txt


Then drag it in to unity

 

Sure - but you are deliberately using something that is officially depreciated. Basically you are choosing to ruin your future project. The only reason it's still supported is to ensure a smooth exit for people who are too far along to change in their existing projects.

So don't do that.

 

UnityScript at least was better for beginners, is more easy to understand not like C#.
You could keep UnityScript just for "educational reasons", it's much easier to move from that programming language to C#. But for a beginner it's pretty hard to start with C #, at least from my experience with the people I had to learn them to work in Unity, what they saw was hieroglyphs, they do not think logically.

 

UnityScript is deprecated and it is not coming back. Move forward.

 

They are removing UnityScript because it is in the way of future engine development. They are not going to keep it as some beginner language because for some reason you think beginners would benefit from having to learn two separate programming languages to properly use Unity.

Unity tries to be beginner friendly when it can, but Unity is designed to be a professional level game development system.

 

They have removed UnityScript. This is not an ongoing thing. Its a done deal.

 

Did they actually remove the compiler? Last I checked the compiler is still in there, and still works if using the legacy runtime.