A pragmatic solution to the flatten proposal problem #smooshgate #JavaScript
Tags: javascript, tc39
Published: 2018-03-08 20:10:47

---
title: A pragmatic solution to the flatten proposal problem #smooshgate #JavaScript
published: true
description: 
tags: javascript, tc39
---

# The Problem

A new TC39 proposal is in conflict with an older library, [mootools](https://mootools.net).

The proposal would add `flatten` to ECMAScript, but would be incompatible with mootools, which has already added a `flatten` to `Array.prototype`. Adding `Array.prototype.flatten` would then break any existing sites that are still using mootools.

This is apparently not the first time mootools has been incompatible with TC39 proposals.

{% twitter 971193585822396416 %}

The TC39 has the difficult job of not only approving new language proposals, but also making sure those proposals are backwards compatible and do not break the web.


# Not the solution

[Another proposal](https://github.com/tc39/proposal-flatMap/pull/56) has recommended renaming `flatten` to `smoosh`. I'm not sure if this is a tongue in cheek recommendation, but it has sparked a large debate now dubbed #smooshgate.

[![Break the web?](https://thepracticaldev.s3.amazonaws.com/i/6uciq30vo5osmk867fri.png)](https://twitter.com/bterlson/status/971210573818904576)

This would be a _workaround_ as `flatten` is a better name than `smoosh`. And to rename this method for an 8+ year old library seems insane.

Adding fuel to this fire, there appears to be [yet another proposal](https://github.com/staltz/prevent-smoosh) to prevent the use of `smoosh` by using an incompatible version of `smoosh` in production sites today, thus forcing the TC39 to not break compatibility with `smoosh`.

**Backwards compatibility is important**. I definitely don't want to go through old legacy sites that have been running just fine for years and update them simply because new features have been added to JavaScript. So, **clobbering old libraries is not a good solution**.

Though, researching every ancient library ever created for the web to ensure compatibility will also slow down progress and coming up with silly names also seems, well, silly.

# A solution

I propose we learn some lessons from [Ethereum](https://ethereum.org) and how they  have already solved this exact problem in [Solidity](https://solidity.readthedocs.io).

Solidity allows you choose which version of the Ethereum Virtual Machine (EVM) you want to run by adding a `pragma` tag to the top of the code file.

```solidity
// run this code with EVM 0.4.0
pragma solidity ^0.4.0;

contract MyContract {
}
```

It is clear to me that this simple solution is also the best long term solution for ECMAScript. This proposal will allow legacy sites to remain unbroken when new features come out. It will also allow the TC39 to progress than language faster and use the best proposals without fear of breaking the legacy web.

Sample Code:

```javascript
'pragma ecmascript ^2018.0.0';

var arr1 = [1, 2, [3, 4]];
arr1.flatten();
// [1, 2, 3, 4]
```

We have already dome something similar with `use strict`. This would simply be the next evolution of `use strict`.

What is your opinion on this whole `flatten`, `smoosh` debacle? I would love to hear your thoughts in a comment below.

Cheers!