Encapsulation / Data Hiding in Javascript?

I guess that's cause person is visible, so it exposes all of its properties.

not exactly. First of all, person is a regular function. it can perfectrly be called without the new-keyword, but the results will blow up your whole application.

To understand why, you should first understand what the new-keyword does behind the scenes. This would be an js-implementation:

function fakeNew(constructor, ...args){
    if(typeof constructor !== "function"){
        throw new TypeError(constructor + " is not a constructor");
    }

    //create a new Instance of the constructors prototype-property
    var instance = Object.create(constructor.prototype);

    //invoke the constructor with the scope set to the instance and the provided arguments
    var result = constructor.apply(instance, args);

    //check wether the returned value is an Object (and functions are considered as Objects)
    if(result === Object(result)){
        //then return the result-value in favor to the instance
        return result;
    }

    //otherwise return the instance
    return instance;
}

On the other hand, any function can also be a constructor; no special needs, it's all up to you.

So back to jack

var jack = person("Jack", 30);  //would result in the following desaster:
console.log(jack);      //undefined, since person doesn't return anthing

console.log(jack.getName());    
//will throw, since jack is still undefined, and therefore doesn't have any properties

//BUT:
console.log(window.getName())   //will return "Jack" now

console.log(window.getAge);     //undefined, but this is fine 
//global scope has not been polluted with this one, cause getAge was a local variable inside the function-call

console.log(window.giveAge())   //can still call the enclosed (private) function getAge()

then

var jill = person("Jill", 28);
//will overwrite the global functions and expose new values now
console.log(window.getName(), window.giveAge()) //"Jill", 28    
//and Jack is kind of gone, well the variable is left but the variable contained undefined, so...

next thing is scoping. let's assume you made this correct

//first let's add a function that executes on the scope
//inside the constructor
this.getNameAndAge = function(){
    return this.getName() + ": " + getAge();
}

.

var andy = new person("Andy", 45);
var joe = new person("Joe", 32);

//let's make Andy a little younger
andy.getNameAndAge = joe.getNameAndAge;
console.log(andy.getNameAndAge(), andy.getName() + ": " + andy.giveAge());
//will result in "Andy: 32", "Andy": 45

waaaaat?

well you've overridden the public method getNameAndAge.
the name is accessed by invoking the (also public) method getName() on the current Object.
but giveAge() still the enclosed variable from the scope where this specific "instance of the getNameAndAge-function" was declared, and therefore it's from Joe's function call.

To understand the impacts of this, let's make the scoping even more weird

funciton Animal(species, _name){
    //species is likewise a local variable and can be enclosed, modified, or whatever
    //we don't need to write it to some different variable

    //but we want to expose the name of this animal, since it should be possible to change it later
    //without the need to create a getter and a setter just to change the property of _name
    this.name = _name;

    this.whoAreYou = function(){
        //so we concat the enclosed value from species with the name-argument on this object
        //in the hope that everything will be alright.
        return species + " " + this.name;
    }
}

var jack = new Animal("dog", "Jack");
var jill = new Animal("cat", "Jill");
var joe = new Animal("fish", "Joe");

console.log(jack.whoAreYou());  //"dog Jack"
console.log(jill.whoAreYou());  //"cat Jill"
console.log(joe.whoAreYou());   //"fish Joe"

//as far so good; till now ...
//since these properties are still writable someone will start and move them around

//maybe like a callback
function someFunction(someArg, callback){
    console.log(someArg, callback());
}
someFunction("Who are you?", jack.whoAreYou);

//or sth. like this:
//you may not believe that someone would ever do that, but it will happen!
jack.whoAreYou = jill.whoAreYou;
console.log(jack.whoAreYou());

//and now the poor dog has an Identity-crisis.
//the first one will result in:
"Who are you?", "dog undefined"

//the latter will log "cat Jack"

or even more fummy if sth. like this happens:

var fn = joe.whoAreYou;
console.log(fn.call(jack), fn.call(jill), fn.call(joe), fn.call(Animal));
//cause now they are all fishes, even the Animal-constuctor

I don't want to say that this is bad, or that you should avoid it but there is the way that it works, and that should be considered.

cause this way provides us with prototypal inheritance, and a great way to write mixins, without writing wrapper-methods all the time.

You can look at that as "i need to secure my private state", or "I work in whatever enviorment you provide to me"

And one more question, why does console.log(jack.getAge()); throws an error?

because jack.getAge is undefined and undefined is no function

var getAge = function() {
    return age;
}

another comment to this line

in JS function- and variable-declarations are hoisted and therefore available from the beginning of the function. Expressions are not.

var person = function(){
    //...
    foo();
    bar();
    baz();

    function foo(){ console.log("this will work"); }
    var bar = function(){ console.log("this will fail"); }
    //because to this point, bar was delared and assigned with undefined, 
    //and we remember? undefined can't be invoked

    return whatever;

    function baz(){ console.log("event this would work"); }
    //unless some preprocessor decided (falsely), that this function can be removed 
    //since it is after the return-statement, and is therefore unreachable
}