Предлагаю вашему вниманию перевод статьи «JavaScript Fatigue: An Alternative Perspective» Джоша Бёрджесса (Josh Burgess). Оригинал наодится здесь.
Во-первых, позвольте мне сказать пару слов о статье JavaScript Fatigue от @ericclemmons, где определённо были несколько действенных пунктов. Текущий React/JavaScript/front-end landscape может быть сложным для начинающих. Там много похожих вариаций инструментов, много литературы с перекрытым функционалом, много конкурирующих framework'ов, и, честно говоря, много принципиально противоречивых идеологий о том, как структурировать большие приложения и как писать чистый и поддерживаемый код. Чёрт, многие JavaScript программисты не могут даже разделить, какие парадигмы и особенности языка следует использовать, а какие следует игнорировать (ООП против FP, необходимое против декларативного, ASI и semicolon debate, необходимость классов ES6 и т.д.).
Для тех, кто новичок в JS, или для тех кто в первую очередь Back-End (но и время от времени Front-end) инженер, для тех кто перешёл с других языков, для тех кому не особо нравится или тех кто не тесно знает тонкости языка, это может быть сложновато. Однако, я видел много негатива по этой теме в Twitter, Medium и Reddit, и я думаю что мы должны сделать шаг назад и изучить реальную ситуацию и это происходит. Природой JavaScript языка является то, что не может нарушить существующий код в разработке. Все обновления языка должны обеспечивать обратную совместимость. Некоторые люди ненавидят это. Они хотят избавиться от проблемных функций, но это так. Не следует рассматривать отрицательно то что нельзя преодолеть. Это не тёмное облако надвигающееся над головой, вечно отягощая front-end. Это просто факт. Прямым следствием этого является то, что JS это язык, при котором данная задача может быть решена различными способами.
Как мы с этим боремся? Вы боретесь с этим постепенно далеко отходя от функций/синтаксиса/парадигм, вы уже больше не чувствуете что лучше вам служит, как ценные инструменты программирования. Это тоже самое, как люди пишут JS код в функциональном стиле. Это чисто функциональный язык, как Haskell? Нет, это язык мульти парадигмы, что поддерживает различные формы ООП, она не имеет сильной или статической типизации, и это только сейчас правильная хвостовая оптимизация… но вы всё ещё можете кодить в функциональном образом, осуществляя самодисциплину и сдержанность. Вы можете использовать анонимные функции (функции без гражданства) и оттолкните побочные эффекты по краям вашего приложения. Вы можете использовать const (строительство) что бы избежать переназначения и Object.freeze, deep-freeze, или Immutable.js что бы избежать изменения объекта. Вы можете воспользоваться преимущества мистрогой типизации с помощью TypeScript or Flow…
… Или вы можете забыть всё это и принять ООП в JavaScript, либо через попытки подражания класса на основе модели классического наследования C++ / Java / C#, с помощью простого prototype behavior delegation & ducktype checking, или собирать всё по составу. Это ваш выбор. Это часть красоты языка. некторорые языки целенаправленно сужают сферу, что бы к цели был «один истинный путь» без комнаты для принятия решений… При этом есть очевидные плюсы, но есть и минусы, с которыми вам придется согласиться сделанными авторами языка. Вы когда нибудь встречали языки программирования без недостатков? Я уверен, что нет, реальность ситуации в том, что JavaScript не тип языка. Это есть в каждом браузере. Это есть и на сервере. Это в вашей оснастке. Это питание робототехники и loT. Это везде. JavaScript обманчиво прост. Это один из самых простых языков, чтобы нырнуть в него, одновременно непонятный и редко осваиваемый. Это показал разнообразный бассейн программистов, которые приходя из разных слоев, имеющих разные уровни квалификации и на благо различных арихитектурных моделей. Это не свобода, быть таким догматичным.
Важно понимать, что у вас есть выбор уровня, потому что эти варианты доступны для вас. Может иметь много выбора подавляет время от времени? Конечно! Может настройки ограничения помогут вам установить более продуктивные рабочие процессы и написать более модульный, в сопровождении код? Определенно! Однако вы тот кому необходимо сделать этот вызов. Имея эту гибкость для развития вашего стиля программирования, вы становитесь неоценимы. Тоже самое можно сказать когда речь заходит о выборе framework'ов, библиотек и инструментов.
React и the Flux архитектура появилась, потому что инжинеры Facebook взял время, чтобы выбросить предвзятых представлений о «best practic» для того, чтобы решить свои собственные проблемы реального мира с большим MVC-style одностраничного приложения. Redux заимствовал идеи из Elm и принес их в JavaScript, чтобы упорядочить и упростить Flux. Такие инструменты как Babel и Webpack позволяют обойти ожидание на новые стандарты чтобы быть реализованы. Такие характеристики, как горячей перезагрузки и отладки путешествия времени (time travel debugging) значительно улучшит рабочий процесс front-end'a.разработки. «CSS в JS» встроенные стили CSS и модули признать проблемы CSS сферы охваты и попытки предложить лучшие альтернативы. FraphQl, Falcor и Relay дают нам современные замены для традиционных RPC и REST APIs.
Мы даже увидим свежие framework'и, как Cycle, Motorcycle, и yolk предполагает более радикальные идеи о том, как мы можем улучшить React. Некоторые люди называют это отток (churn), но я называю это прогресс. Все эти вещи пытаются продвигать то, как мы строим приложения в Интернете. Оба JavaScript и web — быстро развиваются, и будут продолжать делать это в обозримом будущем. Правда если вам не нравится постоянно изучать что то новое, то веб-разработки, вероятно не для вас. Вы возможно выбрали не ту карьеру.
Во-первых, позвольте мне сказать пару слов о статье JavaScript Fatigue от @ericclemmons, где определённо были несколько действенных пунктов. Текущий React/JavaScript/front-end landscape может быть сложным для начинающих. Там много похожих вариаций инструментов, много литературы с перекрытым функционалом, много конкурирующих framework'ов, и, честно говоря, много принципиально противоречивых идеологий о том, как структурировать большие приложения и как писать чистый и поддерживаемый код. Чёрт, многие JavaScript программисты не могут даже разделить, какие парадигмы и особенности языка следует использовать, а какие следует игнорировать (ООП против FP, необходимое против декларативного, ASI и semicolon debate, необходимость классов ES6 и т.д.).
Для тех, кто новичок в JS, или для тех кто в первую очередь Back-End (но и время от времени Front-end) инженер, для тех кто перешёл с других языков, для тех кому не особо нравится или тех кто не тесно знает тонкости языка, это может быть сложновато. Однако, я видел много негатива по этой теме в Twitter, Medium и Reddit, и я думаю что мы должны сделать шаг назад и изучить реальную ситуацию и это происходит. Природой JavaScript языка является то, что не может нарушить существующий код в разработке. Все обновления языка должны обеспечивать обратную совместимость. Некоторые люди ненавидят это. Они хотят избавиться от проблемных функций, но это так. Не следует рассматривать отрицательно то что нельзя преодолеть. Это не тёмное облако надвигающееся над головой, вечно отягощая front-end. Это просто факт. Прямым следствием этого является то, что JS это язык, при котором данная задача может быть решена различными способами.
Как мы с этим боремся? Вы боретесь с этим постепенно далеко отходя от функций/синтаксиса/парадигм, вы уже больше не чувствуете что лучше вам служит, как ценные инструменты программирования. Это тоже самое, как люди пишут JS код в функциональном стиле. Это чисто функциональный язык, как Haskell? Нет, это язык мульти парадигмы, что поддерживает различные формы ООП, она не имеет сильной или статической типизации, и это только сейчас правильная хвостовая оптимизация… но вы всё ещё можете кодить в функциональном образом, осуществляя самодисциплину и сдержанность. Вы можете использовать анонимные функции (функции без гражданства) и оттолкните побочные эффекты по краям вашего приложения. Вы можете использовать const (строительство) что бы избежать переназначения и Object.freeze, deep-freeze, или Immutable.js что бы избежать изменения объекта. Вы можете воспользоваться преимущества мистрогой типизации с помощью TypeScript or Flow…
… Или вы можете забыть всё это и принять ООП в JavaScript, либо через попытки подражания класса на основе модели классического наследования C++ / Java / C#, с помощью простого prototype behavior delegation & ducktype checking, или собирать всё по составу. Это ваш выбор. Это часть красоты языка. некторорые языки целенаправленно сужают сферу, что бы к цели был «один истинный путь» без комнаты для принятия решений… При этом есть очевидные плюсы, но есть и минусы, с которыми вам придется согласиться сделанными авторами языка. Вы когда нибудь встречали языки программирования без недостатков? Я уверен, что нет, реальность ситуации в том, что JavaScript не тип языка. Это есть в каждом браузере. Это есть и на сервере. Это в вашей оснастке. Это питание робототехники и loT. Это везде. JavaScript обманчиво прост. Это один из самых простых языков, чтобы нырнуть в него, одновременно непонятный и редко осваиваемый. Это показал разнообразный бассейн программистов, которые приходя из разных слоев, имеющих разные уровни квалификации и на благо различных арихитектурных моделей. Это не свобода, быть таким догматичным.
Важно понимать, что у вас есть выбор уровня, потому что эти варианты доступны для вас. Может иметь много выбора подавляет время от времени? Конечно! Может настройки ограничения помогут вам установить более продуктивные рабочие процессы и написать более модульный, в сопровождении код? Определенно! Однако вы тот кому необходимо сделать этот вызов. Имея эту гибкость для развития вашего стиля программирования, вы становитесь неоценимы. Тоже самое можно сказать когда речь заходит о выборе framework'ов, библиотек и инструментов.
React и the Flux архитектура появилась, потому что инжинеры Facebook взял время, чтобы выбросить предвзятых представлений о «best practic» для того, чтобы решить свои собственные проблемы реального мира с большим MVC-style одностраничного приложения. Redux заимствовал идеи из Elm и принес их в JavaScript, чтобы упорядочить и упростить Flux. Такие инструменты как Babel и Webpack позволяют обойти ожидание на новые стандарты чтобы быть реализованы. Такие характеристики, как горячей перезагрузки и отладки путешествия времени (time travel debugging) значительно улучшит рабочий процесс front-end'a.разработки. «CSS в JS» встроенные стили CSS и модули признать проблемы CSS сферы охваты и попытки предложить лучшие альтернативы. FraphQl, Falcor и Relay дают нам современные замены для традиционных RPC и REST APIs.
Мы даже увидим свежие framework'и, как Cycle, Motorcycle, и yolk предполагает более радикальные идеи о том, как мы можем улучшить React. Некоторые люди называют это отток (churn), но я называю это прогресс. Все эти вещи пытаются продвигать то, как мы строим приложения в Интернете. Оба JavaScript и web — быстро развиваются, и будут продолжать делать это в обозримом будущем. Правда если вам не нравится постоянно изучать что то новое, то веб-разработки, вероятно не для вас. Вы возможно выбрали не ту карьеру.