My desire to learn JavaScript in depth dates back to 2007. Unfortunately for one reason or another I did not have the time to do it until 2012. Back in 2011 I wrote why I would like to spend time on JavaScript. And now my focus is fully on learning it. I hope that this delay is for good. Now I see an ecosystem around JavaScript that is really impressive and more importantly stable. However the availability of so many new technologies, libraries, frameworks, and standards hinders the learning process.

I know that there are many books out there that cover the JavaScript language, or particular library or framework. But I wanted to have something like a map that is more oriented towards the layers of software architecture and the development process. I needed to know which technology, framework, aspect, or technique fits where in the development process, or in which part of a layered software architecture.

So I allowed myself to create a structure that helps me organize my knowledge. Each category in it has a brief discussion over the related theory and links to resources that I found most useful for understanding particular topic. During the time I am going to blog about particulr topics in detail and I will put links to these entries in the corresponding category. Some of these posts will have presentation slides as well. These blog posts will probably be heavily influenced by other materials on the web or sometimes will be a direct insight as a result of my development.

As you can see this is a work in progress. However, my wish is to cover most of the things in a period of 1 year. So I plan to update this content very often.

If you like you could follow me on twitter to get notifications for the latest updates.

Usually most of us (at least me) prefer to work with technologies that give us immediate feedback of what we are doing. JavaScript is such technology – we do something and see results. Moreover, we could take a library or two and make some things on the web that are pretty impressive without having much knowledge about the language.

However I think that the fun is much more when one knows the specifics. Learning EcmaScript (the standard which JavaScript language implements) core theory is not that easy. But if you are lucky enough you will find out the blog of Dmitry Soshnikov and the things will start changing. He explains the most important things in EcmaScript version 3 and version 5 of the standard in an amazingly understandable way.

My JavaScript language insights came after I have read his posts as well as some other nice posts by Juriy Zaytsev and Angus Croll So my purpose is not to rewrite the explanation of all these concepts from scratch.

Instead I have prepared a presentation, included some more materials, structured the flow a little bit differently, and added some tweaks from my perspective. In this presentation (and this is also valid for all my presentations and blog posts) I am trying to not be so scientific. I don’t know is this a good approach but I am trying to post things that could be understood even by non-programmers. I am trying to simplify the stuff and to not use more than one term for the same thing. So I have wrapped the presentation of the core theory concepts in a CRUD framework. With other words the presentation flow is based on create, read, update and delete operations. If I am not wrong the programming languages are kind of in-memory CRUD operations so presenting terms along with each operation sounds natural to me.

Finally I would like to mention that I see some concepts like history of EcmaScript and EcmaScript versions, JavaScript Engines and JavaScript Dialects as prerequisites for learning JavaScript Core Theory.

Find here a presentation about patterns.

TODO The role of JavaScript for presentation purposes. Suggested Content:
1. jQuery, MooTools etc. manipulating the DOM and styles
2. CSS related stuff
3. History - Responsive Web Design, Progressive Enhancement, Graceful degradation etc.
4. Tools like Twitter Bootstrap and the related common techniques for content presentation - tables, pagination, carusel etc. 5. Templating mechanisms.LinkedIn comparison could be a good starting point http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more and http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates

The software and the way we build it heavily depend on what the business needs. So if you need to understand why we build software in particular manner, just try to understand what are business needs. In the context of web based applications (including mobile applications) the organizations want more and more desktop-like software with very intuitive and dynamic user interfaces and huge reactivity. Sometimes responsive features are a must in order to be able to deliver mobile solutions with fewer costs.

You can read the two articles by Paul Hammant which summarize very well the history of web application architectures and the current trends in web application architectures.

The consequences for the web application developer are that he must deal with a huge amount of client-side code. And all kind of questions arise. But the most important is: How to organize the huge amount of client side code in a more structured way? And the answer is...MV* family of patterns.

The community responded immediately with a huge amount of client-side libraries and frameworks. They strive to help us apply best practices out of the box. Have a journey through the jungle of these libraries and frameworks and read a nice classification and comparison between the most popular of them. If you need to be aware about the available libraries and frameworks and have a hands on experience with them just check out TodoMVC project.

Have you ever thought about the differences between library and framework?

Usually I use them interchangeably although this probably is completely wrong. In the context of JavaScript landscape I really like the definition that Steven Sanderson gave in his blog post about the seven top JavaScript frameworks/libraries for single-page and rich JavaScript applications. I am citing:

Library

Slots into your existing architecture and add specific functionality

Framework

Give you an architecture (file structure, etc.) that you are meant to follow and, if you do, are intended to handle all common requirements

These definitions are an amazing starting point if you need to understand all those libraries and frameworks out there.

Tell me more about the libraries?
When you are taking an architectural decision take into account that most of the libraries are just a bunch of convenient classes, useful functionality, and often built-in templating mechanism. You are going to need them for sure if you want to structure your code (in MV* style) and optimize some operations (like let’s say making server requests in a REST manner). Of course, if you are professional JavaScript developer it is easy to roll out your own library for this kind of stuff. However it seems that libraries like Backbone are close to perfection and in most of the cases it is completely unnecessary to reinvent the wheel.

What about the frameworks?
As it is mentioned in the Steven’s definition above they give you extra features that you also going to need for sure like file structure, view management, and sort of architectural guidelines that you must follow.

So we end up with several options here:

Backbone Style MV* + Architecture on top of it

To achieve complete application architecure with Backbone we have a lot of options like Boilerplate + LayoutManager, Marionette, Chaplin, and Thorax

Another MV* Style + Architecture on top of it

We have different style MV* libraries like MVVM Knockout and probably some architectures on top of them. For more libraries check out TodoMVC project

Full Framework (Application Architecture)

The third option is to use full application architectures like Ember or AngularJS

Yes, there are a lot of choices. Which is the best one? Probably this question has no answer. Personally my reasoning is the following. Generally, it is safer to choose Backbone and postpone your more concrete architectural decisions until you do some prototyping and development. Then you can roll out your own layer on top of Backbone or choose one of the existing.

Going with a framework is more risky because:

It is not lean…..you make some commitments in advance that could turned out to be wrong later.
You are not flexible enough to make changes on the fly.
You take a decision for several aspects simultaneously. For example I don’t think that one should decide about file structure in the same time when he wants to decide about its preferred MV* style – which exactly happens when going with a framework. For me file structure, build operations and workflows are part of the development process and require another round of picking up solutions like Grunt, Yeoman, Brunch, etc. (see Chapter 11, Development Process)

Sooner or later you will want to dig deeper into particular library or framework. This is possible since most of them are easily accessible on Github. If you want to grasp them easier make sure you have read the theory about JavaScript architectures:

Nicolas Zakas: Scalable JavaScript Application Architecture (Video and Slides)

Addy Osmani: Patterns for Large-Scale JavaScript Application Architecture (Online Book and Backbone Aura - Application architecture that applies the concepts by Zakas and by Osmani)

Steven Sanderson is in the game again. He used this term in his comparison of top 7 libraries and frameworks. The important note here is that these application libraries and frameworks (with some exceptions) does not have any explicit demands on server. You could use whatever server-side technology you want and keep its respective architecture practices. We were talking about application architectures in this chapter. But is there any server-side involved in all these talks? It is counter intuitive but the proper answer is ‘NO’. We were talking about client-side frameworks most of the time. Respectively the patterns and practices are applicable for client-side code.

Some of the techniques involve the server in one way or another. This is especially true when we talk about routing, module and template loading. If we go with Node.js and fully JavaScript based stack definitely all of the concepts are transferable to the server-side code. Similar full stack JavaScript framework is Meteor, which involves not only the server (augmented Node.js) but also the database (mongoDB). Personally I believe that this framework has a huge potential and will gain significant “market share” in the near future.

TODO Suggested Content:
1. Performance
Very good article that makes you understand about the JS performance issues: http://blog.mrale.ph/post/12396216081/the-trap-of-the-performance-sweet-spot Also note the comments section where the Mozilla strategy is defined.
This talk as well http://channel9.msdn.com/Events/Build/2012/4-000
2. Security
3. Authentication

TODO Suggested Content:
1. Build tools like Grunt, Yeoman, Brunch. There was a nice comparison between them.
2. Testing - BDD, TDD, Mocha, Jasmine, JsTestDriver, Buster.
3. CI with Travis, etc.
4. Documenting javascript code

The latest moves from the major vendors like Google and Microsoft allows JavaScript to be used for development of mobile and desktop applications as well.

TODO. Suggested Content:
1. Different HTML5 APIs
2. HTML5 Boilerplate + Modernizr + Intializr
Resources:
http://www.netmagazine.com/features/developer-s-guide-html5-apis
http://www.html5rocks.com/en/
http://movethewebforward.org/
http://html5doctor.com/
http://docs.webplatform.org/wiki/Main_Page
http://html5test.com/
http://diveintohtml5.info/
http://html5please.com/
3. Polyfillying browsers - missing HTML5 functionality with JavaScript http://addyosmani.com/polyfillthehtml5gaps/slides/#1