JavascriptFrom beginning to modern

Written By:Prem Narain

HistoryJavaScript, not to be confused with Java, was created in 10 days in May 1995 by Brendan Eich, then working at Netscape and now of Mozilla.

JavaScript was not always known as JavaScript: the original name was Mocha, a name chosen by Marc Andreessen, founder of Netscape. In September of 1995 the name was changed to LiveScript, then in December of the same year, upon receiving a trademark license from Sun, the name JavaScript was adopted.

In 1996 - 1997 JavaScript was taken to ECMA to carve out a standard specification, which other browser vendors could then implement based on the work done at Netscape.

In July of 2008 the disparate parties on either side came together in Oslo. This led to the eventual agreement in early 2009 to rename ECMAScript 3.1 to ECMAScript 5 and drive the language forward using an agenda that is known as Harmony.

2

IntroductionJavascript can be used as Client side either or Server side scripting language.

Javascript

Server Side Javascript

Client Side Javascript

3

Client Side ScriptingClient side scripting is used when the user's browser already has all the code and the page is altered on the basis of the user's input.

Client side javascript comprises the basic language and predefined objects which are relevant to running java script in a browser. The client side javascript is embedded directly by in the HTML pages. This script is interpreted by the browser at run time.

Client side scripting cannot be used to connect to the databases on the web server.

Client side scripting can’t access the filesystem that resides at the web server.

Response from a client-side script is faster as compared to a server-side script because the scripts are processed on the local computer.

Best client side javascript frameworks are : Angular.js,Ember.js,React.js,Aurelia.js,Backbone.js,Reactive.js,POOF.js,Mercury.js etc

4

Server Side ScriptingServer-side scripting is a technique used in web development which involves employing scripts on a web server which produce a response customized for each user's (client's) request to the website. The alternative is for the web server itself to deliver a static web page. Scripts can be written in any of a number of server-side scripting languages that are available.

Server side scripting is used to create dynamic pages based a number of conditions when the user's browser makes a request to the server.

Server executes server-side scripts to send out a page but it does not execute client-side scripts.

Server-side JavaScript (SSJS) refers to JavaScript that runs on server-side and is therefore not downloaded to the browser.

The first implementation of SSJS was Netscape's LiveWire, which was included in their Enterprise Server 2.0 back in 1996.

Examples are Node.js,Express.js,Total.js,Silk.js,Ejscript,Wakanda,Helma,etc.5

Design Pattern and its BenefitsA pattern is a reusable solution that can be applied to commonly occurring problems in software design - in our case - in writing JavaScript web applications. Another way of looking at patterns are as templates for how we solve problems - ones which can be used in quite a few different situations.

A design pattern is a reusable software solution.

Patterns can be easily reused: A pattern usually reflects an out of the box solution that can be adapted to suit our own needs. This feature makes them quite robust.

Patterns can be expressive: When we look at a pattern there’s generally a set structure and vocabulary to the solution presented that can help express rather large solutions quite elegantly.

Design patterns are advanced object-oriented solutions to commonly occurring software problems.

Patterns exemplify a level of sophistication that can provide both performance boosts and reduction of excess memory usage.

6

Structure Of Design PatternA pattern is initially presented in the form of a rule that establishes a relationship between:

A context

A system of forces that arises in that context and

A configuration that allows these forces to resolve themselves in contextA design pattern should have a:Pattern name and a description.

Context outline – the contexts in which the pattern is effective in responding to the users needs.

Problem statement – a statement of the problem being addressed so we can understand the intent of the pattern.

Solution – a description of how the user’s problem is being solved in an understandable list of steps and perceptions.

Design – a description of the pattern’s design .

Implementation– a guide to how the pattern would be implemented.

Illustrations – a visual representation of classes in the pattern

Examples – an implementation of the pattern in a minimal form

7

Types of Design PatternsCreational patterns focus on ways to create objects or classes. This may sound simple (and it is in some cases), but large applications need to control the object creation process.Like Builder Pattern,Prototype Pattern,Abstract, Prototype, Singleton .

Structural design patterns focus on ways to manage relationships between objects so that your application is architected in a scalable way. A key aspect of structural patterns is to ensure that a change in one part of your application does not affect all other parts.Like Composite Pattern,Facade Pattern,Flyweight, Adapter and Proxy.Behavioral patterns focus on communication between objects.Like Observer Pattern,Mediator Pattern,Observer and Visitor.

8

Javascript MV* Patterns

There are three different patterns which are● MVC (Model,View,Controller)

● MVP (Model,View,Presenter)

● MVVM (Model,View,ViewModel)

9

MVC and MVPThese design patterns are about separation of concerns:

Model: captures the business entities and business logic for manipulating the entities. Model may be supported with a service-oriented architecture. In that case, the model may capture the client logic to interact with various services.

View: captures the presentation and interaction logic of individual screens. A particular view may be constructed with a hierarchy of sub views.

Controller or presenter: captures the gluing logic that would coordinate views and models to support the end-to-end scenarios.Presenter does not control traffic like Controller.

10

The major difference between MVC and MVP is that, in MVC, models and views can be directly bound; in contrast, in MVP, models and views are not directly bound. Therefore, in MVC, a view can directly render from the provided models in response to the initiation or changes. In contrast, in MVP, the presenter will be responsible for getting data from the models to update the view in response to the initiation or changes. As illustrated in the diagram, in MVC, views are coupled with the models; and yet, in MVP, the views are separated from the models.

MVP is generally used most often in enterprise-level applications where it's necessary to reuse as much presentation logic as possible. Applications with very complex views and a great deal of user interaction may find that MVC doesn't quite fit the bill here as solving this problem may mean heavily relying on multiple controllers. In MVP, all of this complex logic can be encapsulated in a presenter, which can simplify maintenance greatly.

Depending on the implementation, MVP may be more easy to automatically unit test than MVC. The reason often cited for this is that the presenter can be used as a complete mock of the user-interface and so it can be unit tested independent of other components

11

MVC vs MVP

MVP vs MVVMMVVM was originally defined by Microsoft for use with Windows Presentation Foundation (WPF) and Silverlight, having been officially announced in 2005 by John Grossman in a blog post about Avalon (the codename for WPF). It also found some popularity in the Adobe Flex community as an alternative to simply using MVC.

In recent years, MVVM has been implemented in JavaScript in the form of structural frameworks such as Knockout JS, Kendo MVVM and Knockback.js, with an overall positive response from the community.

12

MVVMA viewmodel in MVVM is a special type of presenter. The view model often has properties that directly reflect the fields in the view. The properties and the fields stay in sync. Such synchronization is often implemented with with some sort of observer framework.

Pros:MVVM Facilitates easier parallel development of a UI and the building blocks that power it.The ViewModel can be easier to unit test than event-driven code.The ViewModel (being more Model than View) can be tested without concerns of UI automation and interaction.

Cons:For simpler UIs, MVVM can be overkill.Whilst data-bindings can be declarative and nice to work with, they can be harder to debug than imperative code where we simply set breakpoints.In larger applications, it can be more difficult to design the ViewModel up front to get the necessary amount of generalization.

13

14