This article tells you what you need to know when starting out learning JavaScript when you have a background in ABAP. Think of it as "JavaScript 101 for ABAPers". The aim is to give you a good appreciation of the differences so that you can start off in the right way. To quote Douglas Crockford, one of the best known exponents of JavaScript:
"JavaScript is a language with enormous power... it is even better if you know what you're doing"
There is lots of JavaScript documentation out there, but none that I could find focusing on those learning with an ABAP background. I've been working with ABAP in one way or another for nearly 20 years and I started looking seriously at JavaScript a couple of years ago, having previously thought of it as just a "toy" language. Here are my top 10 things you need to know when moving from ABAP to JavaScript. Let me know what I should add!
You may well ask "but why learn JavaScript?". I see a couple of reasons for taking JavaScript seriously.
Firstly, JavaScript is an important skill to master if you're interested in native HANA development using XS JavaScript (HANA server side JavaScript) or frontend SAPUI5 development. Even the new SAP River technology can generate JavaScript on compilation, so that is what you could be debugging some of the time.
Secondly, and this is a more long term reason, it is everywhere. Pretty much every smartphone, tablet, laptop and desktop in the world today, regardless of the operating system, has a JavaScript interpreter inside it, preinstalled. JavaScript has moved away from being just something to fiddle with web page content to being a serious language running server-side frameworks like node.js. The clincher for me came when Microsoft gave JavaScript/HTML5 apps equal rights in their Windows 8 app store, on a par with C++/DirectX programs. I think the ubiquitous nature of the language means we will see it popping up more and more in new technologies.
JavaScript is not without its faults. Douglas Crockford again (and we'll be hearing more from Crockford in this article, he speaks a lot of sense):
"JavaScripts's popularity is almost completely independent of its qualities as a programming language"
The language has been vilified over the years, partly because of it's association with the difficulties of web page development using the DOM and the long history of browser (in-)compatibility issues. However, bear in mind that all languages suck, apart from ABAP :smile: which is not listed here: https://wiki.theory.org/YourLanguageSucks
Note that Java and JavaScript have virtually nothing in common. JavaScript has Java-like syntax, but otherwise the languages share nothing and are very different. The name JavaScript was chosen for marketing reasons to try to capitalise on the success of Java. They ended up with a name that thoroughly confuses where the ending "Script" makes it sound like a lightweight scripting tool.
JavaScript has lots of concepts that will be familiar to ABAPers, and the syntax is easy if you know other "curly braces" languages like C# and Java. There are variables, functions, objects and methods.
So on the surface lots is familiar, but underneath there are major differences, so don't be misled. ABAP has constructs like internal tables to make coding business processes easier, whilst without any supporting frameworks JavaScript is pretty bare. ABAP has its roots in Cobol, whilst JavaScript, only 10 years younger than ABAP, has its roots in Scheme and Self. ABAP gets compiled before code execution, whilst JavaScript is generally an interpreted language.
A good point made by Katen Patel in the comments to this blog, is that when you are coding in ABAP your target platform is pretty much always going to be the same. You can be pretty sure techniques you use on one project will work on another. The same is not true of JavaScript. Although JavaScript has had a very stable life as technologies go (maybe 3 major releases) you may well have to deal with platform specific differences. If you code in XS JavaScript then you can use the bang-up-to-date version called "ECMA 6 Strict mode". If you are coding for a browser frontend then you need to think what JavaScript version is supported by the target browser. Frontend libraries like jQuery and SAPUI5 (which is based on jQuery) do a great job of abstracting away browser-specific differences, but there may well be some niggles leftover.
Some of the differences are only apparent when you're down in the detail. JavaScript is a world where there are no integers, a world where you can use variables before you declare them, in fact you dont need to declare them at all. It is a world where you can pass any number of parameters of any type to any function regardless of the function signature, and the program still runs! This "softness" takes some getting used to. The very biggest differences, though, are the way JavaScript deals with functions and the way it deals with object-oriented concepts. More on these later.
JavaScript and ABAP are typed differently, and I dont mean how you press the keys on the keyboard :wink: . ABAP is strongly typed, and because it is so tightly integrated with the database layer we are encouraged to make use of data dictionary types. This is good because the ABAP compiler can catch a lot of errors for us before execution. Strong typing means we cannot accidentally do things like try to "SELECT... INTO TABLE..." and then don't give an internal table as the target, you get a hard error at activation time.
JavaScript is loosely typed. Now, loosely typed does not mean untyped because internally the JavaScript interpreter does know what types are around. There are a bunch of predefined data types containing the usual suspects: booleans, numbers, strings, dates, plus arrays and objects. Notable by their absence are char, integer, float and decimal. Only numbers exist in JavaScript and they are always held internally as 64-bit floats.
JavaScript also supports dynamic typing, you can store all different types in the same variable at different times. So let's look at our first bit of sample code. The // are comments that explain each line:
var x; // declare variable x, without a type or value
var x = 5; // x is the number 5 (internally only 64-bit floats exist)
x = "sap"; // x is now the string "sap". You can use " or ' for strings
x = [1,2,3]; // x is now an array of 3 numbers
x = 5; // x is back to being a number again
So you only need to learn the statement "var" to define all your data! The other important thing about variables is their scope. In ABAP, variables have scope within their form, method or function module that they are defined in. All nice and tidy. In JavaScript, if you declare a variable outside a function (more on functions soon) it is global. If you forget to declare a variable, it gets automatically created for you as a global.
JavaScript doesn't have a direct equivalent of the ABAP "write" statement to print to the screen. How you output results depends on the environment you are in. Here are some options:
alert("ABAP"); // displays a popup if you are executing in a browser
console.log("ABAP"); // writes to Chrome's developer tools console
$.trace.info("ABAP"); // writes to HANA trace file, if you are executing XSJS
document.write("<p>ABAP</p>"); // writes HTML to the page you are executing in
ABAP had OO added on back in the late 1990s, and it uses a classical approach where you define classes, then create objects as an instance of a class. A class can inherit functionality from another class. JavaScript is very different. It uses a class-free OO model and inheritance is done using what is called prototypal inheritance. JavaScript is very lightweight when you deal with classes, and I kind of like it. There is not the overhead of defining classes.
Let's look at some code. This is how easy it is to define an object:
var x = { name : "abap", value = 4 }; // creates object with 2 properties, a string "abap" and a number 4
x.name = "javascript"; // the name property is now javascript
x.status = "active"; // status property gets added if not already there
Those curly braces {} being used to define the object is called JavaScript Object Notation (JSON). The very handy thing is that very often web services (e.g. the google maps geodata service or services that return oData) can return JSON directly. This makes it trivial to build an object from the web service result, you just create the object directly from the JSON. All properties of an object are public, which sounds a bit shocking, but there are techniques to encapsulate that are outside the scope of this article.
The inheritance model is quite simple in principle. Every object has a "hidden pointer" to a prototype object that is it's parent. You link a child object to it's parent by setting the "prototype" property which every object has. Hence you get this setup of "prototypal inheritance". Code samples for this are outside the scope of this article, they start to get quite involved and you need to learn a lot more stuff first, such as functions.
In JavaScript, functions are treated as "first class". Wikipedia describes this well, saying that if a language supports first class functions, then:
the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures
Let's see some code, first here is how to define a function:
function fun(a) {
a = a * a;
return a;
}
var x = fun(4); // x is 16
A function can also be defined inside another function.
function fun(a) {
var temp = 100;
function innerFun(b) {
alert(a + b + temp);
}
innerFun(1);
}
// this next line will display an alert popup saying 105
// which is a + b + temp = 4 + 1 + 100
fun(4);
A function can return a function. This is a bit like dealing with ABAP <field-symbols>. In the same way that ABAP field-symbols are pointers to data, we can have pointers to functions in JavaScript. We can have our function return a pointer to its inner function like this.
function fun(a) {
var temp = 100;
return function innerFun(b) {
alert(a + b + temp);
}
}
// this next line sets x to be a pointer to the function called "innerFun".
// notice we don't actually execute the "innerFun" this time, we just return
// "innerFun", so this next line gives us no alert
var x = fun(4);
Why do we go to all the trouble to get a pointer to an inner function? Why is this useful? We will find out when we look at closures.
JavaScript closures are a very common and powerful technique for encapsulation, and you will eventually need to learn how to use them. It is not something that is very easy to "get" and reading formal definitions of it I found to be not really helpful. To try to put it simply: a closure is when functions defined inside other functions "keep alive" any local data they need, even after the outer function has completed. I think the very simplest code example gives you a better idea of how they work. We've actually already coded a closure, we just didn't know it. Let's look at the code again:
function fun(a) {
var temp = 100;
return function innerFun(b) {
alert(a + b + temp);
}
}
var x = fun(4); // x is now a pointer to the inner function "innerFun", it is a closure
Now, what do you think this next line will do?
x(1);
We know x points to the function "innerFun", so it is like us calling innerFun(1). But when you look at the source code for innerFun() it needs to know what the variables defined outside it are, it needs to know what "a" and "temp" are. So perhaps it will generate an error? Not so! We get a popup saying 105 again, how did that happen? The answer is that the "innerFun" function keeps alive the local data it needs, so it remembers that "a" was 4 and "temp" was 100.
Another way to think about this is by comparing with the ABAP OO model. In a classical OO model like ABAP uses, you have data (local data inside the object) with some behaviour (methods) attached. So you can think of this as data that carries around the behaviour it needs. With closures what is happening is that the behaviour (a JavaScript function) keeps alive the data it needs outside that function. So it is like the behaviour is carrying around the data it needs.
ABAP of course has lots of checks done at design time, so when you compile you get to see and deal with lots of errors. You can also run the Code Inspector, or the extended syntax check to find other potential issues. JavaScript is much more "relaxed" and doesn't like to trouble you with these sorts of things.
Functions can be called with any number of parameters of any type. If you forget to declare a variable it automatically gets generated for you as a global. You can happily call methods that do not exist, and no error is thrown at design time or runtime, you just get back a value "undefined". JavaScript also does type conversion itself, to try to be helpful:
var x = 1000 / "sap"; // = NaN (meaning Not a Number)
var x = 1000 / "100"; // = 10
In many other languages the above would throw errors.
In ABAP, coding style is important from a maintainability perspective, but being a strongly typed language a lot of checks are done for you. In JavaScript, coding conventions become very important, because as Crockford says:
"because the language is so soft... it is really easy for a program to collapse into a puddle of confusion"
Once you are more familiar with the language you can review more comprehensive code conventions but here are some highlights to get you started:
a) Use open brackets at the end of the line
So you should use the K&R style brackets {} like this:
return {
name : "abap"
}
The above returns an object (remember the curly braces are JSON) with a name property = ABAP. If you put in a new line before the braces, like this:
return
{
name : "abap"
}
Then the interpreter can do something called "semi-colon insertion" to try to be helpful, and the result is the code executed is:
return;
without any object.
b) Take care with equality operators
The JavaScript == equality operator might be familiar to you from other languages, but in JavaScript this operator does type coercion before the comparison. So you get some weird things going on:
0 == '' // true --> number 0 equals empty string
0 == '0' // true --> number 0 equals string 0
'' == '0' // false --> empty string does not equal string 0
JavaScript also has a === equality operator, that does not do type coercion. The above all give a result of false if you use === and that is much more what you'd expect.
ABAP of course has an excellent standardised IDE with tools for tracing, performance, debugging, quality checking, and is tightly integrated into the change and transport systems. We are spoiled, really! In contrast, JavaScript has no standard IDE that "everyone uses" like Visual Studio for Windows development or Xcode for iOS. There is a huge variety of JavaScript tools out there, and what you choose will depend on what you are doing. For learning and offline development I use Brackets (a lightweight JavaScript editor) and Google's Chrome browser (which has an excellent debugger, watchpoints, breakpoints, performance tracing and lots more). I understand Firebug is good too, and I am sure there are other good tools I've not seen yet.
If you are developing XS JavaScript for HANA native development, then you will need to use Eclipse, however I found the whole save/active/test cycle quite slow, and you need to be online. I still try to develop tricky stuff in Brackets/Chrome before placing it up on the XS server. There is a program called JSLint that acts like ABAP's code inspector and highlights potential areas of concern, you will find JSLint embedded in most JavaScript tools.
Now for some good news. Core JavaScript (so ignoring any libraries like jQuery) is actually a very small language, particularly when compared with ABAP which has many more keywords to learn. Furthermore, although there many 100s of JavaScript books out there, you only need two of them:
JavaScript: The Definitive Guide by David Flanagan - a weighty 1200 pages.
JavaScript: The Good Parts by Douglas Crockford - a slender volume of 120 pages.
To quote Crockford again:
"if you want to learn about the bad parts of JavaScript, and how to use them badly, consult any other JavaScipt book"
Some other learning resources worth a look:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
6 | |
5 | |
4 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 |