Комментарии 58
Я все-таки пока слабо понимаю, зачем сейчас нужен ES6 на фронте (с нодой вопросов нет) — ведь все равно приходится все конвертировать в 5 версию. Ну окей, какая-то часть нового функционала является просто синтаксическим сахарком и потому засовывается в режим совместимости безболезненно (например, стрелочные функции или let). Но вот классы и их наследование бабель конвертит в какие-то настолько жуткие и уродливые конструкции, что я лучше по старинке напишу.
Вот если бы можно было большинству клиентов подсовывать нативный es6 и только в старые браузеры отдавать бабель-версию, было бы понятно. А так все равно все будут жевать транс-компилированную версию.
Или я что-то не понимаю?
Вот если бы можно было большинству клиентов подсовывать нативный es6 и только в старые браузеры отдавать бабель-версию, было бы понятно. А так все равно все будут жевать транс-компилированную версию.
Или я что-то не понимаю?
Ну это как сравнивать паскаль и дельфи. В одном есть ООП, в другом его можно изобразить. Вроде даже похожие языки, но код в результате совершенно другой, не столько по синтаксису (и это тоже), сколько по стилистике.
Ну вот, для примера, небольшой набросок ActiveRecord на ES2015 (под клиент): https://gist.github.com/SerafimArts/cc85891cffb7c1fd235e
Ну вот, для примера, небольшой набросок ActiveRecord на ES2015 (под клиент): https://gist.github.com/SerafimArts/cc85891cffb7c1fd235e
Я понимаю, в чем достоинства ES6. Я не понимаю, как их сейчас по-нормальному использовать, если даже обладатели самых новых браузеров всё равно будут получать бабель-суррогат.
А исходники зато чистые и красивые.
А как использовать нынче Go, Rust, C#, C++, etc, если даже обладателя самых новых процессоров будут получать ассемблер-суррогат? ;)
А как использовать нынче Go, Rust, C#, C++, etc, если даже обладателя самых новых процессоров будут получать ассемблер-суррогат? ;)
НЛО прилетело и опубликовало эту надпись здесь
Может потому что вероятность протащить 'clojurescript, coffescript, typescript — инструменты' в браузеры нативно намного меньше, чем поддержка ES6?
НЛО прилетело и опубликовало эту надпись здесь
Тут всетрчаются две мысли — зачем «самом модному хипстерскому сервису» поддержка каких-то там старых браузеров и зачему самому наджному древнему энтерпрайзу, все эти модные фишечки esXXXX.
Так что проблема я считаю надуманна, эти два множества никак не пересекаются.
Так что проблема я считаю надуманна, эти два множества никак не пересекаются.
Понимаете, тут фундаментальная проблема в том, что в вебе ВСЕГДА будут старые броузеры.
Таки лёд тронулся же. Тот же Microsoft отошел от именования версий браузеров — будет один Edge обновляемый подобно хрому. Использование старых версий в таком случае получается следованием принципу «сам себе злобный Буратино» — так можно и обновления безопасности, закрывающие дырки продуктов не ставить и потом страдать от того, что ими кто-то воспользовался.
Никогда не говори никогда.
Всегда избегай слова всегда
Всегда избегай слова всегда
Я немного подумал и наконец понял в чём реально вопрос. Если я не угадал — просьба поправить.
Так вот, весь код на ES2015 (и даже ES2016) запросто переводится на ES5, включая даже некоторые API, вроде Map, Set и т.д., которые вроде как входят в спецификацию. Единственная проблема — это Proxy — единственное что невозможно транслировать и пока очень слабо поддерживается даже самыми современными браузерами. В остальном — абсолютно весь код можно запускать на любом браузере, используя все возможности современных версий даже на каких-нибудь относительно старых версиях браузеров (в пределах разумного конечно, не ИЕ6 какой-нибудь, хотя кто знает...).
Так что код бабела можно смело использовать в продакшене уже сейчас, а лет через 5 (надеюсь) можно будет тот же самый код отдавать уже без трансляции без каких-либо его исправлений.
Так вот, весь код на 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 читаемость результата и так не должна доставлять проблем.
Какая разница, что там получает браузер, если оно работает, как задумано? Вся соль в удобстве разработки.
Я сейчас в песочнице просто из головы набрал
Он мне это компильнул в 100+ строк довольно замороченного кода. Я не уверен, что вся эта музыка будет работать так же быстро, как должна была бы при нативной поддержке браузером. Причем это совершенно простенький пример. Что будет с тысячами строк кода?
простенький пример, 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 в том что вы получаете новые фишки языка, которые можете использовать сегодня! в том что вашь код становитсья коротким и понятным с первого взгляда, и.т.д.
смысл использвания ES6 в том что вы получаете новые фишки языка, которые можете использовать сегодня! в том что вашь код становитсья коротким и понятным с первого взгляда, и.т.д.
Нормально все будет и 1000 строк и с 10 000 тысячами, код пишется в первую очередь для людей, поэтому то как он выглядит для машины не имеет ровным счетом никакого значения.
Во вторых, аргумент за производительность вообще не аргумент в этом контексте, я вам дам 100% гарантию что ваше приложение сначала начнет тормозить сначала из-за неправильной работы с дом, потом из за криворукости реализации, потом из за монстрячей конструкции какого нибудь фреймворка, примерно к концу списка тормоза можно будет объяснить вспышками на солнце, но и даже в этом случае тормоза из за кода трансплиттера будут еще далеко.
Во вторых, аргумент за производительность вообще не аргумент в этом контексте, я вам дам 100% гарантию что ваше приложение сначала начнет тормозить сначала из-за неправильной работы с дом, потом из за криворукости реализации, потом из за монстрячей конструкции какого нибудь фреймворка, примерно к концу списка тормоза можно будет объяснить вспышками на солнце, но и даже в этом случае тормоза из за кода трансплиттера будут еще далеко.
Я уже написал выше — используйте loose mode, выхлоп сокращается до 50 с копейками строк, но не гарантируется 100% совместимость со стандартом (правда на практике никаких проблем с этим нет, если не влезать во внутренности реализации).
Если вы там нейросети на JS пишете (это про вашу неуверенность в быстроте), то лучше наверно использовать emscripten.
Добавляется 70 строк общих фукций(если отформатировать), считай runtime, сами классы остаются довольно читабильными и не сильно жиреют. +6 строк в данном примере. Если убрать геттер и включить loose mode — код почти как рукописный, с прототипами и анонимными фукциями.
А зачем пользователям отдавать исходные коды? Сейчас уже практически везде используют средства сборки/минификации скриптов и стилей. Использовать es6 для разработки на JavaScript повышает производительность и удобство разработки.
Попробуйте исследовать лицензии ваших любимых компонент, которые вы используете на javascript (или кстати любом другом скриптовом языке), и вы поймете, что либо вам придется отказываться от них, либо перелицензировать, либо принудительно открывать свои исходники, так как оно почти все GPL (правда часто LGPL или аналог).
p.s. кстати, а использование таких компиляторов из чегототам в javascript разве не освобождает программистов от необходимости выкладывать ИСХОДНЫЙ текст программы, если это требует лицензия на компоненты?
p.s. кстати, а использование таких компиляторов из чегототам в javascript разве не освобождает программистов от необходимости выкладывать ИСХОДНЫЙ текст программы, если это требует лицензия на компоненты?
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, поправила опечатку. Когда буду заливать вторую часть, поправлю весь код по цвету.
Если честно, то перевод у вас, мягко сказать, не очень хороший. Вчера ребята из css-live запостили перевод этой статьи, вы извините, но по сравнению с вашим — земля и небо. Сравните сами.
Извините, по этому же поводу вопрос: а маркированные списки в оригинале тоже на самом деле не были HTML-списками? А то читать не очень удобно(
Ежегодный релиз-цикл, необратимые изменения начинают действовать со следующего релиза.
На моей памяти, индустрия постоянно предпринимала попытки избавится от JS. Разработчики разных браузеров то и дело встраивали поддержку других языков, предлагая сообществу лучшие альтернативы. Но эта стратегия ни разу не принесла успеха. Подавляющее большинство продолжало упорно использовать JavaScript. Похоже, что на этот раз решили действовать по-другому, превратив JavaScript в Perl (как показала практика оно потом само дохнет).
Имхо, JS, несмотря на всю свою несуразность и изначальные просчеты, получил такое распространение и популярность благодаря простоте языка, четкому стандарту, не ломающейся годами совместимости и как следствие интероперабельности кода. Все это очень удобно на практике.
Теперь, наряду некоторым набором определенно полезных вещей, в спецификацию вбросили адову кучу синтаксических трюков, что усложняет язык в разы. Снаружи добавилось интсрументирование — трансплитеры уже необходимость. Если они собираются менять и спецификацию каждый год, то скоро эпохе JS придет конец.
Я вообще удивлен, что в браузерах до сих пор не установлена (и главное грамотно открыт доступ к компонентам) песочница с LLVM машиной, тогда разработчики могли бы работать с любым языком… да и с библиотеками, так хочется чтобы они в браузере ставились (загружались) не каждый раз при заходе, а устанавливались из репозитариев, желательно с cdn или с использованием p2p…
Наверняка, о чем-то подобном мечтали и разработчики Sliverlite. Думаю здесь работает эффект «вавилонской башни» (я имею ввиду ту часть этой истории, когда люди говорили на одном языке, а потом их наказали). WEB основан на сравнительно небольшом множестве простых концепций, поддержанных в открытых стандартах. Мне кажется, что в таких масштабах профит от использования единого для всех языка перевешивает все недостатки (даже на сервер js притащили). Мультиязычность неплохо работает в огороженных мирках, но в массе, дробит сообщество и увеличивает хаос.
Именно Microsoft Silverlight был не способом исправить текущую ситуацию с языками, а способ затмить собой Adobe Flash со всеми вытекающими от сюда минусами от монополии.
LLVM полностью открыто, поддерживается сразу несколькими компаниями, УЖЕ имеет поддержку большого количества оборудования и вообще, я не понимаю, почему все на него не переходят дружными рядами.
LLVM полностью открыто, поддерживается сразу несколькими компаниями, УЖЕ имеет поддержку большого количества оборудования и вообще, я не понимаю, почему все на него не переходят дружными рядами.
За исключением редких случаев которые не рекомендовались к использованию (типа блочного определения функций) будет полная обратная совместимость со старыми версиями. Можете продолжать писать хоть на ES3 и дальше. Введенные конструкции отчасти добавляют сахар для упрощения читаемости нового кода, отчасти призваны решить проблемы архитектуры больших приложений.
Жаль, что переменная super определена только в классах. При программировании на прототипах она тоже была бы полезна.
Да, это удобно, хотя тоже всего лишь сахар для обращения к родителю. Сейчас тоже ничто не мешает создать на него ссылку и записать ее в super.
Конечно, можно. Каждый, кому не лень, писал свой велосипед.
Дело в том, что предложенный стандарт выглядит недоделанным. Скажем, переменная this существует всегда, можно заглянуть в спецификацию и узнать, чему она равна в каждом конкретном случае.
А вот super…
Дело в том, что предложенный стандарт выглядит недоделанным. Скажем, переменная this существует всегда, можно заглянуть в спецификацию и узнать, чему она равна в каждом конкретном случае.
А вот super…
Ну в строгом режиме к ней тоже нельзя обращаться всегда, так что ничего страшного — this как и super созданы для работы с классами где их и стоит применять.
Большое спасибо за перевод полезного материала)
По теме ES2015 — немного понять для себя лично не могу до сих пор… Есть ли там действительно великие по полезности нововведения? Ну, появились let, const, ну, получили мы новые типы хешей. Синтаксический сахар — это вообще мелочь, хотя и приятно иногда с ним, но крайней необходимости в нём никогда не ощущал. Ну, «классы» теперь есть. Хотя я и раньше просто функцию создавал и запихивал в неё все нужные методы, мало чем от класса в итоге оно отличается.
Так есть ли там что-нибудь из реальных killer features? Может ли кто-нибудь пояснить?)
По теме ES2015 — немного понять для себя лично не могу до сих пор… Есть ли там действительно великие по полезности нововведения? Ну, появились let, const, ну, получили мы новые типы хешей. Синтаксический сахар — это вообще мелочь, хотя и приятно иногда с ним, но крайней необходимости в нём никогда не ощущал. Ну, «классы» теперь есть. Хотя я и раньше просто функцию создавал и запихивал в неё все нужные методы, мало чем от класса в итоге оно отличается.
Так есть ли там что-нибудь из реальных killer features? Может ли кто-нибудь пояснить?)
ИМХО, сделали вещи которые помогут чуть меньше наступать на грабли. Например, хотя бы объявление классов. Для людей из других ЯП код JS с новыми классами будет выглядеть привычней, да и мусора будет немного меньше. Некоторые штуки, пока с ними все не столкнутся — будут вызывать только недоумение, хотя на практике будут делать код короче (я сейчас о fn(...arr), это ведь действительно быстрее, чем fn.apply(this, arr)). Пока я увидел кучу синтаксического сахара, и трудно себе представляю код, который будет им изобиловать (сейчас я не о классах). Для меня он в читабельности несколько потеряет, пока я не освою все мельчайшие нюансы.
Интересно, а есть у разработчиков планы по решению бородатых неточностей JS?
Интересно, а есть у разработчиков планы по решению бородатых неточностей JS?
Ну, это выглядит как стандартизация костылей.
К тому же это странно, с одной стороны делать вход в язык для разработчиков проще, а с другой стороны добавлять такой адский синтаксический сахар как в разделах Assignment Destructuring и прочих.
Особенно { foo } выглядит совсем странно.
К тому же это странно, с одной стороны делать вход в язык для разработчиков проще, а с другой стороны добавлять такой адский синтаксический сахар как в разделах Assignment Destructuring и прочих.
Особенно { foo } выглядит совсем странно.
людей из других ЯП код JS с новыми классами будет выглядеть привычней
Боюсь именно поэтому мусора станет больше, т.к. люди из других ЯП будут ещё реже заглядывать в спецификацию JS.
Киллер фичи в основном в ES2016 есть, но так как мы все дружно пользуемся бабелом — разницы никакой. Сами фичи: async\await, проперти и декораторы
В ES2015 можно полукиллерфичами назвать как минимум import\export, классовые геттеры\сеттеры и генераторы + символ итератор метод.
В ES2015 можно полукиллерфичами назвать как минимум import\export, классовые геттеры\сеттеры и генераторы + символ итератор метод.
Map, Set, Proxy, Reflect, Symbols, Promises, subclasses, generators, iterators, tail call optimisation — по моему достаточно киллер фич. Конечно в 2016 добавят намного больше, в том числе асинхронные функции которые помогут писать код в синхронном силе с помощью промисов. Но и 2015 — это большой шаг в нужную сторону (хотя я лично немного сомневаюсь на счет классов).
Обидно, что
не работает и нужно его расписывать в 2 хода:
На самом деле не совсем понятно в чем разница при использовании между отсутствием всплытия и наличием ВМЗ. В реализации разница есть, но поведение как мне кажется от этого не меняется.
Определение функций внутри блока всегда было злом, но теперь удивительно, что область их видимости сузили до блока. Это хорошее решение, но оно потенциально может нарушить совместимость старого и нового кода.
В описаниях классов вообще противоречия:
при этом такую конструкцию приводят в пример как замену Foo.prototype.bar. Насколько мне известно — верно второе, да и babel записывает данные методы в прототип, а не в экземпляр.
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)
]
}
Даже так можно
let поднимается в верхнюю часть блока, в то время как var поднимается в верхнюю часть функции.
let не поднимается. Пруф:
In ECMAScript 6, let does not hoist the variable to the top of the block.
var {foo: {bar: deep}} = { foo: { bar: 'baz' } } даст вам deep: 'baz'.наверное меня сейчас заминусуют, но это же ад какой-то. Если такого будет много, как такое можно читать, особенно бегло?
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор ES6 в 350 пунктах. Часть первая