---
tags: "ProperJS"
---

# Frictionless JavaScript

> One way we could summaries the state of the JavaScript ecosystem between 2015 and 2020 … When too much comfort gets in our way, that we forget to notice when we are causing our own discomfort.

The biggest technical struggles to use JavaScript in development today stem from a lot of make-shift conventions that were introduce to mitigate a language limitation which was closed in 2015.

While ECMAScript modules are far from ideal, they were perfectly suitable for development purposes from the get go. Our practices on the other hand, those were riddled with priorities that somehow made a lot of friction in the ecosystem.

As the ECMAScript specifications continue to recieve refinements, we can expect ECMAScript modules to continue to grow in adoption. Sadly, the ecosystem will continue to lag at the behest of those who insist on struggling with legacy tooling, and those who got tangled in creating workflows that offered the false comforts of writing code and forgot to realize it was never JavaScript in the first place.

And so, biggest technical struggles to use JavaScript come from make-shift conventions that are coupled into tooling which encouraged people to forget to practice first-class fluency in the JavaScript language itself.

This is when you begin to understand, why some of us started thinking of ProperJS. Because once you notice the disparity in technical complexicities, you cannot help but realize the tradeoffs.

The most powerful thing that attracted developers to JavaScript, the fact that you are right in the middle of the action. Later, we had developers being forced into the ecosystem who never really understood that. They came to want see things with mindsets incapable of appreciating how to leverage this level of intimacy, without compilers and opinionated configurations.

That is what ProperJS is trying to correct, the fact that JavaScript code is actually not a matter of compilers and opinionated configurations, it is well-defined, including how its modules are meant to be written.

---

## Considerations

### Prototyping

The tooling culture created a lot of cognitive dissonance and overload through layers of contradictions.

### Modules

#### Bare Specifiers

> **Note**: As of 2020, the ECMAScript specifications do not differentiate between the forms of specifiers, only the idempodency of the module resolution semantics for the set of unique specifier strings imported into a realm.

A large number of runtimes offer ECMAScript compliant support for bare specifiers that allow developers to leverage packages distributed via private and/or one of many widely-accepted channels of the JavaScript ecosystem.

The biggest obstacles lie in browsers which lack of support or fail to reach the consistency needed to leverage bare specifiers.

Following the ProperJS conventions, you should avoid using bare specifiers, unless:

- You have an out-of-realm mechanism to rewrite faithfully specifiers for unsupporting runtimes.

- The code itself is only ever be used in supporting environments which must be clearly indicated.