Home Java Articles JavaScript for Java programmers

JavaScript for Java programmers

November 24, 2018

302

JavaScript is weakly typed

Being weakly typed is the first and most important difference from the Java language .

JavaScript does not have the canonical types you are used to in Java, but a feature that recalls the behavior of the wrappers you know. For example, the value <code>1</code> is an object instance <code>Number</code> and is an integer.

You would be inclined to think that objects like <code>Double</code> and <code>Float</code> for floating point numbers also exist . This is not the case: it exists only <code>Number</code> and it is the JavaScript interpreter that dynamically considers variables according to their value.

Here are some variables with different types of data. Notice the absence of the type declaration.

let numInt = 10; // full
typeof numInt; // Number
let numDec = 9.52; // decimal
typeof numDec; // Number
let strSingleQuotes = 'Hello'; // string
typeof strSingleQuotes; // String
let strDoubleQuotes = "Hello";
typeof strDoubleQuotes; // String
typeof foo; // undefined
let obj = {
	bar: 'ok',
	method: function() {
		return this.bar;
	}
};
typeof obj; // Object (oggetto letterale);
let fn = function() {
    console.log('fn()');
};
typeof fn; // Function
let arr = [1, 2, 'a', 'b', {a: 1}]; // array
typeof arr; // Object
let n = null; // null value
typeof n; // Object

The operator <code>typeof</code> returns the data type of a variable, but as demonstrated by the last two examples, it has limited reliability. You will also have noticed that the arrays in JavaScript can contain any type of data and their size is as variable as the collections in Java. Answering your question about the disconcerting outcome of the last two calls to typeof, in JavaScript the following solutions are used:

let arr = [1, 2, 'a', 'b', {a: 1}]; // array
		Array.isArray(arr); // true
		let n = null; // null value
		(n === null); // true, notice the identity operator, preferred in JavaScript

JavaScript has partial support for the OOP

JavaScript currently does not have visibility operators, interfaces, abstract types and more generally all of the advanced features you’re used to in Java. Currently, JavaScript implements a basic version of the classes that support only the constructor and the static methods, but for the most part in JavaScript there are no classes in Java.

In fact, since JavaScript supports functions, mostly objects are created using functions as constructors and exploiting the property prototypefor inheritance and extension.

It follows that in JavaScript the functional paradigm is widespread and in recent years thanks to the success of libraries like Underscore and Lodash has successfully established itself. Ultimately, we can say that JavaScript, despite being an object-based language, does not have the only way to structure the code in the OOP paradigm.

Concision: value or defect?

Following the debate on the stream and lambda functions in Java, we can say that in JavaScript the concision has always been the focus of various discussions about the fact that thanks to the concatenation you get a more compact code but also more difficult to read especially for those who are at the beginning.

Let’s take an example:

'use strict'; // Enable strict mode
const uniqueId = function(len) {
	return 'abcdefghijklmnopqrstuvxyz0123456789'.split('').sort(() =&amp;amp;amp;gt; { return Math.random() * 0.5; }).join('').substring(0, len);
};

For beginners, such a function is almost indecipherable. Analyzing the chain of methods we can deduce that a random alphanumeric string of length is generated len, but the point is that after a long time returning to an implementation written in this way can be difficult.

JavaScript can be concise, but this feature becomes a defect if it is abused.

Internationalization and localization

Despite the huge advances made by JavaScript in recent years in the field of internationalization and localization, we are still far from the level you are used to in Java.

This becomes particularly evident if you use JavaScript on the server with NodeJS . Unlike PHP, Node does not have a set of locales at the time of installation, but folds back to the EN-US locale by default. As a result, the expression:

console.log(new Date().toLocaleDateString());

will produce:

which is correct in Italian format on an OS and a browser in Italian, but if we try to change locale on the server we will not get the desired results unless we specify a different locale when compiling Node (this is not possible if it is installed via the distribution package).

To solve this problem, the solution is to use modules that already contain a set of locales for formatting strings, monetary values and dates.