January 13, 2013 at 18:22

JavaScript: from start to finish

    TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

    JavaScript has a very amazing fate. He crossed 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 a “regular” object-oriented. And in order to make it easy to search for developers for the new language, we decided to make the syntax similar to Java and even made the name similar.
    But the story does not end there. Java, JavaScript are trademarks of Sun (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 named it JScript. They did reverse engineering, and did it so well that they even ripped off all the bugs in the implementation. Later they decided to make a standard and called it ECMAScript.

    Bad parts


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

    A programming language with weak typing, with errors in implementation, with a heavy legacy, with the 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 (global variables) works, how this, prototype and constructors work. Also help jshintto avoid the "bad parts" of the language.

    This whole story is told in more detail in the second lecture of Douglas Crockford . And it's better to see all 8-series . There are captions;).

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

    The basic things you need to understand (following 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 error handling works ( try / catch does not always help ).

    JSON, AJAX and cross-browser compatibility


    The next step in the development of JS was JSON , AJAX and cross-browser development . A huge leap in this step was made thanks to jQuery. I highly recommend reading the tutorial by John Rezig (author of jQuery). The tutorial shows some of the tricks used to create jQuery. Or you can see interesting ideas directly in jQuery sources . Also, interesting tricks are discussed in JavaScript patterns and in essential js design patterns . If it’s still difficult for you, then you can read more basic things here: JavaScript Garden , eloquentjavascript

    Flash off


    HTML5 ( html5rocks , diveintohtml5 ) and CSS3 supplanted Flash from browsers (well, not yet to the end, but this is only a matter of time ). Special thanks to Steve Jobs for this . Now JS has at its disposal: Canvas, WebGL, WebSockets, WebWorkers, Audio, Video, etc.

    Server side


    Google was born a browser. And accelerated JavaScript to impossible, giving the whole world V8. From which, in turn, NodeJS was born (by Ryan Dahl ). So JS got to the server. It would seem much further, and so occupied the entire web technology stack. But this is not the end, JavaScript has managed to supplant SQL as well . Thanks to the guys from 10gen for MongoDB . Related: SQL to MongoDB , sql comparison .

    Everyone can make this conclusion themselves, but I ’ll say it out loud and write: now you can develop a web application from beginning to 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 open-ended questions. That is, it is clear how to write a chat on NodeJS, but what about large and complex projects? ..
    • There are no normal tutorials, as the technology is actively developing, and they quickly become obsolete.
    • The development of modules is spontaneous. Many modules are abandoned. You go to Github and you see that the last commit was about a year ago.
    • There are no "adult" frameworks. There are "young" promising projects. But there are no rail level frameworks.
      Lyrical digression
      There is an opinion that the last rails have 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. Frameworks for node leave a lot of space for imagination (not enough CoC ). If you look at the projects on Express ( de facto web framework ), 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 these are “teenage acne,” which will pass over time. 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 are tools for automation (a tool written in js specifically for these purposes) and a package manager (I know that this is not the first manager, but let's hope that everyone will use it). All this is piled up in the yeoman project . Speaking of yeoman, one cannot but mention: html5-boilerplate and bootstrap

    MV *


    Along with Ajax, the first “heavyweight" libraries / frameworks appeared: ExtJS, YUI, etc. But they are bulky and inconvenient. JQuery on the other hand is 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 . Following Backbone, a lot of MV * frameworks appeared. About them already spoke: article on Habré , continuation and article in English . And you can also compare the frameworks “in practice” by reading the sources on todomvc .

    Angular


    This framework is notable for trying to bring a DataBinding to JavaScript. This is not the only framework that does this. But the authors do not stop there and want to bring native DataBinding support to browsers. They are developing the “model driven views” specification with the Chrome team. Well, he’s also good, because there is good documentation, video, testing is laid . It is quite lightweight and integrates well with other libraries.

    Meteor


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

    But what no Meteor can offer is any other technology: full code reuse from the server on the client (or vice versa), and also a little magic trolley (databinding, client hot reload ...).
    Its only advantage is its minus. Client and server code are not discontinuous. Meteor is not very suitable for cases when the client is done using a different technology. For example, a native mobile or desktop client.
    By the way, in the nearest competitor Meteor derby we solve this issue. Since they use Express and much less magic, you can fasten the REST API to it.
    If you think about it, this is not the first attempt to get away from the classic client-north approach. Before that, there was, for example, GWT. But all previous attempts were less spectacular and it was not JavaScript.

    Mobile


    Not only did JS reach mobile browsers and survive Flash, it also claims to be the place of native applications. This was made possible thanks to Adobe Phonegap (the core of the project was given to open-source called Appache Cordova ).
    If you add libraries for mobile devices, for example: jQtouch, Sencha Touch, zepto; then we 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 easy as writing web applications. Here are some of the latest contenders: tidesdk , Packaged apps from Google Chrome .
    There are other similar projects which were earlier told on Habré: AppJS , Node Webkit .

    JavaScript Substitutes


    After everyone realized how important JavaScript was, we decided to come up with something more successful than JavaScript. There are a bunch of JPs that can be compiled in JS . Among these projects, it is especially possible to distinguish:
    Of course, with this approach with the languages ​​of "intermediaries" the problem with debug 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, JavaScript substitutes, es6 . But despite all the problems, JavaScript is actively developing and gaining momentum: the community is growing, investments are pouring in . All interesting is yet to come!
    Tags:

    Also popular now: