Наскоро написах статия за ES6 Tips and Tricks, която има над 17 000 гледания и 4600 пляскания. Един коментар беше от Боб Мунк, който каза, че:

Тази статия представя много силен аргумент за избягване на JavaScript като чума при всяка употреба, при която искате дългосрочна надеждност, поддръжка и възможност за модифициране.

Неговото мнение изглежда е, че ако езикът се променя толкова, колкото е, той подписва собствената си смъртна присъда.

Какво добавят ES6, 7 и 8 към JavaScript

Най-новите спецификации добавят много нови функции към езика. Деструктуриране, кратко присвояване на обекти и символи, за да назовем само няколко. Има някои добри неща, но тази статия има за цел да подчертае проблемите.

Защо това е проблем?

Искате да създадете функция, която да получава обект и да прави някаква логика върху него. Просто нали? Но по какъв начин ще го направите?

var data = { a: "print me" };
function method1(data) {
    var a = data.a;
    console.log(a);
}
function method2(data) {
    console.log(data.a);
}
function method3({ a: info }) {
    console.log(info);
}
function method4({ a }) {
    console.log(a);
}

Всички тези методи ви дават абсолютно същия резултат. Това е много тривиален пример, но важи за много по-сложни функции.

Как да решим какво да използваме?

Има 3 основни метода за решаване по какъв начин да направите това:

  • Оценете и сравнете наличните опции.
  • Просто използвайте каквото искате.
  • Имайте политика за това къде да използвате.

Всеки от тях има своите предимства и недостатъци.

Оценете и сравнете наличните опции

Това изглежда като очевиден избор, но дали е най-добрият? Правенето на това всеки път означава, че трябва да оценявате предимствата и недостатъците на всеки метод ВСЕКИ ПЪТ, когато пишете функция. Това е много мисловна сила, която може да се използва за проблема, който се опитвате да разрешите.

Вие и всички, с които работите, трябва да знаете предимствата, недостатъците и нюансите на всеки метод. Това не изглежда много лошо, има само 4, но тогава какво ще кажете за справянето с асинхронното поведение? Използвате ли обратни извиквания, обещания, генератори или Async/Await или комбинация от тях?

Това означава, че всеки, с когото работите, трябва да разбира всяка част от езика. Предполагам от броя на прегледите на моята статия за ES6, че много хора все още учат някои от по-основния езиков синтаксис. Това означава, че има много малко хора, които разбират сложността на асинхронното поведение (което в момента се опитвам да разбера добре).

Просто използвайте каквото искате

Това е най-често срещаният подход за физически лица и компании. Това може да е чудесно, тъй като означава, че не губите време и усилия за изчисляване на най-добрия избор.

Проблемите могат да възникнат, когато някой друг дойде да прочете или поправи вашия код. Може да сте майстор на JavaScript и да знаете всички най-нови методи за всичко. Но следващият човек, който дойде да прочете или промени работата ви, може да няма представа какво сте направили.

Това също насърчава огромни стилови различия между компании и колеги. Това може също да означава различия между вас и бъдещия вас, когато научите нов синтаксис. Това не е страхотно и прави четенето на код, написан от множество разработчици, много по-трудно.

Политика

Независимо дали става въпрос за фирмена или лична политика, това елиминира много от проблемите с първите два подхода. Не изисква мислене и насърчава последователността в кодовата база. За съжаление все още има няколко проблема.

С новите версии на спецификациите на ECMAScript, които редовно излизат, възниква дилема. Трябва ли компанията да промени политиката си, за да бъде в съответствие с най-новите версии? Или напишете политика и никога не я променяйте - пропускате новите функции? Или трябва да е някъде по средата?

Новоназначените трябва да научат политиката и да знаят как да я използват. Да, можете да имате брошура за правилата, но може да отнеме повече време, за да намерите спецификацията, отколкото да напишете реда код. Дори ако открият правилата за асинхронно поведение, те трябва да могат да го използват. Това може да доведе до потискане на младши разработчици до просто кодиране, тъй като те не искат да нарушат правилата, ограничавайки масово техния растеж.

Какво наистина предоставя ES6+?

Каква е истинската разлика между примерите, които дадох по-горе? Новият синтаксис по-лесен ли е за четене или предоставя ли някаква допълнителна функционалност?

техните предложения трябва да {направят} с намаляване на натисканията на клавиши и добавяне на трикове, които са „чисти“.

Наистина не виждам голяма полза, ако има такава, от използването на деструктуриране или сбит синтаксис на обект, освен запазването на натискания на клавиши. Може да има предимства в производителността или някаква специална магия, която не знам или разбирам, но:

„Нито една от тези разлики в производителността няма никакво значение! — YDKJS»

Този цитат е някак изваден от контекста, така че ще обясня. Да предположим, че метод X изпълнява 1 000 000 операции/секунда, а метод Y изпълнява 500 000 операции/секунда. Това означава, че X е два пъти по-бърз от Y. Норазликата във времето на работа е само 1 микросекунда. Това е 100 000 пъти по-бавно от това, което човешкото око може да възприеме. Така че никаква разлика в производителността няма никакво значение!

Спестяванията, направени чрез използване на различни методи, вероятно ще бъдат толкова малки, че няма значение. Ако се опитвате да напишете възможно най-бързия код, защо го пишете в JavaScript?

Какво предоставя и ES6

Объркване, сложност и опции.

По-късно в дискусията с Боб той каза това за JavaScript:

Трябва да го декодирате, за да разберете какво прави. Синтаксисът и семантиката на езика са сложни, заплетени, заплетени. Програмистите, които отстраняват грешки, поддържат, подобряват и преработват вашия код на следващия ден или десетилетие по-късно, ще имат проблеми с разбирането му. Те ще се чудят дали нещо, което сте направили, е било невероятно умно или невероятно глупаво.

Това е толкова вярно за мен. Открих, че разглеждам кода, който съм написал, озадачен да разбера какво съм направил и защо съм го направил. Въпреки че можете да пишете сложен и объркващ код на всеки език, JavaScript ви дава много възможности да се измъкнете.

Направих това на себе си в статията за ES6. От 4000 души, които прочетоха цялата статия, само 5 успяха да намерят грешката ми, преди да я коригирам. Кое от тези е правилно?

let person = { 
    name: "John", 
    age: 36, 
    job: { company: "Tesco", role: "Store Assistant"}
}
function methodA({ name: driverName, age, job.company: company}){ ... }
function methodB({ name: driverName, age, job: { company }){ ... }

Използвах грешния и повечето хора не забелязаха. Само малцината, които го пробваха, успяха да открият грешката.

Какво всъщност осигуряват тези два метода, за да оправдаят допълнителното объркване и сложност? Много хора могат да четат, пишат и разбират функция като тази:

function methodC(person){
    var driverName = person.name,
        age = person.age,
        company = person.job.company;
    ...
}

Да, трябваше да напиша 32 допълнителни знака, но тъй като по-голямата част от програмирането е мислене, а не писане, спестяваме ли време за писане само за да прекараме повече от него в мислене?

Това не е само допълнителното време, което авторът прекарва в мислене за това, това е всеки човек, който чете този код след тази точка (често авторът отново). Сложният код има „данък мислене“ всеки път, когато се чете, а ние, като хора, разполагаме само с ограничен запас от мисловна сила всеки ден.

Не всичко е лошо

Въпреки че изглежда, че тази статия разглежда ES6, има някои неща, които увеличават четливостта и поддръжката. Обещанията, асинхронните функции и async/await помагат да се абстрахират сложностите на асинхронното поведение, правейки кода по-логичен и по-лесен за четене. Това е, върху което вярвам, че трябва да се съсредоточим, а не трикове за спестяване на клавиши.

Дългосрочни ефекти

Въпреки че това вероятно няма да има значение за вас като разработчик, компаниите с много разработчици може да почувстват въздействието. Трябва първо да разберете какво прави синтаксисът, преди да разберете какво прави кодът, което води до ненадежден и неподлежащ на поддръжка код.

Това може да доведе до загуба на благоволението на JavaScript за всичко, което е голямо, сложно, критично или развиващо се. Това би бил огромен пазар, на който JavaScript да загуби.

Резюме

  • ES6 ни дава още повече начини да изпълним същата задача.
  • Можете да изчислите кое е най-добро, да правите каквото искате или да имате политика за това.
  • ES6 ни дава нови трикове, за да спестим някои натискания на клавиши.
  • Тези нови трикове увеличават сложността и шансовете за грешка, като същевременно намаляват четливостта.
  • Има някои добри части от ES6, които увеличават четливостта.
  • Възможно ли е увеличената сложност и намалената четливост да накарат компаниите да го използват по-малко в сложни, критични или постоянно развиващи се решения?

Какво мислиш? Уведомете ме в коментарите. Ако ви е харесало, пляскайте го и ме последвайте за още статии с JavaScript.