From JavaScript to Frankenstein's monster


Even if we talk mainly about ActionScript 3, it is still worth keeping an eye on the JS world

and so here some link dump …

10 popular modern JavaScript features for front-end devs
A beginner’s look at features typically used with React, Vue and other frameworks

so this article starts literally with that

(async x => {
    const { mystery: fun } = {
        [x]: (a = 3, { b = 3 } = {}) => value => [a * b],
    [x] = await fun(2)('TEST');

Don’t try to figure out the output of the above, but can you identify which modern JavaScript features it uses?

JavaScript is a very different language than it used to be a few years ago. ECMAScript, which is the official specification that JavaScript conforms to, has improved a lot in the past few years after a rather long period without any updates to the language at all.

Indeed JS is not a glue language anymore, it has evolved a lot, but really? is it that good?

see JS, in its ES3 form, was something super simple and straightforward to pickup, because the syntax was simple and limited, now it kind of feels like advanced Perl or C++, unless you have actually read in details what the syntax is doing and all the special cases you can not understand it by just reading it

to the point now when someone introduce an article about JS they warn you to not even bother trying to understand it

sure the language is “more advanced”, but all those new syntaxes that are supposed to make you write code faster, are simply inflating the cognitive load which has the exact opposite effect: make you write code slower, or worst “not being completely sure” and having doubt

should have used var or let or const ?
what if …

it is a shame really

But the cognitive load is not only stopping at the language syntax, it goes waaaaaay beyond that

The Ultimate Guide to JavaScript Fatigue: Realities of our industry

interesting read, great advices like

JS Fatigue happens when people use tools they don’t need to solve problems they don’t have.

and then you realise that absolutely nobody out there are following those simple stuff, no it is hte opposite, everyone is like

let invent new tools for new problem we don’t have and let’s do that every day with JS

and so…
where you will see references to other articles

The State of Babel
or “Yippee ki yay Motherfucker” why write in the actual JS syntax supported by everyone
but instead write with the JS syntax of the future and cross-compile it later


Moving Past RequireJS
or let re-invent every day how we deal with modules in JS

where you can read this flabbergasting thing

AMD’s asynchronous nature remains a theoretical advantage, but in practice, modern module loaders have found ways to solve these problems for CommonJS. Webpack allows configuration options for lazy loading individual modules, and developers using Browserify have found workarounds to the problem. At this point there’s no real difference in the capabilities of AMD compared to other module formats.

oh you found workaround, well… good for you!!!

and then other things that talk about fatigue

A Study Plan To Cure JavaScript Fatigue

This didn’t come as a surprise though: I’ve known for a long time that the JavaScript ecosystem can be confusing. In fact, the very reason why I ran the State Of JavaScript survey was to find out which libraries were actually popular, and finally sort the signal from the noise.

oh? that didn’t come as a surprise? no kidding?

but that’s OK this guy gonna give us hope

But today, I want to go one step further. Instead of simply complaining about the state of things, I’m going to give you a concrete, step-by-step study plan to conquering the JavaScript ecosystem.

wow really???

and then it fall flat on its arse

Disclaimer: this post will include a few affiliate links to courses by Wes Bos, but the material is recommended because I genuinely think it’s good, and not just because of the affiliate scheme.

the guy is swearing it is genuinely good, not at all because he try to shove up your ass some paying material … the classic “trust me, I know”

man the amount of bullshit… wow this fatigue thing is for real, I feel it so hard

OK here another one

ES5 to ESNext — here’s every feature added to JavaScript since 2015

not clickbaity at all… I swear, trust me!!!

ah the perfect intro

I wrote this article to help you move from pre-ES6 knowledge of JavaScript and get you quickly up to speed with the most recent advancements of the language.

JavaScript today is in the privileged position to be the only language that can run natively in the browser, and is highly integrated and optimized for that.

The future of JavaScript is going to be brilliant. Keeping up with the changes shouldn’t be harder than it already is, and my goal here is to give you a quick yet comprehensive overview of the new stuff available to us.

I’m pretty sure “pre-ES6 knowledge” make you feel like some Neanderthals if you don’t know ES6, but no worries there is some magic sauce (paying tutorials anyone?) to make you up to speed

because JavaScript today is in the privileged position to change every goddam day, so you have to re-learn it every day and that forever, because you’re stuck with it, no matter what, as it is “the only language that can run natively in the browser”

and wow… in fact, I can just quote literally

“The future of JavaScript is going to be brilliant”
yay!!! new stuff to learn every day, new tutorial to sell every day!!!

“Keeping up with the changes shouldn’t be harder than it already is”
wait a minute for it …does he mean it is already harder? oh you bet he means that!!!

at this point it must be a running joke

Introduction to ECMAScript

Whenever you read about JavaScript you’ll inevitably see one of these terms: ES3, ES5, ES6, ES7, ES8, ES2015, ES2016, ES2017, ECMAScript 2017, ECMAScript 2016, ECMAScript 2015… what do they mean?

They are all referring to a standard , called ECMAScript.

yeah it is standard, but it does change every day so the standard part is meaningless!!!

and so

Future JavaScript: what is still missing?

hey off course, if they keep changing the standard every day that must mean there is ALWAYS something missing

I can not wait for “ECMAScript 2024” that will be published in 2026 but no worries you will be able to cross-compile it as soon as 2020, or whatever…

but DO NOT WORRY because as the article says

7.1. Will JavaScript ever support static typing?

Not anytime soon! The current separation between static typing at development time (via TypeScript or Flow) and pure JavaScript at runtime, works well. So there is no immediate reason to change anything.

shorter answer: “never” LOL

and also

8. Thoughts on language design

As a language designer, no matter what you do, you will always make some people happy and some people sad. Therefore, the main challenge for designing future JavaScript features is not to make everyone happy, but to keep the language as consistent as possible.

However, there is also disagreement on what “consistent” means. So, the best we can probably do is to establish a consistent “style”, conceived and enforced by a small group of people (up to three). That does not preclude them being advised and helped by many others, but they should set the general tone.

shorter answer: our consistent “style” of language design is to never be consistent and change things every day

in short, your future studying JavaScript is that you will have to do it all the time, every day, and as soon as you will stop, you will lack behind, come back to the language and not recognise WTF is going on here ?!?

and if that’s not enough, you will have to learn a new JS framework every week!!! yayyyyyy!

That’s fatigue alright …


Nowadays JS is Cabala…
It seems like code clarity, even if it involves more lines, is uncool.
Also, a few string and array manipulation shortcuts count as a language “fantastic advancement”.