Var, let или const? Проблемы областей видимости переменных и ES6

[mwizard]

Шел 2018 год, const и let все еще считаются новыми возможностями.

[zaqqq13]

Ну так в основном ТЗ заказчика выглядит примерно так — «Хочу красиво, быстро, да еще чтобы в IE7 работало, потому как у меня парк машин на Win XP и обновлять его ближайшие пару сотен лет я не планирую»

[mwizard]

IE7 все еще не основание не использовать современную версию языка. К счастью, у babel есть транспилеры даже в es3, а недостающий рантаймовый функционал, типа тех же ES6 Proxy, можно нахреначить либо через нативные расширения браузеров, либо тотальным опесочиванием.

[zaqqq13]

А о таком варианте как-то не подумал сразу) Спасибо за уточнение) Но опять же — лично мне на это плевать, ибо стараюсь обходиться константами и чистыми функциями когда пишу на js, а учитывая что приходится делать это достаточно редко, то проблем особых не испытываю

[mwizard]

Ну es6 не ограничивается только константами. Это и итераторы, и стрелочные функции, и выведение имен, и генераторы, и промисы, и асинхронные функции…

[zaqqq13]

Само собой. Я сейчас обсуждение веду в рамках статьи просто, тут об этих возможностях es6 ни слова, вот и я не упоминаю

[i360u]

в основном

хм, я такого не встречал уже… лет 8 точно. Где вы таких находите?

[zaqqq13]

Спросите это у нашего руководства. Кстати это и стало основной причиной моего ухода, осталось еще 2 недели отработать и с радостью свалю. Но факт остается фактом — конкретно на моем текущем месте работы примерно так ситуация и выглядит, потому как фирма ориентирована на рынок СНГ

[k12th]

Исключительно в блоге компании RUVDS.

[evil_random]

Это уже не говоря о том, что они какими-то мутными целями оправдывают написание говнокода с var. Как будто нет бабеля на let-const и нельзя код писать нормально. Короче статья ради статьи реально.

Вот тут очень толково и сжато написано если кому надо: learn.javascript.ru/es-modern

[zaqqq13]

Как по мне — использовать var в 2018 году уже не имеет смысла, разве что для поддержки древних браузеров, которые не могут в ES6. Ну и как кому, лично я вообще предпочитаю по возможности приближаться к функциональщине при работе с js, а при таком подходе в принципе ни let, ни var не нужны, достаточно const, но это уже вкусовщина

[Bhudh]

Как быстро, однако, сейчас становятся "древними" браузеры, выпущенные в феврале 2016 года. Всего 2,5 года — и ты уже "замшелая древность".

[justboris]

Современные браузеры обновляются автоматически. Новая версия раскатывается на всех пользователей в течение нескольких недель.

Если у вас до сих пор стоит старый Хром, значит у вас что-то сломалось.

[Bhudh]

Сразу понятно, что под Presto Вы не разрабатываете.

[justboris]

А зачем? Последняя версия вышла 5 лет назад. Этот движок уже устарел по любому критерию

[Bhudh]

Я написал, когда вышла последняя версия Оперы на этом движке. 16 февраля 2016 года.
Вы ошиблись в 2 раза.
И Вы напрасно думаете, что его никто не использует вообще.

[justboris]

И правда, был релиз в 16 году. Но это было исправление безопасности, а не какое-то развитие с новыми фичами.

В моем представлении такой продукт выглядит скорее мертвым, чем живым.

[SagePtr]

Presto ещё живой?

[Bhudh]

Он ещё и используется.
dev.opera.com/articles/browsers-modes-engines

[VolCh]

Не везде автоматически. В компаниях на рабочих местах часто только волею администратора. А ещё версия прибита может быть из-за какого-то софта, который, например, не хочет нормально работать в хроме 49+.

[VolCh]

И на серверах какие-то хедлесс или под селениумом не обновляются часто годами.

[justboris]

Прибитая гвоздями версия ради энтерпрайзного продукта — такое случается, но это скорее исключение из правил.

А вот тестовые браузеры под Selenium лучше своевременно обновлять, чтобы не было ложных срабатываний на баги, которых у пользователей никогда не будет.

[VolCh]

Программно управляемые браузеры это не только тестовые фермы, но и различные агрегаторы, например, парсящие ваши SPA. Но и для тестовых ферм целесообразно использовать те версии браузеров, которые используют конкретно ваши пользователи, если вы работаете на высококонкурентном рынке и пользователь скорее уйдёт к конкурентам чем будет ради вас обновлять браузер. Например, профессиональные ресурсы для бухгалтеров или кадровиков часто имеют очень большой процент старых браузеров.

[justboris]

но и различные агрегаторы, например, парсящие ваши SPA

Если агрегатор с более старым браузером может парсить сайт, то проблем нет. А вот даунгрейдить фичи только чтобы ублажить агрегатор, вместо заботы о конечных пользователях — это странный труд.

Я знаю, что GoogleBot использует Chrome 41. Но для меня это повод задуматься о полноценном сервер-рендеринге, а не ограничивать себя в let/const.

если вы работаете на высококонкурентном рынке и пользователь скорее уйдёт к конкурентам чем будет ради вас обновлять браузер

Что-то я не верю в анекдот "один вебмастер не использовал es6, и его продажи удвоились за счет пользователей с завирусованных компьютеров, пользующихся Амиго или Chrome 46". Все-таки у подавляющего большинства пользователей обновления включены.

[VolCh]

Я не про даунгрейд специальный, а про отсутствие апгрейда :) А серверный рендеринг может оказаться довольно сложной технической задачей. Не, если у вас сервер на ноде и фронт фреймворк, поддерживающий рендеринг из коробки, то чуть ли не парой строк в конфиге можно решить. А если сервер на том же PHP, а фронт фреймворк про ноду плохо осведомлён, то одним из вариантов серверного рендеринга будет как раз создание фермы с браузерами :)

В целом может быть у подавляющего большинства и включены. Но, как по мне, прежде всего за счёт индивидуальных пользователей. Корпоративный сектор более консервативен по разным причинам и если ваш ресурс ориентирован на него, то, скорее всего, статистика использования браузеров будет отличаться от общемировой или региональной (даже тут специфика есть — если в регионе плохо с Интернетом, трафик дорогой и(или) скорости низкие, то новых версий будет заметно меньше в статистике даже на чисто гиковских ресурсах).

[DENCREAT]

как пример, у нас поддержка ие11+… и вот даже при данном стечении обстоятельств, мы можем юзать только let и const, и то с некоторыми ограничениями в виде циклов))))

[Zibx]

Особенно удобно использовать let и const в developer тулзах. После игр с новыми волшебными классами я окончательно убедился в том что старое хотя бы предсказуемо и стабильно работает. При том у меня есть сильное подозрение что let и const по факту нужны только для генерации исключений в момент компиляции и приводят только к деоптимизации кода на низком уровне путём создания лишних замыканий в тех местах где они могут быть не нужны.

[mwizard]

Если сможете это подозрение оформить в виде статьи с замерами, было бы замечательно.

[Zibx]

Это не имеет смысла. Спецификация не описывает реализацию, а это значит что идеальный jit сделает оптимальный код. Ресёрчем я могу только подтвердить подозрения. И это будут не замеры, а сравнение генерируемого V8 байткода.

[Chamie]

let, кстати, местами совершенно неочевидно работает. Например, в for'е.

[zaqqq13]

А можно поточнее? Я лично стараюсь юзать иммутабельные переменные и let использую в for-е в качестве счетчика и пока не замечал некорректного поведения

[VolCh]

А знаете, что в for in/of можно const использовать? :)

[Chamie]

let a = [];
for(let i = 0;i<4;i++){
  a.push(function(){
    return(i);
  });
  i++;
}
console.log(a.length);
console.log(a[0]());
console.log(a[1]());

>2
>1
>3

[zaqqq13]

Благодарю за пример, познавательно) Но зачем лишний раз инкрементить i? Сразу не заметил и не мог понять прикола. А так да, вы пропускаете лишнюю итерацию, все логично

[Chamie]

Долго искать в стандартах, но действует примерно так — для каждого прогона тела цикла создаются копии переменных, в них копируются текущие значения, а после прогона тела их значения копируются обратно в переменные (по крайней мере, Бабель как-то так делает).
Сделано это, как я понял, для упрощения стандартных действий с циклами — чтобы и замыкать можно было каждый раз на новое значение переменной, и со счётчиками можно было работать как раньше, меняя их вручную.

[zaqqq13]

Благодарю, кстати этот же код с var работает совсем некорректно. Сам на js пишу редко и каждый раз такие вещи заставляют улыбаться. Так что по факту let сделал из этого кода хоть что-то работоспособное)

[Chamie]

этот же код с var работает совсем некорректно

C var он работает неудобно, но понятно — функции в массиве замкнуты на одну и ту же переменную и обе возвращают одно и то же значение.

[Bhudh]

С замыканиями работает вполне корректно:

var a = [];
for(var i = 0;i<4;i++){
  a.push(function(i){
    return function(){
      return i;
    };
  }(i));
  i++;
}
console.log(a.length);
console.log(a[0]());
console.log(a[1]());

[Chamie]

Так он всегда корректно работает — согласно стандарту. Просто немного не так, как от него можно было ожидать.

[Chamie]

Благодарю за пример, познавательно) Но зачем лишний раз инкрементить i? Сразу не заметил и не мог понять прикола. А так да, вы пропускаете лишнюю итерацию, все логично

Только сейчас понял, что не объяснил-таки, в чём смысл примера. Смысл в том, что переменная цикла, вроде как, одна (i), но функция, создаваемая в теле цикла, в разных экземплярах функции видит разное значение. При этом, если изменить её в теле цикла, то в условии выхода проверится тоже изменённое значение, как будто это, всё-таки, одна и та же переменная. В итоге, совершенно непонятно без специальных раскопок, что такое эта i в разных местах — в теле цикла и в трёх частях параметров оператора for.

[sayanlar]

var неудобен, но let с его предобработкой инициализации — еще хуже.
Создавать переменную с одинаковым именем для разных задач в рамках одного и того же сегмента кода — плохая практика, и ее не сделать лучше никаким образом. Не стоило и пытаться, я считаю.