Мы все читали ужасные истории от разработчиков, пытающихся перейти на Интернет. Эхо-камера полна недовольных и неудовлетворенных пользователей Javascript и соответствующей экосистемы, кричащих такие вещи, как: «Язык плохо спроектирован!», «Разработчики экосистемы явно не знают, что они делают!» И «Это буквально Гитлер! »… ладно, возможно, не последний, но, безусловно, есть несколько ярких мнений.
Пытаюсь понять, почему
Я работал от человека, который более 10 лет занимался профессиональной интерфейсной веб-разработкой, и мне посчастливилось увидеть, как разворачивается эта история. Я часто чувствую разочарование - не из-за использования языка / экосистемы, а из-за этого консенсуса, который многие разработчики считают, что Javascript и веб-разработка просто отстой, и изменить это невозможно.
Я годами боролся с этой идеей, пытаясь придумать какое-то подобие того, как люди приходят к такому выводу. Имейте в виду, что это мнение, но я заметил тенденцию. В большинстве случаев разочарование пользователей возникает не из-за самого языка или его возможностей, а из-за плохого взаимодействия с пользователем, с которым впервые сталкиваются. В частности, при переходе с других платформ, особенно в последние несколько лет.
Как это случилось?
Если вы вернетесь примерно на пять-десять лет назад, вы получите множество комментариев о состоянии языка, и это подводные камни в то время. Проблемы со скоростью, сложным для изучения синтаксисом и ограниченными возможностями стандартизованного структурирования крупномасштабных приложений.
Помните также, какие виды товаров производятся в настоящее время для Интернета. Большинство разработчиков начинали формировать онлайн-присутствие своей компании. Включая в основном статические веб-сайты с некоторым динамическим содержанием, обычно использующие базовую CMS (на базе PHP, Wordpress или аналогичную). Конечно, полнофункциональные веб-приложения существовали, но они все еще были относительно новыми для этой области.
Перенесемся в сегодняшний день. Каждая технологическая компания, от стартапов до крупных корпоративных компаний, живет и дышит в Интернете. Ненормально не иметь какой-либо онлайн-учетной записи для управления вашим продуктом - или, возможно, сам продукт целиком состоит из веб-приложения. Все признаки указывают на то, что потребность и требование к веб-платформе по-прежнему будут оставаться актуальными и в будущем.
Технический стек также переместился с PHP в те времена на такие решения, как Ruby / Rails, к более сложным решениям с Javascript. Я считаю, что это частично связано с мощностью и простотой javascript (единственный язык сценариев, изначально доступным в браузере) и улучшениями, которые язык получил за последние несколько лет (от более быстрого рендеринга с V8 до улучшений спецификаций с ES6). Не говоря уже о желании иметь отзывчивый интерфейс, который мгновенно реагирует на использование взаимодействия. Одна из основных функций Javascript в Интернете.
Что стимулировало этот переход?
Здесь все становится немного сложнее. То, что мы наблюдаем за последние несколько лет, - это приток идей от самых разных умов, пытающихся разработать самоуверенные решения проблем и желаний «современной сети».
Это явно не безболезненный процесс. Фактически, боли роста были довольно распространены. Что, в свою очередь, привело к одной из самых больших проблем платформы - входной барьер представляет собой вертикальную стену, а не изгиб. Существует так много идей (некоторые хорошие, некоторые плохие), и все они пытаются определить «лучший» способ решения сложного набора проблем для расширяющейся системы. Это привело к ошибочному представлению о том, что вы должны выучить каждого, чтобы не отставать и соревноваться.
Стандартная библиотека функций Javascript вам не подходит? Попробуйте Underscore или Lodash. Возникли проблемы со структурированием больших приложений? Такие инструменты, как Angular и Ember, могут предоставить решения. Нужен упрощенный способ установки и обслуживания всех ваших различных сторонних пакетов? Попробуйте NPM или Bower. И этот список можно продолжить…
Это серьезная проблема для новых пользователей. Практически никогда не существует однозначного ответа на вопрос, что новым пользователям следует изучить и использовать для решения проблемы. Вместо этого им бросают мнения, как если бы они были правдой. Многие люди дают рекомендации, исходя из своих предпочтений и личных предубеждений, а не поддающихся количественной оценке данных.
Паралич выбора также может поразить, когда доступно так много вариантов. Как вы решаете, что лучше для вас? Как вы вообще обнаруживаете и узнаете, какие существуют варианты? Тем более найти время, чтобы изучить их все. Это может быть чуждое понятие от кого-то из другого языка, у которого есть четко определенные ответы на общие задачи.
Состояние постоянного изменения
Еще одна серьезная жалоба, которую я слышу в веб-мире, заключается в том, что все меняется слишком быстро, новые возможности вводятся слишком быстро, и за этим «невозможно» угнаться.
Опять же, это исходит от людей, которые привыкли использовать одну и ту же структуру или инструменты, стандартизированные более 10 лет. Кому-то могут позавидовать веб-разработчики, но это роскошь, явно недоступная для платформы, которая так резко меняется за такой короткий промежуток времени.
Мало того, что требования к сети быстро меняются в сторону мобильных и веб-приложений, но и выпуск недавней спецификации ECMAScript 6 еще больше усложнил это.
(К вашему сведению, ECMA - это комитет, который определяет спецификацию для языка ECMAScript, более известного как Javascript. Новые выпуски выходят не часто, поэтому когда они появляются, это имеет большое значение.)
Любой, кто провел время в этой сфере, знает, что вендоры браузеров придерживаются значительной политики в отношении того, «когда и как». Не говоря уже о том, что эти изменения не всегда сразу отражаются с настольного компьютера на мобильный, даже для одного и того же поставщика. Это снова вызывает боль, когда нелегко определить, что работает в каждом браузере / устройстве.
Чтобы попытаться решить подобные проблемы, особенно с введением EC6, мы стали свидетелями появления таких инструментов, как Typescript. Предоставление средств для использования технологии JS завтрашнего дня уже сегодня. TypeScript позволяет пользователям писать код в стандарте ES6, который затем переносится в ES5 (поскольку ES6 в основном состоит из синтаксического сахара). Кроме того, он уникальным образом вводит концепцию типов в Javascript, который обычно является языком с динамической типизацией. Со всеми льготами в инструментах, которые идут вместе с этим.
Однако это создает собственный набор проблем - во-первых, объяснение новым пользователям, что такое Typescript, и объяснение его преимуществ. Особенно, когда все новые пользователи могут изначально увидеть требование изучить две «версии» одного и того же языка и добавить дополнительные инструменты и шаги для и без того сложного процесса.
Как мы с этим справляемся?
Бремя ложится на разработку лучшего способа объяснить необходимость и причину колебаний, а также пользу, которую предоставляют эти инструменты. Не говоря уже о том, чтобы было ясно, что эти инструменты на 100% необязательны. Что-то не так даже с некоторыми опытными разработчиками Javascript, которых я знаю.
Мое личное предложение - это бесплатное руководство с открытым исходным кодом, которое представляет собой дорожную карту для изучения языка и экосистемы небольшими фрагментами. Вот пример того, как это может выглядеть:
- Javascript 101: изучите основной язык (синтаксис, стандартную библиотеку, отладку, наследование прототипов, манипуляции с DOM и т. Д.)
- Объясните улучшение, появившееся в ES6, и объясните, как его использовать сегодня (Typescript / Babel)
- Библиотеки «Качество жизни» (подчеркивание, lodash, jQuery)
- Менеджеры пакетов для управления и сторонние зависимости (Bower / NPM)
- Введение в инструменты сборки для автоматизации (Gulp / Grunt)
- Изучение и использование Javascript на сервере (Node)
- Структурирование крупномасштабных приложений и модулей (Angular / React + Flux / Ember, Vue и т. Д.)
Вы уловили идею. Очевидно, что приведенный выше порядок не высечен на камне. Помните, что на изучение каждого шага может уйти много времени, не говоря уже о мастерстве. Об этом обязательно нужно донести до пользователей.
Проложить четко определенный путь, который начинается с ядра JS и веб-разработки, а затем со временем расширяется решениями, улучшающими структуру и производительность, и объясняет преимущества с течением времени.
В руководстве можно попытаться четко определить несколько наиболее популярных вариантов, доступных для каждой части процесса, подробно рассказать об их общих преимуществах и сделать это (насколько это возможно) беспристрастно.
Что будет дальше?
Нам нужно будет помнить об уровне усилий и знаний, которые потребуется приложить ответственному лицу или группе для создания и поддержки такого руководства. Особенно, когда все еще находится в таком движении. Новые технологии могут приходить и уходить, и обуздание предвзятости будет настоящей проблемой. Так что, возможно, в качестве альтернативы был бы набор самоуверенных руководств. С вариантами, адаптированными к различным потребностям пользователей, и вариантами ветвления вместо универсального подхода.
Ясно, что что-то должно произойти, если мы не хотим, чтобы Javascript и веб-экосистема продолжали сохранять свою пресловутую репутацию. Поэтому, если вы или кто-то из ваших знакомых хотели бы внести свой вклад в нечто подобное, дайте мне знать в комментариях.
Мне бы хотелось иметь возможность работать с единомышленниками, чтобы предоставить решение, которое поможет новым пользователям преодолеть эти препятствия, а также укрепит и укрепит Javascript и веб-платформу в целом. Особенно, если это означает предоставить возможность поделиться любовью к платформе, которой я наслаждаюсь столько лет.
