The events that gave rise to JavaScript unfolded over a six-month period, from May to December 1995. Netscape Communications has been steadily making its way into the web technology space. They had everything they needed to find ways to further develop web technologies.
The web needed a lightweight scripting language.
And this is where Brendan Eich, the father of JavaScript, comes into our story. Ike was to develop a "Browser Scheme" for Netscape. Scheme is a dynamic, powerful and functional dialect of the Lisp programming language with the most simplified syntax.
The team was tasked with preparing a working prototype in the shortest possible time.
Mocha was intended to be a scripting companion to Java, similar to how C/C++ and Visual Basic interact on the Windows platform.
Within a few weeks, a working prototype was prepared and then integrated into Netscape Communicator.
What was supposed to be the equivalent of Scheme for the browser turned out to be something completely different. Ike's hand was driven by the need to close the deal with Sun and make Mocha a scripting companion to Java. The syntax had to be as close as possible to Java. In addition, semantics for a large number of established idioms were inherited from Java. So Mocha was nothing like Scheme. It looked like dynamic Java, under the skin of which there was a hybrid of Scheme and Self.
The result is an easy-to-learn, dynamic, laconic and powerful language with many advantages, such as an object model and some functional features.
Syntax and semantics of the language
The biggest problems in JS are the syntax and semantics of the language. Together they create an ugly and verbose language that is usually painful to read, according to the opposition.
This can only be true for newly born JS
The web needed a lightweight scripting language.
And this is where Brendan Eich, the father of JavaScript, comes into our story. Ike was to develop a "Browser Scheme" for Netscape. Scheme is a dynamic, powerful and functional dialect of the Lisp programming language with the most simplified syntax.
The team was tasked with preparing a working prototype in the shortest possible time.
Mocha was intended to be a scripting companion to Java, similar to how C/C++ and Visual Basic interact on the Windows platform.
Within a few weeks, a working prototype was prepared and then integrated into Netscape Communicator.
What was supposed to be the equivalent of Scheme for the browser turned out to be something completely different. Ike's hand was driven by the need to close the deal with Sun and make Mocha a scripting companion to Java. The syntax had to be as close as possible to Java. In addition, semantics for a large number of established idioms were inherited from Java. So Mocha was nothing like Scheme. It looked like dynamic Java, under the skin of which there was a hybrid of Scheme and Self.
The result is an easy-to-learn, dynamic, laconic and powerful language with many advantages, such as an object model and some functional features.
Syntax and semantics of the language
The biggest problems in JS are the syntax and semantics of the language. Together they create an ugly and verbose language that is usually painful to read, according to the opposition.
This can only be true for newly born JS
Historical issues
Problems in the language that remain for historical reasons require crutches, but they are also clumsy and complex. This arose as a result of haste even at the birth of the language, or more precisely, because of the circumstances under which this haste was necessary. Despite this, some of the problems in the language were corrected along with the standardization of the language.
Perhaps one of the biggest mistakes made due to the rush in which JavaScript was developed was that objects that behave exactly the same could be of different types. For example, the type of the string (Hello world) is not the same as the type of the new String object (new String('Hello world')). This sometimes leads to undesirable consequences that can be confusing.
Problems in the language that remain for historical reasons require crutches, but they are also clumsy and complex. This arose as a result of haste even at the birth of the language, or more precisely, because of the circumstances under which this haste was necessary. Despite this, some of the problems in the language were corrected along with the standardization of the language.
Perhaps one of the biggest mistakes made due to the rush in which JavaScript was developed was that objects that behave exactly the same could be of different types. For example, the type of the string (Hello world) is not the same as the type of the new String object (new String('Hello world')). This sometimes leads to undesirable consequences that can be confusing.
Let's look at another example.
The value true will be printed to the console. This result will be due to the fact that JavaScript has an old bug. typeof null returns "object".
These bugs have existed for many years and will most likely never be fixed. This is because there is too much code written that relies on this kind of erroneous behavior.
Speaking of standards. The language standard is ECMAScript, often called ES. Version 1 was released in June 1997. This event opened up JavaScript to a larger audience and gave third-party developers the opportunity to participate in the development of the language.
Dynamic Typing
One of the favorite arguments against JavaScript is dynamic typing. Developers working in statically typed languages consider this to be crazy, which is why they call it a non-language. For such cases, TypeScript was developed to solve this problem, which for the most part is a matter of everyone’s habit, as much as a flaw of the language.
But we must remember that dynamic typing carries both great power and great responsibility.
These bugs have existed for many years and will most likely never be fixed. This is because there is too much code written that relies on this kind of erroneous behavior.
Speaking of standards. The language standard is ECMAScript, often called ES. Version 1 was released in June 1997. This event opened up JavaScript to a larger audience and gave third-party developers the opportunity to participate in the development of the language.
Dynamic Typing
One of the favorite arguments against JavaScript is dynamic typing. Developers working in statically typed languages consider this to be crazy, which is why they call it a non-language. For such cases, TypeScript was developed to solve this problem, which for the most part is a matter of everyone’s habit, as much as a flaw of the language.
But we must remember that dynamic typing carries both great power and great responsibility.
Speed
Another favorite criterion for evaluating programming languages is their speed. There is an opinion that JS is slow.
It is also believed that the “native” purpose of JS is DOM manipulation. In fact, this has not been the case for a long time and JS is successfully used on the server, in mobile devices and even in microcontrollers. But that's not what this is about. The point is that when you work with the DOM using JavaScript, it is not the JS that slows down, but the DOM. There are many reasons why the DOM is so slow, but let me narrow the focus to just one reason. The problem is with the HTML specification itself.
In section 1.1.1 The DOM Structure Model there is the following paragraph:
...objects in the DOM are live; that is, changes to the underlying document structure are reflected in all relevant NodeList and NamedNodeMap objects…
The point is that objects in the DOM tree are “live”. This means that whenever any part of the DOM changes, those changes are reflected in every DOM object.
There is a project called Benchmarks Game. The guys wrote programs (binary tree traversal, n-body, etc.) in all popular programming languages and developed a method for measuring speed and memory consumption.
Of all the interpreted languages, JavaScipt is the fastest. As of 2016, it is five times faster than Python and Ruby (including JRuby).
No alternative
Also, a significant reason for dislike is the lack of alternatives. Formally, this is not entirely true, but when working with the web, you will be working with JavaScript.
Prototypical Inheritance Model
The prototypical model of inheritance causes confusion and, as a result, dissatisfaction.
When it comes to inheritance, there is only one construct in JavaScript: objects. Each object has an internal reference to another object, called its prototype. This prototype object has its own prototype, and so on until an object with a null value is reached as its prototype. null by definition has no prototype and acts as the last link in that prototype chain.
This architecture causes the following problems:
Changing prototype properties can have unexpected results: if a prototype property is changed, it can affect all objects that inherit that prototype. This can cause your application to behave unexpectedly and make debugging more difficult.
Incorrect inheritance of properties and methods: If an object inherits a property or method that is already in its prototype, it can lead to conflicts and unpredictable application behavior.
Lack of explicit association between objects: Prototypical inheritance can be implicit, making it difficult to understand the relationships between objects and complicate their further modification.
Low entry threshold
The supposedly low barrier to entry into the language gives rise to even more gossip that comes from the element of the language - JavaScript, when it was created, was designed as a simple scripting language for the dynamism of pages. Nowadays, the language has added a lot of features for large programming and does not make it so easy.
End
I would like to end with a quote:
“There are only two types of programming languages: the ones that people complain about all the time, and the ones that no one uses.” Bjarne Stroustrup
Another favorite criterion for evaluating programming languages is their speed. There is an opinion that JS is slow.
It is also believed that the “native” purpose of JS is DOM manipulation. In fact, this has not been the case for a long time and JS is successfully used on the server, in mobile devices and even in microcontrollers. But that's not what this is about. The point is that when you work with the DOM using JavaScript, it is not the JS that slows down, but the DOM. There are many reasons why the DOM is so slow, but let me narrow the focus to just one reason. The problem is with the HTML specification itself.
In section 1.1.1 The DOM Structure Model there is the following paragraph:
...objects in the DOM are live; that is, changes to the underlying document structure are reflected in all relevant NodeList and NamedNodeMap objects…
The point is that objects in the DOM tree are “live”. This means that whenever any part of the DOM changes, those changes are reflected in every DOM object.
There is a project called Benchmarks Game. The guys wrote programs (binary tree traversal, n-body, etc.) in all popular programming languages and developed a method for measuring speed and memory consumption.
Of all the interpreted languages, JavaScipt is the fastest. As of 2016, it is five times faster than Python and Ruby (including JRuby).
No alternative
Also, a significant reason for dislike is the lack of alternatives. Formally, this is not entirely true, but when working with the web, you will be working with JavaScript.
Prototypical Inheritance Model
The prototypical model of inheritance causes confusion and, as a result, dissatisfaction.
When it comes to inheritance, there is only one construct in JavaScript: objects. Each object has an internal reference to another object, called its prototype. This prototype object has its own prototype, and so on until an object with a null value is reached as its prototype. null by definition has no prototype and acts as the last link in that prototype chain.
This architecture causes the following problems:
Changing prototype properties can have unexpected results: if a prototype property is changed, it can affect all objects that inherit that prototype. This can cause your application to behave unexpectedly and make debugging more difficult.
Incorrect inheritance of properties and methods: If an object inherits a property or method that is already in its prototype, it can lead to conflicts and unpredictable application behavior.
Lack of explicit association between objects: Prototypical inheritance can be implicit, making it difficult to understand the relationships between objects and complicate their further modification.
Low entry threshold
The supposedly low barrier to entry into the language gives rise to even more gossip that comes from the element of the language - JavaScript, when it was created, was designed as a simple scripting language for the dynamism of pages. Nowadays, the language has added a lot of features for large programming and does not make it so easy.
End
I would like to end with a quote:
“There are only two types of programming languages: the ones that people complain about all the time, and the ones that no one uses.” Bjarne Stroustrup
