Под какой ES сейчас все работают?

[Malleys]

В учебнике ни намека с какого ES каждая из этих фичей работает.
Как такие вещи побыстрее понимать/находить?
Например по деструктивному присваиванию.

Тот учебник, он что по последнему какому то самому ES с абсолютным игнором браузеров?

В эпоху, где браузеры сами обновляются, это не проблема... У обычного человека всегда будет обновлённый браузер с необходимым функционалом, а тех, кто использует что-то старое, вся ответственность лежит на них... Для них следует вывести напоминание, что пора обновиться, как это делает, например, YouTube и множество других сайтов!

Дык если транспилять всё равно - то какая разница?

И как это сделать для WASM или WebGL? Правильное решение — предложить обновиться до последней версии. Это не сложно!

Протранспиляй WeakMap и WeakSet.
Так, что бы работали как положено, а не видимость представляли.

Я, например, не вижу такой необходимости, если вам везде нужна стабильная работа приложения, то вы сами можете использовать нужный браузерный движок! Например, Electron используют Skype, VS Code и пр.

А между тем большинство тех, кто начинает сегодня программировать, скорей всего не сталкивались с IE. И правда, где можно встретить IE? Молодой человек покупает телефон/планшет/ноутбук, разве там такое есть? Даже я его только видел только в виртуальной машине, когда запустил там ради интереса Windows XP. Знаете, этот ваш IE — это лицорука и развод пенсионерами! Там даже CSS нормально не работает! Вы должны радоваться, что больше нет такого мерзкого браузера, а не думать, как туда что-то транспилировать!

[Aetae]

Транспилять всё равно надо. Потому что typescript. Потому что vue sfc. Sass. CSS modules... И т.д. и т.п.
Без транспиляния нынче как без штанов.

[voraa]

Я, например, не вижу такой необходимости, если вам везде нужна стабильная работа приложения, то вы сами можете использовать нужный браузерный движок! Например, Electron используют Skype, VS Code и пр.

А при чем тут приложение?
Просто код в браузере. На простой ваниле.
Я, например, довольно широко использую WeakMap.
Есть у нас некоторые внутренние библиотеки, где на них многое держится.
Навешиваются на элемент DOM некоторые дополнительные массивы данных. Если элемент удаляется, то не приходится думать, что эти данные застрянут в памяти и не будут убраны сборщиком мусора.

[Aetae]

Навешиваются на элемент DOM некоторые дополнительные массивы данных.

А можно с тем же успехом по старинке навешивать на элемент DOM некоторые дополнительные массивы данных... (буквально)

[Malleys]

Транспилять всё равно надо. Потому что typescript. Потому что vue sfc.

Плохо смотрел. Открываем рандомный файл Vue и видим, что всё там по-современному.

Плохо смотрел. Это не JavaScript. И вообще какие мотивы движут людьми, которые напишут что-то на TypeScript и дают имени файла расширение .js (вместо .ts)? С# тоже местами похож на JS, однако ни у кого не возникает желания косить под JS! 😜😜

А при чем тут приложение?
Просто код в браузере. На простой ваниле.
Я, например, довольно широко использую WeakMap.

Если это вам так важно, то приложение как раз гарантирует, что ваш WeakMap всегда сработает, а сайт могут открыть (почему-то) в старом браузере.

Без транспиляния нынче как без штанов.

Какая ложная аналогия! Вы вполне можете писать на стандартном JS и всё нормально будет работать.

[voraa]

А можно с тем же успехом по старинке навешивать на элемент DOM некоторые дополнительные массивы данных... (буквально)

Навешивать прямо на DOM не хорошо. Нельзя в чужой объект пихать свои поля. Нет никакой гарантии, что когда-нибудь производитель браузера не введет туда поле с таким же именем.
Есть легенда, что тип Symbol появился как раз из за этого. Когда захотели ввести итераторы, то первая мысль была ввести в массивы и разные другие объекты служебное поле iterator (ну как есть length у разных объектов) Выяснилось, что существует довольно много библиотек, которые внедряют в прототипы стандартных объектов поля и методы с этим и другими именами. Пришлось вводить новый тип, который гарантированно никто не использует.

[Malleys]

А можно с тем же успехом по старинке навешивать на элемент DOM некоторые дополнительные массивы данных...

И не «по старинке» тоже...

const array = Symbol();
node[array] = [];

Нет никакой гарантии, что когда-нибудь производитель браузера не введет туда поле с таким же именем.
Есть легенда, что тип Symbol появился как раз из за этого.

Да, тип Symbol именно для этого и предназначен!

Заметил, что в bootstrap, jQuery, vuejs всё ещё используются var, т.е. они в стиле ES5 написаны.

Объявление переменных при помощи var было доступно как в ES3, так и доступно до сих пор в ES2020. Конечно в большинстве случаев вам достаточно let с его блочной видимостью, однако когда вам не нужна блочная видимость, то как раз подходит var — например, два последовательных цикла, второй из которых использует переменные инициализированные (при помощи var) в первом цикле.

лично я придерживаюсь мнения, что нет смысла терять 5% посетителей ради них. Они привносят лишь небольшое удобство, которое даёт профит только на больших проектах, а на стандартных сайтах и с var нормально живётся.

Если у вас долгоиграющий проект, то у вас был сайт (например, написанный в одну кучу на PHP), а теперь вы, например, хотите сделать его как «одностраничное» приложение (SPA). Не спешите разрушать или дефрагментировать диски со старым проектом, вы можете его перенести с https://example.com/ на https://example.com/olddesign. А по адресу https://example.com/ разместить свой новый проект, в котором будет проверка на нужные API, в случае их отсутствия, будет перенаправление на https://example.com/olddesign.

Многие вещи и бабель не разжевывает.
Например, всякие прокси.
Про теневой дом, не знаю, я им не пользуюсь, но сомневаюсь.
Ну и при многих фичах от CSS бабель тоже бессилен.

А если проект совсем новый, то и беспокоится не о чем... 😂 😂 😂 ни у кого из пользователей нет опыта работы с приложением через старый браузер, так что вы можете им спокойно продавать теорию о том, что нужен новый браузер! Поверьте, они купятся и скачают! 😉

[voraa]

Тут недавно дошло до смешного. Написал довольно большой модуль (т.к. мы можем в своей работе не думать про всякие ИЕ и прочее старье) то использовал те возможности, которые считал более удобными. Решил его минифицировать с помощью гугл клаши.
Не тут то было. Выдает ошибку за ошибкой. Оказывается клаша не распознает синтаксис полей классов, которые были введены еще в 72-ом Хроме (а сейчас уже 80-й)

[voraa]

const array = Symbol();
node[array] = [];

Ну не красиво. Запариваешся эти скобки постоянно писать.
К тому же иногда думаешь об оптимизации (хотя по большому выигрыш, наверно, в наносекундах)
V8 при оптимизации многие функции компилирует в машинный код. При выполнении ряда условий. Например вызов этой функции должен всегда происходить с параметрами одного типа. Как выяснилось если параметр объект, то {а: , b: }, {a:, b:, c:}, {b:, a:} - это уже разные типы

[Malleys]

которые были введены еще в 72-ом Хроме (а сейчас уже 80-й)

А ещё когда-то в «Кроум» (Chrome — это вам не «Хроме») были введены HTML imports, которые потом были благополучно выпилены. Не всё, что есть в Chrome — стандартизировано, и соответственно может исчезнуть! Полей классов не было в ECMAScript2019, соответственно и не поддерживается в Closure Compiler.

Поля классов даже в этом году скорей всего не войдут в стандарт!

Ну не красиво. Запариваешся эти скобки постоянно писать.

Это стандартный синтаксис для определения поля при помощи символа. Тоже самое вам придётся сделать, если имя вычисляемое!