Pull to refresh

Comments 58

Я все-таки пока слабо понимаю, зачем сейчас нужен ES6 на фронте (с нодой вопросов нет) — ведь все равно приходится все конвертировать в 5 версию. Ну окей, какая-то часть нового функционала является просто синтаксическим сахарком и потому засовывается в режим совместимости безболезненно (например, стрелочные функции или let). Но вот классы и их наследование бабель конвертит в какие-то настолько жуткие и уродливые конструкции, что я лучше по старинке напишу.

Вот если бы можно было большинству клиентов подсовывать нативный es6 и только в старые браузеры отдавать бабель-версию, было бы понятно. А так все равно все будут жевать транс-компилированную версию.

Или я что-то не понимаю?
Ну это как сравнивать паскаль и дельфи. В одном есть ООП, в другом его можно изобразить. Вроде даже похожие языки, но код в результате совершенно другой, не столько по синтаксису (и это тоже), сколько по стилистике.

Ну вот, для примера, небольшой набросок ActiveRecord на ES2015 (под клиент): https://gist.github.com/SerafimArts/cc85891cffb7c1fd235e
Я понимаю, в чем достоинства ES6. Я не понимаю, как их сейчас по-нормальному использовать, если даже обладатели самых новых браузеров всё равно будут получать бабель-суррогат.
А исходники зато чистые и красивые.

А как использовать нынче Go, Rust, C#, C++, etc, если даже обладателя самых новых процессоров будут получать ассемблер-суррогат? ;)
Мне думается, что компиляция языка высокого уровня в опкоды или байткод виртуальной машины это несколько другое нежели компиляция одного языка высокого уровня в другой язык высокого уровня.

И если уж вдаваться в детали, то программы на описанных вами языках пишутся для работы в одном, максимум 2-3 окружениях, это в конце концов не ANSI C. А сгенерированный ES5 будет работать минимум в 4 разных браузерах, которые еще и будут разных версий.

Кстати уважаемое JS-сообщество может дать мне ответ, почему оно в массе своей так радостно ждало ES6, который по факту работает в продакшене и будет работать еще минимум год исключительно через трансляторы, но все это время игнорировало clojurescript, coffescript, typescript — инструменты для которых воркфлоу один и тот же что и для текущего ES6?
Может потому что вероятность протащить 'clojurescript, coffescript, typescript — инструменты' в браузеры нативно намного меньше, чем поддержка ES6?
Но через год будет es2016, который опять таки будет поддерживаться только через трансляцию, а потом еще через год…

Понимаете, тут фундаментальная проблема в том, что в вебе ВСЕГДА будут старые броузеры. Поэтому единственный способ обеспечить работоспособность приложения у максимального числа пользователей — это транслировать в некую старую версию JS.

Так почему все проснулись только когда вышел es6, хотя по сути его использование ничем не отличается от того же coffeescript? Та же трансляция, та же отладка через сорц-мапы.
Тут всетрчаются две мысли — зачем «самом модному хипстерскому сервису» поддержка каких-то там старых браузеров и зачему самому наджному древнему энтерпрайзу, все эти модные фишечки esXXXX.
Так что проблема я считаю надуманна, эти два множества никак не пересекаются.
Понимаете, тут фундаментальная проблема в том, что в вебе ВСЕГДА будут старые броузеры.

Таки лёд тронулся же. Тот же Microsoft отошел от именования версий браузеров — будет один Edge обновляемый подобно хрому. Использование старых версий в таком случае получается следованием принципу «сам себе злобный Буратино» — так можно и обновления безопасности, закрывающие дырки продуктов не ставить и потом страдать от того, что ими кто-то воспользовался.
Никогда не говори никогда.
Всегда избегай слова всегда
Я немного подумал и наконец понял в чём реально вопрос. Если я не угадал — просьба поправить.

Так вот, весь код на ES2015 (и даже ES2016) запросто переводится на ES5, включая даже некоторые API, вроде Map, Set и т.д., которые вроде как входят в спецификацию. Единственная проблема — это Proxy — единственное что невозможно транслировать и пока очень слабо поддерживается даже самыми современными браузерами. В остальном — абсолютно весь код можно запускать на любом браузере, используя все возможности современных версий даже на каких-нибудь относительно старых версиях браузеров (в пределах разумного конечно, не ИЕ6 какой-нибудь, хотя кто знает...).

Так что код бабела можно смело использовать в продакшене уже сейчас, а лет через 5 (надеюсь) можно будет тот же самый код отдавать уже без трансляции без каких-либо его исправлений.
а лет через 5 (надеюсь) можно будет тот же самый код отдавать уже без трансляции без каких-либо его исправлений

Боюсь, что через 5 лет появится уже какой-нибудь ES2020, который вообще ни в одном месте не совместим ни с одним браузером. И опять всем придётся пользоваться babel или его аналогами.
Ну либо js браузерный всё же будет развиваться в другую сторону, нежели (io|node).js.
Когда то было предложение (ссылку на статью на хабре я сейчас не найду) добавляющая в браузеры возможность передачи байткода, так что компилировать к 2020му году всё равно будет выгоднее, даже при условии, что браузеры будут поддерживать синтаксис этого ES2020. Ну это при условии, что браузеры начнут поддерживать этот байткод.
P.S. А для создания читаемых классов можно использовать опцию loose es6.classes (в документации есть). Это сделает исходный код на выхлопе в разы читаемей (правда в результате не на 100% совместимый со стандартом). Хотя при наличии source maps читаемость результата и так не должна доставлять проблем.
Какая разница, что там получает браузер, если оно работает, как задумано? Вся соль в удобстве разработки.
Я сейчас в песочнице просто из головы набрал
простенький пример, 24 строчки
class Apple {
  constructor(color, weight) {
    this.color = color;
    this.weight = weight;
  }
  get cost () {
    let price = 100;  // rub/kg
    let coeff = {
      green:   1,
      yellow:  1.2,
      red:     1.5,
      magenta: 1.8
    };
    return this.weight * price * (coeff[this.color] || 1);
  }
};

class RedApple extends Apple {
  constructor(weight) {
    super();
    this.color = "red";
    this.weight = weight;
  }
};

Он мне это компильнул в 100+ строк довольно замороченного кода. Я не уверен, что вся эта музыка будет работать так же быстро, как должна была бы при нативной поддержке браузером. Причем это совершенно простенький пример. Что будет с тысячами строк кода?
вы когда на C#/Java/etc пишите, тоже потом скомпилированный байткод изучаете?
смысл использвания ES6 в том что вы получаете новые фишки языка, которые можете использовать сегодня! в том что вашь код становитсья коротким и понятным с первого взгляда, и.т.д.
Нормально все будет и 1000 строк и с 10 000 тысячами, код пишется в первую очередь для людей, поэтому то как он выглядит для машины не имеет ровным счетом никакого значения.
Во вторых, аргумент за производительность вообще не аргумент в этом контексте, я вам дам 100% гарантию что ваше приложение сначала начнет тормозить сначала из-за неправильной работы с дом, потом из за криворукости реализации, потом из за монстрячей конструкции какого нибудь фреймворка, примерно к концу списка тормоза можно будет объяснить вспышками на солнце, но и даже в этом случае тормоза из за кода трансплиттера будут еще далеко.
Я уже написал выше — используйте loose mode, выхлоп сокращается до 50 с копейками строк, но не гарантируется 100% совместимость со стандартом (правда на практике никаких проблем с этим нет, если не влезать во внутренности реализации).
Если вы там нейросети на JS пишете (это про вашу неуверенность в быстроте), то лучше наверно использовать emscripten.
Добавляется 70 строк общих фукций(если отформатировать), считай runtime, сами классы остаются довольно читабильными и не сильно жиреют. +6 строк в данном примере. Если убрать геттер и включить loose mode — код почти как рукописный, с прототипами и анонимными фукциями.
А зачем пользователям отдавать исходные коды? Сейчас уже практически везде используют средства сборки/минификации скриптов и стилей. Использовать es6 для разработки на JavaScript повышает производительность и удобство разработки.
Попробуйте исследовать лицензии ваших любимых компонент, которые вы используете на javascript (или кстати любом другом скриптовом языке), и вы поймете, что либо вам придется отказываться от них, либо перелицензировать, либо принудительно открывать свои исходники, так как оно почти все GPL (правда часто LGPL или аналог).

p.s. кстати, а использование таких компиляторов из чегототам в javascript разве не освобождает программистов от необходимости выкладывать ИСХОДНЫЙ текст программы, если это требует лицензия на компоненты?
Гм. Использую десятки сторонних библиотек, везде MIT/BSD-лицензия.
Спасибо вам за перевод. Постарайтесь пожалуйста внимательнее относиться к опечаткам. И по возможности выделять код так же как и в оригинале. Но поскольку на хабре туго с форматированием, придется ограничиться &ltfont color="#112233"&gt.

var {foo} = pony то же, что var foo = pony.foo.
Спасибо, поправила опечатку. Когда буду заливать вторую часть, поправлю весь код по цвету.
Если честно, то перевод у вас, мягко сказать, не очень хороший. Вчера ребята из css-live запостили перевод этой статьи, вы извините, но по сравнению с вашим — земля и небо. Сравните сами.
Извините, по этому же поводу вопрос: а маркированные списки в оригинале тоже на самом деле не были HTML-списками? А то читать не очень удобно(
Ежегодный релиз-цикл, необратимые изменения начинают действовать со следующего релиза.

На моей памяти, индустрия постоянно предпринимала попытки избавится от JS. Разработчики разных браузеров то и дело встраивали поддержку других языков, предлагая сообществу лучшие альтернативы. Но эта стратегия ни разу не принесла успеха. Подавляющее большинство продолжало упорно использовать JavaScript. Похоже, что на этот раз решили действовать по-другому, превратив JavaScript в Perl (как показала практика оно потом само дохнет).

Имхо, JS, несмотря на всю свою несуразность и изначальные просчеты, получил такое распространение и популярность благодаря простоте языка, четкому стандарту, не ломающейся годами совместимости и как следствие интероперабельности кода. Все это очень удобно на практике.

Теперь, наряду некоторым набором определенно полезных вещей, в спецификацию вбросили адову кучу синтаксических трюков, что усложняет язык в разы. Снаружи добавилось интсрументирование — трансплитеры уже необходимость. Если они собираются менять и спецификацию каждый год, то скоро эпохе JS придет конец.
Я вообще удивлен, что в браузерах до сих пор не установлена (и главное грамотно открыт доступ к компонентам) песочница с LLVM машиной, тогда разработчики могли бы работать с любым языком… да и с библиотеками, так хочется чтобы они в браузере ставились (загружались) не каждый раз при заходе, а устанавливались из репозитариев, желательно с cdn или с использованием p2p…
Наверняка, о чем-то подобном мечтали и разработчики Sliverlite. Думаю здесь работает эффект «вавилонской башни» (я имею ввиду ту часть этой истории, когда люди говорили на одном языке, а потом их наказали). WEB основан на сравнительно небольшом множестве простых концепций, поддержанных в открытых стандартах. Мне кажется, что в таких масштабах профит от использования единого для всех языка перевешивает все недостатки (даже на сервер js притащили). Мультиязычность неплохо работает в огороженных мирках, но в массе, дробит сообщество и увеличивает хаос.
Именно Microsoft Silverlight был не способом исправить текущую ситуацию с языками, а способ затмить собой Adobe Flash со всеми вытекающими от сюда минусами от монополии.

LLVM полностью открыто, поддерживается сразу несколькими компаниями, УЖЕ имеет поддержку большого количества оборудования и вообще, я не понимаю, почему все на него не переходят дружными рядами.
За исключением редких случаев которые не рекомендовались к использованию (типа блочного определения функций) будет полная обратная совместимость со старыми версиями. Можете продолжать писать хоть на ES3 и дальше. Введенные конструкции отчасти добавляют сахар для упрощения читаемости нового кода, отчасти призваны решить проблемы архитектуры больших приложений.
Жаль, что переменная super определена только в классах. При программировании на прототипах она тоже была бы полезна.
Да, это удобно, хотя тоже всего лишь сахар для обращения к родителю. Сейчас тоже ничто не мешает создать на него ссылку и записать ее в super.
Конечно, можно. Каждый, кому не лень, писал свой велосипед.
Дело в том, что предложенный стандарт выглядит недоделанным. Скажем, переменная this существует всегда, можно заглянуть в спецификацию и узнать, чему она равна в каждом конкретном случае.
А вот super…
Ну в строгом режиме к ней тоже нельзя обращаться всегда, так что ничего страшного — this как и super созданы для работы с классами где их и стоит применять.
Проблема в том, что под капотом — prototype. С классами работать не всегда удобно. Класса у меня вообще может не быть, а super, тем не менее, нужен. Приходится в одном месте использовать нативный, а в другом — самоделку.
Оказывается можно и без класса. Супер будет работать для методов с [[HomeObject]]:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/super
https://learn.javascript.ru/es-object
Большое спасибо за перевод полезного материала)

По теме ES2015 — немного понять для себя лично не могу до сих пор… Есть ли там действительно великие по полезности нововведения? Ну, появились let, const, ну, получили мы новые типы хешей. Синтаксический сахар — это вообще мелочь, хотя и приятно иногда с ним, но крайней необходимости в нём никогда не ощущал. Ну, «классы» теперь есть. Хотя я и раньше просто функцию создавал и запихивал в неё все нужные методы, мало чем от класса в итоге оно отличается.

Так есть ли там что-нибудь из реальных killer features? Может ли кто-нибудь пояснить?)
ИМХО, сделали вещи которые помогут чуть меньше наступать на грабли. Например, хотя бы объявление классов. Для людей из других ЯП код JS с новыми классами будет выглядеть привычней, да и мусора будет немного меньше. Некоторые штуки, пока с ними все не столкнутся — будут вызывать только недоумение, хотя на практике будут делать код короче (я сейчас о fn(...arr), это ведь действительно быстрее, чем fn.apply(this, arr)). Пока я увидел кучу синтаксического сахара, и трудно себе представляю код, который будет им изобиловать (сейчас я не о классах). Для меня он в читабельности несколько потеряет, пока я не освою все мельчайшие нюансы.
Интересно, а есть у разработчиков планы по решению бородатых неточностей JS?
Ну, это выглядит как стандартизация костылей.
К тому же это странно, с одной стороны делать вход в язык для разработчиков проще, а с другой стороны добавлять такой адский синтаксический сахар как в разделах Assignment Destructuring и прочих.
Особенно { foo } выглядит совсем странно.
людей из других ЯП код JS с новыми классами будет выглядеть привычней

Боюсь именно поэтому мусора станет больше, т.к. люди из других ЯП будут ещё реже заглядывать в спецификацию JS.
Киллер фичи в основном в ES2016 есть, но так как мы все дружно пользуемся бабелом — разницы никакой. Сами фичи: async\await, проперти и декораторы

В ES2015 можно полукиллерфичами назвать как минимум import\export, классовые геттеры\сеттеры и генераторы + символ итератор метод.
Так import/export пока нет так как Loader API не определили. Его скорей всего в 2016 добавят.
Map, Set, Proxy, Reflect, Symbols, Promises, subclasses, generators, iterators, tail call optimisation — по моему достаточно киллер фич. Конечно в 2016 добавят намного больше, в том числе асинхронные функции которые помогут писать код в синхронном силе с помощью промисов. Но и 2015 — это большой шаг в нужную сторону (хотя я лично немного сомневаюсь на счет классов).
Обидно, что
let [a, ...rest, b, c, d] = [1, 2, 3, 4, 5, 6, 7, 8];

не работает и нужно его расписывать в 2 хода:
let [a, ...rest] = [1, 2, 3, 4, 5, 6, 7, 8];
let [b, c, d] = rest.splice(-3);


На самом деле не совсем понятно в чем разница при использовании между отсутствием всплытия и наличием ВМЗ. В реализации разница есть, но поведение как мне кажется от этого не меняется.

Определение функций внутри блока всегда было злом, но теперь удивительно, что область их видимости сузили до блока. Это хорошее решение, но оно потенциально может нарушить совместимость старого и нового кода.

В описаниях классов вообще противоречия:
Методы экземпляра new Foo().bar объявляются при помощи упрощенного синтаксиса литералов объекта class Foo { bar () {} }.

при этом такую конструкцию приводят в пример как замену Foo.prototype.bar. Насколько мне известно — верно второе, да и babel записывает данные методы в прототип, а не в экземпляр.
На самом деле работает первый пример, даже несколько… в одном массиве, вот пример:
export function arrayRemove(state:Array, index:Number):Array {
    return [
        ...state.slice(0, index),
        ...state.slice(index + 1, state.length)
    ]
}
export function arrayReplace(state:Array, index:Number, newItem:Object):Array {
    return [
        ...state.slice(0, index),
        newItem,
        ...state.slice(index + 1, state.length)
    ]
}

Даже так можно
На самом деле нет (можете проверить в ff). В вашем примере нет ни диструктивного присваивания ни переменных аргументов функции потому он и работает.
let поднимается в верхнюю часть блока, в то время как var поднимается в верхнюю часть функции.

let не поднимается. Пруф:
In ECMAScript 6, let does not hoist the variable to the top of the block.
UFO landed and left these words here
Ну можно сказать и поднимается, создавая TDZ, это скорее вопрос терминологии :)

if(true){
  typeof x === 'undefined'; // ReferenceError
  let x = 42;
}
UFO landed and left these words here
var {foo: {bar: deep}} = { foo: { bar: 'baz' } } даст вам deep: 'baz'.
наверное меня сейчас заминусуют, но это же ад какой-то. Если такого будет много, как такое можно читать, особенно бегло?
То что есть такая возможность не значит что в таком виде этим будут пользоваться везде и всюду.
По опыту могу сказать что такая запись
let
    { foo, bar, baz } = this.prop;


Читается вполне себе удобно и становится вполне привычной.
это же недоpattern matching, что здесь сложного?
UFO landed and left these words here
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
2009
Location
Израиль
Website
company.plarium.com
Employees
1,001–5,000 employees
Registered