This post will go over the Javascript language from the point of view of a Java developer, focusing on the differences between the two languages and the frequent pain points. We will go over the following:
\n
\n
\n
\n
\n
\n
\n
\n <\/p>\n
A lot of Java frontend development work is done using Java\/XML based frameworks like JSF or GWT. The framework developers themselves need to know Javascript, but in principle the application developers don’t. However the reality is that:<\/p>\n
The end result is that Javascript is usually needed to do at least the last 5 to 10% of frontend work, even using Java frameworks. Also it’s starting to get more and more used for polyglot enterprise development, alongside Angular<\/a> for example.<\/p>\n The good news is that, besides a few gotchas that we will get into, Javascript is a very learneable language for a Java developer.<\/p>\n One of the most surprising things about Javascript is that although it’s an object oriented language, there are no classes (although the new Ecmascript 6 version<\/a> will have them).<\/p>\n Take for example this program, that initializes an empty object and set’s two properties:<\/p>\n Javascript objects are just like a Java HashMap of related properties, where the keys are Strings only. The following would be the ‘equivalent’ Java code:<\/p>\n This means that a Javascript object is just a multi-level ‘hash map’ of key\/value pairs, with no class definition needed.<\/p>\n Functions in Javascript are just values of type This creates a function (a value of type Java does not<\/strong> have the equivalent of the Javascript This is how to pass So although a But if we pass functions around, what happens to the meaning of the What Javascript allows to do with This program creates an object By passing around Running this snippet would give as output: This is because the variable \nIn Javascript the value of the The snippet above would print again In Javascript, there is no class inheritance, instead objects can inherit directly from other objects. The way this works is that each object has an implicit property that points to a ‘parent’ object.<\/p>\n That property is called When looking up a property, Javascript will try to find the property in the object itself. If it does not find it then it tries in it’s prototype, and so on. For example:<\/p>\n This snippet will output As we can see, although the Let’s now say that the rights for the Avengers where bought by DC Comics:<\/p>\n If we call This mechanism is very simple and very powerful. Anything that can be done with class inheritance can be done with prototypal inheritance. But what about constructors?<\/p>\n In Javascript an attempt was made to make object creation similar to languages like Java. Let’s take for example:<\/p>\n Notice the capitalized name, indicating that it’s a constructor function. Let’s see how it can be used:<\/p>\n This code snippet outputs You might think that this looks just like Java, and that is exactly the point! What this Let’s say that we want to specify that all super heroes have a This would output But the syntax The recommended way to go is to ignore the Javascript Unlike the Javascript Closures are not that different from Java anonymous inner classes used in a certain way. take for example the We can can pass it a fly command like this in Java 8:<\/p>\n The output of this snippet is This notion of a function that remembers about variables outside it’s block scope for later use is called a Closure<\/strong> in Javascript. For further details, have a look at this blog post Really Understanding Javascript Closures<\/a>.<\/p>\n In Javascript a closure looks like this:<\/p>\n The Javascript closure, unlike the Java Lambda does not have the constraint that the This seemingly innocuous difference is actually a ‘killer’ feature of Javascript closures, because it allows them to be used for creating encapsulated modules.<\/p>\n There are no classes in Javascript and no Here a function When the The output of this snippet is The result is Understanding block scope in Javascript is simple: there is no block scope! Take a look at this example:<\/p>\n By looking at this coming from Java, you might expect:<\/p>\n It turns out that only one of these three things is true, and the output is actually this:<\/p>\n Because there is no block scope, the loop variable i is visible for the whole<\/strong> function. This means:<\/p>\n What might be the most puzzling is that line 3 actually sees the variable declared but undefined, instead of throwing This is because the Javascript interpreter first scans the function for a list of variables, and then goes back to interpret the function code lines one by one.<\/p>\n The end result is that it’s like the variable i was hoisted<\/strong> to the top, and this is what the Javascript runtime actually ‘sees’:<\/p>\n To prevent surprises caused by hoisting and lack of block scoping, it’s a recommended practice to declare variables always at the top of functions.<\/p>\n This makes hoisting explicit and visible by the developer, and helps to avoid bugs. The next version of Javascript (Ecmascript 6) will include a new keyword ‘let’ to allow block scoping<\/a>.<\/p>\n The Javascript language shares a lot of similarities with Java, but also some huge differences. Some of the differences like inheritance and constructor functions are important, but much less than one would expect for day to day programming.<\/p>\n Some of these features are needed mostly by library developers, and not necessarily for day to day application programming. This is unlike some of their Java counterparts which are needed every day.<\/p>\n So if you are hesitant to give it a try, don’t let some of these features prevent you from going further into the language.<\/p>\n One thing is for sure, at least some<\/em> Javascript is more or less inevitable when doing Java frontend development, so it’s really worth to give it a try.<\/p>\nObjects Only – No Classes<\/h2>\n
\/\/ create an empty object - no class was needed !!\r\nvar superhero = {};\r\n\r\nsuperhero.name = 'Superman'; \r\nsuperhero.strength = 100;<\/pre>\nMap<String,Object> superhero = new HashMap<>();\r\n\r\nsuperhero.put(\"name\",\"Superman\"); \r\nsuperhero.put(\"strength\", 100);<\/pre>\n
Functions Are Just Values<\/h3>\n
Function<\/code>, it’s a simple as that! Take for example:<\/p>\nvar flyFunction = function() { \r\n console.log('Flying like a bird!');\r\n};\r\n\r\nsuperhero.fly = flyFunction;<\/pre>\nFunction<\/code>) and assigns it to a variable flyFunction<\/code>. A new property named fly<\/code> is then created in the superhero object, that can be invoked like this:<\/p>\n\/\/ prints 'Flying like a bird!' to the console\r\nsuperhero.fly();<\/pre>\n
Function<\/code> type, but almost. Take for example the SuperHero<\/code> class that takes a Power<\/code> function:<\/p>\npublic interface Power { \r\n void use();\r\n}\r\n\r\npublic class SuperHero {\r\n\r\n private Power flyPower;\r\n\r\n public void setFly(Power flyPower) {\r\n this.flyPower = flyPower;\r\n }\r\n\r\n public void fly() {\r\n flyPower.use();\r\n }\r\n}<\/pre>\nSuperHero<\/code> a function in Java 7 and 8:<\/p>\n\/\/ Java 7 equivalent\r\nPower flyFunction = new Power() { \r\n @Override\r\n public void use() {\r\n System.out.println(\"Flying like a bird ...\");\r\n }\r\n};\r\n\r\n\/\/ Java 8 equivalent \r\nsuperman.setFly( \r\n ()->System.out.println(\"Flying like a bird ...\"));\r\n\r\nsuperman.fly();<\/pre>\nFunction<\/code> type does not exist in Java 8, this ends up not preventing a ‘Javascript-like’ functional programming style.<\/p>\nthis<\/code> keyword?<\/p>\nThe ‘this’ Keyword Usage<\/h2>\n
this<\/code> is quite surprising compared to the Java world. Let’s start with an example:<\/p>\nvar superman = {\r\n\r\n heroName: 'Superman', \r\n\r\n sayHello: function() {\r\n console.log(\"Hello, I'm \" + this.heroName );\r\n } \r\n};\r\n\r\nsuperman.sayHello();<\/pre>\nsuperman<\/code> with two properties: a String heroName<\/code> and a Function<\/code> named sayHello<\/code>. Running this program outputs as expected Hello, I'm Superman<\/code>.<\/p>\nWhat if we pass the function around?<\/h3>\n
sayHello<\/code>, we can easily end up in a context where there is no heroName<\/code> property:var failThis = superman.sayHello;\r\n\r\nfailThis();<\/pre>\n
Hello, I'm undefined<\/code>.<\/p>\nWhy does
this<\/code> not work anymore?<\/h3>\nhello<\/code> belongs to the global scope, which contains no member variable named heroName<\/code>. To solve this:<\/p>\n\n
this<\/code> keyword is completely overridable to be anything that we want!\n<\/p>\n<\/blockquote>\n\/\/ overrides 'this' with superman\r\nhello.call(superman);<\/pre>\n
Hello, I'm Superman<\/code>. This means that the value of this<\/code> depends on both the context on which the function is called, and on how<\/em> the function is called.<\/p>\nClassic vs Prototypal Inheritance<\/h2>\n
__proto__<\/code>, and the parent object is called the object’s prototype<\/strong>, hence the name Prototypal Inheritance.<\/p>\nHow does
prototype<\/code> work?<\/h3>\nvar avengersHero = { \r\n editor: 'Marvel'\r\n};\r\n\r\nvar ironMan = {};\r\n\r\nironMan.__proto__ = avengersHero;\r\n\r\nconsole.log('Iron Man is copyrighted by ' + ironMan.editor);<\/pre>\nIron Man is copyrighted by Marvel<\/code>.<\/p>\nironMan<\/code> object is empty, it’s prototype does contain the property editor<\/code>, which get’s found.<\/p>\nHow does this compare with Java inheritance?<\/h3>\n
avengersHero.editor = 'DC Comics';<\/pre>\n
ironMan.editor<\/code> again, we now get Iron Man is copyrighted by DC Comics<\/code>. All the existing object instances with the avengersHero<\/code> prototype now see DC Comics<\/code> without<\/em> having to be recreated.<\/p>\nConstructors vs Constructor Functions<\/h2>\n
function SuperHero(name, strength) { \r\n this.name = name;\r\n this.strength = strength;\r\n}<\/pre>\nvar superman = new SuperHero('Superman', 100);\r\n\r\nconsole.log('Hello, my name is ' + superman.name);<\/pre>\nHello, my name is Superman<\/code>.<\/p>\nnew<\/code> syntax really does is to it creates a new empty object, and then calls the constructor function by forcing this<\/code> to be the newly created object.<\/p>\nWhy is this syntax not recommended then?<\/h3>\n
sayHello<\/code> method. This could be done by putting the sayHello<\/code> function in a common prototype object:<\/p>\nfunction SuperHero(name, strength) { \r\n this.name = name;\r\n this.strength = strength;\r\n}\r\n\r\nSuperHero.prototype.sayHello = function() { \r\n console.log('Hello, my name is ' + this.name);\r\n}\r\n\r\nvar superman = new SuperHero('Superman', 100); \r\nsuperman.sayHello();<\/pre>\nHello, my name is Superman<\/code>.<\/p>\nSuperHero.prototype.sayHello<\/code> looks anything but Java like! The new<\/code> operator mechanism sort of half looks like Java but at the same time is completely different.<\/p>\nIs there a recommended alternative to
new<\/code>?<\/h3>\nnew<\/code> operator altogether and use Object.create<\/code>:<\/p>\nvar superHeroPrototype = { \r\n sayHello: function() {\r\n console.log('Hello, my name is ' + this.name);\r\n } \r\n};\r\n\r\nvar superman = Object.create(superHeroPrototype); \r\nsuperman.name = 'Superman';<\/pre>\nnew<\/code> operator, one thing that Javascript absolutely got right where Closures.<\/p>\nClosures vs Lambdas<\/h2>\n
FlyingHero<\/code> class:<\/p>\npublic interface FlyCommand { \r\n public void fly();\r\n}\r\n\r\npublic class FlyingHero {\r\n\r\n private String name;\r\n\r\n public FlyingHero(String name) {\r\n this.name = name;\r\n }\r\n\r\n public void fly(FlyCommand flyCommand) {\r\n flyCommand.fly();\r\n }\r\n}<\/pre>\nString destination = \"Mars\"; \r\nsuperMan.fly(() -> System.out.println(\"Flying to \" + \r\n destination ));<\/pre>\n
Flying to Mars<\/code>. Notice that the FlyCommand<\/code> lambda had to ‘remember’ the variable destination<\/code>, because it needs it for executing the fly<\/code> method later.<\/p>\nWhat is the main difference between Lambdas and Closures?<\/h3>\n
var destination = 'Mars';\r\n\r\nvar fly = function() { \r\n console.log('Fly to ' + destination);\r\n}\r\n\r\nfly();<\/pre>\ndestination<\/code> variable must be immutable (or effectively immutable since Java 8).<\/p>\nModules and Encapsulation<\/h2>\n
public<\/code>\/ private<\/code> modifiers, but then again take a look at this:<\/p>\nfunction createHero(heroName) {\r\n\r\n var name = heroName;\r\n\r\n return {\r\n fly: function(destination) {\r\n console.log(name + ' flying to ' + destination);\r\n }\r\n }; \r\n}<\/pre>\ncreateHero<\/code> is being defined, which returns an object which has a function fly<\/code>. The fly<\/code> function ‘remembers’ name<\/code> when needed.<\/p>\nHow do Closures relate to Encapsulation?<\/h3>\n
createHero<\/code> function returns, noone else will ever be able to directly access name<\/code>, except via fly<\/code>. Let’s try this out:<\/p>\nvar superman = createHero('SuperMan');\r\n\r\nsuperman.fly('The Moon');<\/pre>\nSuperMan flying to The Moon<\/code>. But happens if we try to access name<\/code> directly ?<\/p>\nconsole.log('Hero name = ' + superman.name);<\/pre>\nHero name = undefined<\/code>. The function createHero<\/code> is said to a be a Javascript encapsulated module<\/strong>, with closed ‘private’ member variables and a ‘public’ interface returned as an object with functions.<\/p>\nBlock Scope and Hoisting<\/h2>\n
function counterLoop() {\r\n\r\n console.log('counter before declaration = ' + i); \r\n\r\n for (var i = 0; i < 3 ; i++) {\r\n console.log('counter = ' + i); \r\n }\r\n\r\n console.log('counter after loop = ' + i); \r\n}\r\n\r\ncounterLoop();<\/pre>\n\n
counter before declaration = undefined \r\ncounter = 0 \r\ncounter = 1 \r\ncounter = 2 \r\ncounter after loop = 3<\/pre>\n
\n
i is not defined<\/code>.<\/p>\nfunction counterLoop() {\r\n\r\n var i; \/\/ i is 'seen' as if declared here! \r\n\r\n console.log('counter before declaration = ' + i); \r\n\r\n for (i = 0; i < 3 ; i++) {\r\n console.log('counter = ' + i); \r\n }\r\n\r\n console.log('counter after loop: ' + i); \r\n}<\/pre>\nConclusion<\/h2>\n