Може да не се наложи да транслирате вашия JavaScript

Популярни ръководства като YouMightNotNeedJQuery.com и Вие не се нуждаете от Lodash / Underscore оспориха обичайните индустриални практики.

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

StatCounter събира данни за около 15+ милиарда показвания на страници всеки месец от 2,5 милиона уебсайта по целия свят. От май 2017 г. това е статуквото:

Нещото, което прави тази диаграма интересна, е, че първите 3 браузъра (Chrome, Safari и FireFox) са вечнозелени,което означава, че 74% от потребителите получават последната версия на своя браузър автоматично.

Нека да видим дали това предположение е вярно.

Ето най-добрите версии на браузъра на пазара:

Chrome 58 беше пуснат преди по-малко от месец и неговата настолна версия заема 12,77% от глобалния пазарен дял на браузъра. Chrome 57 излезе само 42 дни преди това и версията му за настолни компютри заема 9,96% от глобалния пазар на браузъри. За съжаление StatCounter не прави разлика между хромираните версии на мобилни платформи, но приемайки същото съотношение като десктоп, в крайна сметка:

Какво означава това за моя код?

Според таблицата за съвместимост ES най-новата версия на всички основни браузъри има много добра поддръжка за ES6 функции:

С други думи, ако транслирате вашия JavaScript на ES5, вие правите кода си ненужно голям и бавен, за да поддържате малцинство от потребителите, които вероятно ще надстроят системата си до момента, в който успеете да конфигурирате вашия Webpack и Babel! ?

Защо все още бихте транслирали?

Все още може да искате да преведете кода си, но се надяваме след претегляне на минусите и плюсовете или възможните алтернативи:

  • Използвате React JSX (който е доста популярен в момента, така че предполагам, че много разработчици се вписват в тази категория). JSX в основата си е трансформация на XHTML в JS код и не е необходим пълен транспилатор като Babel. Освен това, ако всичко, от което се нуждаете, е VirtualDom, използвайте това вместо това.
  • Искате да изпробвате най-новите функции на езика. Освен ако не сте част от TC39 или не изпитвате горещо желание за инжектиране на нестабилни езикови функции във вашия производствен код, вероятно сте добре с ES6. В днешно време имаме приличен език, тъй като по-голямата част от браузърите и нуждата от транслиране отшумяват.
  • Използвате TypeScript и се надяваме да прецените минусите и плюсовете. Компилаторът на TypeScript, когато насочва към съвременна версия на ES6, предимно премахва информацията за типа, вместо да трансформира синтаксиса.
  • Искате да намалите размера на кода с помощта на разклащане на дървета (ето как можете да го направите в webpack и сборен). Искате да скриете кода си или да намалите размера му чрез минимизиране. Искате условно да изключите част от кода. Това изисква статичен анализ на кода. Можете да използвате интелигентен пакет за чувствителни към размера производствени услуги като мобилни устройства, но ще видим по-внимателни оценки на разходите при създаването на такива алтернативни внедрявания. Този вид статичен анализ на кода ще продължи да бъде полезен като „усъвършенствани техники за оптимизация“ за производствения код.Не е нужно да минимизирате файловете си. UglifyJS не може да минимизира ES6 в момента (въпреки че съществува хармоничен клон), но Babili може да се справи с него. Алгоритмите за компресиране вършат доста прилична работа (не когато файловете са твърде малко) и освен ако не изпращате операционна система при всяко зареждане на страница, тя трябва да се справи добре, без компресия. В наши дни изображенията и мултимедийното съдържание заемат много повече честотна лента от кода.
  • Искате слона в стаята:

NPM е най-големият мениджър на пакети на планетата. Повечето нетривиални уеб приложения използват някакъв код от NPM и това предполага използването на модулен пакет. Това скоро ще се промени! Chrome вече поддържа ES6 модули в Canary (Chrome 60 официално ще достави тази функция този август) и Safari също е близо до нея, докато Firefox и Edge работят по нея.

Освен това HTTP / 2 позволява доброволно изпращане на ресурси към браузъра. Това означава, че ако a.js импортира b.js и c.js , сървърът може да натиска b.js и c.js всеки път, когато a.js бъде извлечен, което минимизира времето между заявките. Това разбира се е опростен изглед, защото на практика браузърът може вече да има b.js и c.js в кеша си. HTTP / 2 се поддържа в повечето браузъри.

Бъдещето без Транспилация

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

Транспилацията е решение. Може би сме го правили твърде дълго, че сме свикнали, но помислете. Ние „съставяме“ „интерпретиран“ език на „интерпретиран“ език! Освен това:

  • Конфигурирането на Webpack / Browserify в много случаи е ненужен данък
  • Отстраняването на грешки с помощта на sourcemaps винаги е по-трудно от отстраняването на грешки в действителния изпълняващ се скрипт (някой се е забавлявал, опитвайки се да отстранява грешки thisили променливи, когато sourcemaps не работят правилно?)
  • Той убива DX, когато трябва да изчакате няколко секунди (понякога половин минута) след всяко редактиране, за да видите най-новия код. Hot Module Reloading (HMR) е отговор на това, но не винаги е плавен и бърз за конфигуриране. Без транслация всичко, което трябва да направите, е да опресните страницата и за по-малко от секунда най-новата ви страница е там!

Този август, когато ES6 модулите се доставят, някои видове приложения изобщо няма да използват транпилация:

  • Разширения за Chrome
  • Настолни приложения на Electron
  • B2B уеб приложения, създадени да се управляват от бизнес потребители, които вече разполагат с добри съоръжения, предоставени от компанията

Когато транспилацията стане нещо от миналото, библиотеките със синтаксис на Hyperscript ще донесат идеите на React към POJS (обикновен стар JavaScript, който не се транслира и лесно може да се отстрани на конзолата).

Не транслирайте, а компилирайте истински!

WASM е новото дете в града и това е официалната цел на компилация, която обещава по-бърза скорост на изпълнение и по-малък размер на кода. Понастоящем Chrome и Firefox поддържат WASM, но има голям консенсус между големите доставчици на браузъри, че WASM ще бъде общото време за работа в бъдеще. Ако имате Chrome, можете да опитате.

Ако сте от разработчиците, които търсят нещо ново, погледнете Rust. Той се компилира в WASM, но не се ограничава до уеб. Хората всъщност го използват, за да пишат операционна система или браузър. Освен старите разработчици C / C ++ разработчиците го одобряват и харесват и има много приветлива общност.

Няколко бележки

  • Според бившия технически директор на Mozilla Chrome е спечелил и е малко вероятно да има нова война в браузъра. Интересното е, че Chrome го спечели с меритокрация . Той е с отворен код и Google ясно е определил каква информация събира от потребителите. Chrome печели дори бизнес потребителите, които традиционно използват Windows. Въпреки това, докато крайните потребители избират Chrome поради неговата скорост, сигурност и простота, програмистите обожават инструментите за разработчици. Google има активна роля в TC39, който движи бъдещето на JavaScript и като цяло е най-силният поддръжник на уеб платформата, въпреки че може да се конкурира със собствената си мобилна операционна система. Не само това, но и Google помага на своите конкуренти. Google е един от най-големите финансови поддръжници на Mozilla и неговият механизъм за рендиране се използва от Opera.
  • Microsoft официално отказа подкрепата за IE преди около 17 месеца. IE 11 ще продължи да получава актуализации на защитата до 2025 г., но от вас зависи да решите дали да харчите значителни ресурси за поддръжка на браузър, който използва само 3,24% от пазара. Също така имайте предвид, че Edge е браузърът по подразбиране в Windows 10. Ако някой не иска да надстрои своя Windows до най-новата версия, скорошната атака WannaCrypt вероятно му дава основание да преразгледат! Аз лично се интересувам от проучване на пазара за приходите, идващи от този конкретен клиентски сегмент.
  • Apple постави набор от несправедливи ограничения, за да задържи останалите доставчици на браузъри извън платформата им iOS. Така например Chrome на iOS е технически ограничен до части от двигателя на Safari! Някога Safari беше новата IE, докато през 2016 г. не свършиха добра работа и се превърнаха в браузър с най-добрата поддръжка на ES6:

Като цяло глобалният дял на iOS / Safari е по-малък от Android / Chrome. Тя се различава в зависимост от държавата, например в по-богатите страни iOS има малко по-голямо проникване, докато в развиващия се свят Android е абсолютен победител, но в световен мащаб ето статистиката:

Призив за действие!

Ако сте достатъчно възрастни, вероятно може би си спомняте досадни дни, когато някои уебсайтове принуждават (или учтиво предлагат) избрания от тях браузър (най-вече IE):

Не искаме да правим това! Колкото и да се вълнуваме от Chrome, не искаме да игнорираме 46% от уеб трафика, който не се визуализира от Chrome.

Само защото скоро може да имаме поддръжка за модули ES6 в браузърите, това не означава, че можем да се отървем от процес на изграждане и правилна „пакетна стратегия“. - Стефан Джудис

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

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

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

БОНУС: Погледнете JS Codeshift. Това е CLI за конвертиране на стария код на javascript в нов код на javascript, като актуализира дори старите извиквания на библиотеки на javascript до най-новия им API. Той се опитва да запази колкото е възможно повече оригиналния стил. Работен поток: след като извършите промените си в контрола на версиите, изпълнете това и направете задълбочено сравнение и стартирайте автоматизираните и ръчни тестове. Свършен!

Актуализация 1 (2017–09–8): Chrome 61 кацна преди няколко дни с пълна поддръжка на модула ES6. Той има 54% от световния пазар на браузъри. Safari (14% от световния пазар) от известно време поддържа ES6 модули.

Актуализация 2 (2017–09–10): все още можете да поддържате браузъри, които не поддържат ES6 модули, благодарение на този трикpt nomodule src = ”compiled.js”> <; / scri pt>. Атрибутът nomodule казва на браузърите с поддръжка на модул ES6 да не зареждат скрипта. В Safari има някои предупреждения, които можете да прочетете на страницата, която говори за трика. Прочетете спецификацията.

Актуализация 3 (2017–09–12): ES6 модулите поддържат земи в браузърите: време ли е да се преосмисли пакетирането?

Актуализация 4 (09.12.2017): модул се отложи червено по подразбиране. Ако искате да го заобиколите, добавете асинхронен атрибут към маркера на скрипта, за да предотвратите Single Point Of Failure (SPOF)

Актуализация 5 (2017–09–13): Node LTS 8.5 поддържа ES6 модули (наречени ESM) зад флаг, когато файлът има разширение * .msj . Ето едно хубаво въведение за това как се използват.

Актуализация 6 (2017-09–22): ето няколко чудесни практически съвета за поддръжка както на нови, така и на стари браузъри. Спестяванията на честотна лента за избягване на транпилация са страхотни!

Актуализация 7 (2018–01–15): Lebab (обратната страна на Babel) има CLI за модернизиране на Javascript от стар стил. Това е малко подобно на CodeShift на Facebook, защото и двамата модернизират стария код.

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