August 4, 2017 at 05:40JavaScript as a holiday
This Friday article will be a response to the JavaScript article as a phenomenon in which the author presented unfounded criticism of JavaScript. Personally, I have been writing JavaScript for 15 years and sincerely consider it one of the most powerful PLs to date. The article will, if possible, have a reasoned position on the main points of criticism, since beginners really often have problems with JavaScript. The Script prefix and the frivolous image of the language are misleading, but in fact it turns out that the language is used from front-end and back-end to desktop and mobile applications, programming integrated circuits, video processing and in many other areas. I have long wanted to uncover common misconceptions about JavaScrip t, and then there was just a reason, so welcome under cat.
JavaScript is currently the most popular language on the planet. The reason JavaScript has become so popular (other than the monopoly on the web) is its democratic nature. It allows you to program in a procedural style, and in object-oriented and functional. It imposes minimal restrictions on the developer, allowing you to do any "stupidity". But the irony is that what stupidity is applicable to one class of tasks, applicable to another is more than appropriate. 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 everything superfluous, traditional, "right." The first version of the language turned out to be 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 for 10 years (from 1999 to 2009) the language lived without any changes. Of course, there were negative reasons for this, the policies of Microsoft and Mozilla, much more, but I'm sure not many of the other popular languages could pass the same test and rise after that. Just imagine what would happen to TypeScript or Rust after 10 years of no updates. The reason JavaScript survived is very simple; it solves one problem and does it perfectly.
JavaScript doesn't claim to be syntactic sugar or a bunch of cool features, their programmer can write / connect himself. JavaScript hides from you the hardware of the device, makes it possible to do anything with logic and just leaves you with it. Do you want eval - please, want to redefine any object - there is no problem, you want to pass to the function what is "impossible" to pass - welcome, because it is "impossible" only in your head. Go or C # programmers find it very difficult to understand why this is good. In order not to call upon their hat, these are beautiful languages, just different. Classically, languages put up barriers that prevent programmers from shooting their own legs, such as type checking, various mandatory best practices, and much more. JavaScript does not have these barriers, 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, many languages have some functions blocked, but not in JavaScript. If you drive poorly - maybe it’s a minus for you, dangers, etc., but if you really understand languages too, both in architecture and in paradigms, and you know how to use all of this - you can’t find a better language than JavaScript for common tasks. For private - it is possible, for general, universal - objectively not. Many will argue that, in Java, you can also create dictionaries, an analogue of JS-objects, Python and Ruby are also not typed, there are a lot of eval and duck typing, but it’s as easy to use as in JavaScript. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up not by three buttons and a lever, but by one button under the thumb of the right hand. For private - it is possible, for general, universal - objectively not. Many will argue that, in Java, you can also create dictionaries, an analogue of JS-objects, Python and Ruby are also not typed, there are a lot of eval and duck typing, but it’s as easy to use as in JavaScript. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up not by three buttons and a lever, but by one button under the thumb of the right hand. For private - it is possible, for general, universal - objectively not. Many will argue that, in Java, you can also create dictionaries, an analogue of JS-objects, Python and Ruby are also not typed, there are a lot of eval and duck typing, but it’s as easy to use as in JavaScript. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up not by three buttons and a lever, but by one button under the thumb of the right hand. as in JavaScript it will not work anywhere. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up not by three buttons and a lever, but by one button under the thumb of the right hand. as in JavaScript it will not work anywhere. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up 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 puts many into a stupor, because they are used to being prevented from breaking their foreheads. It's like switching from Windows to Linux. “I entered sudo rm -Rf / and everything broke. Not a system, but r ... but. " With such considerations, the path to the master will be very long. The threshold for entering JavaScript was and remains very low, which gives many newcomers a reason to scold something that they have not figured out. Moreover, a person can have 20 years of experience in Lisp, but in JavaScript he still didn’t even read the documentation, such as 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, read about type conversions must have, and ideally all the documentation (or a good complete book) is not long.
Now I will answer the criticism on the points:
This is very convenient, there are no problems with locking and ownership of objects and other delights of multithreading. Why do you need multithreading? Run the program further while waiting for a long operation to complete? Kolbeks do this much better. NodeJS on one medium machine can hold 100,000 connections. How many would be when replacing callbacks with a flow approach? On multiprocessor machines, js parallels 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 world example of application as the main server technology of an online game with 8 million users. Working with asynchrony / threads is not a weakness, but one of the most powerful advantages of JavaScript. This may require retraining and changing habits, but believe me,
JavaScript has two main options for working with modules:
Both methods work great, and are fully compatible with each other. You can choose the method that you like best. For example, I prefer require because it can be overridden, and this is more in line with the JavaScript philosophy. Sometimes this 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 for working with modules (and many have already created). Another question is whether they will use it outside of your project. The two methods described are the de facto standard in web development, if you are interested in the standards.
I sympathize with your colleagues who "do what they want." Or colleagues with you. There are several typical project structures in web development, as a rule one of them is used, but this is not postulated anywhere, and everyone is really free to write their program based on their view of expediency. What do you want? This is the most popular language on the planet, not some kind of DSL. There are different standards in different JS applications, and rightly so. As for practice, for example, I read even the obfuscated code of libraries very well, which I also wish you. 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 things, by the way. They are also used in JS, in jQuery). The institute did not teach this, right? OOP is only a small part of the world, so small and so hackneyed that it’s even boring to talk. And types in JavaScript are not weak, they basically aren't (except for primitive ones). WeakMap and other things were introduced only to please immigrants from other languages. Reread about duck typing and learn 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 to mention 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 then 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 for 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 code, not always hide behind the IDE skirt. This is not a banter, analyzers are good, but if for you the problem is such errors - somehow you are not programming correctly.
That is, learn the syntax. One option, depending on the situation:
When used properly, problems with this do not occur. If you call a function like myObj.func (), you can be sure that this will equal myObj. When assigning callbacks or passing functions as parameters, information about myObj is lost and, if necessary, you must specify it explicitly via bind. This is logical and understandable for those who know JS, since, for example, you can do so myObj2.func = myObj.func, and the function will be a method of several entities at once. It is not correct to set this to myObj or myObj2, as they are symmetrical. It would not be correct to use the lexical context, as this will introduce confusion into mixins, prototype inheritance, and much more. Therefore, this in such cases is equal to window or undefined, depending on the use of strict mode. But this should not worry you, and this is a fundamental point. This is one of the most typical examples of shooting yourself in the foot. What are you hoping for by calling this on a function called without context? Obviously not something good. There are many such examples, people stack arrays with numbers, divide the result by an object, and complain that they get strange results. In many strange things there is logic, but in particularly strange things it can be just arbitrariness. JavaScript is a flexible language and allows you to do things with which with C ++ your program would not even compile, in the hope that you know what you are doing. No need to neglect this trust and do not know what. If you want a result, then just use this in the right logical way, and leave the phrases a la “I stuck a knife in my throat and I got dark blood 2 times and 2 times light, why so?” Leave for holivars. And don't brag about what do you know what in this non-obvious situation is equal to this or how summarized types add up. Oddly enough, a professionally correct position would be to not know and not to use it, since in different browsers and in different contexts you can get different results. But JavaScript still allows you if you want to use it, for example, to distinguish PhantomJS from a fake User-agent from real Chrome - the road is open.
Two tips:
Callbacks, promises, and async / await are native, so they do not burden the code. I don’t know what you call futures, I don’t trade this. And it’s wonderful that you have a choice of what to use. Callbacks are the basis of everything and neither promises nor async / await will work without them, it is the basic brick of the language. Promises and async / await are perfectly compatible with each other and you can easily use await with any function that returns a promise. If you mean the popular async library for node, then I’m sorry, your knowledge of JS is out of date. The library is good, but less and less used due to the appearance of the above functionality in ES6. But pulling it up depending on the node is also not scary, server dependencies are not given to the user and are easily backed up, in case of removal from npm (in my practice, this has never happened). And there’sFibers , and Sync , and many cool tools used as prescribed by your doctor. Choose the one that is more suitable for specific tasks, and do not complain that there are too many of them.
I don’t know why you decided so. My simple check in the console showed the opposite:
But in fact, it is true or not - it does not matter, const is not created for you, but for the interpreter. And you do not need to change const without deep knowledge of the language. Moreover, on different engines / browsers / devices this functionality can work in different ways, and it is quite possible to find some kind of refrigerator programmed in the JavaScript dialect in which your worst nightmares will happen. The language is open and there are a lot of versions of implementation. In browsers, this error has not been confirmed.
Payment for freedom of creativity and lack of pre-moderation. The problem is not big, just always look at the number of downloads or stars on github. The quality of the top packages is very high. A little popular are also quite good, there are also those as you found. Responsibility for the dependencies used is entirely on you. This is an open community and no one will put your chewed food in your beak. In my opinion, this situation is better than in solutions from one supplier / judge, since libraries have hundreds of thousands of vendors and thousands of them are very worthy. If you want monotony - look at solutions, for example, from Sencha. They are paid, but there were quite good reviews about them. There are thousands of cool libraries in npm, but you had to find the bad one and shoot yourself in the foot. Shoot who will forbid you.
There is no protection from fools in JavaScript, so this category of citizens stuffed bumps, stuffs, and will stuff. In this article I tried to reveal more precisely the philosophy and principles of JavaScript. Often people expect from him what they are used to expect from their old programming language. But JavaScript has its own character, and making friends with it is not difficult. I hope someone this article was useful.
JavaScript is currently the most popular language on the planet. The reason JavaScript has become so popular (other than the monopoly on the web) is its democratic nature. It allows you to program in a procedural style, and in object-oriented and functional. It imposes minimal restrictions on the developer, allowing you to do any "stupidity". But the irony is that what stupidity is applicable to one class of tasks, applicable to another is more than appropriate. 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 everything superfluous, traditional, "right." The first version of the language turned out to be 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 for 10 years (from 1999 to 2009) the language lived without any changes. Of course, there were negative reasons for this, the policies of Microsoft and Mozilla, much more, but I'm sure not many of the other popular languages could pass the same test and rise after that. Just imagine what would happen to TypeScript or Rust after 10 years of no updates. The reason JavaScript survived is very simple; it solves one problem and does it perfectly.
JavaScript doesn't claim to be syntactic sugar or a bunch of cool features, their programmer can write / connect himself. JavaScript hides from you the hardware of the device, makes it possible to do anything with logic and just leaves you with it. Do you want eval - please, want to redefine any object - there is no problem, you want to pass to the function what is "impossible" to pass - welcome, because it is "impossible" only in your head. Go or C # programmers find it very difficult to understand why this is good. In order not to call upon their hat, these are beautiful languages, just different. Classically, languages put up barriers that prevent programmers from shooting their own legs, such as type checking, various mandatory best practices, and much more. JavaScript does not have these barriers, 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, many languages have some functions blocked, but not in JavaScript. If you drive poorly - maybe it’s a minus for you, dangers, etc., but if you really understand languages too, both in architecture and in paradigms, and you know how to use all of this - you can’t find a better language than JavaScript for common tasks. For private - it is possible, for general, universal - objectively not. Many will argue that, in Java, you can also create dictionaries, an analogue of JS-objects, Python and Ruby are also not typed, there are a lot of eval and duck typing, but it’s as easy to use as in JavaScript. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up not by three buttons and a lever, but by one button under the thumb of the right hand. For private - it is possible, for general, universal - objectively not. Many will argue that, in Java, you can also create dictionaries, an analogue of JS-objects, Python and Ruby are also not typed, there are a lot of eval and duck typing, but it’s as easy to use as in JavaScript. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up not by three buttons and a lever, but by one button under the thumb of the right hand. For private - it is possible, for general, universal - objectively not. Many will argue that, in Java, you can also create dictionaries, an analogue of JS-objects, Python and Ruby are also not typed, there are a lot of eval and duck typing, but it’s as easy to use as in JavaScript. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up not by three buttons and a lever, but by one button under the thumb of the right hand. as in JavaScript it will not work anywhere. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up not by three buttons and a lever, but by one button under the thumb of the right hand. as in JavaScript it will not work anywhere. In Java, for example, dictionaries are just an addition attached to a typed class-oriented framework, and in JavaScript, this is the core of the language, and is created with just two "{}" characters. It is as if in a sports car the afterburner was called up 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 puts many into a stupor, because they are used to being prevented from breaking their foreheads. It's like switching from Windows to Linux. “I entered sudo rm -Rf / and everything broke. Not a system, but r ... but. " With such considerations, the path to the master will be very long. The threshold for entering JavaScript was and remains very low, which gives many newcomers a reason to scold something that they have not figured out. Moreover, a person can have 20 years of experience in Lisp, but in JavaScript he still didn’t even read the documentation, such as 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, read about type conversions must have, and ideally all the documentation (or a good complete book) is not long.
Now I will answer the criticism on the points:
Question 1: single-threaded runtime
This is very convenient, there are no problems with locking and ownership of objects and other delights of multithreading. Why do you need multithreading? Run the program further while waiting for a long operation to complete? Kolbeks do this much better. NodeJS on one medium machine can hold 100,000 connections. How many would be when replacing callbacks with a flow approach? On multiprocessor machines, js parallels 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 world example of application as the main server technology of an online game with 8 million users. Working with asynchrony / threads is not a weakness, but one of the most powerful advantages of JavaScript. This may require retraining and changing habits, but believe me,
Question 2: lack of a unified system / standards for the implementation of modules
JavaScript has 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 method that you like best. For example, I prefer require because it can be overridden, and this is more in line with the JavaScript philosophy. Sometimes this 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 for working with modules (and many have already created). Another question is whether they will use it outside of your project. The two methods described are the de facto standard in web development, if you are interested in the standards.
Question 3: the lack of common standards for the structure of the project (everyone does as they want, it can be very difficult to understand the source code)
I sympathize with your colleagues who "do what they want." Or colleagues with you. There are several typical project structures in web development, as a rule one of them is used, but this is not postulated anywhere, and everyone is really free to write their program based on their view of expediency. What do you want? This is the most popular language on the planet, not some kind of DSL. There are different standards in different JS applications, and rightly so. As for practice, for example, I read even the obfuscated code of libraries very well, which I also wish you. Gain experience and learn common patterns.
Question 4: weak types with implicit (and sometimes rather strange) conversions
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 things, by the way. They are also used in JS, in jQuery). The institute did not teach this, right? OOP is only a small part of the world, so small and so hackneyed that it’s even boring to talk. And types in JavaScript are not weak, they basically aren't (except for primitive ones). WeakMap and other things were introduced only to please immigrants from other languages. Reread about duck typing and learn 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 to mention 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 then 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 stupid errors like undefined is not a function)
This is a common problem for 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 code, not always hide behind the IDE skirt. This is not a banter, analyzers are good, but if for you the problem is such errors - somehow you are not programming correctly.
Question 7: lack of type inference in the language itself or in any tool
That is, learn the syntax. One option, depending on the situation:
typeof myVar
myVar.constructor
Question 8: this wonderful context is this (what does this mean at this point in the code - an object? Function?)
When used properly, problems with this do not occur. If you call a function like myObj.func (), you can be sure that this will equal myObj. When assigning callbacks or passing functions as parameters, information about myObj is lost and, if necessary, you must specify it explicitly via bind. This is logical and understandable for those who know JS, since, for example, you can do so myObj2.func = myObj.func, and the function will be a method of several entities at once. It is not correct to set this to myObj or myObj2, as they are symmetrical. It would not be correct to use the lexical context, as this will introduce confusion into mixins, prototype inheritance, and much more. Therefore, this in such cases is equal to window or undefined, depending on the use of strict mode. But this should not worry you, and this is a fundamental point. This is one of the most typical examples of shooting yourself in the foot. What are you hoping for by calling this on a function called without context? Obviously not something good. There are many such examples, people stack arrays with numbers, divide the result by an object, and complain that they get strange results. In many strange things there is logic, but in particularly strange things it can be just arbitrariness. JavaScript is a flexible language and allows you to do things with which with C ++ your program would not even compile, in the hope that you know what you are doing. No need to neglect this trust and do not know what. If you want a result, then just use this in the right logical way, and leave the phrases a la “I stuck a knife in my throat and I got dark blood 2 times and 2 times light, why so?” Leave for holivars. And don't brag about what do you know what in this non-obvious situation is equal to this or how summarized types add up. Oddly enough, a professionally correct position would be to not know and not to use it, since in different browsers and in different contexts you can get different results. But JavaScript still allows you if you want to use it, for example, to distinguish PhantomJS from a fake User-agent from real Chrome - the road is open.
Question 9: absolutely stupid implementation of pattern matching (you match an empty list / object - no problem, you get undefined from there, you mean exactly that, right?) And here again hi cannot read property foo of undefined
Two tips:
- do not make logical mistakes. Your mistakes are not the fault of the language
- if you want to make regular expressions more convenient - use or write libraries. It seems like scolding C # for not being integrated with Facebook. There are hands, there is a head, write what you want, or take one of the many libraries.
Question 10: lack of a unified technology for working with asynchronous code - callbacks, prims, futures, async (if the project has more than one dependency from npm then it is guaranteed that all of them will appear mixed in the code)
Callbacks, promises, and async / await are native, so they do not burden the code. I don’t know what you call futures, I don’t trade this. And it’s wonderful that you have a choice of what to use. Callbacks are the basis of everything and neither promises nor async / await will work without them, it is the basic brick of the language. Promises and async / await are perfectly compatible with each other and you can easily use await with any function that returns a promise. If you mean the popular async library for node, then I’m sorry, your knowledge of JS is out of date. The library is good, but less and less used due to the appearance of the above functionality in ES6. But pulling it up depending on the node is also not scary, server dependencies are not given to the user and are easily backed up, in case of removal from npm (in my practice, this has never happened). And there’sFibers , and Sync , and many cool tools used as prescribed by your doctor. Choose the one that is more suitable for specific tasks, and do not complain that there are too many of them.
Question 11: const (which is actually NOT const)
I don’t know why you decided so. My simple check in the console showed the opposite:
const a = 5
const a = 4
VM1825:1 Uncaught SyntaxError: Identifier 'a' has already been declared
at :1:1
But in fact, it is true or not - it does not matter, const is not created for you, but for the interpreter. And you do not need to change const without deep knowledge of the language. Moreover, on different engines / browsers / devices this functionality can work in different ways, and it is quite possible to find some kind of refrigerator programmed in the JavaScript dialect in which your worst nightmares will happen. The language is open and there are a lot of versions of implementation. In browsers, this error has not been confirmed.
Question 12: absolutely insane npm, with packages of the quality "brother I brought you a meal"
Payment for freedom of creativity and lack of pre-moderation. The problem is not big, just always look at the number of downloads or stars on github. The quality of the top packages is very high. A little popular are also quite good, there are also those as you found. Responsibility for the dependencies used is entirely on you. This is an open community and no one will put your chewed food in your beak. In my opinion, this situation is better than in solutions from one supplier / judge, since libraries have hundreds of thousands of vendors and thousands of them are very worthy. If you want monotony - look at solutions, for example, from Sencha. They are paid, but there were quite good reviews about them. There are thousands of cool libraries in npm, but you had to find the bad one and shoot yourself in the foot. Shoot who will forbid you.
There is no protection from fools in JavaScript, so this category of citizens stuffed bumps, stuffs, and will stuff. In this article I tried to reveal more precisely the philosophy and principles of JavaScript. Often people expect from him what they are used to expect from their old programming language. But JavaScript has its own character, and making friends with it is not difficult. I hope someone this article was useful.