Javascript Fundamentals: Number Datatype Part II

ES2015/ES6 came with the built in datatypes that are really handy. They’re so handy, that they are part of a strong argument for using ES2015 and transpiling, along with Arrow Functions, block scope, destructuring, spread operators, and defaults. ES2015 includes the Number type. This is super handy for dealing with your numbers in a consistent way across different environments and, as you’ll see, even locales.

To review, last time we talked about the JavaScript Number type,  we talked about the Number object and it’s handy qualities, properties and methods. We talked about how the constructor worked: what gets when you use new Number(val).  We took a deep dive into the methods on the global Number. So we learned about using Number to check values to see if they’re compatible with numerical calculations. Number also exposes some of JavaScript’s number constants as properties, where different operating environments have proven difficult; where one environment may tolerate larger integers, Number.MAX_SAFE_INTEGER provides a standard way to check against a constant.

This time, we’re going to dive deep in to the instances of Number. We’re going to look at the method on Number.prototype. When we instantiate an instance of number by calling new Number(val), JavaScript is going to take the prototype on Number and attach it to our new number instance. We’re also going to discuss Number compatibility with native Math functions.

You can see all the methods on the Number Instance here.

We’re going to talk about the Number.prototype.toFixed and Number.prototype.toLocale. There’s other methods, but these two are likely why you’d create an instance in the first place.

Using Number.prototype.toFixed

This works the same way as the old toFixed, which lives on (lowercase) numbers.

Essentially, these two snippets do the same thing:

If we tried to implement a real program, you’d have a bunch of custom coded checking, formating and alternatives. With the Number type, we can easily implement a standardized way to check for values as we saw in the first part of this series.

To do this with a plain number, you’d either have more blocks or have to do some too-clever logical expressions. Either way, readability and maintainability goes down. Here, we have a number, we check it’s ability to be worked on with the object we’re going to instatiate from. It’s consistent, plain and (probably) fairly safe.

Number also allows you to fail gracefully without try/catch blocks.


If you work with an international audience, you can use Number to handle your localization and currency.

For instance, if you want a string formated for a known locale, you can do this.

In the case of number internationalization, you can also use the NumberFormat object as part of JavaScript’s Internationalization Object, Intl, if that’s appropriate.

This concept is foreign to many of us US based devs (pun intentional), but these skills are very valuable. Your ability to understand and work with localization (and accessibility) is a very marketable skill in some industries. Does everyone need to be a Localization Master? No, but I do recommend learning the basics of internationalization and localization.

Math and Numbers v. math and numbers v. JavaScript and Numbers

One of the points of confusion I’ve encountered while using Number over simple number values is the way the Number instance appears when you inspect it in developer tools. Consider the following:

This concern isn’t an issue outside of the console. When JavaScript expressions are evaluated or native JavaScript functions and methods are executed, the Number PrimitiveValue is automatically retrieved.




Written By StevenLacks