Background
When I started working with Salesforce way back in 2008, I had a natural
affinity for the Apex programming language, as I'd spent the previous decade
working with Object Oriented languages - first C++, then 8 years or so with
Java. Visualforce was also a very easy transition, as I had spent a lot of
time building custom front ends using Java technologies - servlets first
before moving on to JavaServer Pages (now
Jakarta Server Pages), which had a huge amount of overlap with the Visualforce custom tag
approach.
One area where I didn't have a huge amount of experience was JavaScript. Oddly
I had a few years experience with server side JavaScript due to maintaining
and extending the
OpenMarket TRANSACT
product, but that was mostly small tweaks added to existing functionality, and
nothing that required me to learn much about the language itself, such as it
was back then.
I occasionally used JavaScript in Visualforce to do things like
refreshing a record detail from an embedded Visualforce page,
Onload Handling
or
Dojo Charts. All of these had something in common though, they were snippets of
JavaScript that were rendered by Visualforce markup, including the data that
they operated on. There was no connection with the server, or any kind of
business logic worthy of the name - everything was figured out server
side.
Then came
JavaScript Remoting, which I used relatively infrequently for pure Visualforce, as I didn't
particularly like striping the business logic across the controller and the
front end, until the
Salesforce1 mobile app
came along. Using Visualforce, with it's server round trips and re-rendering
of large chunks of the page suddenly felt clunky compared to doing as much as
possible on the device, and I was seized with the zeal of the newly converted.
I'm pretty sure my JavaScript still looked like Apex code that had been
through some automatic translation process, as I was still getting to grips
with the JavaScript language, much of which was simply baffling to my server
side conditioned eyes.
It wasn't long before I was looking at
jQuery Mobile to
produce
Single Page Applications
where maintaining state is entirely the job of the front end, which quickly
led me to Knockout.js as I could use
bindings again, rather than having to manually update elements when data
changed. This period culminated my Dreamforce 2013 session on
Mobilizing your Visualforce Application with jQuery Mobile and
Knockout.js.
Then in 2015,
Lightning Components (now Aura Components)
came along, where suddenly JavaScript got real. Rather than rendering via
Visualforce or including from a static resource, my pages were assembled from
re-usable JavaScript components. While Aura didn't exactly encourage it's
developers down the modern JavaScript route, it's successor -
Lightning Web Components
- certainly did.
All this is rather a lengthy introduction to the purpose of this series of
blogs, which are intended to (try to) explain some of the differences and
challenges when moving to JavaScript from an Apex background. This isn't a JavaScript tutorial, it's more about what I wish I'd known when I started. It's also based on my
experience, which as you can see from above, was a somewhat
meandering path. Anyone
starting their journey should find it a lot more straightforward now, but
there's still plenty there to baffle!
Strong versus Weak (Loose) Typing
The first challenge I encountered with JavaScript was the difference in
typing.
Apex
Apex is a strongly typed language, where every variable is declared with the
type of data that it can store, and that cannot change during the life of the
variable.
Date dealDate;
In the line above, dealDate is
declared of type Date, and can only
store dates. Attempts to assign it
DateTime or
Boolean values explicitly will
cause compiler errors:
dealDate=true; // Illegal assignment from Boolean to Date
dealDate=System.now(); // Illegal assignment from DateTime to Date
while attempts to assign something that might be a
Date, but turns out not to be at
runtime will throw an exception:
Object candidate=System.now();
dealDate=(Date) candidate; // System.TypeException: Invalid conversion from runtime type Datetime to
Date
JavaScript
JavaScript is a weakly typed language, where values have types but variables
don't. You simply declare a variable using var or let, then assign
whatever you want to it, changing the type as you need to:
let dealDate;
dealDate=2; // dealDate is now a number
dealDate='Yesterday'; // dealDate is now a string
dealDate=Date(); // dealDate is now a date
The JavaScript interpreter assumes that you are happy with the value you have
assigned the variable and will use it appropriately. If you use it
inappropriately, this will sometimes be picked up at runtime and a TypeError
thrown. For example, attempting to run the
toUpperCase() string method on a
number primitive:
let val=1;
val.toUpperCase();
Uncaught TypeError: val.toUpperCase is not a function
However, as long as the way you are attempting to use the variable is legal,
inappropriate usage often just gives you an unexpected result. Take the
following, based on a simplified example of something I've done a number of
times - I have an array and I want to find the position of the value 3.
let numArray=[1,2,3,4];
numArray.indexOf[3];
which returns undefined, rather than the expected position of 2.
Did you spot the error? I used the square bracket notation instead of round
brackets to demarcate the parameter. So instead of executing the indexOf
function, JavaScript was quite happy to treat the function as an array and
return me the third element, which doesn't exist.
JavaScript also does a lot more automatic conversion of types,
making assumptions that might not be obvious. To use the
+ operator as an example, this can
mean concatenation for strings or addition for numbers, so there are a few
decisions to be made:
lhs + rhs
1. If either of lhs/rhs
is an object, it is converted to a primitive string, number or boolean
2. If either of lhs/rhs
is string primitive, the other is converted to a string (if necessary) and
they are concatenated
3. lhs and
rhs are converted to numbers (if
necessary) and they are added
Which sounds perfectly reasonable in theory, but can surprise you in practice:
1 + true
result: 2, true is converted to the number 1
5 + '4'
result '54', rhs is a string so 5 is converted to a string and
concatenated.
false + 2
result: 2, false is converted to the number 0
5 + 3 + '5'
result '85' - 5 + 3 adds the two numbers to give 8, which is then
converted to a string to concatenate with '5'
[1992, 2015, 2021] + 9
result '1992,2015,20219' - lhs is an object (array) which is
converted to a primitive using the toString method, giving the string
'1992,2015,2021', 9 is converted to the string '9' and the two strings are
concatenated
Which is Better?
Is this my first rodeo? We can't even agree on what strong and weak typing really mean, so deciding whether one is preferred over the other is an impossible task. In this case it doesn't matter, as Apex and JavaScript aren't going to change!
Strongly typed languages are generally considered safer, especially for
beginners, as more errors are trapped at compile time. There may also
be some performance benefits as you have made guarantees to the compiler that
it can use when applying optimisation, but this is getting harder to quantify
and in reality is unlikely to be a major performance factor in any code that
you write.
Weakly typed languages are typically more concise, and the ability to pass any type as a parameter to a function can be really useful when building things like loggers.
Personally I take the view that code is written for computers but read by humans, so anything that clarifies intent is good. If I don't have strong typing, I'll choose a naming convention that makes the type of my variables clear, and I'll avoid re-using variables to hold different types even if the language allows me to.
