Thanks for tuning in to this Interface webinar on JavaScript for C# developers.

What we’re going to do over the next 30 to 45 minutes is walk you through some of the key concepts that you can actually carry over from the C# world you live in now over to JavaScript, and talk about why you’d want to learn some other things. Let’s jump on in here.

The target audience for this particular webinar is people with a C# background. You certainly could use any object‑oriented background, but the demos I’ll show will all be C#‑based.

If you’re just trying to move more into JavaScript, you’ll actually benefit from this as well, but everything’s going to be .NET‑based, as far as the back end and the different demos we’ll do.

What’s the agenda? We’re going to start off with why would you want to learn JavaScript in the first place. If you live on the server side, or you’re building desktop applications, or something along those lines, then, why take the time to learn this?

The answer there is “There are a lot of good reasons to do it, such as single‑page applications or validation, and much more that we’re going to talk about.” We’re also going to go in and compare what does the syntax look like between C# and JavaScript.

You’ll see there are some similarities you’ll be able to carry over directly. From there, we’ll get into what are some of the key differences. There are a lot of key differences here. We’ll talk about some of those as we go through here.

Learning JavaScript, you’ll see, is really not enough, especially, if you’re going to be building web apps. You’re also going to have to know a little bit about the DOM. You’ll have to know about CSS. We’ll talk briefly about that.

Then, we’re going to wrap up with a really, really cool feature in JavaScript. It’s up and coming. It’s not ready for prime time quite yet, as of today, but it’s called “ECMAScript 6,” or you’ll just see ES6, as you see here.

This is the next version of JavaScript. It actually looks a lot like C# in some regards. Let’s go ahead and get started and jump into why learn JavaScript in the first place.

A lot of people, if you’ve been writing C# code, look at JavaScript like this. It looks like one big mess. It’s not exactly the most pleasant thing that you might want to dive into. It feels really messy at first glance. I’ll admit it can be messy if you don’t know what you’re doing.

The good news is it’s not nearly that bad. It’s actually pretty nice to work with once you know some of the key aspects of the language and how it works. We’ll talk about some of the highlights of that in the webinar today.

Along the way, it is nice. Everybody likes jumping in the ocean. With JavaScript, there are a few sharks along the way. I’ll point out a few of those as we jump in here. It’s not all roses, but at the same time, it’s actually very easy to get started with. You can do some really powerful things with this.

Why learn JavaScript in the first place? Really, it all boils down to if you’re building web applications and you want to do more on the client, then, this is a great way to go. JavaScript is the programming language of the Web. That’s not going to change anytime soon, whether you like it or don’t like it.

I started with JavaScript.it was actually called “LiveScript” back in the early ’90s. As I kept moving into JavaScript, a lot of people were thinking I’m crazy, because I liked this language. I’ve actually always liked JavaScript in general.

Nowadays, though, it’s very popular, obviously. There’s a lot of stuff you can do with it that’s pretty cool, that we’ll be talking about. It also plays a critical role in our Web applications. As an example, you might want to do some client‑side validation.

Obviously, it’s nice to give the client that type of instant feedback. You’ll of course have to validate on the server side, as well, but this will give that client instant feedback type of scenario.

You might also want to do some filtering of data or paging or sorting, those types of things on the client side so it almost feels like a desktop application. JavaScript would enable that. One of the big downfalls, I think, of the traditional Web applications is that every time you blink, it feels like, you’re doing a full‑page postback.

With JavaScript, we can leverage AJAX and make asynchronous calls so that we can make more desktop‑like look and feel. It’s pretty snappy. You get the data very quickly. I’ll show you an example where that’s also good on bandwidth and HTTP requests and things.

I mentioned single‑page applications. These are very, very popular these days. Frameworks like AngularJS, or Ember.js, or Backbone, these are all JavaScript frameworks, or libraries that you can use to do some pretty powerful processing.

You’re really moving a lot of the server‑side load down to the client. Nowadays, that’s a cool thing. I recently got a Galaxy Note 3. I have a quad‑core processor right on my phone. Why not let that phone do some more of the heavy lifting and go that route?

There’s a lot more you can do, as well. You can leverage these libraries I mentioned, jQuery is another one that’s very popular. A lot of different things are JavaScript‑based. There’s much more we can talk about, but we’ve got to move on.

Let’s look at a quick demo here, of a server‑side app versus a client‑side app. The first demonstration we’re going to look at is a pure ASP .NET app with C# on the back end. It has normal postbacks.

Let me go ahead and open it. You’ll see it’s very basic, just has a drop‑down. As you switch the drop‑down, it’s going to load some customers. We’ll go load all the customers in British Columbia. No big deal, right?

JavaScript can really help us out here in some scenarios, especially, if you have very much data. The problem is it’s having to bring back this entire table, which is a lot of data, actually, depending on the size of your record.

If we go into the Chrome Developer Tools here, you can hit F12 or do command or control‑shift‑I. If I go in, we’re going to monitor the network requests. We can actually take a look at what is actually going back and forth over the wire.

Let’s go ahead. Let’s go to Alberta here. It looks like the size of that was 11.3K for this customer ASPX. Let’s go look at Arizona. I think there’s less in Arizona. No. There’s actually more, apparently. It’s 13K.

Let’s do one more. Let’s go Montana. Montana is about 13K, it looks like. You can see the size of the page actually coming back is fairly consistent, but of course, would depend on your data.

Now, let’s do the same app, but this particular app is using some JavaScript that you can see here. This is using a framework, a little library actually, called “KnockoutJS” to do data binding. It’s going to look the same, but let’s look at the actual data that’s sent back and forth.

Here’s the same type of app, but this is 100‑percent client‑side. The server just serves up the initial HTML, and then, we make an API call, specifically Web API. This returns JSON data. It does the same thing, but let’s take a look at the size of the data that’s coming back now.

I’m going to click on this XHR, which will mean our XML HTTP request, in other words, AJAX calls. Let’s run off to British Columbia. It looks like that was 1.8K of data. Not bad.

Let’s go to Montana again. It looks like that was only 256 bytes. Not bad. You can imagine, if you’re designing your apps to run on a phone or a tablet or desktop, then this is a big deal.

Now, by leveraging AJAX, I’m able just to send the raw data that you can see here, instead of having to send all the table tags and the TRs and the TDs back over to the client. That’s a quick look at one reason that you might consider JavaScript as you’re building your applications.

Now that you’ve seen one reason of many that you might want to learn some JavaScript, let’s actually look at some the similarities between C# and JavaScript and how they relate.

The good news is there are a lot of concepts that actually carry over if you already know C#. One of the things when you first learn C# or Java, or whatever your language is, is how to use the squiggly brackets and semicolons. Those are in JavaScript, so you’re going to be pretty comfortable there.

Both languages though have some very close concepts that you can transfer over almost directly. For instance, they both support objects. You can actually create a new instance of an object in C# and in JavaScript and work with it. You’re going to see a little later today that the way you do the objects is certainly different, but very similar concept there.

Variables. Very, very similar. In fact, if you use the var keyword for dynamic inferred typing in C#, then, you can also use the var keyword in JavaScript. Very similar. Very different though on the data types, which we’ll talk about, as well, coming up.

Both languages use functions. I think any language out there uses a lot of functions. That’s very common. Finally, the conditional if statements or switch statements, or a for loop is practically identical in both languages. We’ll look at that in just a second.

Let’s go into a little demo where I have some C# code. I have a little class called “Similarities.cs.” What I’ve done is broken down different parts of this. We have some variables we’re going to talk about. We’re going to talk about some properties and some other features here.

Let’s start off with the one that’s open. In C#, we’re all used to doing something like prop tab tab to get a property definition. It looks like that. You have a get and a set. With the current version of JavaScript…keep in mind there is a new version that’ll be coming out, but it’s not widely supported at all, yet, in browsers.

The current version, that this.age = 0 would be a very similar definition to a property. It almost looks just like a field, if you will, but very, very similar there. You might wonder what the heck is this. It’s similar to C#. However, it changes context.

One thing you will have to watch, for JavaScript, is that normally, if you create a new Similarities here…we’ll call it “S”…and then you say, “S.age,” then, this would represent the Similarities, but the keyword “this” can change context.

Basically, whoever calls into “this” is what “this” is. Whereas in C#, it always represents the actual object itself. A little bit different there, but very similar as far as what you can define.

Let’s go up to just a simple variable. Very similar, as well. You’ll notice that we have a string here, “Fred,” and then, we have a list of string called “names.” This is what it would look like in JavaScript.

Note that I could have just as easily, if it was in a function, put var. Of course, as a field, you don’t do that, in C#, but you’ll notice that it’s almost identical. You’ll see though that the typing is going to be quite a bit different with JavaScript, as we’ll talk about in a moment.

Arrays can actually be defined in different ways, in JavaScript, but arrays are similar in that you can add items into a collection, like a list of string. The way they work though is actually quite a bit different. We’ll talk about some of that, as well.

Moving on down to things like methods. We don’t officially call them “methods” in JavaScript. We just call them “functions,” but it really doesn’t matter. A lot of people do slip out, “It’s a method.” Basically, it’s a function that does something.

Here, we have a C# method, called “GetName,” that returns a string, you can see. Very simple, very standard. The equivalent in JavaScript would be right here. You’ll notice it’s almost identical, aside from you’ve got to put the “function” keyword.

You’ll note that there’s no return type. JavaScript doesn’t specify the type that’s returned from functions. That is a little bit different. Very similar though. Very easy to get started with.

Finally, arrays, loops, and conditionals are also very similar. Here, we have a little field names. Pretty standard C# code. A little bit contrived, but good for the demo.

We’re going to loop through. As we loop, if it equals zero, we’re going to add into the list up top, the list of string, first name. If it’s not zero, then, we’re going to add name, plus, whatever i is as we’re looping.

Let’s look at the JavaScript version. Very similar again. We use the function. Notice that the for loop is identical, because we can use var in C# if we want, for type inference. The if is identical. As we move down, everything looks pretty good there.

One of the big things we’ll talk about in the next section is that the conditionals in JavaScript are a little bit strange. This is the sharks in the water I talked about earlier, that you’ve got to watch out for. We’ll get back to that in just a bit.
Now we talked about some of the key similarities and you can see some of the fundamental concepts like Methods, Loops, Conditionals, and Variables. They are very similar between languages. I don’t think if you do a lot of C# now, I don’t think you are going to struggle learning the syntax of java script. Where people tend to struggle is some of these differences that we are going to cover plus jump into the few of this here.

First of all, JavaScript is a totally dynamic language. There is no compiler which is a little bit of a bummer if you’re used to getting the errors as you compile. It is quickly funny now. What did I do wrong? The reason under that, you run it, and you tried it in the browser or other container, and it either works or it doesn’t.

Then you have to go and do as I did earlier and go into chrome developer tools or IE developer tools, to figure out any JavaScript errors. Another way that it really differs is, with JavaScript, you don’t have the same types of system. In fact, you don’t have types like int, float or double. You do have the concept of that, but you don’t have the same exact data types.

In fact, you always use “var,” as you’re defining your variables. Whereas, of course with C#, we’re used to strongly typed applications. Also, there’s absolutely no native support currently for name spaces or classes. That’s a little bit of a bummer, I will admit if you are coming in from the C# world, and we’re all used to building components if you will, classes that we can build into objects and re‑use those.

JavaScript doesn’t need it, we have that through ECMAScript 5, which is the current version that most browsers support. But ECMAScript 6, which will touch that of an end, does support that concept. There’s a lot of cool stuffs you can do there.

There is only two levels of variable scope in JavaScript unlike three levels in C#. In C#, we’re used to the class level, and then we have the method level, then we have the block level. Well in JavaScript, by default until ECMAScript 6 that is, we have only two levels.

You have variables that are global and you have function level. But if you define something like in the loop or if statement block, that is not actually a scope definition. We can actually step on another definition that is outside of that to watch out in the JavaScript.

One of the biggest kind of “Sharks in the water,” I call it, is the quality comparisons. We’ll run some demos of some of the features here in a moment.

With C# you can use the double equal and it just automatically compares if they are equal or not. You’ll see in JavaScript that it gets a little tricky, and there’s something else that I am going to show you here that you can use. I’ll actually recommend you use when you are writing JavaScript.

Finally functions in the C#, they don’t stand on their own. Functions are always in classes or structures or something in C#. Where in JavaScript, functions can totally stand on their own. They’re actually objects. We will be talking about that as well.

Talking about some of the data types, I mentioned that with JavaScript, we don’t have the different data types, or at least the robust nature of the data types we have in C#. What we do have is primary. We have some composite types and some special types.

The primary types are pretty familiar with as C# developers. We have strings. We do have numbers. But if you’ll notice, numbers are not really broken down into small, double, float, long, short and that type of thing. It is just the number.

You can have decimal. It can be whole numbers, that really just depends. Boolean’s, we do have the ability to numerically evaluate a Boolean in JavaScript, unlike C# where true is true and false is false and there is no numeric equivalent per se.

In JavaScript, zero is a false, a one is true like several other languages out there. We also have object which is the base granddaddy of them all at the top of the hierarchy, very similar to C# in that regard. We have a race, we showed a little bit of that earlier. Then, we also have null, which everybody is used too in the C#. But we have this other one, it is called undefined. I will show you that in just a bit.

Instead of just checking that something is null, you’ll often check if it is null or is it undefined. I will show you some short cut ways that we can actually do that. Jump into a demo here and talk about few of these key differences and how they manifest themselves in JavaScript.

First half, we start with quality. In C#, If I was actually to come in and say, “Hey, does 5 equals 5 in this example right here?” You would say, “Of course not.” Well, in JavaScript it depends. With JavaScript, if I were to code like this: If age equals other age, with the normal double equals that we are used to for quality in C#. That actually will evaluate to true. That is a little bit shocking at first, if you’re brand new to JavaScript.

Well, that is not how it should be, at least in C#. The reason is that, what will happen is, JavaScript will do some type coercion. It will actually try to convert so that the data types can be compared. Technically five in quotes is equal to five here now. One other difference to point out is, if you’ll notice I used the single quotes here like a character in C#.

In JavaScript, I can just as easily have done this with single or I could use double quotes. Either way, it works. A lot of people including myself in JavaScript, like the single quotes. That’s a pretty big jump if you are doing C# for the last five or ten years to switch to that. That’s one big thing.

I mentioned undefined in null. You’ll notice address here, is not a signed value. If we actually to run this code right here, and we try to log the value of address, all it does is update the little bit of dev up here when I run this. It will show the output in just a moment.

But the address is undefined, it doesn’t have a value. It’s not null, it’s undefined. That’s also different compared to C# because we don’t have an undefined in that rule. Street however is null, it is a null pointer in memory. If I run this little page, not really impressive output. But you’ll see it’s true that quoted five equals five, if we use the double quotes.

Here’s the trick I want to show you. It’s false if we use the triple equals. And then room on the street as it’s coming out with the quadruple equals next for another null which is can’t…But that will be a little crazy. But this triple equals is what’s recommended.

I don’t like languages that curse my type to make them equal to each other. You want to stick with the triple equals in almost any app you do. It is little bit hard to remember that, if you are coming from C# world, but that’s a big deal.

Also, you’ll notice that address is not null, it’s actually returning that it’s undefined. That’s because it hasn’t been assigned a value yet, versus street, you can see is null that will be used to in C#. That would be one example of some of the differences.

I want to talk about scope actually a little bit. You” notice I have a variable in JavaScript called “college”, and if we do an alert…Alert is coming like a message box that pops up. It is going to show it is 55. But notice in this loop here, I am defining a new “age” and using that “age” to actually loop through and then riding out age.

Well, that’s going to be function scope, so we have global scope and function scope here. Then down here at the bottom, you’ll notice I’m doing a block. Just four loops standing on its own. I am also redefining “age” as zero. Now the question is, what’s that going to affect? Is it going to affect this one up here which is the function scope age? Is it going to affect the one that’s at the top, the global scope? Well, let’s run it and let’s see.

We should get a three or so message boxes. You will see the first time it ran, global age was 55, and that’s what we would expect that would be correct. Then, the internal one in the function, when it get done looping, it was five. I would expect that. But notice the last one, it should have written out 55. Instead, it wrote five.

The reason for that is we over load the value by doing this “Var age” here because there is no block level scope in JavaScript. Now, you’re going to see that it’s going to change in ECMAScript 6. There’s a new keyword they are going to introduce called, “Let,” and that will make the age scope only to the block. That will help with some of the problems with the scoping. But, that’s not quite ready for prime time yet. That’s another difference that you’ll need to know about is the scoping in JavaScript.

Another big difference, functions can totally stand on their own in the JavaScript world. Whereas in C#, of course you have to put your methods inside your class. Well functions, it turns out in JavaScript are actually objects. This little function definition for a person here, you can almost think of that as like a class. Normally, add under that class, a property called name and assign it to Jane Doe.

Now I can come down here and actually move up that person, just like its regular class. That’s definitely unique compared to the C# type of approach because we are used to classes and you move up to the class.

Well, because we don’t have classes in JavaScript, you can substitute this function approach because functions are objects. There is a lot of interesting things you can do there. This would just write out Jane Doe, if we are to run this one.

Last one I will show you that’s a big difference is inheritance. Because we don’t have classes and inheritance like Java or C#, we have to use what’s built into the language, and it is called prototypal inheritance.

There is a prototype property that every object can hear it from the base object in JavaScript. You’ll notice in this case, we have an object called base. It is a blue print, it is like our class, if you will. Then off base, I am going to go to the prototype, that’s inherited from an object in JavaScript. I am going to add a log function that just does an alert when it’s run.

Now, let’s say that I have a child that needs to inherit the functionality from base and what we really want to do is, when the child is run, we call log. What will happen is, it will first look at the child and ask, “Do you have a log function?” If you do, it will call him. If you don’t, it will then walk up the hierarchy which we are going to create in the next line of code here and say “Do you have a log function?”

What we are going to do here is, we are going to have a child and we are going to assign to the child’s prototype, the new base now. Really, that’s going to make the prototype of the base object available here to our child.

After that, we are going to attack on our own little add method. What is interesting here is, down here in this code, when I call c.log after I move up the child, that’s going to look first in the child’s prototype and the local stuff and say “Do you have a log?” It’s not going to find it. What it is going to do is, it’s going to walk up the prototype chain until it finds a prototype in a parent that has the log and then it would find this guy and then, it would run the function.

Unlike the “add” that you see here, that actually would come in and just call the child’s add that’s on the child’s prototype itself. Inheritance is totally different. This is one of the current ways that you can enable prototypal inheritance, as we call it.

In ECMAScript 6 which will wrap up this webinar we are talking about and we’ll talk more about this and how that’s going to change everything.

That’s a quick example of the few of the key differences and certainly there will be more I can cover, but that will get you thinking about how C# matches up.

If you’re currently doing development work on the Server Side and doing a lot of C# every day. Maybe you’re doing just desktop apps and now you’re being asked to move into the web world. I’d love to say that learning JavaScript is going to solve all the world’s problems but, in fact, JavaScript is only one part of the picture.