How to avoid dichotomy between globals and built-in modules

[sffc]

Since we already have precedent of global objects, we would now be introducing a dichotomy: some standard library functionality is available in globals, and other standard library functionality is available in built-in modules. Programmers would be able to use Map, Set, Intl, etc., without performing an import, whereas future functionality would require an import at the top of your file.

That dichotomy suggests that the older globals are more "important" than the newer, imported modules. However, that isn't the case, and may actually be contradictory, if a newer built-in module replaces an older global.

I've previously thrown out the idea of adding a new strict mode, like "use stricter";, which removes all existing globals, but that hasn't been a very popular suggestion.

[Mouvedia]

Here's a potential example of such a thing.
We talked about range on #16; the proposal introduces a new static method not a std module.

[glen-84]

What about slowly deprecating the use of global objects?

1. The objects are moved to a built-in module (also providing the opportunity to make improvements).

   import {Map, Set} from core "collections";

2. The global objects are documentation-deprecated for X years.
   • Documentation-deprecated just meaning specifications and sites like MDN updated to reflect the changes.
3. Linter rules could be created to discourage the use of global objects where possible (able to use modern browsers or a preprocessor).
4. The global objects are console-deprecated after a further Y years.
   • Console-deprecated meaning warnings are displayed in browser consoles.
5. The global objects are removed after an additional Z years.

The total time could be 10 or even 20 years, but most developers/teachers/projects would migrate long before then.

I don't really agree with the whole "never break the web" thing, as I feel that it holds back innovation/evolution, but this is probably an unpopular opinion.

[ljharb]

@glen-84 more importantly, "never break the web" is a thing all the browsers insist on.

[glen-84]

There's surely a number though? Are the browsers really going to be carrying along all the cruft for decades?

Do they need to keep all of this around "forever"?

Anyway, this is a bit off topic, so I'll say no more.

[kgryte]

@glen-84 Much of the "cruft" that you linked to was never formally standardized. In particular, browsers attempted to provide non-standard APIs. What does make it into the standard is expected to be, and to remain, backward compatible going forward.

[ljharb]

More or less yes, forever, until the heat death of the universe, or of JavaScript, whichever comes first.

[bathos]

always bet on JS, @ljharb

[sffc]

Not breaking the web is where the "use stricter"; suggestion came from.

[kaizhu256]

always bet on JS

because javascript is the best-language for solving ux-problems where jobs will forever-be-in-demand, (while ppl who solve cs-problems are increasingly irrelevant and jobless).

[stiff]

Not breaking the web is where the "use stricter"; suggestion came from.

This also has potential for future updates with "use strictest";. Unfortunately the potential ends there :)

In some primitive scripts globals are really helpful, but in proper big applications they do more harm than good. So having both options is really handy. Like {-# LANGUAGE NoImplicitPrelude #-} in Haskell.