The fact is that the lack of types kills many birds with one stone. The main ones are the readability of the code, and an increase in the simplicity of programming in general. The first is very important strategically, so that with a large amount of code, long development, the project is still readable and expandable, the second - tactically - in order to quickly solve problems. But an adherent of strict typing may not feel these advantages at first, for example, I myself once switched from C ++ to JS and PHP - and probably even a year was indignant. I will try to explain ..
Brain Resources . The presence of types in the code creates an additional nonweak semantic load, and requires serious brainstorming to memorize the hierarchy, to read the code, to prescribe these same types for each sneeze in the code. In the compiled code, the types used to carry the main meaning behind them - the maximum speed of the program, the minimum consumption of the OP. For scripting languages, such a goal is usually not worth it (and modern compilers are not too much eaten away in the absence of types), and therefore the decisive factors of language typing are precisely the types of brains of programmers in the context of scripting language tasks.
Structural complexity . The scripts emphasize the possible complexity of the script, with high readability. And here JS has got better - reading any JS-code you can see how attention is diverted from the object-type component, and focuses on the structural component: nested closures, functional programming, asynchronous programming. And there would be in JS types - of course, this effect of perception of the code would not exist.
Readability . If you correctly name the variables in the JS code, the code will be read like a book, despite the structural complexity. But when types are added to variables, readability loses much: the reading programmer gets a lot of unnecessary information. Here in life we say Убери яблоко в холодильник and not Убери красное круглое яблоко в большой серебристый холодильник , since the first is easier to perceive. For example, I would compare the reading of the JS code of any widely distributed library with the reading of Pushkin’s poems, whereas the reading of typed C ++ code with the reading of Homer's Iliad (now).
About the simplicity of programming without types . It turns out that without types, and with developed functional tools: half of the patterns are not needed, the second half of the patterns are written in three lines instead of 15. The classical implementation of GoF patterns in typed languages today is more like crutches, which simply exist to compensate for the lack of flexibility in the presence of strong typing - respectively, they are unreadable, you need to seriously deal with them, fill yourself with the questions "why is that?" “is it a facade or an adapter?”, etc. In JS, however, there are plus to the old completely different approaches based on closures, encapsulation, and AF. With the implementation of one-and-the same task in the style of OOP-classics on TS, and in the style of OP on JS, the result is:
- The code on JS turns out to be smaller 3 times, and more readable than a code with strict typing on the same TS.
- The programmer implements the task faster, in proportion to the amount of code.
Plus JS works mainly with a tree-like database called DOM - and its task is basically managing this DOM over time. That is, no serious OOP structures are required, the built-in one is more than enough: processing DOM events, asynchronous JS capabilities. This, coupled with the lack of typification, makes the JS code "the quintessence of control logic." "Ease of programming" does not mean that JS programmers will have a freebie, it means that a good programmer will have time to do 3 times more.
What does js lose without types?
The first thing that JS loses is the automatic validation of incoming parameters of a function - this is almost the main role that types perform in modern scripting languages. Parameters can be validated manually in JS, but this is done extremely rarely, unless it is often checked for a void if (!param1) return false; . Why not do? Because JS carries in itself a style of code in which a type is not the main characteristic of a variable - and programmers quickly understand this.
The second thing that JS loses is the inability to build a classical OOP architecture. No, of course, crutches and bicycles can certainly make a strong similarity to OOP - once (far from ES6), the creators of mootools asked this question, and today 90% of JS programmers facing mootools consider it the worst framework of all time and all peoples) Why? Yes, because in JS the richest functionality, including with regards to encapsulation (so necessary for large projects), a lot of ways to make “safe” expansion points for a program, a lot of “its patterns,” it doesn’t need OOP to make any quality extensible program scale. The typification, the more strict, is the locomotive of the “grandfather's PLO” - and, accordingly, the oppressor of flexible ways of constructing programs.
The last is when working in IDE autocomplete and the "transition to the class" work poorly. This happens, but if you decide to write OOP-like code in js, then use JSDoc to help the IDE. At the same time, poor navigation is a problem of the IDE itself, for example PhpStorm (WebStorm) - it works with navigation in JS well and without JSDoc, and promises that it will soon be excellent.
I described it in my own words as best I could, but it’s difficult to explain the many advantages of the lack of types to a programmer in strongly-typed languages: it’s almost a message to the Buddhist that Christianity is cool :)
UPD but in order not to turn the answer into malicious holivar, it should be noted that types are also useful for the same code readability, for example, in function arguments. But when types are used sometimes, and not in 100% of the code. But if you allow only types in arguments in JS (for example, in TS), programmers will immediately start abusing OOP, and kill the established style of the language, and at the same time all the advantages of JS - I think this is the cause of the typology EcmaScript. Strict typing is useless and even harmful, but only if we are not talking about maximum performance: then there are no questions, strict typification will win.
