Javascript like a holiday
This Friday article will be a response to a JavaScript article as a phenomenon in which the author expounded unfounded criticism of JavaScript. Personally, I have been writing on JavaScript for 15 years and sincerely consider it one of the most powerful PLs to date. The article will, if possible, provide a reasoned position on the main theses of criticism, since beginners often have problems with JavaScript. The Script prefix and frivolous image of the language mislead, but in practice it is found that the language is used from front-end and back-end to deskopnyh and mobile applications, programming of integrated circuits, video processing and in many other areas. I have long wanted to reveal the frequent misconceptions about JavaScrip t, and then there was a reason, so welcome under cat.
Currently, JavaScript is the most popular PL on the planet. The reason why JavaScript has become so popular (except for the monopoly on the web) is its democracy. It allows you to program in a procedural style, and object-oriented and functional. It imposes minimal restrictions on the developer, allowing you to create any "nonsense." But the irony is that what is foolishness applicable to one class of tasks, applicable to another is more than reasonable. Legend has it that JavaScript was created in 2 weeks. And again, the irony of life, in such conditions, you can lay in the language only the most important thing, leaving behind all that is unnecessary , traditional, "correct". The first version of the language was very compact and concise. All of these get / set, const and await appeared much later. The initial principles of the language were so good that 10 years (from 1999 to 2009) the language lived without any changes at all. Of course, there were negative reasons for this, the policies of Microsoft and Mozilla, and many more, but I am sure that not many other popular languages ​​could pass the same test and rise after that. Just imagine what would happen with TypeScript or Rust after 10 years of lack of updates. The reason why JavaScript survived is very simple; it solves one problem and does it perfectly.
JavaScript does not claim to be syntactic sugar or a set of cool features , their programmer can write / connect himself. JavaScript hides the hardware of the device from you, makes it possible to do anything with logic and just leaves you with it . If you want eval - please, you want to redefine any object - there are no problems, you want to transfer to the function that “you cannot” pass — welcome, because this “can't” is only in your head. Programmers on Go or C # is very difficult to understand why this is good. In order not to call their heyt on themselves, these are wonderful languages, just others. Classically, languages ​​put barriers that prevent programmers from shooting themselves, this is type checking, various required best practices, and much more. There are no barriers in JavaScript, you have the right to shoot anywhere, and in 0.01% of cases shooting in the leg also makes sense. This can be compared with a sports car, in some languages ​​some functions are blocked, but not in JavaScript. If you are driving poorly - perhaps this is a minus for you, dangers, etc., but if you are really good at languages, architecture, paradigms, and know how to use it all - it’s better than JavaScript for common tasks can not found. For the private - it is possible, for the general, the universal - objectively not. Many people will argue, they say, in Java, you can also create dictionaries, an analogue of JS objects, Python and Ruby are also not typed, in many places there is both eval and duck typing, but using it as easy as in JavaScript will not work anywhere. In Java, for example, dictionaries are just an add-on attached to a typed class-oriented framework, and in JavaScript it is the basis of the language, and is created with just two characters "{}". It is as if in a sports car the afterburner was called not by three buttons and a lever, but by one button under the thumb of the right hand. Freedom is not just possible, it is encouraged.
This leads many into a stupor, because they are used to not being allowed to hurt their foreheads. It’s like switching from Windows to Linux. “I entered sudo rm -Rf / and it all broke. Not a system, but a ... but. " With such reasoning, the path to the master will be very long. The JavaScript entry threshold has been and remains very low; it gives many newcomers a reason to curse something they haven’t understood. Moreover, a person may have 20 years of experience in Lisp, but according to JavaScript, he still didn’t even read the documentation, such as, and so smart. This is enough to write simple programs, but if a person wants to understand why true <2 === true, and why it is correct and logical to read about type conversion must have, and ideally all documentation (or a good full book), this is not long.
')
Now I will answer the criticism by points:
It is very convenient, there are no problems with locks and ownership of objects and other charms of multithreading. Why do you need multithreading? Run the program further while waiting for the execution of a long operation? Kolbeki deal with this much better. NodeJS on one average typewriter can hold 100,000 connections each. How many would there be if replacing the cones with a flow approach? On multiprocessor machines, js will perfectly parallel the launch of a local cluster. 8 cores - 8 processes, 16 cores - 16 processes, each independent of each other and simple inside. This is a real example from the practice of application, as the main server technology of online games with 8 million users. Working with asynchronous / streams is not a weakness, but one of the most powerful advantages of JavaScript. This may require retraining and changing habits, but believe me, you will gain a lot.
In JavaScript, there are two main options for working with modules:
Both methods work great, and are fully compatible with each other. You can choose the way that you prefer. For example, I like require more because it can be redefined, and this is more in line with the JavaScript philosophy. Sometimes it makes sense, for example when writing your preprocessors. Why I say that the two “main” options are because the JavaScript community is open to any innovations, and you can create a third, fourth, thousandth system of working with modules (and many have already created). Another question is whether it will be used outside of your project. The two methods described are the de facto standard in web development if you are interested in standards.
I sympathize with you colleagues who "do what they want." Or colleagues with you. There are several typical project structures in web development, one of them is usually used, but this is not postulated anywhere, and everyone is really free to write their own program based on their view of expediency. What do you want? This is the most popular language on the planet, and not some DSL. JS has different standards in different applications, and rightly so. As for practice, I, for one, perfectly read even the obfuscated code of libraries, which is what you want. Gain experience and learn common patterns.
Strange for whom? Java, C #, PHP, Python, Lisp or Ams programmers? Say asm is not strange? What about Lisp? The world is much richer than your favorite language and what is strange for some is normal for others. Look at least at Haskell with its monads and functors (very powerful stuff, by the way. In JS, they are also used, in jQuery). The institute was not taught this, right? PLO is only a small part of the world, so small and so hackneyed that it is even boring to speak. And the types in JavaScript are not weak, they are fundamentally absent (except for primitive ones). WeakMap and others introduced only in order to please the immigrants from other languages. Re-read about duck typing and learn how to use it, you will not have problems with types.
Again, especially for immigrants from other languages ​​and for the IDE, classes have been introduced for quite some time. They are supported by all major browsers, not talking about NodeJS. OOP in JavaScript is richer than in most other languages. You can inherit through classes, you can through prototypes. In many cases, the proper use of JavaScript prototypes are faster, more convenient and more logical, and the program is more compact and more readable. But again, this is not taught at the institute, and the JavaScript community must then prove that this is also possible.
This is a common problem of all interpreted languages ​​with eval, and to give up this power for the sake of being able to catch 5% of the most stupid mistakes is a dubious idea. In general, develop the discipline of the code, not all the time behind the IDE skirt to hide. This is not banter, analyzers are good, but if the problem is such errors for you, somehow you do not program correctly.
This is, learn the syntax. One of the options, depending on the situation:
this . myObj.func(), , this myObj. , myObj , , bind. JS, , , myObj2.func = myObj.func, . this myObj myObj2, . , , . this window undefined, strict mode. , . . , this , ? - . , , , . - , . JavaScript , C++ , , , . . , this , - « 2 , 2 , ?» . , this . , , , . JavaScript , , , PhantomJS c User-agent Chrome — .
:
, , async/await — , . , , . , , . async/await , . async/await await , . async node, , JS . , ES6. , , npm ( ). Fibers, Sync, , . , , , .
, . :
— , const , . const. , // , - , JavaScript, . . .
. , github. . , , . . . , , /, . — , , Sencha. , . npm , . , .
JavaScript , , , . JavaScript. -, . JavaScript , . - .
Currently, JavaScript is the most popular PL on the planet. The reason why JavaScript has become so popular (except for the monopoly on the web) is its democracy. It allows you to program in a procedural style, and object-oriented and functional. It imposes minimal restrictions on the developer, allowing you to create any "nonsense." But the irony is that what is foolishness applicable to one class of tasks, applicable to another is more than reasonable. Legend has it that JavaScript was created in 2 weeks. And again, the irony of life, in such conditions, you can lay in the language only the most important thing, leaving behind all that is unnecessary , traditional, "correct". The first version of the language was very compact and concise. All of these get / set, const and await appeared much later. The initial principles of the language were so good that 10 years (from 1999 to 2009) the language lived without any changes at all. Of course, there were negative reasons for this, the policies of Microsoft and Mozilla, and many more, but I am sure that not many other popular languages ​​could pass the same test and rise after that. Just imagine what would happen with TypeScript or Rust after 10 years of lack of updates. The reason why JavaScript survived is very simple; it solves one problem and does it perfectly.
JavaScript does not claim to be syntactic sugar or a set of cool features , their programmer can write / connect himself. JavaScript hides the hardware of the device from you, makes it possible to do anything with logic and just leaves you with it . If you want eval - please, you want to redefine any object - there are no problems, you want to transfer to the function that “you cannot” pass — welcome, because this “can't” is only in your head. Programmers on Go or C # is very difficult to understand why this is good. In order not to call their heyt on themselves, these are wonderful languages, just others. Classically, languages ​​put barriers that prevent programmers from shooting themselves, this is type checking, various required best practices, and much more. There are no barriers in JavaScript, you have the right to shoot anywhere, and in 0.01% of cases shooting in the leg also makes sense. This can be compared with a sports car, in some languages ​​some functions are blocked, but not in JavaScript. If you are driving poorly - perhaps this is a minus for you, dangers, etc., but if you are really good at languages, architecture, paradigms, and know how to use it all - it’s better than JavaScript for common tasks can not found. For the private - it is possible, for the general, the universal - objectively not. Many people will argue, they say, in Java, you can also create dictionaries, an analogue of JS objects, Python and Ruby are also not typed, in many places there is both eval and duck typing, but using it as easy as in JavaScript will not work anywhere. In Java, for example, dictionaries are just an add-on attached to a typed class-oriented framework, and in JavaScript it is the basis of the language, and is created with just two characters "{}". It is as if in a sports car the afterburner was called not by three buttons and a lever, but by one button under the thumb of the right hand. Freedom is not just possible, it is encouraged.
This leads many into a stupor, because they are used to not being allowed to hurt their foreheads. It’s like switching from Windows to Linux. “I entered sudo rm -Rf / and it all broke. Not a system, but a ... but. " With such reasoning, the path to the master will be very long. The JavaScript entry threshold has been and remains very low; it gives many newcomers a reason to curse something they haven’t understood. Moreover, a person may have 20 years of experience in Lisp, but according to JavaScript, he still didn’t even read the documentation, such as, and so smart. This is enough to write simple programs, but if a person wants to understand why true <2 === true, and why it is correct and logical to read about type conversion must have, and ideally all documentation (or a good full book), this is not long.
')
Now I will answer the criticism by points:
Question 1: single threaded runtime
It is very convenient, there are no problems with locks and ownership of objects and other charms of multithreading. Why do you need multithreading? Run the program further while waiting for the execution of a long operation? Kolbeki deal with this much better. NodeJS on one average typewriter can hold 100,000 connections each. How many would there be if replacing the cones with a flow approach? On multiprocessor machines, js will perfectly parallel the launch of a local cluster. 8 cores - 8 processes, 16 cores - 16 processes, each independent of each other and simple inside. This is a real example from the practice of application, as the main server technology of online games with 8 million users. Working with asynchronous / streams is not a weakness, but one of the most powerful advantages of JavaScript. This may require retraining and changing habits, but believe me, you will gain a lot.
Question 2: the lack of a unified system / standards for the implementation of modules
In JavaScript, there are two main options for working with modules:
- official through import
- and traditional, through require
Both methods work great, and are fully compatible with each other. You can choose the way that you prefer. For example, I like require more because it can be redefined, and this is more in line with the JavaScript philosophy. Sometimes it makes sense, for example when writing your preprocessors. Why I say that the two “main” options are because the JavaScript community is open to any innovations, and you can create a third, fourth, thousandth system of working with modules (and many have already created). Another question is whether it will be used outside of your project. The two methods described are the de facto standard in web development if you are interested in standards.
Question 3: the lack of uniform standards for the project structure (everyone does everything as they want, the source code can be very difficult to understand)
I sympathize with you colleagues who "do what they want." Or colleagues with you. There are several typical project structures in web development, one of them is usually used, but this is not postulated anywhere, and everyone is really free to write their own program based on their view of expediency. What do you want? This is the most popular language on the planet, and not some DSL. JS has different standards in different applications, and rightly so. As for practice, I, for one, perfectly read even the obfuscated code of libraries, which is what you want. Gain experience and learn common patterns.
Question 4: weak types with implicit (and sometimes rather strange) transformations
Strange for whom? Java, C #, PHP, Python, Lisp or Ams programmers? Say asm is not strange? What about Lisp? The world is much richer than your favorite language and what is strange for some is normal for others. Look at least at Haskell with its monads and functors (very powerful stuff, by the way. In JS, they are also used, in jQuery). The institute was not taught this, right? PLO is only a small part of the world, so small and so hackneyed that it is even boring to speak. And the types in JavaScript are not weak, they are fundamentally absent (except for primitive ones). WeakMap and others introduced only in order to please the immigrants from other languages. Re-read about duck typing and learn how to use it, you will not have problems with types.
Question 5: Lack of Normal Classes / OOP
Again, especially for immigrants from other languages ​​and for the IDE, classes have been introduced for quite some time. They are supported by all major browsers, not talking about NodeJS. OOP in JavaScript is richer than in most other languages. You can inherit through classes, you can through prototypes. In many cases, the proper use of JavaScript prototypes are faster, more convenient and more logical, and the program is more compact and more readable. But again, this is not taught at the institute, and the JavaScript community must then prove that this is also possible.
Question 6: the lack of a single sane and working static code analyzer (welcome to the wonderful world of the silliest errors like undefined is not function)
This is a common problem of all interpreted languages ​​with eval, and to give up this power for the sake of being able to catch 5% of the most stupid mistakes is a dubious idea. In general, develop the discipline of the code, not all the time behind the IDE skirt to hide. This is not banter, analyzers are good, but if the problem is such errors for you, somehow you do not program correctly.
Question 7: no type inference in the language itself or in any tool
This is, learn the syntax. One of the options, depending on the situation:
typeof myVar
myVar.constructor
8: this ( this — ? ?)
this . myObj.func(), , this myObj. , myObj , , bind. JS, , , myObj2.func = myObj.func, . this myObj myObj2, . , , . this window undefined, strict mode. , . . , this , ? - . , , , . - , . JavaScript , C++ , , , . . , this , - « 2 , 2 , ?» . , this . , , , . JavaScript , , , PhantomJS c User-agent Chrome — .
9: pattern matching ( / — , undefined, , ? ) cannot read property foo of undefined
:
- . —
- — . , C# , Facebook . , , , .
10: — , , , async ( npm )
, , async/await — , . , , . , , . async/await , . async/await await , . async node, , JS . , ES6. , , npm ( ). Fibers, Sync, , . , , , .
11: const ( const )
, . :
const a = 5
const a = 4
VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared
at <anonymous>:1:1
— , const , . const. , // , - , JavaScript, . . .
12: npm, « »
. , github. . , , . . . , , /, . — , , Sencha. , . npm , . , .
JavaScript , , , . JavaScript. -, . JavaScript , . - .
Source: https://habr.com/ru/post/334858/
All Articles