Javascript: from beginning to end

TL;DR   .   "   ".     ,  ,        .        " JavaScript",     . 

JavaScript has a very amazing fate. He covered the path from the most misunderstood to the most amazing language. He had a difficult childhood:

Initially, the Author wanted to write a functional language. But managers wanted to get, "ordinary" object-oriented. And so that it was easy to search for developers for the new language, the syntax was decided to be similar to Java and even the name was made similar.

But the story does not end there. Java, JavaScript are Sun trademarks (and now Oracle). Microsoft could not use the name JavaScript (Netcape and Sun were friends against Microsoft). As a result, Microsoft decided to reverse engineer JavaScript and called it JScript. They made reverse engineering, and did it so well that they even tore off all the bugs in the implementation. Later decided to make a standard and called it ECMAScript.

Bad parts

Due to the fact that the language was written almost in two weeks (this is very little), a number of bugs were allowed in it. And later, when the language came out and was torn off by Microsoft, it was already too late to change something. Some ideas are a heavy legacy of Java, from which the syntax of the language is taken.



A programming language with weak typing, with errors in implementation, with a heavy legacy, with features of a functional language causes only one feeling - “HOW? Well, how? A constantly updated list of "pearls" can be found here .



In order not to go crazy when working with JavaScript, you need to understand how weak typing works, how the scope of variables works (global variables are evil), how this, prototype and constructors work. Jshint will also help to avoid the “bad parts” of the language.

')

This whole story is described in more detail in the second lecture of Douglas Crockford . And it’s better to watch all 8 episodes . There are captions;).



It is worth noting that, despite all the drawbacks, the author managed to make the first functional language, with such a wide distribution. Crockford has an introductory article on the functional nature of JavaScript .



The basic things that need to be understood (resulting from the functional / asynchronous nature of the language) are: what is control flow and how does it help when working with asynchronous language and how does error handling work ( try / catch do not always help ).

JSON, AJAX and cross-browser compatibility

The next stage in the development of JS were JSON , AJAX and cross-browser development . A huge leap in this stage was made thanks to jQuery. I highly recommend to get acquainted with the tutorial from John Rezig (by jQuery). The tutorial shows some of the techniques used to create jQuery. Or you can see interesting ideas directly in the jQuery source . Also interesting techniques are discussed in JavaScript patterns and in essential js design patterns . If this is still difficult for you, then you can familiarize yourself with more basic things here: JavaScript Garden , eloquentjavascript

Flash off

HTML5 ( html5rocks , diveintohtml5 ) and CSS3 pushed Flash out of browsers (well, not completely, but it's only a matter of time ). Special thanks for this to Steve Jobs . Now JS has at its disposal: Canvas, WebGL, WebSockets, WebWorkers, Audio, Video, etc.

Server-side

Google was released by the browser. And sped up JavaScript can not be, giving the world a V8. From which, in turn, was born NodeJS (by Ryan Dahl ). So JS got on the server. It would seem much further, and so occupied the entire web-stack of technologies. But this is not the end, JavaScript has managed to oust more and SQL . Thanks to the 10gen guys for MongoDB . Related topics: SQL to MongoDB , sql comparison .



Everyone can make this conclusion themselves, but I will say it out loud : now you can develop a web application from the beginning to the end, knowing only JavaScript (html and css do not count).

A spoon of tar

• NodeJS has not yet reached version 1, there are a number of not closed questions. That is, it’s clear how to write a chat on NodeJS, but how to deal with large and complex projects? ..
• There are no normal tutorials, as the technology is actively developing, and they quickly become obsolete.
• The development of modules occurs spontaneously. Many modules are abandoned. You go to Github and see that the last commit was about a year ago.
• There are no "adult" frameworks. There are "young" hopeful projects. But there are no rails level frameworks.
  
  
  Lyrical digression

  There is an opinion that in the last rails there is a very high entry threshold, but in fact this is because all the standard tasks are solved in the rails and you do not need to reinvent the wheel every time. The frameworks for the node leave a lot of space for imagination (not enough CoC ). If you look at the projects on Express ( web framework de-facto ), then you will not find two identical projects. Someone puts the settings in config.js , someone makes the central application as a module for testing, someone uses syntactic sugar to autoload the modules , etc.

Most likely it is "teen acne", which eventually will pass. But while it is still relevant.

Further more

Frontend development

Finally, the front-end development got out of the Stone Age, when everything was done manually. There were tools for automation (a tool written in js specifically for this purpose) and a package manager (I know that this is not the first manager, but let's hope that everyone will use this). All this is collected in a bunch in the project yeoman . If we talk about yeoman, it is impossible not to mention: html5-boilerplate and bootstrap

MV *

Along with Ajax, the first heavyweight libraries / frameworks appeared: ExtJS, YUI, etc. But they are cumbersome and inconvenient. JQuery is, on the other hand, more lightweight and familiar, but since it is a library and not a framework, it does not offer a method for structuring code. Backbone came to the rescue. Behind Backbone, many MV * framewalks appeared. About them already told: article on Habré , continuation and article in English . And you can also compare the frameworks "in practice" by reading the source code on todomvc .

Angular

This framework is notable for trying to bring a databinding into javascript. This is not the only framework that does this. But the authors do not stop at this and want to bring native support for DataBinding to browsers. They develop the model driven views specification along with the Chrome team. Well, he is also good, because there is good documentation, video, testing laid. It is fairly lightweight and integrates well with other libraries.

Meteor

It is behind this framework (and others like it) that the future of NodeJS. And this is why, in itself, JavaScript on the server is still something “fun.” We all understand that all these stories about rabid performance due to asynchrony are just marketing. Speed, fault tolerance, the ability to withstand the load is determined not by the PL, but by the architecture. On how data storage (sharding), caching, task queue, distributed computing and from the absence of bottlenecks (bottleneck), etc. are organized. Understanding this, I would rather choose a PL that is easy to write and maintain a large code base for which there are a lot of ready-made solutions (hinting at RoR). Bottlenecks requiring tremendous performance, distributed computing, etc. can be written in Erlang, Java or C.



But no other technology can offer what Meteor can do: full reuse of the code from the server to the client (or vice versa), and there’s also a small cart of magic (databinding, client hot reload ...).

Its only advantage is its disadvantage. Client and server code are not discontinuous. Meteor is not very suitable for those cases where the client is done using another technology. For example, native mobile or desktop client.

By the way, in the closest competitor Meteor derby this issue is resolved. Since they use Express and much less magic, you can tie the REST API to it.

If you think this is not the first attempt to get away from the classic client-northern approach. Before this was, for example, GWT. But all previous attempts were less spectacular and it was not javascript.

Mobile

Not only did JS get to mobile browsers and Flash survived, he also claims to be in the place of native applications. This was made possible by Adobe Phonegap (the core of the project was given to open-source called Appache Cordova ).

If you add a library for mobile devices, for example: jQtouch, Sencha Touch, zepto; That will get applications with a "native interface". Here's how to mix angular and jqtouch under PhoneGap

If you add game engines , you get mobile games, etc.

Desktop

There have long been attempts to make writing desktop applications as simple as writing web applications. Here are some of the latest contenders: tidesdk , packaged apps from Google Chrome .

There are other similar projects that were previously told on Habré: AppJS , Node Webkit .

JavaScript Substitutes

After everyone realized how important JavaScript is, we decided to come up with something more successful than JavaScript. There are a bunch of YAPs that can be compiled into JS . Among these projects, the most notable are:

• coffeescript - JS Ruby way. Here is a book
  
  
• emscripten - Compiler from LLVM to JavaScript. And in LLVM you can compile a lot of C / C ++ libraries and more.
• dartlang - js google way. Read about it on Habré .
• typescriptlang - JS Microsoft way. Announcement on Habré
  
  

Of course, with such an approach with languages ​​“mediators”, there is a problem with debagging on the face. It is solved using Source Maps .

Total

JavaScript is a very peculiar language, with birth injuries that at different times tried to solve in different ways: jslint, substitutes for JavaScript, es6 . But despite all the problems, JavaScript is actively developing and gaining momentum: the community is growing, investments are flowing . All the fun is yet to come!