I've been dimly aware of the coming of "ES6", which I took to mean an updated kind of meta-javascript.

Down here at the coalface (perhaps a more apt metaphor is me walking along the railroad, picking up coal that fell off)...

I'm having a look at the shiny new[-ish, but already deprecated] "sw-toolbox", a *lieberry* that handles Googlian "service worker" cache API calls which are the replacement for never-really-quite-worked "application cache". The sw-toolbox API is in ES6. Yeah, it has those pointy (=>) things.

I can copy-and-paste with the best of them and that sort of works for a prototype build, but ES6 has piqued my curiosity. WTF is it, really?

My first line of inquiry: https://www.lewagon.com/blog/from-jquery-to-dom-and-es6

The premise is quite interesting: to paraphrase, ES6 is better, faster, stronger because it don't need no steenking lieberries (oh wait...).

Assuming this is valid in use-cases not involving service worker cache API calls, for which there are, indeed lieberries (and TFFT), and in the specific use-case of  jquery-replacement, the first thing that strikes me is that, in this article's given examples, ES6 requires more custom code by character count. E.g.:

var lead = $('#lead')

const lead = document.getElementById('lead')

This holds true for all given examples in the article, of which there are admittedly not very many, addressing the simplest functions.

Without the jquery upfront hit, well, yes that means less download and processing for vanilla ES6. Two things:

1. For virtually all, extant modern device hardware capabilities, the jquery 'hit' is trivial, and

2. If you using a *lot* of custom code, that apparent ES6 code bloat (vs. jquery) will add up, and fast.

Also, although the given ES6 examples aren't that difficult to parse side-by-side jquery equivalents, it is considerably less (than jquery) like (so-called) natural language, and more a shorthand-like, symbol-laden abstraction. Going in the wrong direction, then. Maybe ES6 will be easier for AI code generation. Maybe that's the whole point.

> Maybe ES6 will be easier for AI code generation. Maybe that's the whole point.

You forget to mention Grunt, Docker, and Blockchain. Oh, and of course CoCs.

Combined Oral Contraceptives? Canadian Opera Company?

ES6 (ES2015) is JavaScript (technically, JavaScript is an implementation of EcmaScript) and it's already here.

There is also ES2016 (ES7), ES2017 (ES8) and ES2019 (ES9) all of which contain forthcoming features for JavaScript to implement.

Don't confuse ES6 with the removal of frameworks/libraries, it doesn't do away with them nor forbid them. It's rai·son d'ê·tre is to improve JavaScript to add functionality like document.querySelector that allow you to accomplish jQuery-like functionality without importing the entirety of jQuery, but there are still plenty of things that ES6 cannot do that jQuery can (more easily). To be clear, there is nothing stopping jQuery from still existing and making use of ES6 features if it wants to.

To summarise, ES6 is an evolution of JavaScript, not something to replace all your libraries.
  These are called arrow-functions and they are awesome.

Yeah, I'm slowly getting my head around some of the features. And the unrelated do's and dont's of service workers. Like SWs don't do DOM stuff, and sw "modules" are sandboxed to hell (because security?).