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.
Formally introduced in ES6,
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
NOTE: some initial implementations may have thrown different exceptions on reassignment, were not limited in scope, or treated
const like ‘
Name may start with letter, underscore or $ character.
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.
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:
<!-- not supported (always uses .min) <suffix>-min</suffix> -->
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!
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
// some script
NOTE: for XHTML or XML documents, the use of a CDATA style comment is still required.
The use of
In most cases,
document.write() can be replaced by inserting
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.
As a bonus, it is packaged as a webjar and available in Maven Central:
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:
/* MOVED */
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.
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.
- 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.
Until there is native support, you can pre-compress files by following instructions here…