Кто-то использует EcmaScript 6?

Чистое любопытство.

Уже полгода где-то мониторю вакансии на предмет использования современной версии спецификации, тем более babel.js большую часть новых фич реализует. А сама 6 версия (оооочень много вкусностей и удобств, смотрите на хабре — отличные живые статьи) уже зарелизена и не будет меняться — вроде как, смело используйте.

Вот и вопрос: используете ли, а если осознанно не используете(а не потому что уже существующий проект лучше на старой версии писать, лишь бы не делать винегрет) — то почему не используете?

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Сперва хотел создать тему про ECMAScript, но потом подумал — дай-ка поищу, может уже есть тема подобная той, насчет которой хотел спросить, и нашел данный топик от 2015 года (да, некропостинг, но новую тему создавать по моему вопросу как-то влом).
В общем вопрос заключается в следующем:

Какой стандарт ECMAScript’а юзают большинство JS-разрабов в 2019-2020 г.? ES6? Или более новые (ES2016, ES2017, ES2018, ESNext...)? Или пофиг какая именно версия ECMAScript, если есть туториалы по популярным фреймворкам и либам, тайпскрипт и babel с разными вебпаками?

Что хотят то и юзают.
Никто никого ни в чем не ограничивает.
И это прелестно.

пофиг какая именно версия ECMAScript, если есть туториалы по популярным фреймворкам и либам, тайпскрипт и babel с разными вебпаками

^ this

Вообще как-то не сильно задумываюсь фичи какой версии использую. Если есть нужда тестирую в Edge/IE

все уже давно на тайпскрипте пишут

Или более новые (ES2016, ES2017, ES2018, ESNext...)?

уже ж перешли на новый подход с 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 пока не трогал

нравятся arrow functions
Непривычно смотрятся они

в спецификации ECMAScript 2015 разве нет?

собеседовался на вакансию где требуются знания es6 с использованием babel.js. так что уже ищут таких специалистов. на практике — для собственного проекта использую и на каком то этапе он станет в продакшен в будущем. не использую на работе потому что уже куча кода по старому написана, чтобы начать использовать надо много усилий приложить, чтобы все перепроверить. но к этому всё идет.

требуются знания es6
Не думаю что реально требуются. Просто засунули в вакансию новенькое-модное. Имхо.

кстати самое крутое крутое это предложенный в ES7 async/await
и traceur их поддерживает
ну это по субъективным ощущениям

«самое радикальное» — вы хотели сказать? :)
как и yield с генераторами-итераторами — оно мощное, но слишком свежее еще. нужен глаз да глаз за кодом с этими штуками, легко выстрелить себе в ногу.

а самое удобное — то, что легко ложится на синтаксис и не меняет концепцию.
деструктуризация и механизмы по работе с аргументами функции, например.

деструктуризация и механизмы по работе с аргументами функции
+100500 :)

1. меняешь сборщик модулей с requirejs/browserify на webpack
2. подключаешь loader для es6
3. пишешь все новые модули на es6
4. ????
5. PROFIT

Да, использую немного в пет-проджектах.

3. пишешь все новые модули на es6
та нууу. каша ж будет.
только не говори, что у тебя модули настолько изолированы друг от друга, что даже друг-друга не вызывают :)

Нет, конечно, они подключаются через лоадер:

var myModule = require('babel!path/to/myModule.es6');
и на момент сборки вебпак, перед тем как вписать myModule в общий bundle.js просто скомпилит его бабелем из es6 в es5.

Таким образом можно использовать хоть es6, хоть jsx, хоть, прастихоспади, coffeescript — лишь бы лоадер нужный был.
По сути стадия компиляции в обычный es5 будет проходит не отдельной таской в галпе/гранте, а в момент подключения модуля. :)

та ну.
я о другом.
несколько подходов в пределах одного проекта.
конечно, технически это решается легко.
но тут та же проблема, что и, например, использовать в параллель less и sass, или .bind/$.proxy/_.bind → мешанина подходов ухудшает читаемость и понимаемость.

Если правильно подходить к этому вопросу — ничего не мешается.

Для маленького проекта — да — может быть неоправданно, когда тебе самому часто придется скакать между модулями, написанными в разном формате, чуть дольше врубаться что здесь написано и допиливать.

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

о, кста, была одна живая вакансия в Киеве с указанием babeljs в качестве «желательно иметь опыт».
что круто.

В пет проекте ))) ароу функция зло

Они сохраняют не явно контекст, а инода это то чего не хочешь, что иногда усложняет работу. Но если юзать для чистого мап редюс то конечно гуд

к’мон, разве они не ради этого самого и были вточены? :)
в литеральной форме записи объекта, например, есть короткая форма указания метода: без двоеточия, что даже лаконичнее arrow-функции.
ну, я про
{ someMethod() { return this.a + this.b; } }
плюс, arrow-функция нормально читается только пока умещается в одну строку, если там какая-то сложная логика, отсутствие явных скобок сыграет плохую службу. согласны?

чистого мап редюс
пожалуй, список побольше: filter/sort/map/reduce

ваш пример это не арроу функция, зло начинается след. образом:

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.
скажу что это можно контролировать пока один на проект, а когда 10+ разработчиков на проекте
ну, я даже подход предлагаю: более одной строки — не использовать arrow-функции :)

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

окей, а что бы вы изменили?
зачем вам вообще использовать арроу вместо обычной анонимной?

Какие альтернативы в JS?

1. параметры. те же event handler’ы получают объект event, в котором запросто добраться до текущего элемента
2. подмена контекста через .bind/.apply/.call

Это был риторический вопрос. Все предложеное — хаки, так или иначе. Ну, или я их так воспринимаю. Такая модель неймспейсов, что поделать.

bind нормально, не хак.

Как по мне наилучший вариант это .bind

как замена var that = this; — да, согласен

ну не совсем, конечно при очень корявом подходе можно его добится, но это по сути не из-за этой конструкции будет, а потому что отсутствуют знания по GC

само по себе, из-за использования переменной через замыкание — нет.
в этом плане конструкция «$.proxy(obj.methodName, obj)» настолько же мемори-лико-опасная

Нет. Скорее, просто некрасивый подход

Подписаться на комментарии