Кто-то использует EcmaScript 6?
Чистое любопытство.
Уже полгода где-то мониторю вакансии на предмет использования современной версии спецификации, тем более babel.js большую часть новых фич реализует. А сама 6 версия (оооочень много вкусностей и удобств, смотрите на хабре — отличные живые статьи) уже зарелизена и не будет меняться — вроде как, смело используйте.
Вот и вопрос: используете ли, а если осознанно не используете(а не потому что уже существующий проект лучше на старой версии писать, лишь бы не делать винегрет) — то почему не используете?
54 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівСперва хотел создать тему про ECMAScript, но потом подумал — дай-ка поищу, может уже есть тема подобная той, насчет которой хотел спросить, и нашел данный топик от 2015 года (да, некропостинг, но новую тему создавать по моему вопросу как-то влом).
В общем вопрос заключается в следующем:
Какой стандарт ECMAScript’а юзают большинство JS-разрабов в2019-2020 г.? ES6? Или более новые (ES2016, ES2017, ES2018, ESNext...)? Или пофиг какая именно версия ECMAScript, если есть туториалы по популярным фреймворкам и либам, тайпскрипт и babel с разными вебпаками?
Что хотят то и юзают.
Никто никого ни в чем не ограничивает.
И это прелестно.
^ this
Вообще как-то не сильно задумываюсь фичи какой версии использую. Если есть нужда тестирую в Edge/IE
ясно) будем знать)
все уже давно на тайпскрипте пишут
уже ж перешли на новый подход с TC’39 proposals. Нет смысла в громких версиях, если все равно браузеры не поддерживают все-все-все фичи стандарта.
по вопросу — я бы предложил юзать штуки не ниже Stage 3(чтоб сама спека гарантированно стабильная), с обязательным вебпаком для начала.
на odessajs решил потроллить человека из EPAM(вроде, так, на 100% не уверен, а в программе — не указаны «сессии спонсоров»), который сказал, что у них используются самые новые технологии. спросил, юзают ли Babel с ES6. Человек сказал, что юзают. Если будете собеседоваться — спрашивайте, чем черт не шутит :)
Алсо на реддите тоже озадачились вопросом «так, может, пора уже?»
www.reddit.com/...or_serious_use_so_that_i
Кстати, есть видео с одессаджс?
без понятия. я там лично был, незачем мониторить видео :)
Используем в Amadeus, недавно перешли с requirejs на webpack с babel-loader’ом в уже существующем большом проекте. Даже если не брать во внимание новый синтаксис, будет полезно www.2ality.com/...il-call-optimization.html , если например активно использовать подход ФП
оу, пропустил, когда это авторы запилили в траслятор. невероятно!
Такой вот мастер-класс будет еще 12 сентября:
dou.ua/calendar/8051
Да, используем.
Пробую чуть-чуть, с ember-cli. Но пока мало, не изучал всех фич ещё.
пам’ятаю в softserve один senior .net розробник node.js назвав «хіпстерською штукою» ))
по темі: поки не використовую, але по троху розбираюся. Натівно ж браузери близько 50% ± 15% лише підтримували, от як дойдуть до 100% тоді й вакансії будуть імхо :).
Руби тоже считается для хипстеров
а где можно полный список посмотреть?
приобщиться, так сказать.
в курилках, где завсегдатые Java/C# Developer’ы
на последнем проекте использовал только на клиенте, а на текуще использую и на сервере и на клиенте, особенно нравятся arrow functions, let и то, что можно не писать function для функций обьекта
{ someFunction () { } }использование генераторов для работы с асинхронностью пока избегаю, мне это кажется костылем, а async/await пока не трогал
в спецификации ECMAScript 2015 разве нет?
собеседовался на вакансию где требуются знания es6 с использованием babel.js. так что уже ищут таких специалистов. на практике — для собственного проекта использую и на каком то этапе он станет в продакшен в будущем. не использую на работе потому что уже куча кода по старому написана, чтобы начать использовать надо много усилий приложить, чтобы все перепроверить. но к этому всё идет.
кстати самое крутое крутое это предложенный в ES7 async/await
и traceur их поддерживает
ну это по субъективным ощущениям
«самое радикальное» — вы хотели сказать? :)
как и yield с генераторами-итераторами — оно мощное, но слишком свежее еще. нужен глаз да глаз за кодом с этими штуками, легко выстрелить себе в ногу.
а самое удобное — то, что легко ложится на синтаксис и не меняет концепцию.
деструктуризация и механизмы по работе с аргументами функции, например.
1. меняешь сборщик модулей с requirejs/browserify на webpack
2. подключаешь loader для es6
3. пишешь все новые модули на es6
4. ????
5. PROFIT
Да, использую немного в пет-проджектах.
только не говори, что у тебя модули настолько изолированы друг от друга, что даже друг-друга не вызывают :)
Нет, конечно, они подключаются через лоадер:
и на момент сборки вебпак, перед тем как вписать myModule в общий bundle.js просто скомпилит его бабелем из es6 в es5.Таким образом можно использовать хоть es6, хоть jsx, хоть, прастихоспади, coffeescript — лишь бы лоадер нужный был.
По сути стадия компиляции в обычный es5 будет проходит не отдельной таской в галпе/гранте, а в момент подключения модуля. :)
та ну.
я о другом.
несколько подходов в пределах одного проекта.
конечно, технически это решается легко.
но тут та же проблема, что и, например, использовать в параллель less и sass, или .bind/$.proxy/_.bind → мешанина подходов ухудшает читаемость и понимаемость.
Если правильно подходить к этому вопросу — ничего не мешается.
Для маленького проекта — да — может быть неоправданно, когда тебе самому часто придется скакать между модулями, написанными в разном формате, чуть дольше врубаться что здесь написано и допиливать.
Для большого, когда над разными кусками проекта работают разные люди — подойдет. Пару раз в спринт на код ревью посмотрел код, чтобы оставаться в курсе и дальше за свой станок.
о, кста, была одна живая вакансия в Киеве с указанием babeljs в качестве «желательно иметь опыт».
что круто.
Я вот эту нашел:
jobs.dou.ua/...s/youscan/vacancies/1730
дааа, вот эти ребята ©
В пет проекте ))) ароу функция зло
а что с ней не так?
Они сохраняют не явно контекст, а инода это то чего не хочешь, что иногда усложняет работу. Но если юзать для чистого мап редюс то конечно гуд
к’мон, разве они не ради этого самого и были вточены? :)
пожалуй, список побольше: filter/sort/map/reduceв литеральной форме записи объекта, например, есть короткая форма указания метода: без двоеточия, что даже лаконичнее arrow-функции.
ну, я про
{ someMethod() { return this.a + this.b; } }плюс, arrow-функция нормально читается только пока умещается в одну строку, если там какая-то сложная логика, отсутствие явных скобок сыграет плохую службу. согласны?
ваш пример это не арроу функция, зло начинается след. образом:
this.data = {..}; cmp.on('event', () => { ..... var valueFromClosureScope = this.data; .... });выглядет сперва удобно. и допустим есть несколько таких хендлеров, но допустим нам нужен таки скоуп на котором стригерен, а для этого ароу функция не сработает, и нам нужна анонимная, функцияthis.data = {..}; cmp.on('event', function () { ..... var valueFromCmp = this.dataFromCmp; .... });а теперь посмотрите внимательна на оба примера, и станет очевидно что проблемы со скоупом станут еще слегка не очевиднеена ваше замечание что они не для того предназначались, скажу что это можно контролировать пока один на проект, а когда 10+ разработчиков на проекте, и каждый меняет код на свое усмотрение (зависит от скила), то по факту будет тяжко, и код ревью далеко не всегда спасает
P.S. лично мне из ES6 больше всего понравились String templates, этого действительно мегаудобно, ибо конкатенация от лукавого (особенно после String templates))))
ну, я даже подход предлагаю: более одной строки — не использовать arrow-функции :)
тогда это делать лучше на уровне статического анализатора кода, и прекомит хуком.
а вообще мы тут обсуждаем ограничения нового стандарта, который должен был сделать язык более удобным, но как по мне ароу функции вносят неоднородность поведения... (((
окей, а что бы вы изменили?
зачем вам вообще использовать арроу вместо обычной анонимной?
var that = this — зло
Какие альтернативы в JS?
1. параметры. те же event handler’ы получают объект event, в котором запросто добраться до текущего элемента
2. подмена контекста через .bind/.apply/.call
Это был риторический вопрос. Все предложеное — хаки, так или иначе. Ну, или я их так воспринимаю. Такая модель неймспейсов, что поделать.
bind нормально, не хак.
Как по мне наилучший вариант это .bind
как замена var that = this; — да, согласен
объясните почему это зло?
memory leak?
ну не совсем, конечно при очень корявом подходе можно его добится, но это по сути не из-за этой конструкции будет, а потому что отсутствуют знания по GC
само по себе, из-за использования переменной через замыкание — нет.
в этом плане конструкция «$.proxy(obj.methodName, obj)» настолько же мемори-лико-опасная