Каково оно учить JavaScript в 2016

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
  • Перевод


— Эй, я получил новый веб-проект, но, если честно, я не занимался веб-кодингом в течение нескольких лет, и я слышал, все немного поменялось. Ты же самый современный веб-разработчик, правда?

— Это теперь называется Front-End инженер, но да, я — именно он. Я работаю с вебом в 2016. Визуализации, музыкальные плееры, летающие дроны, которые играют в футбол, все что угодно. Я только что вернулся из JsConf и ReactConf, так что я знаю новейшие технологии для создания веб-приложений.

— Круто. Мне нужно создать страницу, которая отображает последние действия со стороны пользователей, так что мне просто нужно получить данные от REST и отобразить их в какой-то фильтруемой таблице, ну и обновлять её, если что-то изменится на сервере. Я думал, может быть, использовать JQuery для извлечения и отображения данных?

— О, Мой Бог! Нет! Никто больше не использует JQuery. Ты должен попробовать React: это — 2016!

— Интересно. Что такое React?

— Это — очень крутая библиотека, сделанная ребятами из Facebook. Она реально дает полный контроль и повышает производительность приложения, позволяя очень легко обрабатывать любые изменения представлений.

— Звучит заманчиво. Могу ли я использовать React для отображения данных с сервера?

— Ага, но сначала нужно добавить React и React DOM в виде библиотек.

— Подожди, почему две библиотеки?

— Ну, одна — это сама библиотека, а вторая — для манипулирования DOM, который ты теперь можешь описать в JSX.

— JSX? Что такое JSX?

— JSX — это просто расширение синтаксиса JavaScript, который выглядит очень похоже на XML. Это своего рода еще один способ описать DOM. Думай о нем, как об улучшенном HTML.

— Что случилось с HTML?

— Это 2016. Никто больше не пишет на сыром HTML.

— Ну хорошо. Если я добавляю эти две библиотеки, то я могу использовать React?

— Не совсем. Нужно добавить Babel, а затем можно использовать React.

— Другая библиотека? Что за Babel?

— О, Babel — это транспайлер, он позволяет ориентироваться на конкретные версии JavaScript, в то время как пишешь код в любой версии JavaScript. Тебе не обязательно добавлять Babel для того, чтобы писать на ReactJS, но если ты это не сделаешь, то ты застрял с ES5, ну а это 2016, ты должен кодить в ES2016+ как и все крутые чуваки.

— ES5? ES2016+? Я потерялся. Что за ES5 и ES2016+?

— ES5 означает ECMAScript 5. Это версия, на которую ориентируется большинство, поскольку она реализована в большинстве браузеров на сегодняшний день.

— ECMAScript?

— Да, знаешь стандарт JavaScript, который был основан в 1999 году после его первоначального выпуска в 1995 году? Тогда, когда JavaScript был назван LiveScript и только работал в Netscape Navigator. Это было очень запутано тогда, но, к счастью, теперь все ясно, и у нас есть 7 версий этой реализации.

— 7 версий. Серьезно. А ES5 и ES2016+ это?…

— Пятое и седьмое издание соответственно.

— Подожди, а что случилось с шестым?

— ES6? Да, каждое издание является надстройкой предыдущего, так что если ты используешь ES2016+, то ты используешь все функции предыдущих версий.

— Хорошо. А зачем использовать ES2016+ над ES6 тогда?

— Ну, ты можешь использовать ES6, но для интересных штук, типа async и await, тебе нужно использовать ES2016+. В противном случае ты застрял с ES6 генераторами и сопрограммами для блокировки асинхронных вызовов и нормального управления потоком.

— Я понятия не имею, что ты только что сказал, и все эти имена запутаны. Слушай, я просто хочу загрузить кучу данных с сервера, просто подключить JQuery из CDN и просто получить данные с помощью AJAX. Почему я не могу сделать это?

— Чувак, это 2016. Никто не использует JQuery больше, это заканчивается кучей запутанного кода. Все же это знают.

— Ясно. Так что моя альтернатива — это загрузить три библиотеки для извлечения данных и отображения таблицы HTML.

— Ну, ты включаешь эти три библиотеки, но связываешь их с менеджером модулей, чтобы загрузить только один файл.

— Понятно. А что за менеджер модулей?

— Определение зависит от окружающей среды, но для веба мы обычно подразумеваем все, что поддерживает модули AMD или CommonJS.

— Хорошооооо. А AMD и CommonJS это?…

— Определения. Есть куча способов, чтобы описать, как несколько библиотек и классов JavaScript должны взаимодействовать. Ты можешь написать несколько файлов JavaScript, определяющих API AMD или CommonJS, и использовать что-то вроде Browserify, чтобы связывать их.

— Хорошо, имеет смысл… наверное. А что такое Browserify?

— Это инструмент, который позволяет связать CommonJS описанния зависимостей для файлов, которые могут быть запущены в браузере. Он был создан, потому что большинство людей публикуют эти зависимости в NPM.

— NPM?

— Это очень большое общественное хранилище, где умные люди постят код и зависимости в виде модулей.

— Как CDN?

— На самом деле, нет. Это больше похоже на централизованную базу данных, где каждый желающий может опубликовать и скачать библиотеки, так что ты можешь использовать их локально для разработки, а затем загрузить их на CDN, если захочешь.

— О, как Bower!

— Да, но это 2016, сейчас никто больше не использует Bower.

— Хм, ясно… так мне нужно загрузить библиотеки из NPM?

— Да. Например, если ты хочешь использовать React, то загружаешь модуль React и импортируешь его в коде. Это можно сделать для почти каждой популярной библиотеки JavaScript.

— О, это как в Angular!

— Angular это слишком 2015. Но да. Angular тоже там есть, наряду с VueJS, RxJS и другими интересными библиотеками из 2016. Хочешь узнать о них?

— Давай придерживаться React, я уже узнал слишком много о нем. Так что, если мне нужно использовать React, я вытяну его из этого NPM, а затем использую Browserify?

— Да.

— Это кажется слишком сложным, чтобы просто взять кучу зависимостей и связать их вместе.

— Ага, именно поэтому ты используешь менеджер задач, типа как Grunt или Gulp, или Broccoli для автоматизации запуска Browserify. Ты даже можешь использовать Mimosa.

— Grunt? Gulp? Broccoli? Mimosa? Черт возьми, о чём мы говорим сейчас?

— Task менеджеры. Но они уже не такие крутые. Мы использовали их в стиле 2015 с Makefiles, но теперь мы перешли на Webpack.

— Makefiles? Я думал, что в основном это используется для C или C++ проектов.

— Ага, но, видимо, в вебе мы любим делать вещи сложными, а затем вернуться к основам. Мы делаем это типа каждый год. Ты подожди, через год или два мы еще запилим сборки (assemblies) в вебе.

— Пффф. Ты упомянул что-то под названием Webpack?

— Это другой менеджер модулей для браузера, в то же время он и своего рода Task менеджер. Это как улучшенная версия Browserify.

— ОК. А почему он лучше?

— Ну, может быть не лучше, но более гибкий в плане того, как зависимости связаны. Webpack позволяет использовать различные менеджеры модулей, а не только CommonJS. Например, родные модули ES6.

— Я очень запутался в этих CommonJS/ES6.

— Да все в этом запутались, но можешь больше не париться, потому что есть SystemJS.

— О, Боже, опять что-то-JS. Хорошо, а что это за SystemJS?

— Ну, в отличие от Browserify и WebPack 1.x, SystemJS представляет собой динамический модуль загрузчика, который позволяет связать несколько модулей в нескольких файлах, а не связывая их в один большой файл.

— Подожди, я думал, что мы хотели объединить наши библиотеки в один большой файл и загрузить его!

— Да, но из-за HTTP/2 несколько HTTP запросов на самом деле лучше.

— Стоять! Так чего же мы не можем просто добавить три оригинальные библиотеки для React?

— Ты, конечно, можешь добавить их в качестве внешних скриптов с CDN, но все равно нужно будет добавить Babel.

— Эх. И это плохо, не так ли?

— Да, придется включить полностью Babel-core, а это не будет эффективным для production. На production необходимо выполнить ряд предварительных задач, чтобы проект был полностью готов, а это ритуал, в сравнении с которым вызвать дьявола — это рецепт как сварить яйцо. Надо будет минимизировать файлы, сделать uglify, поиграться со стилями, подумать о загрузке скриптов…

— Понял, понял. Но если не скачивать библиотеки непосредственно с CDN, то как иначе?

— Я бы сделал транспайл из TypeScript с помощью комбо Webpack + SystemJS + Babel.

— TypeScript? Я думал, что мы пишем код на JavaScript!

— Typescript — это и есть JavaScript, или, лучше сказать, надмножество JavaScript. Более конкретно — JavaScript на версии ES6. Ну, та шестая версия, о которой мы говорили.

— Я думал, что ES2016+ — уже надмножество ES6! Почему нам сейчас нужен еще и TypeScript?

— Потому что это позволяет нам использовать JavaScript как типизированный язык и уменьшить количество ошибок во время выполнения. Это 2016, надо добавить некоторые типы в код на JavaScript.

— И TypeScript, очевидно, делает это.

— И Flow, хотя он проверяет только типы, в то время как TypeScript является надстройкой JavaScript, который нужно скомпилировать.

— Эээ… и Flow?

— Это — инструмент для проверки статической типизации, сделанный парнями из Facebook. Они написали его на OCaml, так как функциональное программирование является удивительно крутым.

— OCaml? Функциональное программирование?

— Ну это то, что сегодня юзают крутые пацаны, ну типа, знаешь, 2016. Функциональное программирование. Функции высокого порядка. Currying. Pure функции.

— Я понятия не имею, что это.

— Никто не понимает, в начале. Надо просто знать, что функциональное программирование лучше, чем объектно-ориентированное программирование, и это то, что мы должны использовать в 2016 году.

— Подожди, я учил ООП в универе, я думал, что это круто?

— Ну так было пока Oracle не купил Java. Я имею в виду, что ООП был хорош раньше, и его используют до сих пор, но теперь каждый понимает, что манипулировать состояниями эквивалентно пинанию младенцев, так что теперь все движется к immutable объектам и функциональному программированию. Ребята из Haskell уже 100 лет кричат об этом, и это я еще не упоминал Elm. Но, к счастью, в сети теперь у нас есть такие библиотеки, как Ramda, которые позволяют нам использовать функциональное программирование на простом JavaScript.

— Ты что, просто придумываешь имена? Что еще за Ramnda?

— Нет. Ramda. Как и Lambda. Ну, знаешь, библиотека Дэвида Чембера?

— Дэвида кого?

— Дэвида Чембера. Крутой чел. Один из авторов Ramda. Глянь еще работы Эрика Мейера, если серьезно относишься к изучению функционального программирования.

— А Эрик Мейер это?…

— Тоже функциональщик. Крутой чел. У него есть куча презентаций, где он в странной цветной футболке громит Agile. Еще глянь что делают Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani…

— ОК. Притормози. Все это хорошо и прекрасно, но я думаю, что все это слишком сложно и ненужно для простой выборки данных и их отображения. Я уверен, что я не должен знать этих людей или все эти вещи, чтобы создать таблицу с динамическими данными. Давай вернемся к React. Как я могу извлечь данные с сервера в React?

— Ну, на самом деле для выборки данных не надо React, он отображает данные.

— О, черт. Так а что используется для выборки данных?

— Используй Fetch для получения данных с сервера.

— Использовать Fetch для выборки данных? Тот, кто называет эти вещи, нуждается в тезаурусе.

— О, да. Fetch это имя нативной реализации для выполнения XMLHttpRequests.

— О, AJAX.

— AJAX это просто запросы XMLHttpRequest. А Fetch позволяет делать AJAX на основе промисов, которые затем можно резолвить, чтобы избежать callback hell.

— Callback hell?

— Да. Каждый раз, когда выполняется асинхронный запрос, ты должен ждать его ответа, который заставляет добавить функцию внутри функции, которая называется пирамида callback hell.

— О, хорошо. А промисы решают эту проблему?

— Еще бы! Манипулируя коллбеками через промисы, ты можешь писать более понятный код, тестировать его, а также выполнять несколько одновременных запросов одновременно и ждать, пока все они отработают.

— И это можно сделать с помощью Fetch?

— Да, но только в некоторых браузерах, в противном случае необходимо включить Fetch polyfill или использовать Request, Bluebird или Axios.

— Сколько библиотек мне нужно знать, ради бога? Сколько из них?

— Это JavaScript. Тут тысячи библиотек, которые делают одно и то же. Мы знаем эти библиотеки. Наши библиотеки огрооооомные, а иногда мы добавляем картинки с Guy Fieri в них.

— Guy Fieri? Давай покончим с этим. Что эти Bluebird, Request и Axios делают?

— Это библиотеки для выполнения XMLHttpRequests, которые возвращают промисы.

— А методы AJAX JQuery не возвращают промисы?

— Мы больше не используем «J» в 2016. Просто используйте Fetch polyfill или Bluebird, Request или Axios. Затем управляй промисами с async, await и Бац!, у тебя правильный поток управления.

— Это третий раз, когда ты говоришь о await, но я понятия не имею, что это такое.

— Await позволяет блокировать асинхронный вызов, что позволяет лучше все контролировать во время получения данных и увеличивает читаемость кода. Это потрясающе, просто нужно, чтобы убедиться, что ты добавил stage-3 в Babel, или использовать синтаксис асинхронных функций и плагин transform-async-to-generator.

— Это безумие.

— Нет, безумие — что нужно перекомпилировать код TypeScript, а затем транспайлить его с Babel, чтобы использовать await.

— Шта!? Это не входит в TypeScript?

— Входит в следующей версии, но в версии 1.7 он только ES6, так что если хочешь использовать await в браузере, сначала нужно скомпилировать код TypeScript в ES6, а затем транспайлить с Babel в ES5.

— Я не знаю, что сказать.

— Слушай, это легко. Пиши весь код в TypeScript. Все модули, использующие Fetch компилируй в ES6, транспайль их с Babel с stage-3, и загружай с SystemJS. Если у тебя нет Fetch, используй polyfill, или Bluebird, Request или Axios, и обрабатывай промисы с await.

— У нас очень разные определения «легко». Так, с этим ритуалом я, наконец, получил данные и теперь я могу показать их с помощью React правильно?

— А приложение будет обрабатывать любые изменения состояния?

— Грр, я не думаю. Мне просто нужно отобразить данные.

— О, слава богу. В противном случае мне пришлось бы объяснить Flux и реализации, такие как Flummox, Alt, Fluxible. Хотя, если быть честным ты должен использовать Redux.

— Как же достали эти имена. Опять же, мне просто нужно отобразить данные.

— А, если просто отобразить данные, не надо начинать с React. Можно взять движок шаблонов.

— Ты шутишь, что ли? Думаешь, это смешно?

— Да я просто объяснил, что ты мог бы использовать.

— Стоп. Просто остановись.

— Я имею в виду, даже если просто использовать шаблонизатор, я бы все равно использовал комбо TypeScript + SystemJS + Babel на твоем месте.

— Мне нужно отобразить данные на странице, а не выполнить оригинальный фаталити Sub Zero из Мортал Комбат. Просто скажи мне, какой движок шаблонов использовать.

— Их много, с каким ты знаком?

— Уф, не могу вспомнить название. Это было давно.

— jTemplates? jQote? PURE?

— Не то. Еще один?

— Transparency? JSRender? MarkupJS? KnockoutJS?

— Другой

— PlatesJS? JQuery-tmpl? Handlebars? Некоторые люди до сих пор используют его.

— Может быть. А есть что-то похожее на последний?

— Mustache, underscore? Я думаю, что теперь даже у lodash есть шаблонизатор, но это своего рода 2014.

— Грр… возможно он был поновее.

— Jade? DustJS?

— Нет.

— DotJS? EJS?

— Нет.

— Nunjucks? ЕСТ?

— Нет.

— Чувак, никто не любит синтаксис CoffeeScript в любом случае. Jade?

— Нет, ты уже сказал Jade.

— Ну я имел в виду Pug. Я имел в виду Jade. Я имею в виду, Jade теперь Pug.

— Пф. Нет. Не помню. Какой из них ты бы использовал?

— Наверное, нативный ES6 template strings.

— Дай угадаю. Это требует ES6.

— Да.

— Который, в зависимости от того, какой браузер я использую требует Babel.

— Да.

— Который, если я хочу включить без добавления всей библиотеки, нужно, загрузить в качестве модуля NPM.

— Да.

— Который, требует Browserify или Wepback, или, скорее всего, SystemJS.

— Да.

— Который, если это не Webpack, в идеале должен управляться Task runner-ом.

— Да.

— Но, так как я должен использовать функциональное программирование и типизированные языки, я в первую очередь должен предварительно скомпилировать TypeScript или добавить этот Flow.

— Да.

— А потом отправить это на обработку в Babel, если я хочу использовать await.

— Да.

— Так что я могу затем использовать Fetch, промисы и управление потоком и всю эту магию.

— Только не забудь polyfill Fetch, если он не поддерживается, Safari до сих пор не может справиться с этим.

— Знаешь что. Я думаю, мы закончим здесь. На самом деле, я думаю, я закончил. Я закончил с этим вебом и с JavaScript в целом.

— Хорошо, через несколько лет мы все будем кодить в Elm или WebAssembly.

— Я просто хочу вернуться к бэкэнду. Я не могу справиться со всеми этими изменениями, версиями, изданиями, компиляторами и транспайлерами. Сообщество JavaScript безумно, если оно думает, что кто-то может идти в ногу с этим.

— Понятно. Тебе тогда надо попробовать сообщество Python.

— Почему?

— Слышал о Python 3?
Метки:
Поделиться публикацией
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама
Комментарии 297
  • –1
    Неплохие мысли от Эдди Османи по этому поводу. https://medium.com/@addyosmani/totally-get-your-frustration-ea11adf237e3#.3opyc4gll
    • +27
      Сначала нужно создать проблему, а потом героически ее побеждать. Странно, что замечая callback hell никто не замечает tools mess.
      • +2
        Я думаю это часть моды. Делать инструменты — проще, а главное романтичнее, чем скучные аппликации для пользователей.
        • 0
          Я думаю, дело не в моде.
          Толстые клиенты умирают, а толстые программисты нет. Не найдя на веб горизонте привычных классов, делают свой инструментарий. Добавьте хорошую документацию и вот вам фреймворк.
          • +1
            >Не найдя на веб горизонте привычных классов,

            Ext.js — Привычные классы — свыше 300 штук.
            • НЛО прилетело и опубликовало эту надпись здесь
            • +1
              АППЛИКАЦИЯ, -и; ж. [от лат. applicatio — прикладывание]. 1. Способ создания изображения посредством наклеивания или нашивания на что-л. разноцветных, разнофактурных кусочков ткани, бумаги и т.п. А. на шёлке, картоне. 2. Картина, украшение и т.п., изготовленные таким способом. Сделать аппликацию. Передник с аппликацией. 3. Физиотерапевтическая процедура: накладывание на какой-л. участок тела лечебной грязи, парафина и т.п. <Аппликационный, -ая, -ое (1 зн.). А-ые работы.


              application сущ. комп. прикладная программа (program)
              • 0
                Поищите в том же словаре ещё такие слова, как дедлайн, митап и эджайл.
                • +3
                  Некорректный аргумент: коротких устоявшихся аналогов, имеющих такой же смысл и коннотацию этим словам в русском языке нет, поэтому мы их заимствуем напрямую.

                  Слову application есть — это «приложение» или «прикладная программа», в то время как «аппликация» — это либо медицинский термин, либо вид картины, выполненной при помощи наклеивания.
                  Т.е. употребление слова «аппликация» вместо «приложение» в данном контесте — безграмотность и отсутствие чувства языка. В то время как употребление слова «дедлайн» — норма.

                  Точно так же как expertise — это «мастерство» или «опыт». А «мы продаем экспертизу» — нелепый набор слов, потому что «экспертиза» в русском языке имеет иной смысл, как во фразе «проведена криминалистическая экспертиза».
                  • +1
                    Жестокий и строгий ваш ответ то.

                    Товарищ хотел просто написать «апликухи» — но рука просто дрогнула у него.

                    Имхо, конечно, имхо. ;-)
          • +42
            • –2
              Статья сильно натянута.
              btw, что ещё за «Jash Kenas»? Его зовут Jeremy Ashkenas — автор coffeescript и underscore.
            • +3
              Сообщество JavaScript безумно, если оно думает, что кто-то может идти в ногу с этим.

              Самое главное — что в ногу с этим не могут идти браузеры. Следовательно, и нам не стоит, чтобы не отрываться от реальности.

              • +2

                За чем конкретно из списка выше не успели браузеры?)

                • +26

                  Некоторые браузеры не успели сдохнуть. Поэтому некоторые вещи не получается внедрить.

                  • +1

                    Эм, старые версии браузеров, в смысле?)

                    • 0
                      Походу всё, кроме вебкита. Это тайная мечта некоторых молодых разработчиков, не нюхавших гегемонию IE6 в интернете.
                      • +2

                        Вы понимаете, что edge лучше поддерживал ES6 какое-то время, а у нового safari вообще 100% поддержка, судя по ES compatibility table?

                        • 0
                          Да на это пофиг тем, кто ориентируется только на вебкит и его особенности оптимизации JS. Что не статья об оптимизации- то рассказы про то, как работает V8 и как под это лучше подстроится.
                          • +1

                            Вебкит никак не относится к JS. Статьи про V8, на этом движке сделана node.js и много открытой информации о том, как он устроен, какие есть уровни оптимизаций, как работает каждый из компиляторов.
                            Так что это действительно проблема, но я думаю, это проблема создателей других движков. Надо больше рассказывать о себе.

                          • 0

                            У edge очень своеобразное мнение на счёт того, как должен работать метод postMessage. Поэтому приходится для мелкомягких чертей отдельное поведение реализовывать (ага, и детектить их для этого).

                        • –4

                          Мелкомягкие черти в первую очередь. Из-за необходимости поддерживать всё что можно и что нельзя, языковые нововведения может быть появляются в рабочем коде года через два после их анонса. А может, не появляются. Мы, например, до сих пор тянем версию для IE8, где даже JS1.6 нативно не поддерживался.

                          • –3
                            Edge такое же ненужное гуано, как как и его предшественник, пока не запилят расширения
                            • +3
                              давно уже запилили
                            • +1
                              Корпоративный сектор. Старые компы с XP (конечно же времён царя гороха). И дряхлые бабки с IE8!
                              • 0

                                И тысячи их! (точнее, овер 200 000 человек)

                      • +2
                        Наверное, это так, если хочешь соответствовать некоторому абстрактному «рынку» и пробовать по технологии за вечер — сейчас это уже невозможно. Если же требуется реальное приложение и ты работаешь над ним долго, то стек сам органично выстраивается.

                        Приложению на три таблицы не требуется поддержка? Почему бы не использовать чистый JS.

                        Если же приложение больше, то никакого такого ада там и нет. По мере необходимости из широкого ассортимента выбираются инструменты и им находится применение. И TypeScript будет в радость, и обилие npm пакетов и сборщики. Есть возможность собрать проект без webpack — замечательно, хотите использовать React с jQuery? Без проблем.

                        Но многим хочется готовых мануалов «Как стать модным фронтом 2016+», много лет назад они брали и писали же на чистом JS такой-то UI и все хорошо было то, а теперь надо же придумали! Хочется сразу использовать всю мощь, но что бы не разбираться. Но тогда и мощи не было бы, разрабатывали бы мощный фреймворк all-in-one, тратили бы годы на стандартизацию, имели бы мы приложение уровня 2005 года, зато было бы спокойно и понятно все.
                        • +20
                          Первая проблема в том, что работая в своем органичном стеке в течении двух лет, Вы выходите на рынок устаревшим, потому что всем нужен уже <Впишите имя> фреймворк.
                          Вторая проблема в том, что стремясь к упрощению, мы идем в непонимание того как это работает. И чем дальше, тем этого непонимания больше.
                          А что самое неприятно, что даже потратив время и силы на то что бы разобраться как же работает тот или иной супер фреймворк, ты не получаешь ничего, так как завтра он, опять же, уже никому не нужен.
                          • +1
                            Не может быть так, чтобы масса суперуниверсальных разработчиков не уменьшалась в таких условиях. Уменьшается масса, снова становятся востребованы разработчики с опытом решения реальных задач, а не мультистековые ребята, тратящие на поддержание своих знаний 90% рабочего времени.

                            В общем не понимаю, как эта ситуация хуже стала? Раньше разработчик разбирался в JS + jQuery и поверх писал свои велосипеды, а сегодня использует готовое, разбираясь в вещах уровнем выше, но не брезгуя смотреть открытый код? Получается проработав N лет, точно так же терял это время на специфичную для клиента систему, а сейчас только отрывается на несколько версий фреймворка, если совсем не смотрит по сторонам.
                            • +5
                              > Первая проблема в том, что работая в своем органичном стеке в течении двух лет,
                              > Вы выходите на рынок устаревшим, потому что всем нужен уже <Впишите имя> фреймворк.
                              ИМХО, это как бы и не проблема. Веб-разработчика «продаёт» его портфолио, а не знание фреймворков. А заказчик, в общем случае, говорит: «Мне нужен сайт с таким-то функционалом», и практически никогда не говорит «Мне нужен сайт на Angular».
                              У нас, к примеру, разработка сайтов направление непрофильное, но вполне активное. И мы давно уже не ввязываемся в эту гонку вооружений. Никакой выгоды с этого мы не получаем, т.к. затраты ресурсов на освоение и внедрение в проектах свежих новинок в мире JS нынче превышают преимущества от их использования.
                              • +1
                                Это если исходить из краткосрочных проектов под множественных заказчиков. А если ищешь работу, то в объявлениях достаточно часто указываются конкретные фреймворки. И, к сожалению, на собеседованиях порой любят гонять именно по специфичным для фреймворка вопросам. К счастью, однако у большинства работодателей (по крайней мере тут, в Чехии) существует прекрасное понимание того, что мир JS быстро эволюционировать, чтобы ждать мега-профи по какому-то конкретному фреймворку. А с учетом того, что по крайней мере в бекенде, часто JS используется для микросервисов, то больших познаний всего обилия, перечисленного в статье, и не требуется.
                                • +2
                                  > если ищешь работу, то в объявлениях достаточно часто указываются конкретные фреймворки. И, к сожалению, на собеседованиях порой любят гонять именно по специфичным для фреймворка вопросам.

                                  Речь о конкуренции. Если требуется JS программист, пришло трое, один знает ext.js, второй angular 2, третий react.js, а проект будет разрабатываться (допустим уже известно) на react.js — то кого возьмут?

                                  Ответ обычно очевиден.

                                  И не важно, что мир JS меняется стремительно. — Речь о конкуренции на рынке труда.
                                • 0
                                  >И мы давно уже не ввязываемся в эту гонку вооружений
                                  Это прекрасно ровно до того момента, когда дев с 5+ лет работы у вас, решит походить на собеседования.
                                  Т.е. идея хороша, но из-за тенденции (как мне кажется) опасна для разработчиков.
                                  • 0
                                    В текущем JS-хаосе это как раз нормальный вариант… Лучше через 5 лет изучить то, что будет тогда актуально, чем каждый месяц учить что-то, что через 5 лет никому нафиг не нужно будет :-)
                                    • 0
                                      > Это прекрасно ровно до того момента, когда дев с 5+ лет работы у вас, решит походить на собеседования.

                                      Со стороны работодателя, это прекрасно и после.
                                      • 0
                                        Думаю большинство присутствующих здесь не работодатели. Так что в большинстве своем это скорее грустно.
                                        • +2
                                          Да не так уж и грустно, на самом деле. Вы думаете, разработчику JS будет полезно набивать свои мозги технологиями, которые будут неактуальны через пару-тройку лет? Если речь идет о своей полезности на рынке, то достаточно потратить несколько месяцев перед тем, как выходить на рынок труда, на изучение того, на что в настоящее время есть спрос. А не поддерживать себя во мнимой актуальности, затянув в свои мозги огромный зоопарк фреймворков и инструментов, 90% которого не пригодятся больше никогда.
                                          • 0
                                            Частично соглашусь, подход здравый. Но так хочется быть в курсе.
                                  • +7
                                    Первая проблема в том, что работая в своем органичном стеке в течении двух лет, Вы выходите на рынок устаревшим, потому что всем нужен уже <Впишите имя> фреймворк.


                                    tl;dr — вообще в вакансиях сейчас всего два фреймворка: AngularJS и React.

                                    Если подробнее, то сильно преувеличено. Давайте разберем на
                                    примере
                                    image


                                    Формально здесь видно четыре столбика из ExtJS, Backbone, AngularJS и React.
                                    Здесь и далее имеется в виду сайт hh.ru и город Москва (поскольку я из Москвы), и Киев (из вашего профиля)

                                    1) Начнём с ExtJS. В принципе этот старичок сегодня даже в статье упоминался, но в вакансиях бывает часто. Не забываем в запросе дописать «extjs not angularjs not angular not react». Число вакансий уменьшится на 1/3 (для Киева вообще вдвое) по сравнению с запросом только «extjs». В оставшихся вакансиях часто требуется не чистый «фронтендер», а всякие ASP.NET, Java, PHP и прочие бэкендеры от которых будут просить еще и фронтенд писать. Чистых вакансий на фронтенд, где требуется ExtJS и не подходит ангуляр или реакт, я нашел штук 5 в Москве и 0 в Киеве.
                                    2) Далее Backbone. Он упоминается в 123 вакансиях для Москвы, но без AngularJS и React только 29. Для Киева цифры — 34 и 11 соответственно. Итого, если вы не знаете уже слегка подустаревший Backbone вы потеряете максимум треть от тех вакансий, где его просят.
                                    3) AngularJS. Его первая версия — один из стандартов SPA разработки сегодня. В Москве на него аж 300 вакансий, отдельно от React — 234.
                                    В Киеве — 72 и 58. Да ангуляр стоит учить.
                                    4) React. Появился в 13, массовое распространение в 14. Всего вакансий в Москве и Киеве — 224 и 58 соответственно. Без ангуляра 178 и 30.
                                    Реакт тоже стоит уже учить, если не выучили.

                                    Другие фреймворки
                                    5) Ember: без AngularJS и React нашел одну вакансию в Москве. В Киеве не искал.
                                    6) Vue.js: без AngularJS и React в Москве не упоминается.

                                    Другие технологии
                                    1) ES6/ES2015 — суммарно около 80-ти вакансий в Москве, почти везде пишут, что знание рассматривается как преимущество.
                                    2) TypeScript — 78 вакансий в Москве, как требование выдвигает примерно каждый третий.

                                    Итого на рынке труда фреймворков сейчас два, массовое распространение их началось 4 и 2 года соответственно. Для трудоустройства будет достаточно любого из них. Через годик хорошо бы что-то прочитать про ES2015 и TypeScript (это опять же для рынка труда, нормальные разработчики и так про них в курсе).
                                  • 0
                                    Даёшь JavaScript on Rails!
                                    • +1
                                      > Даёшь JavaScript on Rails!

                                      Уже дали и назвали CoffeeScript — Но НЕ ВЗЛЕТЕЛ.
                                      • +1
                                        Я так понимаю, RoR — это такой фреймворк со всем необходимым под Ruby, а Coffee же вроде просто сахарок для JS, в общем очередной транспайлер. Или мои сведения ошибочны?
                                        • 0
                                          Вы совершенно правы.

                                          «Если копнуть немного истории, то с 2009-го года язык писался на Ruby, с 2010 — он пишется на самом же CoffeeScript.
                                          И в Ruby on Rails, начиная с версии 3.1, он «заменил» JavaScript.»

                                  • +25
                                    В итоге:
                                    — 3 дня потратил на настройку среды;
                                    — 10 дней машинного времени на 1500 сборок;
                                    — 2 часа писал уникальный код;
                                    — 3 дня на обьяснение заказчику своей крутизны;
                                    — 10 дней на споры с заказчиком о ньюансах архитектуры;
                                    — за 2 часа рабочего времени получил оплату по тарифу 150 у.е./час (фактически по тарифу чернорабочего 10 у.е. /день за 30 календарных дней)

                                    Все пошло на оплату интернета, комуналки и жрачку. Но теперь можно кичится, что за меньше чем за 150 у.е./час даже нефиг браться.
                                    • 0
                                      Зато на следующем заказчике можно нагреть руку. Да и вообще, получается, что ты учился, так тебе еще за это платили. Неплохо так.
                                      • 0
                                        А потом оказывается что React умер. Angular 2 — не «пракатило!!!».
                                        Все пишут на «WebAssabley». И вообще все хотят assembler в web!
                                        • 0
                                          >А потом оказывается что React умер. Angular 2 — не «пракатило!!!».
                                          Все пишут на «WebAssabley». И вообще все хотят assembler в web!

                                          Вряд ли мы можем СЕЙЧАС предугадать что будет через ПЯТЬ лет.
                                          • 0
                                            А потом оказывается что React умер. Angular 2 — не «пракатило!!!».
                                            Все пишут на «WebAssabley».

                                            WebAssembly не исключает ни React, ни Angular, ни даже JQuery, наоборот, он им даёт новые возможности.
                                      • +27
                                        У меня дежавю, или я уже читал что-то в точности похожее на хабре? Даже повествование было таким же)
                                      • +17
                                        пока читал статью написал фреймворк!
                                        • +38
                                          Пока читал комментарии этот фреймворк безвозвратно устарел.
                                        • +7
                                          А в чём прикол с python3? Он же офигенный <3
                                          • +4
                                            Вы — счастливый человек, если не приходилось поддерживать код, который бы работал под 2.7 и 3.х одновременно :)
                                            • –7
                                              А не могли бы объяснить — зачем себя так мучить? Используйте python2 и не парьтесь.
                                              • +13
                                                python2
                                                У Вас ошибка в слове «python3».
                                                • +4
                                                  я на данный момент занимаюсь разработкой в неком стартапе, у которого, кроме бизнес-пользователей, есть еще две категории разработчиков:
                                                  — математики/актуарии, которые привыкли к питону 2.
                                                  — современные разрабочики, интегрирующие нашу систему в целевые платформы, разрабатывающиеся сейчас, язык интеграции — питон 3

                                                  Первых с каждым годом становится все меньше, вторых все больше (с учетом того, что многие компании пинками загоняют своих разработчиков только в питон3).

                                                  Ну так вот. Я это научное сообщество, которое привыкло к двойке и не привыкло меняться, хочу молотками по головам постучать. Они любят, например, jupyter, у которого ядро по умолчанию — питон 3. И любят они numpy/scipy etc, которые тоже сейчас по умолчанию под питон 3 разрабатываются. Но — они будут плакать и колоться, но жрать кактус, пытаясь установить jupyter + scipy + matplotlib + еще кучу всего, вместо двух команд в pip3.
                                                  • +2
                                                    Как молодая часть этого научного сообщества, я пытаюсь использовать и продвигать Python3. Но есть одна проблема: все расчёты обычно выполняются для кучи очень дорогих данных (как пример — коллайдерные коллаборации). И тут очень важно верифицировать инструменты, ведь один баг может привести к неправильным результатам для данных стоимостью в пару десятков-сотен миллионов доларов. Поэтому все по максимуму держатся за старые и проверенные временем инструменты.
                                                    • 0
                                                      Довольно редкая ситуация, как мне кажется.
                                                      • 0
                                                        Нет. Как раз абсолютно типичная. Стартапы могут позволить себе использовать python3, потому что им «нечего терять». И то не всегда, как видим.

                                                        В крупных же сообществах только сейчас потихоньку-полегоньку начинают задумываться о том, что они будут делать в 2020м году. Причём я не удивлюсь если будет принято решение выделить средства на то, чтобы поддерживать python2 — благо и делать-то там особо много не нужно будет.

                                                        В том же Android'е куча скриптов на python'е — и нет даже планов никаких по адаптации python3. Та же самая история — в Chromium'е. Обратите внимание на активность разработчиков в соответсвующем баге.
                                                        • 0
                                                          Я все-таки про общую картину со всеми разработчиками и проектами, в смысле что вообще со всеми.
                                                          • +1
                                                            А «вообще со всеми» — ситуация такая, как я и сказал: подавляющее большинство разработчиков — используют python2 и о переходе если и задумываются, то не очень сильно. Потому что для них python — это инструмент и переделывать всё-на-свете из-за того, что кому-то моча в голову ударила и нормального плана перехода так никто и не придумал — они не будут.

                                                            Люди, которые познакомились с python'ом после 2008го года, в основном используют python, но их пока — далеко не большинство. К тому же когда они приходят в компанию, где python начали использовать раньше они начинают «жрать кактус» вместе со всеми.

                                                            В результате после семи лет пения «всё хорошо, прекрасная маркиза» разработчики python3 начали задумываться над тем, как бы всё-таки убедить этих «ретроградов» перейти на новую версию.

                                                            Придумали много разных вещей, но не поняли главного: не будут люди в коммерческих компаниях переписывать свои скрипты. Не будут. Либо будут разработаны «транспайлеры», либо python2 заживёт отдельной жизнью рано или поздно.

                                                            P.S. На Хабре вы этого, впрочем, можете и не заметить, так как работает очень хороший отбор: людям, которые сделали что-то новое — важно об этом заявить на Хабре, людям, которые работают над проектом, которому лет 20-30 — это нафиг не нужно. Но правда заключается в том, что новых проекты — быстро возникают и быстро умирают, а проекты 30-летней давности остаются. Вместе с python2. Так что я, когда писал, что нужно писать на python2 и «не париться» не лукавил ни разу. Не бойтесь вы 2020го года — что-нибудь да придумают.
                                                            • +1
                                                              lamo4ok > Либо будут разработаны «транспайлеры», либо python2 заживёт отдельной жизнью рано или поздно.

                                                              Эка право. И тут Javascript обошёл всех, с идеей использования этих самых «транспайлеров».

                                                              :-0
                                                              • +1
                                                                Всё новое — это хорошо забытое старое. Транспайлеры JavaScript'а решают ту же задачу, которую решают модули TURBO3.TPU и GRAPH3.TPU, по сути.

                                                                Это как раз разработчики python3 предложили «уникальное решение»: скрипт, который превращает python2 в неработающий python3 — так что переход от python2 к python3 получается «по бразильской системе»: либо вам везёт и вы переходите успешно, либо вас увольняют нафиг, так как никакой возможности отката нет в принципе!

                                                                С тем же успехом можно переходить не с python2 на python3, а, скажем, с python'а на Go. Забавно впрочем, что и разработчики Perl'а и PHP наступили на те же грабли в 6й верcии языка… Только те оказались в состоянии понять — что произошло, а разработки python'а — пока нет…
                                                  • 0
                                                    поддержка это поддержка, тут люди так при разработке мучаются )
                                                    • +1
                                                      Не вижу никаких проблем поддерживать код, который бы работал под 2.7 и 3.4+.
                                                      Вот поддерживать одновременно 2.7 и 3.0 — это да…
                                                    • +1
                                                      да офигенный, это просто хороший пример того, как можно делать версионность без 7 вариантов, которые нужно транспайлить из одного в другой.
                                                      Похоже, для персонажа из статьи, это не то, что ему нравится.
                                                      • –3
                                                        О как? А как по мне — так это отвратительный пример. Приведший к тому, что существует такое себе сферическое сообщество питонистов, объясняющих друг-другу как у них всё хорошо. И есть люди, которые реально используют питон — и им все эти чудеса по барабану. И которые просто используют python 2 — и всё. Ни о каком python 3 речь просто не идёт.

                                                        Если вы считаете, что это лучще, чем транспайлеры… ну это ваши проблемы.
                                                        • 0
                                                          Реально использую питон3. ЧЯДНТ? Правда, свежие версии андроида я не пишу, ну так им прекрасный мир программирования не ограничивается.
                                                          • 0
                                                            А вашими стартапами — ограничивается? Правда заключается в том, что переход от python2 к python3 — один из самых неудачных подходов к «версионности».

                                                            Не самый неудачный, впрочем. Попытка перехода от perl5 к perl6 или от php5 к php6 — ещё мрачнее (обе кончились тем, что никто никуда так и не перешёл — причём php6 в конечном итоге просто умер).

                                                            Причём очень может быть что python окажется там же, где perl: просто в конечном итоге, потеряв несколько лет, разморозят развитие 2й ветки и всё.

                                                            Я лично знаю достаточно много людей, которые просто отказались от использования python3. Уже одно то, что в нём нельзя безопасно получить список файлов в каталоге — много говорит о том, какую траву курили разработчики.
                                                            • 0
                                                              Справедливости ради PHP6 не релизился, поскольку сами разработчики признали неудачной попытку реализовать эту версию, вместо чего продолжили эволюцию ветки 5.x. Perl6 же вышел, когда интерес к Perl5 как таковому уже угас, а сам язык в современных представлениях сильно устарел и его нишу постепенно занимает Python2.
                                                              • 0
                                                                Проблема в обоих случаях была одна и та же: вот этот вот самый «подход к версионности» в стиле перехода с NCP на TCP. Это неплохо работает, когда у чего-то пользователей — сотни, хуже — если их тысячи и совершенно не работает если их миллионы. Только в случае с PHP и Perl'ом это привело к тому, что переход на несовместимые версии так и не состоялся, а в случае с Pyhton'ом — к появлению костылей типа того же six. Ну а большая эклектичность мира JavaScript обозначает автоматом, что костылей нужно больше, вот и всё.
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                  • –1
                                                                    Если ваша единстуенная цель — заработать, то вам биржевыми спекуляциями заниматься надо, а не программированием.

                                                                    А вот если вы хотите что-то сделать, чем будут пользоваться через 10-20 лет, то лучше выбирать популярные технологии, а не эффективные. Ибо на долгих дистанциях наличие разработчиков — важнее эффективности.
                                                    • +28

                                                      Как оно в действительности писать на Javascript в 2016 году.


                                                      Хэй, мне нужно создать страницу, которая показывает последнюю активность пользователей, так что мне надо получать данные с REST-сервиса и отображать в некой сортируемой и фильтруемой таблице, и обновлять её, если что-нибудь поменялось на сервере. Я думаю использовать jQuery для получения и отображения данных.

                                                      — Конечно, ты можешь по прежнему использовать jQuery. Но если ты планируешь сделать что-нибудь более сложное на фронтенде ты, вероятно, должен попробовать React. Это даст большие преимущества в дальнейшем.


                                                      — Звучит круто. Как мне лучше начать разработку с React?


                                                      — Самый простой путь: запустить npm install create-react-app -g в своем терминале и можешь начинать проект сразу после этого.


                                                      — Круто, ты так говоришь, будто не нужно никаких дополнительных настроек?


                                                      — Нет.


                                                      — Мне нужно установить специальные IDE, такие как Visual Studio, Android Studio, или XCode?


                                                      — Нет, просто создай свое приложение командой create-react-app my-cool-app и ты готов к пути.


                                                      — А что насчет дополнительных зависимостей? Может мне нужно установить Java на мою машину? Может мне также нужны Maven, Gradle, CocoaPods, или может быть мне нужно скачать дополнительно 20-гигабайтный SDK?


                                                      — Нет, просто выполни cd в папку со своим проектом и запусти npm start. Это всё.


                                                      — Мне нужно собирать своё приложение и ждать долгой пересборки после каждого изменения?


                                                      — Нет. Если ты сделаешь изменения, страница автоматически обновится. Если ты изменишь CSS — это будет живая перезагрузка, без обновления страницы.


                                                      — Звучит очень полезно! Я думаю так я смогу немного увеличить скорость процесса разработки. Но подожди, что делать, если мне когда-нибудь понадобится развернуть production версию моего сайта? Потому-что никто в действительности не развертывает неминифицированные версии index.html, app.css, main.js в production, правильно?


                                                      — Да, ты прав. Если тебе нужно развернуть production сборку своего сайта просто запусти npm run build и всё что тебе нужно бедут в папке /build. Миниицированное, оптимизированное и готовое к развертыванию.


                                                      — Спасибо приятель, очень полезно.


                                                      https://medium.com/@kitze/how-it-actually-feels-to-write-javascript-in-2016-46b5dda17bb5#.wvne8zb17

                                                      • +21
                                                        Всё хорошо. За исключением того, что это неправда в любом случае кроме вывода hello world.
                                                        • +1

                                                          create-react-app предоставляет необходимый минимум для работоспособного приложения. Этого минимума достаточно для решения текущей задачи пользователя — вывести фильтруемую и сортируемую таблицу. Остальное, например, роутинг (react-router), централизованное хранение данных (redux), библиотеку с набором готовых компонент интерфейса — подключается по мере развития приложения и/или роста знаний разработчика.


                                                          Это отличный стартовый шаблон для изучения React или начала разработки нового приложения.


                                                          Посмотрите https://github.com/facebookincubator/create-react-app


                                                          Также есть простой способ сделать из вашего приложения Progressive Web App, с возможностью установки в смартфон, для работы без подключения к интернету https://github.com/jeffposnick/create-react-pwa/compare/starting-point...pwa

                                                          • 0
                                                            Только при этом в простейшем виде нужно использовать компонент для таблицы вроде https://www.npmjs.com/package/react-sortable-table — это уже приводит к знанию jsx. А данные для таблицы надо откуда-то брать, для этого делать серверную часть с апи, для этого использовать что-нибудь вроде express плюс модуль для работы с СУБД, а данные нынче модно хранить в redis… В общем, даже такая простейшая задача превращается в какое-то исследование и больше всего напоминает мне работу с C++.
                                                            • –3
                                                              знанию jsx

                                                              Звучит примерно как «знанию TXT».

                                                            • +3
                                                              В Реакт приложении все самое сложно как раз и начинается после подключения redux. Код начинает обрастать reselect, recycle, reduxThunk и код постепенно превращается в набор черных ящиков, которые гоняют данные между собой и что-то с ними делают.
                                                          • –3
                                                            В первый раз за 10 лет чтения хабра пожалел, что не могу поставить плюс комментарию
                                                            • 0
                                                              Сам сегодня совершенно случайно обнаружил в webstorm замечательный вариант React Starter Kit при создании проекта, с отличной документацией и работой всего стека из коробки. Как для реальной разработки, пока оценить не могу, но для ознакомления — волшебно!
                                                              • +3
                                                                — Мне нужно установить специальные IDE, такие как Visual Studio, Android Studio, или XCode?

                                                                — Нет, просто создай свое приложение командой create-react-app my-cool-app и ты готов к пути.

                                                                — Что, даже текстовый редактор не потребуется?


                                                                — Нет, реакт настолько крутой, тебе вообще не придется писать код.

                                                                • 0
                                                                  >Нет, реакт настолько крутой, тебе вообще не придется писать код.

                                                                  Сбылась мечта программиста. (С)
                                                                  ;-)
                                                                • 0
                                                                  да но зачем мне nodejs и npm если я хочу сделать только SPA приложение которое общается с бэкэндом который не на nodejs работает? Т.е. чисто фронтэнд. В том вопрос.
                                                                  • +2

                                                                    А зачем вам текстовый редактор, если вы делаете фотогалерею? Но, я думаю, без него вы мало что наверстаете.


                                                                    Вот и с nodejs и npm так же — это инструменты разработки, которые делают разработку удобнее. Не надо относиться к nodejs как к серверу — на самом деле, это всего лишь консольная запускалка скриптов.

                                                                    • –2

                                                                      А чем в качестве «консольной запускалки скриптов» плоха (извините) консоль?

                                                                      • +2

                                                                        Консоль сама по себе ничего не запускает. Консоль лишь рисует символы.

                                                                        • 0

                                                                          Могу я узнать причину минуса? Может быть, я не знаю какого-то определения, но я слабо себе представляю запуск скрипта в консоли без каких бы то ни было консольных программ.

                                                                          • –4
                                                                            >Могу я узнать причину минуса?

                                                                            Вряд ли. Минусы тут ставят от балды.
                                                                            • 0
                                                                              В качестве предположения: слово «консоль» используется зачастую и для обозначения интерпретатора командной строки, запущенного в консоли («набери в консоли, запусти в консоли» и т.д.). Просто в силу того, что масса приложений ныне — GUIевые, и консоль прочно ассоциируется с и.к.с.Тот же .bat файл, интерпретируемый инт. командной строки, это скрипт.
                                                                              • +1

                                                                                Я и сам слово "консоль" в этом смысле часто использую. Но даже в этом случае скрипт на js не может быть запущен "в консоли" напрямую, вот ведь в чем дело...

                                                                                • +1
                                                                                  Но даже в этом случае скрипт на js не может быть запущен «в консоли» напрямую

                                                                                  В вебинструментах современных браузеров есть вкладка консоли, которая вполне исполняет JS код.
                                                                                  • 0

                                                                                    Оу, спасибо, теперь до меня дошло что имелось в виду...

                                                                          • +1

                                                                            Если вы про консоль браузера — то она является неплохим инструментом для отладки клиентских скриптов. Но js-скрипты не делятся на клиентские и серверные, есть еще одна категория скриптов — системные скрипты. (Прилагательное "системный" в данном случае означает, что ими пользуется не конечный пользователь, а разработчик)


                                                                            А именно, есть такие скрипты как


                                                                            browserify — обычному веб-разработчику этот скрипт и правда не интересен. Но разработчику библиотеки этот скрипт позволяет просто писать код, а не думать про правильные обертки для модуля в разных окружениях;


                                                                            babel — компилятор js, позволяет использовать при разработке самые свежие фичи, не дожидаясь пока они дойдут до браузера;


                                                                            webpack — умеет минифицировать и склеивать скрипты и таблицы стилей.


                                                                            Это — исключительно полезные скрипты, которые стоит попробовать любому веб-разработчику. Они ничего не усложняют и не замедляют — напротив, после начального изучения они нехило упрощают веб-разработку и ускоряют работу веб-приложения (webpack, за счет минификации). И каждый из них для своей работы должен читать файлы с диска и записывать их на диск, чего нельзя добиться в консоли браузера. Поэтому для их запуска нужна nodejs

                                                                          • 0
                                                                            Но все таки мой вопрос была немного о другом, что делать если у меня уже есть бэкэнд сервер и и мне нужно создать SPA которое соответственно полностью выполняется только на стороне браузера?
                                                                            • 0

                                                                              Извиняюсь за грубость, но вы чем читаете? Какая вообще разница, какой у вас есть бэкэнд, и есть ли он вообще?


                                                                              nodejs — это не сервер.

                                                                              • 0
                                                                                Да, но тогда получается для фронтэнд разработки ставить nodejs, и прочие вещи описанные в статье и получать весь этот ад? Пытался разобраться в этих кучах фреймворков, но похоже что каждый день выходит новый фреймворк обещающий убрать проблемы своих прендшественников, но в итоге получается еще один стопицотый фреймворк.
                                                                                • 0

                                                                                  Какой ад?


                                                                                  Во-первых, фреймворк вам надо выбрать один раз и его использовать. Старый фреймворк устаревает когда его перестают поддерживать разработчики, а не когда выходит новый.


                                                                                  Во-вторых, клиентские фреймворки к nodejs не имеют ни малейшего отношения.

                                                                                  • 0
                                                                                    Во-вторых, клиентские фреймворки к nodejs не имеют ни малейшего отношения.


                                                                                    Тогда для чего мне nodejs если у меня клиент в виде SPA как я написал?
                                                                                    • 0
                                                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                                                      • 0
                                                                                        А для чего нужен gcc в с++ проектах? Для сборки. На node.js написан софт, который собирает ваш SPA, все, больше он не нужен. Если переписать эти сборщики с node.js на питон или даже на плюсы, для SPA ничего не поменяется.
                                                                        • +7

                                                                          Не надо выдавать бредни воображаемого "специалиста" за состояние технологии...


                                                                          JQuery? Да, можно. Но ты еще не устал?

                                                                          — Что случилось с HTML?
                                                                          — Ничего не случилось. Но для динамической разметки нужен свой язык.
                                                                          — Типа шаблонизатора?
                                                                          — Да, JSX — это шаблонизатор.

                                                                          — Другая библиотека? Что за Babel?
                                                                          — Компилятор. Позволяет пользоваться новыми фичами языка раньше, чем их поддержка появится в браузере.

                                                                          — Слушай, я просто хочу загрузить кучу данных с сервера, просто подключить JQuery из CDN и просто получить данные с помощью AJAX. Почему я не могу сделать это?
                                                                          — Ты можешь так и сделать, но ведь потом эти данные надо еще вывести на страницу.

                                                                          — Давай придерживаться React, я уже узнал слишком много о нем. Так что, если мне нужно использовать React, я вытяну его из этого NPM, а затем использую Browserify?
                                                                          — Да.
                                                                          — Это кажется слишком сложным, чтобы просто взять кучу зависимостей и связать их вместе.
                                                                          — Не сложнее чем скачивать каждую библиотеку вручную.

                                                                          Фрагмент про менеджеры задач не нужен — потому что они не нужны для этой задачи. Как и про TypeScript, функциональное программирование и прочее.

                                                                          — О, да. Fetch это имя нативной реализации для выполнения XMLHttpRequests.
                                                                          — О, AJAX.
                                                                          — Ну да, Fetch это новая реализация AJAX. Помнишь, XMLHttpRequest был настолько неудобен, что все использовали только jquery-обертку вокруг него? Теперь обертка не нужна.

                                                                          — А методы AJAX JQuery не возвращают промисы?
                                                                          — Да, возвращают.

                                                                          — Это третий раз, когда ты говоришь о await, но я понятия не имею, что это такое.
                                                                          — Синтаксический сахар для промисов.
                                                                          — У… а можно его не использовать?
                                                                          — Можно. Наверное, так будет даже лучше первое время — потом будет понятно что за магия внутри происходит.

                                                                          • –1
                                                                            Ну вот. А у меня другой опыт и последние пару месяцев депрессия и аллергия на js buzzwords.
                                                                            — Другая библиотека? Что за Babel?
                                                                            — Компилятор. Позволяет пользоваться новыми фичами языка раньше, чем их поддержка появится в браузере.

                                                                            Причем каждую «фичу» типа того же Реакта нужно скачивать отдельно.

                                                                            — Слушай, я просто хочу загрузить кучу данных с сервера, просто подключить JQuery из CDN и просто получить данные с помощью AJAX. Почему я не могу сделать это?
                                                                            — Ты можешь так и сделать, но ведь потом эти данные надо еще вывести на страницу.

                                                                            Ну, прямо там взял и вывел данные, даже не выходя из метода.

                                                                            — Ну да, Fetch это новая реализация AJAX. Помнишь, XMLHttpRequest был настолько неудобен, что все использовали только jquery-обертку вокруг него? Теперь обертка не нужна.

                                                                            Кроме случаев, когда нужно обрабатывать progress event.

                                                                            ЗЫ. Заметил, что чем больше денег приносит приложение, тем меньше парятся что у него внутри.

                                                                            • 0
                                                                              Причем каждую «фичу» типа того же Реакта нужно скачивать отдельно.

                                                                              Реакт — это не фича, Реакт — это библиотека.


                                                                              Кроме случаев, когда нужно обрабатывать progress event.

                                                                              Ни разу не было такой задачи за два года веб-программирования...

                                                                              • –1
                                                                                Поэтому в кавычках. Я не про сам Реакт, а его плагин для Babel.

                                                                                А у меня все время прогресс загрузки хотят видеть поэтому приходится или XHR «вручную» использовать или сторонние типа axios который еще и в промисы умеет.
                                                                                • –1

                                                                                  Загрузки чего? Вы грузите пару мегабайт в ajax-запросе, да еще и "все время"?

                                                                          • +2
                                                                            надо было ставить linux Ember
                                                                            • 0
                                                                              Вот уж да!!! Очень мне он нравится, вроде всё тоже, что и раньше, но при этом современный код!
                                                                              • 0

                                                                                Не учтено, что он тяжеловес (серверная сторона) тот ещё.

                                                                                • 0
                                                                                  Ну потому и тяжеловес, потому что всё из коробки) Там уже в основном вся тяжесть из-за специфического поведения npm, который тащит всё что можно
                                                                              • 0
                                                                                Подтверждаю!
                                                                              • +14
                                                                                Чорт, я как раз перестал иметь дело с фронтендом 6 лет назад, а сейчас мне надо получить немного данных по rest'у и вывести их на страничку… И тут такой ужос!..
                                                                                • +11
                                                                                  Хинт: jQuery все еще развивается, новые версии выходят и т.д… Вы можете сделать все в стиле 2010, и оно будет прекрасно работать во всех современных браузерах включая сафари.
                                                                                  Обычные пользователи вашей странички скорее всего не будут заглядывать в код и никогда не догадаются о том, что он не модный.
                                                                                  А весь этот выше перечисленный зоопарк можно оставить тем, кто ведет действительно крупные проекты или гонится за модой.
                                                                                  • 0
                                                                                    Согласен, это все нужно для одностраничных сайтов с динамическим всем-всем, а для простейших задач jQuery и ее армии плагинов за глаза хватает.
                                                                                    • +1
                                                                                      > а для простейших задач jQuery и ее армии плагинов за глаза хватает.

                                                                                      Простейшие задачи не в тренде. ;-)
                                                                                      • +1
                                                                                        Ну да.
                                                                                        В тренде решать не задачи (самым простым возможным способом), а надуманные проблемы, которые сами создали при решении задач. :)
                                                                                        • +1
                                                                                          >В тренде решать не задачи (самым простым возможным способом), а надуманные проблемы, которые сами создали при решении задач. :)

                                                                                          Верно. Это как первая модель авто типа «Форд-Т» — прост и понятен.

                                                                                          Сейчас же, чтобы поехать, надо аж столько в авто всего запихнуть — что страшно становится… разработчику авто, но не водителю этого современного авто, жмущему на кнопку! ;-)
                                                                                  • +2
                                                                                    Больше половины из указанного точно не понадобится.
                                                                                  • +1
                                                                                    Я наверное странный человек, но неужели не хватит стека:

                                                                                    js +jQuery +backbone/angular/ember/react (на выбор что-то одно)? + grunt (если надо сборку делать).
                                                                                    • +7
                                                                                      Для описанной задачи хватит даже более простого стека:
                                                                                      js + jQuery + DataTables (jQuery плагин) + grunt (если надо сборку делать).

                                                                                      А автор статьи просто не умеет выбирать подходящие инструменты и способы решения поставленной задачи, создавая для себя проблемы на пустом месте.
                                                                                      • –7
                                                                                        >Я наверное странный человек, но неужели не хватит стека:

                                                                                        Если вам этого хватает, то вы — откатываетесь назад стремительным домкратом. :-)

                                                                                        Чтобы оставаться только(!) на месте, вам надо… бежать. (Как говорил известный персонаж).
                                                                                      • +4
                                                                                        Великолепно!
                                                                                        • +8
                                                                                          Прямо все, что я думаю о фронтенде. Начал использовать angular, а он уже устарел оказалось, а angular 2, это какой-то ад. Вернусь на jQuery, мне всего-то данные с rest отобразить в таблице.
                                                                                          • +40
                                                                                            image
                                                                                            • –2
                                                                                              Del
                                                                                              • –1
                                                                                                Шедеврально)))
                                                                                                • 0
                                                                                                  Именно потому я использую VanillaJS и jQuery. Максимум, могу добавить шаблонизатор на стороне сервера (вроде liquid, erb).
                                                                                                  • +3
                                                                                                    И ни слова о том как это «многообразие» потом надо поддерживать. Как будто «написал и забыл» работает.
                                                                                                    • +1
                                                                                                      Так в этом и суть.
                                                                                                      Все это потом будет оплачивать заказчик. :)
                                                                                                    • +4
                                                                                                      Труъ.
                                                                                                      Недавно решил попробовать запилить проект, но на NodeJS+express+React. До этого NodeJS тыкал давным-давно, когда он еще только появился. Иии…
                                                                                                      WebPack, Babel и прочие страшные слова вызвали легкое недоумение, но в принципе понятно, для чего это надо и зачем. В ES6 действительно куча классных фич, и оно стоит того.
                                                                                                      Потом тыкался с express. Вроде бы это самый популярный и простой фреймворк на данный момент? Но черт побери, почему в 2016 году в самом популярном и простом фреймворке нужно вручную подключать такие функции, как парсинг форм и cookie? Я как-то привык, что подобные вещи есть «из коробки». Может это сделано ради скорости — чтобы использовать только то, что тебе нужно? Но для скорости я предпочел бы Go, чем Javascript. А в express вообще какой-то middleware hell получается, честное слово.
                                                                                                      В итоге почти неделю я потратил только на то, чтобы разобраться во всем этом и реализовать регистрацию и вход пользователей на сайт, с подтверждением по емейлу. Посмотрел на все это дело… Плюнул, снес все нафиг и ввел что-то типа: rails new myapp -B && cd myapp && echo "gem 'devise'" >> Gemfile && bundle install && rails g devise User && rake db:setup. Всего несколько команд дали мне функционал, на который я убил кучу времени.
                                                                                                      Да, у меня нет опыта в написании проектов на NodeJS, express и прочим. Профессионалы этого дела запросто заткнут меня за пояс, да и вообще презрительно прочитают этот комментарий и гневно уничтожат одной тирадой. Но лично для меня все эти штуки до сих пор сыроваты и сложны в использовании, тем более когда под рукой уже есть наработанный и вполне готовый функционал.
                                                                                                      • 0
                                                                                                        Но черт побери, почему в 2016 году в самом популярном и простом фреймворке нужно вручную подключать такие функции, как парсинг форм и cookie?

                                                                                                        А что если вам не нужен парсинг форм? Что, если вы не используете печеньки?


                                                                                                        rails new myapp -B && cd myapp && echo "gem 'devise'" >> Gemfile && bundle install && rails g devise User && rake db:setup.

                                                                                                        Ок, вы подключили библиотеку devise и она сделала то, что вам нужно. Почему вы в таком случае не догадались использовать passport?

                                                                                                        • +1
                                                                                                          Догадался. Но если использовать только стратегию local, без OAuth и прочего, эта библиотека становится практически бесполезной. Все манипуляции с базой (поиск и добавление пользователей, проверка пароля и т. п.) производятся вручную. И получается, что все, что выполняет данная библиотека, это хранение данных в сессии.
                                                                                                          По факту эта библиотека более-менее полезна тем, кто использует различные стратегии в ней (вход через соцсети). Для local-only толку от нее практически нет.
                                                                                                          Поправьте, пожалуйста, если я не прав.
                                                                                                      • 0

                                                                                                        Расскажите, как оно учить С++ в 2016 году, чтобы писать программы конкурентоспособные на мировом рынке? Мне реально интересно узнать в практических целях.

                                                                                                        • 0
                                                                                                          Да подобный рассказ можно написать по любому развитому языку.
                                                                                                          • +1
                                                                                                            Развитый язык подразумевает, что стек раз в 2 года не переписывают.
                                                                                                          • +3
                                                                                                            Установить IDE + компилятор, читать книги, пробовать примеры.

                                                                                                            А дальше уже в зависимости от цели. Если гуи то можно в Qt погрузится. Если сервера то многообразие разных возможностей, начиная от голых сокетов, boost.asio, libev ну или еще чего-нибудь. И отдельно читать книги про многопоточность. Если игры… ну опять же можно хоть на opengl а можно взять популярный фреймворк ( тот же cocox2dx ).

                                                                                                            зы. Читая книги, помните что те из них которые написаны до появления 11 стандарта не будут охватывать все то многообразие безумных возможностей которые у нас появились. Поэтому про них нужно будет читать отдельно.
                                                                                                          • 0
                                                                                                            Спасибо! Классная статья, которая отражает рельное положение дел в веб-разработке.
                                                                                                            Куча библиотек, фреймворков и прочего соединённых костылями и дополнительными библиотеками. Всё это сдобрено всякими пакетными менеджерами и трансляторами.
                                                                                                            С одной стороны хорошо, что есть выбор, с другой стороны появляется куча проблем:
                                                                                                            — высокий порог входа в проект.
                                                                                                            — то что ты выучил и использовал на одном проекте скорее всего не пригодится в другом. К тому же будет считаться устаревшим.

                                                                                                            Можете считать меня отсталым, но меня связка ASP.Net MVC или WebAPI + JQuery + KnockoutJS вполне устраивает и пока менять не собираюсь. (Разве что может быть попробую ангуляр).

                                                                                                            Для меня хороший набор технологий, это тот, который позволяет создать и скомпилировать пустой проект за 10 минут. И разработка которого потребует как можно меньше написанного кода для рутинных операций.

                                                                                                            Мне кажется, что пока 80% браузеров не будут поддерживать TypeScript/ES2016 из коробки без необходимости перекомпиляции/преобразования — нет смысла использовать эти языки.

                                                                                                            Мне кажется, что эта мешанина библиотек и фреймворков должна пройти лет через 5 и путём естественного отбора оставить только то, что действительно удобно (как тот же JQuery в своё время)
                                                                                                            • 0

                                                                                                              Я к своему стыду аспнет кор, который 5й так и не осилил, хотя на 4м написал маленькую веб бухгалтерию пару лет назад.


                                                                                                              Сейчас вот пишу на рельсах панель управления хостингом приложений (не сайтов, это важно), с реактом на фронде и понимаю, что мне надо очень сильно помучаться чтобы подключить вебпак и внешние компоненты к реакту. Так что пока тренируюсь на кошках и реализовываю все сам, пока нет готового прототипа и денег на отдельного фронтендера

                                                                                                              • 0
                                                                                                                Мне кажется, что пока 80% браузеров не будут поддерживать TypeScript/ES2016 из коробки без необходимости перекомпиляции/преобразования — нет смысла использовать эти языки.

                                                                                                                Почему вы смело используете C#, у которого довольно сложный процесс построения (build) — но отрицаете необходимость этапа построения для клиентских языков?

                                                                                                                • 0
                                                                                                                  Потому что для того, чтобы собрать C# приложение мне не нужно устанавилвать и конфигурировать кучу инструментов. Всё происходит «само» по нажатию одной кнопки из среды разработки. А также потому, что в C# нет зоопарка стандартов и мне нет смысла писать на .Net 4.6, а потом конвертировать с помощью специальных инструментов в .Net 2.0, чтобы это заработало.

                                                                                                                  Как должно быть: поставил VS for JS, создал проект, пишешь на ES2016/TypeScript/что либо ещё. Нажал кнопку скомпилировать и оно открылось в браузере и заработало (хоть в IE10, хоть в хроме последнем).
                                                                                                                  • 0

                                                                                                                    Говорят, в ASP.NET Core так и сделано.

                                                                                                                • 0
                                                                                                                  Я бы все-таки посоветовал обратить внимание на React, вместо Knockout. Ибо Knockout — довольно тормознутая штука (по крайней мере была, до введения deferred updates в 3.4.0).