IEEE Consumer Electronics Magazine - November/December 2020 - 85

One nice thing about the heritage of Lisp is
the orthogonality-the rich set of mechanisms
are built on a simple base. While there is an
emphasis on performance on high-end browsers,
it also allows for compact implementations
where appropriate.

HOW AND WHY JAVASCRIPT

In 2014, I wrote about the growing importance of HTML5.Ã Writing applets in Java was
problematic because the apps had full access to
the host computing environment. Confining
JavaScript to the browser meant the code was
portable and sandboxed.
That also meant that the code would be
sloppy, at least at first, because the damage was
limited to an errant web page. The applications
ran outside the security perimeter since the
servers could trust any code on the client side
(AKA, in the browser).
Google has a huge financial interest in
browser performance since a few tenths of a second in browser response time could translate
into billions of dollars in revenue. Thus, the
great incentive to improve the performance of
JavaScript and it worked far better than I
expected. I had been using JavaScript for simple
projectsþ when my friend Dan Bricklin commented that JavaScript had become a high-performance language with Google's V8 engine
playing a key role.
One of the techniques used is JIT or Just-inTime compilation. As computer performance
increased, the percentage of time spent translating machine code relative to the total execution
time become very small thus eliminating the
need for precompilation. This meant that the JIT
compiler could take advantage of the on-theground knowledge such as exactly which processor was being used and what special feature it
may have.
Part of this was using the knowledge of the
types of the parameters. Thus, if a piece of code
is being called with an integer parameter that
method could be compiled for just that case.
The compiled code would do a quick check for
the parameters to make sure that, at runtime,

indeed, the parameters were integers. For a simple operation like addition that might be high
overhead but such checking gets pushed back
into the containing method and a whole set of
operations can be made safe and efficient
because the type checking could cover a variety
of methods.
All this while preserving the ability to edge
cases on the fly rather than having to check for
them every time thus allowing more streamlining
that precompiled code.
Another technique is memoization that can
short circuit the entire computation by recognizing that the parameters are the same as a previous invocation and that the code has no sideeffects.
These techniques work well when the code is
regular but that is a very reasonable assumption
akin to the locality assumption that allows both
modern operating systems and machine learning
to work so well. Oddball cases can cause performance problems but are not fatal.
Declaring types in programming languages is
not merely about performance, it is also about
safety. Having strong typing means that bugs are
discovered at compilation time rather than lurking until the program runs. It turns out that using
types for safety and types for runtime performance would be decoupled. I see Microsoft's
TypeScriptz as a way to have a conversation
with the IDE-Integrated Development Environment rather than as a necessity for compilation.
The IDE can help me identify problems and,
just as important, refactor code, by following the
implications of my declarations. If I try to add 12
to a string "12" raw JavaScript would simply convert the number to a string and give me the
result "1212" which may or may not be what I
want. If I use TypeScript the IDE would flag it
thus forcing me to be explicit about what I want.
Or not-I could just tell it to ignore the type
information by using the "any" type. I get a
chance to decide what is appropriate for the
code I am writing.
TypeScript is an important part of scaling
code. I rely on its assistant to manage my own
code since I need a housekeeper. It is more important for large teams of programmers. This is why

https://rmf.vc/IEEEHtml5
https://rmf.vc/IEEEBlinky

November/December 2020

https://en.wikipedia.org/wiki/TypeScript

https://www.rmf.vc/IEEEHtml5 https://www.rmf.vc/IEEEBlinky https://en.wikipedia.org/wiki/TypeScript

IEEE Consumer Electronics Magazine - November/December 2020

Table of Contents for the Digital Edition of IEEE Consumer Electronics Magazine - November/December 2020