Эта статья была рецензирована Томом Греко , Дэном Принсом и Мэллори ван Ачтербергом . Спасибо всем рецензентам SitePoint за то, что сделали контент SitePoint как можно лучше!
У JavaScript как языка есть некоторые фундаментальные недостатки — я думаю, что большинство из нас согласны с этим. Но у каждого свое мнение о недостатках.
Кристоффер Петтерсон недавно написал, что « JavaScript просто должен стать лучшим языком » — о недостатках стандартной среды выполнения JavaScript и о том, как это создает культуру микропакетов и полизаполнений.
В этой связанной статье я бы хотел оспорить эту точку зрения:
Недостатки языка JavaScript и времени выполнения не являются основной причиной, по которой у нас есть микропакеты или полизаполнения.
В то время как различные недостатки стандартной библиотеки времени выполнения являются очевидной и непосредственной причиной создания микропакетов, я собираюсь утверждать, что эта точка зрения фактически затеняет более глубокую, основную проблему.
Что касается мнений о недостатках самого языка или о стандартных временах исполнения, важно понимать, что у каждого разработчика свой опыт, свой опыт, разные потребности, темперамент, ценности и множество других культурных мотивов и проблем — индивидуальные мнения всегда будут в значительной степени личными и, в некоторой степени, нетехническими по своему характеру.
Для меня лучшим ответом на недостатки самого языка был Typescript, но я понимаю, что это не все чаепития. Для одного парня это CoffeeScript, для другого — Dart, Scala, Go, Rust и так далее.
Моя точка зрения такова: фундаментальная проблема заключается не в недостатках стандартной библиотеки времени выполнения и в особых технических недостатках самого языка.
Настоящая проблема заключается в том, что мы не готовы принять культурное разнообразие.
Один размер не подходит для всех
Кажется, что существует массовое заблуждение, что мы можем каким-то образом сделать JavaScript идеальным языком для всех и каждого.
Такие инициативы, как ES6, хотя, казалось бы, улучшают ситуацию, на самом деле являются шагом в неверном направлении.
Например, те, кто предпочитает классическое наследование, могут получить удовольствие от добавления ключевого слова class, в то время как другие могут отклонить его как противоречащее идее прототипной модели наследования.
Опять же, все это основано на мнении, и из-за огромного количества разработчиков, которые полагаются на эту технологию, поскольку их хлеб и масло, суб-сообщества и религиозность формируются вокруг шаблонов, анти-шаблонов, практик, стандартов де-факто, микро пакеты, полифилы, рамки, инструменты для сборки и т. д.
Меньше — больше
JavaScript, к настоящему времени, достаточно повсеместен, чтобы затронуть буквально каждого программиста в индустрии программного обеспечения — индустрии программного обеспечения, которая исторически не известна своей способностью быстро и единодушно соглашаться, ну, во всяком случае.
Проблема, на мой взгляд, в первую очередь не техническая, а культурная.
Что нам действительно нужно, так это не очередная итерация языка или среды выполнения, а освобождение от вынужденной идеи «универсального» языка и среды выполнения.
Другими словами, нам нужно стандартизировать вещи на более низком уровне. Нам нужно выяснить, с чем мы можем согласиться, и избегать личных и деликатных мнений о языковых деталях и функциях времени выполнения.
Нам нужно стандартизировать чашку Петри, а не всю культуру.
На мой взгляд, это означает одну из двух вещей:
- Мы стандартизируем конечное подмножество JS (например, asm.js ) — и избегаем бесконечной борьбы через будущие итерации языка JavaScript, конкурирующие супер-наборы и транспортеры, или
- Мы корректируем нашу точку зрения и соглашаемся принять JavaScript таким, какой он есть, но начинаем думать о нем как о виртуальной машине для других языков.
Последнее уже изучалось, в некотором роде, в течение нескольких лет, но далеко не настолько, чтобы исключить необходимость использования JavaScript как языка, с которым вы должны научиться жить, независимо от того, подходит он вам или нет.
Несмотря на растущее разнообразие языков, которые компилируются в JavaScript, сам язык остается доминирующим языком как в клиентских, так и в серверных экосистемах для веб-разработки. Идея замены JavaScript на языки, компилируемые в JavaScript, была исследована, и по каким-то причинам она никого не освободила от JavaScript.
Это оставляет первый вариант: уменьшить масштабы проблемы. Упростить.
По иронии судьбы то, что мы делаем сегодня, по сути является противоположным: вместо того, чтобы уменьшить масштаб проблемы, мы продолжаем ее наращивать, эффективно увеличивая количество деталей и проблем для всех.
Два шага вперед, три шага назад
Несмотря на такие инициативы, как ES6, в конце концов некоторые вещи продвигаются «вперед» (после стольких лет виртуального застоя), развитие языка и времени выполнения фактически переместилось «назад» для других — и, несмотря на мгновенный толчок волнения что что- то , наконец, меняется, весь процесс в значительной степени остается в том же историческом тупике.
ES6 делает некоторых разработчиков немного счастливее, а других — менее счастливыми.
По моему мнению, подмножество JavaScript (asm.js или что-то в этом роде) должно происходить в гораздо большем масштабе и должно стать гораздо более доступным и вездесущим.
По моему собственному, несколько радикальному мнению, для того, чтобы это произошло, язык JavaScript и среда выполнения должны быть «устаревшими».
Конечно, не в том смысле, что JavaScript должен исчезнуть. Я не сумасшедший.
Но в том смысле, что он должен быть отделен пуповиной от клиентской и серверной платформ.
JavaScript должен вылететь из удобного гнезда и научиться выживать самостоятельно, наравне с другими языками и средами исполнения. Время взрослеть, малыш.
Если бы JavaScript был отделен от клиентской и серверной платформ, давление монокультуры было бы снято — следующая итерация языка JavaScript или среды выполнения больше не должна была бы радовать каждого разработчика в мире, а вместо этого могла бы сосредоточиться на удовольствии гораздо меньшая аудитория разработчиков, которые любят JavaScript и преуспевают с ним, позволяя другим переходить на альтернативные языки или среды выполнения.
Это было бы лучше для JavaScript и для любого другого языка.
Устранение того, что является, пожалуй, самой большой монокультурой в истории разработки программного обеспечения , означало бы, что мы, сообщество, могли бы наконец-то взять на себя ответственность как за языки, так и за время выполнения, и начать итерацию и расширение их независимо от браузерных / серверных платформ, поставщиков. и организации, все тянутся в разные стороны, борются за контроль над стандартами и (возможно, самое главное) освобождают все сообщество разработчиков от группового давления « Один язык управляет ими всеми» .
Наши языки и среды выполнения будут размещаться и распространяться в CDN, а не встраиваться в наши клиентские и серверные среды, где они становятся рискованными и трудными для изменения — где на каждую итерацию уходят годы, чтобы договориться, и дополнительные болезненные годы полифилов и откатов в то время как они распространяются на браузеры.
Представьте себе мир, в котором вы можете обновить свое приложение до следующей версии JavaScript в тот же день, когда оно будет выпущено .
Представьте себе JavaScript, который развивается для нужд тех, кто действительно хочет язык, а не становится наименьшим общим знаменателем мнений, в том числе тех, которые придерживаются люди, которые действительно предпочли бы использовать другой язык.
Попытка угодить всем , с одной стороны , всегда оказывается компромиссом, который действительно никому не нравится.
Стандарты: Хорошо, Однородность: Плохо
Не поймите меня неправильно — стандарты великолепны. Однородность это плохо.
Антропологически мы процветаем благодаря нашей способности адаптироваться к различным условиям и диверсифицировать себя. Наше любопытство и стремление учиться дают нам перспективу и обогащают нас культурно. Культура разработчиков, смиренно, является частью этого культурного богатства, и мы должны принять это.
Попытка заставить эту вещь работать для всех — худший способ сделать это.
В заключение, это было мнение — и как таковое, конечно, я приветствую ваше мнение и надеюсь, что это вызывает некоторые вдумчивые, конструктивные комментарии, а не только пламя 😉