JavaScript

##History

JavaScript was originally developed by Brendan Eich, while he was working for Netscape Communications Corporation browser Netscape navigator. Netscape wanted a lightweight interpreted language that would complement Java by appealing to nonprofessional programmers, and Eich was commissioned to create it.

The first version was completed in ten days in order to accommodate the Navigator 2.0 Beta release schedule,and was called Mocha, which was later renamed LiveScript in September 1995 and later JavaScript in the same month.

In November 1996, Netscape announced that it had submitted JavaScript to Ecma International for consideration as an industry standard, and subsequent work resulted in the standardized version named ECMAScript. In June 1997, Ecma International published the first edition of the ECMA-262 specification. In June 1998, some modifications were made to adapt it to the ISO/IEC-16262 standard, and the second edition was released. The third edition of ECMA-262 was published on December 1999. Development of the fourth version was never completer and 2009 brought the 5 edition.

After realizing the long process that took to release a new version of ECMAScript and the fast rhythm of the industry, 2015 brought the partial implementation of ES6 or ES2015 edition and it has been proposed to change the release cycle to a year. Being ES2016 the first of the new series of the standard.

##Characteristics of the language

• C like syntax

• OOP but not class oriented: An object-oriented program is a collection of individual objects that perform different functions. These objects are usually related in a hierarchical manner, in which new objects and subclasses of objects inherit the properties and methods of the objects above them in the hierarchy. JavaScript does not allow class instancing as it implements Prototype-based object-oriented programming. in this approximation behaviour reuse is performed via a process of cloning existing objects that serve as prototypes.

• No variable typing: JavaScript has typed values, not typed variables. The following built-in types are available:

• string

• number

• boolean

• null

• undefined

• object

• symbol (new to ES6)

• Scripting language with JIT compilation

• Functional programming: It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas through anonymous functions..

• Event Driven: A mechanism that handles executing multiple chunks of a program over time, at each moment invoking the JS engine, called the event loop. This introduces Asynchronous programming as an ordered queue of snippets of code to run, without JavaScript having a real sense of time.

• Dynamic binding: object references checked at run time. This allow the same function to work over different contexts, helping the reuse of code.

##Performance

For a long time javascript was treated as second class language for two main reasons:

1. Slow: The main idea was that JS taked 10 times to run a program than the same program written in C. Even though javascript is a complied language, it is compiled by the engine before execution trying to find possible batter optimization, but it was complicated with characteristics such as the non typed nature of it’s variables and the automatic memory management through the garbage collector. ASM.js proposal works on this areas, restraining javascript to a subset of the language that allows the engine for the best optimization possible.

2. Single threaded: JavaScript runs in only one single thread. The event driven language delivers incredible speed when it comes to I/O operations but spreading the event loop to different threads, for CPU demanding tasks, and maintaining coherence the whole time introduces more complexity. Some advances have been made in this area with the introduction of web workers.

A web worker runs independently of other scripts, in another thread. This way it wont affect the performance of the page. User interaction in the main thread can run uninterrupted, while the web worker runs in the background.

###JavaScript engines

When a game is being developed in an environment such as javascript, it is impossible not to feel that some things escape your control. Even though you’ll be able to launch your game on multiple OS systems, through different web browsers or even different types of devices, you have to take on account that each one of them will have a particular javascript engine. This engine will support the standard APIs up to some exchange, but still if two engines would support the exact same APIs, the underlying implementation would be diverse, and its areas of optimization won’t be the same.

So we’ll look at some points of interest:

####Renderer

WebGL is the new boy in town for web rendering an it offers the developers to send to the GPU repetitive work saving our CPU a lot of time, and has broaden the use of 3D graphics for the web. In a desktop environment it would be my favorite choice without a doubt.

But, mobile is a totally different world. IOS has a very optimized canvas component ans has been know to give problems with WebGL. As for android, forget about it. All pre-Lollipop Android versions will give problems with WebGL. So canvas comes as the reasonable option for this type of environment. Also lets mention that Microsoft didn’t supported WebGL until IE11, which can be a huge problem depending on the country you’re planning to get your main audience from.

####Optimization

As Kyle Simpson says on the fifth book of his You Don’t Know JS saga, Async & Perfor- mance: ’Many common performance tests unfortunately obsess about irrelevant microp- erformance details like x++ versus ++x. Writing good tests means understanding how to focus on big picture concerns, like optimizing on the critical path, and avoiding falling into traps like different JS engines’ implementation details.’

This means we will focus on the maintainability and readability of the code except on critical parts such as update and render methods, on which we will code the most efficient way possible, explaining with comments if needed.

##Data protection analysis

####Cheating

There’s a big problem for data consistency and avoiding data manipulation by evil users with technologies like javascript. The game runs in the client-side, the code will run on the users own device, so it’s sensitive to manipulation. If the game your trying to do is multiplayer, you’ll need to check server side if the actions one user is making are possible in the players context, that takes a lot of server computing, but helps to avoid cheaters.

The most common is typically a server that has an authoritative state of the game. That is, the server receives all players inputs and calculates what the world should look like in order to prevent players from cheating.

####Privacy

Private projects fear their code been stolen as it will be as simple as opening the browser console or scraping the game page. For this and for optimization purposes. Minimization and obfuscation are highly recommended, your code will weight less and be harder to read and modify.

Every task manager like Gulp or Grunt or a bundler like webpack will offer functionalities to take this measures.