Smoosh? SmooshMap?

Silly JS kids.

referring to the pretty serious TC39 proposal to replace flatten & flatmap https://github.com/tc39/...

Got to admit, I'm quite baffled by the fact they'd be willing to ruin future code to preserve some 8 year old legacy code.

@Commodore I've decided not to pick a side.

But I'm wondering if I could write a library to force map/reduce/filter to become transmogrify/distill/purify, that would be neat.

@bittersweet simply submit a pull request on mootools, apparently that's the way to go 😅

@AlexDeLarge I don't know, es6 & 7 were going the right way.

That "smoosh" proposition is getting a lot of bad feedback, so hopefully they'll come up with a better idea

So because some idiots decided to fuck something up in a third party library, people want to fix it by changing the spec of JS itself?
This is a perfect example of why I hate the JS community so much.

@aaxa The problem is that JS is not just a language with a single compiler/interpreter, it's a spec which runs in all these remote code execution platforms people tend to call "browsers".

What JS would have needed is versioning, a "use es262/es6/es7" or whatever in the relevant closures. But it's too late for that as well, as you have no way of knowing what version an unversioned script is supposed to be written in.

I think the solution would be to just move forward at let things break.

Then leave it to browsers to implement an es262-compatible fallback mode, when exceptions are thrown show a little dialog "reload this page with an older version of JS".

@bittersweet that's kind of what 'use strict' is for, right?

@Commodore Yeah... but that's awfully binary.

What will be next? "use stricter", "use strictest", "use ultrastrict", "use final-version-super-serious". Reminds me of ms word document versioning used by students.

JS kind of needs semver & version constraints.

@bittersweet that would be fun but no, I meant use strict as in "use the current standard".
Implying favor forward compatibility instead of backward.

Don't get me wrong, I agree with you, having a semver targeting on the runtime would indeed be the best solution. It's just not quite within the realm of the possible right now 😛

@Commodore Delete all current websites and browsers in the world, start from scratch?

Would be fun.

@bittersweet Yes I know.
But I still think it's fucking horrible that people think a language spec should support 8 year old unmaintained code.
The problem is incompetent developers and/or companies that neglect how browsers and JS works.

Of course, I agree with you, that it's a sign of a MAJOR flaw in JS itself.

But it's not fair that a spec should change for millions of websites, that are actively maintained because a few companies are too lazy to invest in developing something new.

In any way I can't justify the opinion of being pro the change.

@aaxa I think a swappable JS engine might be an idea. Your browser ships with a very forward compatible engine, and might not render websites correctly which haven't been updated in 5+ years.

In the silly case you are absolutely relying on an old website as a consumer, the browser could display a "click here to download & swap to a legacy JS engine" popup.

But this problem with JS is why I personally still prefer to develop near-scriptless websites. I usually stick to a tiny ajax call wrapper, and make sure the backend responds in <30ms. I've developed very heavy Angular and Vue single-page applications, but I've noticed that pushing things back to the backend simplifies so many issues again -- both in terms of stability and usability.