Javascript let keyword

ECMAScript 6 (ES2015) added the ‘let’ keyword. let works a lot like the legacy ‘var’ keyword, but adds scoping capabilities.

Unfortunately, support cannot be retrofitted to older browsers with a polyfill, supported by IE11(with limitations), Edge 12+, Firefox 44+, Chrome 49+, Safari 10+. If you still need to support older browsers or devices you may want to stick with var.

REFERENCES:

Javascript const

Formally introduced in ES6, const was introduced in JavaScript 1.5 and was a Mozilla-specific extension and not part of ECMAScript 5.

Unfortunately, support cannot be retrofitted to older browsers with a polyfill, supported by IE11+, Edge 12+, Firefox 36+, Chrome 21+, Safari 5.1+. If you still need to support older browsers or devices you may want to stick with var.

NOTE: some initial implementations may have thrown different exceptions on reassignment, were not limited in scope, or treated const like ‘var‘.

Name may start with letter, underscore or $ character.

REFERENCES:

RetireJS for Eclipse extension

Several years ago I wrote an Eclipse plugin to help me identify vulnerable javascript libraries using RetireJS. On a whim, I finally got around to submitting it to the Eclipse marketplace last week and it was approved.

This addresses a common OWASP Top-Ten item – A9:2017-Using Components with Known Vulnerabilities.

For Non-Developers… in English, while software developers are creating websites they often use open-source libraries such as jQuery (or literally thousands of other libraries) to simplify their development. Eventually, almost all software is identified as being vulnerable to various attacks. This tool makes it easier to scan and report on libraries that might be used in an application so that they can be updated or replaced.

REFERENCES:

Minify .js files during Maven builds

Minifying files for use on the web is essential to improving performance, to reduce network overhead as well as a slight bump in execution speed.

Long ago I used the YUICompressor plugin for both JS as well as CSS files, unfortunately that project appears to have been abandoned many years ago and no longer functions well for JS files that make use of modern features.

For JS files, I’ve found that most capabilities can be replicated with the following in the pom.xml:

<plugin>
<groupId>com.github.blutorange</groupId>
<artifactId>closure-compiler-maven-plugin</artifactId>
<version>2.21.0</version>
<executions>
<execution>
<id>default-minify-js</id>
<phase>generate-resources</phase>
<configuration>
<!-- not supported (always uses .min) <suffix>-min</suffix> -->
<encoding>UTF-8</encoding>
<baseSourceDir>${basedir}/${webapp-folder}</baseSourceDir>
<baseTargetDir>${webapp.path}/</baseTargetDir>
<sourceDir>js</sourceDir>
<targetDir>js</targetDir>
<skipMerge>true</skipMerge>
<includes>
<include>**/*.js</include>
</includes>
<excludes>
<exclude>**/webjars-requirejs.js</exclude>
<exclude>**/bootstrap*.*</exclude>
<exclude>**/jasmine*.*</exclude>
<exclude>**/*-min.js</exclude>
<exclude>**/*.min.js</exclude>
</excludes>
</configuration>
<goals>
<goal>minify</goal>
</goals>
</execution>
</executions>
</plugin>

NOTE: the only feature I have not yet been able to match is the suffix, as it appears to always use *.min.js (where I used to prefer *-min.js).

An additional advantage of using the plugin is that many common syntax errors will be identified at build time, before they cause user problems… but they will also break your build!

REFERENCES:

Using comments to ‘hide’ SCRIPT tag content – please stop this obsolete practice

Many years ago, when HTML3 and 4 were still widely used in the mid to late 1990s, it was a common practice to place HTML style comments, or in some cases CDATA comments inside the SCRIPT tag in an attempt to hide that content from browsers that could not process it. In those browsers the content (javascript source code) would sometimes be displayed on the page, making it quite a mess.

This practice is now obsolete, and often problematic as there are very few of those browsers in use today – primarily only for testing of legacy functionality.

Example of old approach

<script type="text/javascript">
<--
// some script
-->
</script>

NOTE: for XHTML or XML documents, the use of a CDATA style comment is still required.
<script type=”text/javascript”>
//<![CDATA[
…code…
//]]>
</script>

REFERENCES:

document.write() Intervention!

The use of document.write() has always been a bad “code smell” in JavaScript. Most web performance guides such as WebPageTest and Yahoo Exception Performance have warned against this practice.

In most cases, document.write() can be replaced by inserting innerHTML into an empty element after the rest of the page loads. This approach also allows the developer to “think” about how the page might react in cases where JavaScript is disabled or not available on the client.

Google has recently changed the default behavior, such that when on a slow (currently 2G) connection, but discussions have also leaned toward including any slow connection.
As such, right now, the following will occur on slow (2G) connections:

  • Chrome 53+ (warning displayed in debugger console)
  • Chrome 55+ (blocked – code will not execute, warning message will appear in debugger console)

For users on slow connections, such as 2G, external scripts dynamically injected via document.write() can delay the display of main page content for tens of seconds, or cause pages to either fail to load or take so long that the user just gives up. Based on instrumentation in Chrome, we’ve learned that pages featuring third-party scripts inserted via document.write() are typically twice as slow to load than other pages on 2G.


My advice – remove all use of document.write() for required content in your code now, as your users MAY NOT see that content if you do not.

REFERENCES:

Stanford Javascript Crypto Library (SJCL) JavaScript encryption

I found this while looking for a means to do some simple encryption in Javascript for a browser based application. With open-source support for AES and other protocols, it is quite robust and fast.

As a bonus, it is packaged as a webjar and available in Maven Central:

<dependency>
<groupId>org.webjars.npm</groupId>
<artifactId>sjcl</artifactId>
<version>1.0.6</version>
</dependency>

REFERENCES:

SonarLint for Eclipse IDE

I’ve always been fan of tools for automation of development and testing. I’ve used SonarQube for a long time, and even connect it to my IDE (usually Eclipse), so that I can act on any warnings for code as I’m working on it.

SonarLint takes that to a new level, as it gives notifications before the code is even commited for SonarQube to analyze.

While the instructions here are for Eclipse, SonarLint is also available for IntelliJ IDEA, VisualStudio, and as a command line tool for download from the website.

Eclipse Update Site:
https://www.sonarlint.org/eclipse/

REFERENCES:

Redirect within a javascript file

There often comes a time when you are working on a large project and find a need to refactor javascript resources. Unfortunately, if those assets are accessed by 3rd parties or other code you cannot easily update, you might find yourself stuck.

If you have access to the Tier1 (HTTP server such as ApacheHTTPd) you can often do this within the httpd.conf, or an .htaccess file update. If not, you can always do a simple function within the old javascript file itself, such as the one below.

Put this in the old javascript file location, it is in a closure to prevent the variables from “leaking” into the global namespace.


/* MOVED */
(function(){
"use strict";
var u='/js/newfile.js';
var t=document.createElement('script');t.type='text/javascript';t.src=u;
var s=document.getElementsByTagName('script')[0];s.parentNode.insertBefore(t,s);
})();

Brotli Compression

If you look at HTTP Headers as often as I do, you’ve likely noticed something different in Firefox 44 and Chrome 49. In addition to the usual ‘gzip’, ‘deflate’ and ‘sdhc’ , a new value ‘br’ has started to appear for HTTPS connections.

Request:

Accept-Encoding:br

Response:

Content-Encoding:br

Compared to gzip, Brotli claims to have significantly better (26% smaller) compression density woth comparable decompression speed.

The smaller compressed size allows for better space utilization and faster page loads. We hope that this format will be supported by major browsers in the near future, as the smaller compressed size would give additional benefits to mobile users, such as lower data transfer fees and reduced battery use.

Advantages:

  • Brotli outperforms gzip for typical web assets (e.g. css, html, js) by 17–25 %.
  • Brotli -11 density compared to gzip -9:
  • html (multi-language corpus): 25 % savings
  • js (alexa top 10k): 17 % savings
  • minified js (alexa top 10k): 17 % savings
  • css (alexa top 10k): 20 % savings


NOTE: Brotli is not currently supported Apache HTTPd server (as of 2016feb10), but will likely be added in an upcoming release.

http://mail-archives.apache.org/mod_mbox/httpd-users/201601.mbox/%[email protected]%3E

Until there is native support, you can pre-compress files by following instructions here…
https://lyncd.com/2015/11/brotli-support-apache/

REFERENCES: