I used to be a C# SharePoint Developer – Part 2 – JavaScript history and basics

Brenden Eich born 1961 Pittsburgh, Pennsylvania.

The creator of what we know today as JavaScript. A very controversial figure. He has been in the news in the last few years with his political and social views. Resulting in his somewhat forced exit from his position as CEO of Mozilla.

Eich was commissioned by Netscape to develop a client side scripting language which could be used in HTML pages to offer some form of intractability on the client side. He produced what was at that time a language he syntactically made similar to Java. This project them was seen under his watchful eye and continued as SpiderMonkey, Netscape’s JavaScript engine.

Mocha -> LiveScript -> JavaScript. In the early life of the language it had many names, JavaScript was finally chosen to market the Netscape browsers support for Java and to give it some instant recognisability. Over a decade later, and people still get confused about the difference.

November 1996, this is the true inception of ECMAScript. Netscape submitted the language to ECMA (European Computer Manufacturers Association) and in the June of 1997 ECMA-262, the official designation for the ECMAScript standard was published.

Version History

1.0 – March 1996, Netscape Navigator and Internet Explorer 3 exclusively
1.1 – August 1996. Netscape Navigator
1.2 – June 1997, final non-standard version of JavaScript, implemented in Netscape Navigator and Opera
1.3 – October 1998, the first browser implementations of ECMA-262, Netscape Navigator, Internet Explorer 4.0 and Opera 5.
1.4 – Netscape Server and Opera 6
1.5 – November 2000, ECMA-262 or ECMAScript 3 was now implemented in all of today’s browsers. This was also the final year for Netscape Navigator and the first year for Mozilla and Google Chrome.
1.6 – November 2005, unofficially known as E4x it was only implemented in Mozilla browsers. Array and string generics added.
1.7 – October 2006, only implemented in Mozilla and Google Chrome
1.8 – June 2008, only implemented in Mozilla and Opera, expression closures added
1.8.1 – Mozilla only, native JSON support added
1.8.2 – June 22, 2009. Only implemented in Mozilla.

This is where things got shook up. For years’ browser developers fought over this language and its implementation, with any disparities appearing across browsers. The community fought this out, and development and adoption of the language stuttered.

On the 15th December 2009, at the ECMA General Assembly after interoperability and web compatibility testing, the final draft of the ECMAScript 5 standard was produced. (ECMA, 2009). This is the version which all the years of bad experiences of JavaScript where for the most part over. It wasn’t until 2012 however that all browsers caught up and had a fully implementation of ECMAScript 5.

Fast forward to our latest standard. ECMA-262 ECMAScript 6. On the 6th of June, with all browser developers, and community in agreement we have ECMAScript. This major leap forwards aren’t just bug fixes, and implementation of missing elements. It allows JavaScript to be written as a Loosely Typed or a Strongly Typed language. It provides support for Asynchronous wait chains amongst many other new features.

We won’t see this in SharePoint until the version after SharePoint 2016, but we can start to use the features and way of programming now. With this in mind, I will be future proofing your mind set, looking forwards to ECMAScript 7 and beyond.


Even though the adoption of the earlier versions of JavaScript has been slow, adoption today has turned JavaScript into the world’s most popular programming language.

We have full stack development, meaning that we can program and compile down to machine code if we have the need. This allows for new types of development practices, allowing smaller teams without the need for a diversity of skills to flourish alongside other larger teams.

There is of course people who hate JavaScript, without actual modern reasons. Calling it a hacked together language, buggy amongst other things. Almost all of these concepts are based on the pre ECMAScript 5 standard, and have actual foundation if they weren’t now almost a decade out of date.

All programming languages go through a development cycle. New syntactic sugar is added to aid development and simplify code. JavaScript is no different here, and C# has also followed the same route.


Today this leaves us with a robust language which we have a vast understanding and years of experience in development.

The way we program JavaScript I would say has become more professional, we now see it as something that we don’t just copy snippets here and there into a document and hope it works.

We use traditional development practices and solid Computer Science to develop asynchronous powerful applications, that give the best possible experience an end user could want for.

So where do we go from here? We are in the middle of ECMAScript 5 and 6, it can be a hard place to be, between two standards. As we do in other programming language, we can use shims to ensure support is available. While our core libraries use the latest of development practices and syntactic sugar.

If you aren’t familiar with these concepts, they will be looked at in depth late on in the book.

Basics of JavaScript

Definition: JavaScript is a high-level, dynamic, untyped, and interpreted programming language. (WikiPedia, n.d.)
While this is true to an extent in the definition as provided by Wikipedia. It is also wrong. Whether a language is interpreted or not depends on the implementation. Implementation has nothing to do with the specification. A language decides if it is to be interpreted or compiled. ECMA-262 states an environment, not that it is an interpreted language, and feel this is an important fact to have a handle on.

Today all browsers do compile JavaScript, even in the early days it was compiled using a Just In Time compiler (JIT). As we put more and more demand on JavaScript, so do the optimisations implemented in these compilers.
Later I will go into depth on how different browsers implement JavaScript internally, this knowledge will help lead you to writing more performant code in the future.

JavaScript is a fast to market language, which can require the least amount of work to develop a product from start to finish. It is also one of the simplest to understand. JavaScript’s ECMA-262 specification is tied in closely with common Computer Science teachings, and anyone with a relevant Computer Science degree will understand the specification. This isn’t true of many programming languages, including C#. Many structures in these languages have been developed for faster developer and easier to read syntactic sugar. While JavaScript has been lacking many of the more widely used concepts previously, ECMAScript 6 and 7 are aiming solely to address these issues.


The general advice is, if it seems confusing and pointless then you need to stay away from it. I say no learn what is going on, so that you have the tools to hand when you need them.

Before we take a look through the Types in JavaScript I want to talk about what Abstract Objects vs Concrete Objects. JavaScript deals in both. As a C# Developer you will be used to mainly working with Concrete Objects, they are Strongly Typed. The mathematical approach to this is that an object in JavaScript is an Abstract Data Type.

A Abstract Data Type isn’t an Abstract Class, or Abstraction. It’s an object that is defined by behavior, where as in C# we use Data Structures which are an implementation of multiple Abstract Data Types to create a structure. In C# each Abstract Data Type is wrapped by a class to give it structure, it defined how it is to be compared, how it is built, what are it’s limits.

With this in mind, we have Structured Types and Abstract Types in JavaScript, this allows us to do Abstract comparison as well as strict comparison that looks at the comparison involved. Abstract comparison in JavaScript is also called loose comparison as it converts both sides of the comparison to equivalent types before the comparison is carried out. For this reason we mostly use strict comparison, but using an Abstract comparison can useful in some scenarios. Other usages are forcing a comparison type by using the force operation “”+a == “”+b will force String comparison, +a — +b will force Numeric comparison and !a == !b will force Boolean comparison. I will cover this in more detail when I come to operators.

  • Boolean
    • There are two Boolean types in JavaScript which confuses many people on the way they work. We have the Primitive type Boolean and the object Boolean(). To access the internal Primitive of the Boolean object you have to access it via ValueOf() as accessing the Boolean object directly will only result in an object, and objects are “truthy” meaning new Boolean(false) == true. The reason this object version of primitives exist is purely so that you are able to add methods to the object to allow for extra processing.
  • Null
    • Null is the second primitive type in JavaScript. This does not however have a Object type, as Null is used to express the intent of an object void of any value. Which if you think of it would be crazy if they made a Object type of Null as you would have an Object intent of no value, of intent of no value….? In reality Null represents the lack of identification, this is to indicate that a variable has a type, but points to no value.
  • Undefined
    • Undefined, is in many ways similar to Null. The key difference it is the state of a variable where you have no type or value defined. If you do a simple comparison of null == undefined in JavaScript they will match. This is because as Abstract objects they both compare to being nothing, however using strict comparison they are indeed different.
  • Number
    • a double-precision 64-bit binary format IEEE 754 value. What is that exactly though? The Number type is a primitive with an Object implementation (See Boolean above). It means that it is a precise but not perfect representation of a fractional number. Indeed in this standard 0.1 + 0.2 = 0.3000000000000000444089209850062616169452667236328125. This is because a number in this format is in Scientific Notation (10 = 1 x 101). We have 11 bits for the exponent (The front bit) and 52 for the significand (The bit in the superscript after the number). This means that we aren’t very precise with this. In C# we tend to use Decimal numbers instead of Floating point numbers although both are available. The reality is Floats are no good for thing’s like finance or anything exact. Decimals are much better (Still not perfect, as they would be Fixed Point numbers, as in Fixed Point Arithmetic) and technically since a Decimal does store the Point inside it’s encoding, it is still a Float, but more suited to financial data as they are decimal accurate. This whole topic will get it’s own blog post in the future.
  • String
    • 16bit UTF-16 string of characters that are stored with their length separate. In C-Like languages you normally have a null terminated string.
  • Symbol
    • A new type added to ES6 is the Symbol. In order to add unique properties and behavior we got the Symbol. A symbol is used a unique identifier and on creation is given a String description. These can  be used to create new non iterateable properties on objects, or unique types for constants.
  • Object
    • The base type of all objects. All primitives except Null and Undefined are wrapped in objects, this means they have all the same base functionality has a Base object, plus the extra functionality of their wrapper implementation. Objects in JavaScript also delegate their execution. So if you have a function on a parent Object, this is the function that is referenced from the child which inherits off this object, no copies of properties or functions are made, unless you explicitly do so.

Initialisation & Prototypes

Almost all the time you are working with objects. This means that we base everything on behavior reuse. As I said about Objects JavaScript always delegated inherited Properties and Functions.

JavaScript uses a Classless Object Orientated style of programming, we represent the properties and functionality of an Object, then clone that object and build extra functionality onto it. where as in Class based we build up a taxonomy of objects.

While the implementation is very close to inheritance as we don’t physically copy over the base properties, we make references to them, we aren’t building a class which describes the object first. We build an object, we add to it, we inherit from it and alter the inherited object to create a new object.

Scope & Closures

In C# it appears we can create delegated methods inside of other methods. However this isn’t truly the case, a delegated method is a separate method in C# that is just written inside of the method you are working in. You only have access to the values that are passed into the scope,

A Closure however has access to anything it is in scope of. It’s parent’s variables are accessible, and when used with current state in mind this can be a very powerful concept.

Closures allow us to create well nested Methods, that control privacy, and create Objects in a monadic fashion.

What is a Monad though? A monad is what it is to define a set of operations to create a chain of functionality. It is called a “Programmable Semi-Colon” by some, it is in essence the linkage between functions.

We have moved on from manual Monad programming mostly, now we use Promises to achieve this behavior to get a Workflow style of programming.


Iteration in JavaScript is integer based, it is not recommended to iterate using the Number type due to the possibilities of infinite loops iterating with a Float type.

We have the ability to iterate over objects and data sets, using one of many methods implemented. Due to the vastness of difference in each iteration method this will be a separate blog post on it’s own.


As described above, logic is based on the Abstract types that JavaScript uses. To this effect knowing the difference between strict and loose comparison is important, and knowing when and where to use each is vital.

Error Handling

JavaScript implements Try, Catch, Finally and Throw. Use them. Especially in Enterprise Software Development. I may follow up on this later but I want to explain what I mean by this now.

This is two fold, first you don’t want your users seeing errors, or causing their entire SharePoint page to stop working. Further to this though most exploits use exceptions in code to perform some form of bypass. Preventing your code from throwing errors is one of the first lines of defense against this.

Even if you build in all appropriate checks, use error handling, and use logging to trace these errors back to the source so that you can manage the defects.


JavaScript is best written as an Event based language. Browsers will react faster, and your users will be much happier for it. What is is important to not here is that you want to limit the number of events attached to the Document Object Model of the page. The more events you add, the higher the chance that you create memory leaks. Attaching to the top level of your application in the Document Object Model will allow you to have a faster responding page, with less issues overall. I will cover details Events in TypeScript and JavaScript later in this series.

Code Comments

Write code comments. Explain the intent of a method, it’s input and output. Explain any complex code that you haven’t been able to refactor. Do this and your supportability and maintainability costs of your code reduces dramatically. Some companies look at Code Comment Density to check this as a metric, for me as long as you cover these three things in your code, no matter what language you write you will have done your job.

  • Input
  • Output and intent
  • Complex code


The Document Object Model (DOM for short) isn’t a part of JavaScript, but most implementations that you will use have access to it. Treating the DOM with respect, knowing how a browser works and how JavaScript works and interacts with the DOM are all very points on the list to be covered.

Most modern frameworks will do the DOM Handling for you, however knowing what you are doing, allows you to optimise even very well optimised Frameworks such as Angular even more.

More on Standards

If you want to five into the standard straight away then I recommend looking at the next version draft, and the current version. The next standard draft can be found here ECMAScript® 2019 Draught and for the published edition you can find it here ECMAScript® 2015 Language Specification

Next time…

Next I am going to cover general best practices in JavaScript, I will explain why they are Best Practices and explore some of the alternatives.

© Hugh Wood 1980-Present