Комментарии 41
А изначальную позицию закрыли опытным и сильным девелопером. Стоит он дорого, но такие люди на контрасте с общей массой начинают еще больше цениться.
https://gyazo.com/1f33b7a3cd6a6128a63eee0069e09b5d
Полифиллы, транспиляция.
Часто заказчики вообще требуют поддержки IE6.
вокруг вас там черти с вилами не бегают?
забудьте var, используйте let и const.
Между тем, node.js team пока старается избегать их в местах, критичным к скорости выполнения (например, в циклах). https://github.com/nodejs/node/pull/8873 и https://gist.github.com/Salakar/6d7b84f7adf1f3bc62a754752a6e5d0e
Со времен JS-движки оптимизируют под новый стандарт.
for(var i = 0; i < length; i++)
(function(i){
тело
})(i);
Это несомненно решает проблему когда в теле оказывается ассинхронный код, единственное что могут изобрести js-движки — jit оптимизацию, которая проверит что код синхронен и тогда заменит let на var (логику поведения). Но что если мне действительно надо в ассинхронном коде использовать последнее значение i?
ES6 принёс очень много загадочных мест.
https://docs.google.com/document/d/1EA9EbfnydAmmU_lM8R_uEMQ-U_v4l9zulePSBkeYWmY
переменная "протекает" в другие блоки кода
протекает наружу
Всега было "поднимается" ну или "всплыввает", зачем вводить новое понятие да еще и такое запутанное.
Все же четко: объявление переменной "поднимается" в начало области видимости (функции). И не нужно объяснять почему переменная настолько вредная, что "проникает" в другие блоки
Некоторые фишки очень даже понравились.Особенно «class, constructor».
Но вот это как-то не очень:
ES6
function settings() {
return { display: { color: 'red' }, keyboard: { layout: 'querty'} };
}
const { display: { color: displayColor }, keyboard: { layout: keyboardLayout }} = settings();
console.log(displayColor, keyboardLayout); // red querty
Это, на мой взгляд, просто пример неуместного использования деструктуринга, строка получилась очень длинной и плохо читаемой, при этом вариант settings.display.color
гораздо читабельнее в данном случае.
Но это не потому что деструктуринг плох, а потому что надо в меру фичи использовать.
То же можно сказать и про [...array1, ...array2, ...array3]
. Лучше бы +
починили (ну или какой-нибудь ++
добавили), если concat
не нравится.
Модные и современные веб-языки и технологии проходят тернистый путь развития совершенно без учета граблей, через которые пришлось пройти в свое время традиционным универсальным языкам и платформам.
В C++ изначально было сделано по уму — friend-функции
А вот дальше пошло хуже, но хоть как-то развивалось:
- в Delphi «протекали» private-поля внутри модуля, потом протечки залепили с помощью strict protected;
- в Java protected-поля протекают внутри пакета,
- но потом появился ее близнец C#, в котором protected не протекает, а для контролируемых протечек внутри сборки придумали internal.
На мой взгляд, когда private var виден наружу, это именно «протечка», лучше называть вещи своими именами.
Ок, придумали, let и const теперь. Неясно, почему это нельзя было придумать сразу, с учетом опыта других языков.
Тем более путаница ключевых слов — если с const все понятно, то разницу между var и let нужно держать в голове, или гуглить. Опять же, неужели опыт других языков не учит, где тоже полно схожих ключевых слов с разной семантикой.
Неясно, почему это нельзя было придумать сразу, с учетом опыта других языков.
Javascript появился в 1995 году, опыта других языков типа Java и тем более C# еще не было.
- в 1995-м появился LiveScript, а не JavaScript
- Сколько раз его можно было переделать, пока браузеры не стали массово исполнять JS как стандарт де факто?
- в 1995-м уже давно был C++, и вовсю была Delphi, было на что ориентироваться
- Java вышла в 1995-96-м
Так что по ходу развития JS было на что ориентироваться.
Поэтому и неясно, почему такие детские болезни, как var в JS, дожили аж до 2016.
Ну когда смогли, тогда и сделали.
Лучше поздно, чем никогда, правда?
Но этот и множество других примеров в веб-технологиях удивляют — как будто их разработчики занимались разработкой где-то на Альфа Центавра, иной раз кажется, что ну совершенно без учета опыта индустрии.
А теперь если что-то и исправляется, то преподносится как откровение (а в индустрии в целом это уж 10-20-30 лет как решено).
Проблема в том, что веб давно стал очень актуальным, и дальше — больше (но — со всеми своими детскими болезнями), и было бы интересно понять причины, предпосылки сложившегося состояния дел именно в веб-отрасли.
А так, считаю, что и традиционным языкам есть чему получиться у того же JS (например, доступ к элементами класса как словарю «ключ — значение» — по сути, это рефлексия, встроенная в язык, а не в библиотеки платформы).
Ответ на первой картинке в посте.
С 2000 года почти 10 лет никто языком не занимался вообще, браузеры реализовывали функциональность кто во что горазд.
Потом понадобилось некоторое время, чтобы разобраться с проблемами и прийти к какому-то удовлетворительному решению.
в Java protected-поля протекают внутри пакета,
Чем это плохо?
Неясно, почему это нельзя было придумать сразу, с учетом опыта других языков.
Может потому что он был написан в 1995 за 10 дней?
Тем более путаница ключевых слов — если с const все понятно, то разницу между var и let нужно держать в голове, или гуглить.
Убрать поддержку var нельзя но let внедрять нужно. Как бы вы тут поступили?
var Animal = function(name){
this.name = name;
this.speak = function(){
console.log(this.name + ' makes a noise.');
}
}
var Animal = function(name){
this.name = name;
}
Animal.prototype.speak = function(){
console.log(this.name + ' makes a noise.');
}
var lion = Object.create(new Animal('Simba'))
lion.speak = function(){
Animal.prototype.speak.call(this);
console.log(this.name + ' roars.');
}
lion.speak(); // Simba makes a noise.
Тоже нормально читается. В общем не отпускает чувство что пример нарочно усложнен для контраста, «как все клево стало».
В вашем первом примере на каждый новый экземпляр Animal будет создан свой инстанс метода speak.
Если вынести метод в прототип, то он будет один на все экземпляры. В теории, это сэкономит вам немного памяти, если объектов много.
Обзор базовых возможностей ES6