— Эй, я получил новый веб-проект, но, если честно, я не занимался веб-кодингом в течение нескольких лет, и я слышал, все немного поменялось. Ты же самый современный веб-разработчик, правда?
— Это теперь называется 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?
Комментарии (273)
Drag13
07.10.2016 15:27+27Сначала нужно создать проблему, а потом героически ее побеждать. Странно, что замечая callback hell никто не замечает tools mess.
andreysmind
09.10.2016 17:01+2Я думаю это часть моды. Делать инструменты — проще, а главное романтичнее, чем скучные аппликации для пользователей.
aon24
11.10.2016 17:06Я думаю, дело не в моде.
Толстые клиенты умирают, а толстые программисты нет. Не найдя на веб горизонте привычных классов, делают свой инструментарий. Добавьте хорошую документацию и вот вам фреймворк.
taujavarob
11.10.2016 18:44+1>Не найдя на веб горизонте привычных классов,
Ext.js — Привычные классы — свыше 300 штук.
andybelo
11.10.2016 20:34+5На моей памяти толстые клиенты умирают с времён PC-AT. Вот например, в новых iPhone -7 тончайшие клиенты — 32ГБ и 128ГБ, и самый тонкий — 256ГБ, все с разрешением экрана 1334x750 и ОЗУ 2 ГБ. Куда уже тоньше. Точно, скоро помрут тонкие клиенты <смайл>
MacIn
12.10.2016 15:09+1АППЛИКАЦИЯ, -и; ж. [от лат. applicatio — прикладывание]. 1. Способ создания изображения посредством наклеивания или нашивания на что-л. разноцветных, разнофактурных кусочков ткани, бумаги и т.п. А. на шёлке, картоне. 2. Картина, украшение и т.п., изготовленные таким способом. Сделать аппликацию. Передник с аппликацией. 3. Физиотерапевтическая процедура: накладывание на какой-л. участок тела лечебной грязи, парафина и т.п. <Аппликационный, -ая, -ое (1 зн.). А-ые работы.
application сущ. комп. прикладная программа (program)
DrPass
12.10.2016 15:42Поищите в том же словаре ещё такие слова, как дедлайн, митап и эджайл.
MacIn
12.10.2016 17:33+3Некорректный аргумент: коротких устоявшихся аналогов, имеющих такой же смысл и коннотацию этим словам в русском языке нет, поэтому мы их заимствуем напрямую.
Слову application есть — это «приложение» или «прикладная программа», в то время как «аппликация» — это либо медицинский термин, либо вид картины, выполненной при помощи наклеивания.
Т.е. употребление слова «аппликация» вместо «приложение» в данном контесте — безграмотность и отсутствие чувства языка. В то время как употребление слова «дедлайн» — норма.
Точно так же как expertise — это «мастерство» или «опыт». А «мы продаем экспертизу» — нелепый набор слов, потому что «экспертиза» в русском языке имеет иной смысл, как во фразе «проведена криминалистическая экспертиза».taujavarob
12.10.2016 18:01+1Жестокий и строгий ваш ответ то.
Товарищ хотел просто написать «апликухи» — но рука просто дрогнула у него.
Имхо, конечно, имхо. ;-)
Zenitchik
07.10.2016 16:01+3Сообщество JavaScript безумно, если оно думает, что кто-то может идти в ногу с этим.
Самое главное — что в ногу с этим не могут идти браузеры. Следовательно, и нам не стоит, чтобы не отрываться от реальности.
hell0w0rd
07.10.2016 16:19+2За чем конкретно из списка выше не успели браузеры?)
Zenitchik
07.10.2016 16:41+26Некоторые браузеры не успели сдохнуть. Поэтому некоторые вещи не получается внедрить.
hell0w0rd
07.10.2016 17:02+1Эм, старые версии браузеров, в смысле?)
sumanai
07.10.2016 23:57Походу всё, кроме вебкита. Это тайная мечта некоторых молодых разработчиков, не нюхавших гегемонию IE6 в интернете.
hell0w0rd
08.10.2016 01:16+2Вы понимаете, что edge лучше поддерживал ES6 какое-то время, а у нового safari вообще 100% поддержка, судя по ES compatibility table?
sumanai
08.10.2016 07:07Да на это пофиг тем, кто ориентируется только на вебкит и его особенности оптимизации JS. Что не статья об оптимизации- то рассказы про то, как работает V8 и как под это лучше подстроится.
hell0w0rd
08.10.2016 13:55+1Вебкит никак не относится к JS. Статьи про V8, на этом движке сделана node.js и много открытой информации о том, как он устроен, какие есть уровни оптимизаций, как работает каждый из компиляторов.
Так что это действительно проблема, но я думаю, это проблема создателей других движков. Надо больше рассказывать о себе.
Zenitchik
08.10.2016 22:18У edge очень своеобразное мнение на счёт того, как должен работать метод postMessage. Поэтому приходится для мелкомягких чертей отдельное поведение реализовывать (ага, и детектить их для этого).
Zenitchik
08.10.2016 22:17-4Мелкомягкие черти в первую очередь. Из-за необходимости поддерживать всё что можно и что нельзя, языковые нововведения может быть появляются в рабочем коде года через два после их анонса. А может, не появляются. Мы, например, до сих пор тянем версию для IE8, где даже JS1.6 нативно не поддерживался.
Cyrus
07.10.2016 16:10+2Наверное, это так, если хочешь соответствовать некоторому абстрактному «рынку» и пробовать по технологии за вечер — сейчас это уже невозможно. Если же требуется реальное приложение и ты работаешь над ним долго, то стек сам органично выстраивается.
Приложению на три таблицы не требуется поддержка? Почему бы не использовать чистый JS.
Если же приложение больше, то никакого такого ада там и нет. По мере необходимости из широкого ассортимента выбираются инструменты и им находится применение. И TypeScript будет в радость, и обилие npm пакетов и сборщики. Есть возможность собрать проект без webpack — замечательно, хотите использовать React с jQuery? Без проблем.
Но многим хочется готовых мануалов «Как стать модным фронтом 2016+», много лет назад они брали и писали же на чистом JS такой-то UI и все хорошо было то, а теперь надо же придумали! Хочется сразу использовать всю мощь, но что бы не разбираться. Но тогда и мощи не было бы, разрабатывали бы мощный фреймворк all-in-one, тратили бы годы на стандартизацию, имели бы мы приложение уровня 2005 года, зато было бы спокойно и понятно все.Drag13
07.10.2016 16:16+20Первая проблема в том, что работая в своем органичном стеке в течении двух лет, Вы выходите на рынок устаревшим, потому что всем нужен уже <Впишите имя> фреймворк.
Вторая проблема в том, что стремясь к упрощению, мы идем в непонимание того как это работает. И чем дальше, тем этого непонимания больше.
А что самое неприятно, что даже потратив время и силы на то что бы разобраться как же работает тот или иной супер фреймворк, ты не получаешь ничего, так как завтра он, опять же, уже никому не нужен.Cyrus
07.10.2016 16:32+1Не может быть так, чтобы масса суперуниверсальных разработчиков не уменьшалась в таких условиях. Уменьшается масса, снова становятся востребованы разработчики с опытом решения реальных задач, а не мультистековые ребята, тратящие на поддержание своих знаний 90% рабочего времени.
В общем не понимаю, как эта ситуация хуже стала? Раньше разработчик разбирался в JS + jQuery и поверх писал свои велосипеды, а сегодня использует готовое, разбираясь в вещах уровнем выше, но не брезгуя смотреть открытый код? Получается проработав N лет, точно так же терял это время на специфичную для клиента систему, а сейчас только отрывается на несколько версий фреймворка, если совсем не смотрит по сторонам.
DrPass
07.10.2016 17:22+5> Первая проблема в том, что работая в своем органичном стеке в течении двух лет,
> Вы выходите на рынок устаревшим, потому что всем нужен уже <Впишите имя> фреймворк.
ИМХО, это как бы и не проблема. Веб-разработчика «продаёт» его портфолио, а не знание фреймворков. А заказчик, в общем случае, говорит: «Мне нужен сайт с таким-то функционалом», и практически никогда не говорит «Мне нужен сайт на Angular».
У нас, к примеру, разработка сайтов направление непрофильное, но вполне активное. И мы давно уже не ввязываемся в эту гонку вооружений. Никакой выгоды с этого мы не получаем, т.к. затраты ресурсов на освоение и внедрение в проектах свежих новинок в мире JS нынче превышают преимущества от их использования.tendium
07.10.2016 18:12+1Это если исходить из краткосрочных проектов под множественных заказчиков. А если ищешь работу, то в объявлениях достаточно часто указываются конкретные фреймворки. И, к сожалению, на собеседованиях порой любят гонять именно по специфичным для фреймворка вопросам. К счастью, однако у большинства работодателей (по крайней мере тут, в Чехии) существует прекрасное понимание того, что мир JS быстро эволюционировать, чтобы ждать мега-профи по какому-то конкретному фреймворку. А с учетом того, что по крайней мере в бекенде, часто JS используется для микросервисов, то больших познаний всего обилия, перечисленного в статье, и не требуется.
taujavarob
07.10.2016 21:03+2> если ищешь работу, то в объявлениях достаточно часто указываются конкретные фреймворки. И, к сожалению, на собеседованиях порой любят гонять именно по специфичным для фреймворка вопросам.
Речь о конкуренции. Если требуется JS программист, пришло трое, один знает ext.js, второй angular 2, третий react.js, а проект будет разрабатываться (допустим уже известно) на react.js — то кого возьмут?
Ответ обычно очевиден.
И не важно, что мир JS меняется стремительно. — Речь о конкуренции на рынке труда.
Drag13
10.10.2016 13:14>И мы давно уже не ввязываемся в эту гонку вооружений
Это прекрасно ровно до того момента, когда дев с 5+ лет работы у вас, решит походить на собеседования.
Т.е. идея хороша, но из-за тенденции (как мне кажется) опасна для разработчиков.
Source
10.10.2016 16:03В текущем JS-хаосе это как раз нормальный вариант… Лучше через 5 лет изучить то, что будет тогда актуально, чем каждый месяц учить что-то, что через 5 лет никому нафиг не нужно будет :-)
areht
17.10.2016 12:30> Это прекрасно ровно до того момента, когда дев с 5+ лет работы у вас, решит походить на собеседования.
Со стороны работодателя, это прекрасно и после.Drag13
17.10.2016 15:30Думаю большинство присутствующих здесь не работодатели. Так что в большинстве своем это скорее грустно.
DrPass
17.10.2016 16:30Да не так уж и грустно, на самом деле. Вы думаете, разработчику JS будет полезно набивать свои мозги технологиями, которые будут неактуальны через пару-тройку лет? Если речь идет о своей полезности на рынке, то достаточно потратить несколько месяцев перед тем, как выходить на рынок труда, на изучение того, на что в настоящее время есть спрос. А не поддерживать себя во мнимой актуальности, затянув в свои мозги огромный зоопарк фреймворков и инструментов, 90% которого не пригодятся больше никогда.
DarthVictor
08.10.2016 16:54+7Первая проблема в том, что работая в своем органичном стеке в течении двух лет, Вы выходите на рынок устаревшим, потому что всем нужен уже <Впишите имя> фреймворк.
tl;dr — вообще в вакансиях сейчас всего два фреймворка: AngularJS и React.
Если подробнее, то сильно преувеличено. Давайте разберем напримере
stychos
11.10.2016 13:34Даёшь JavaScript on Rails!
taujavarob
11.10.2016 16:16+1> Даёшь JavaScript on Rails!
Уже дали и назвали CoffeeScript — Но НЕ ВЗЛЕТЕЛ.stychos
11.10.2016 16:29+1Я так понимаю, RoR — это такой фреймворк со всем необходимым под Ruby, а Coffee же вроде просто сахарок для JS, в общем очередной транспайлер. Или мои сведения ошибочны?
taujavarob
11.10.2016 16:51Вы совершенно правы.
«Если копнуть немного истории, то с 2009-го года язык писался на Ruby, с 2010 — он пишется на самом же CoffeeScript.
И в Ruby on Rails, начиная с версии 3.1, он «заменил» JavaScript.»
PretorDH
07.10.2016 16:30+25В итоге:
— 3 дня потратил на настройку среды;
— 10 дней машинного времени на 1500 сборок;
— 2 часа писал уникальный код;
— 3 дня на обьяснение заказчику своей крутизны;
— 10 дней на споры с заказчиком о ньюансах архитектуры;
— за 2 часа рабочего времени получил оплату по тарифу 150 у.е./час (фактически по тарифу чернорабочего 10 у.е. /день за 30 календарных дней)
Все пошло на оплату интернета, комуналки и жрачку. Но теперь можно кичится, что за меньше чем за 150 у.е./час даже нефиг браться.
DjoNIK
12.10.2016 10:15Зато на следующем заказчике можно нагреть руку. Да и вообще, получается, что ты учился, так тебе еще за это платили. Неплохо так.
koeshiro
13.10.2016 14:22А потом оказывается что React умер. Angular 2 — не «пракатило!!!».
Все пишут на «WebAssabley». И вообще все хотят assembler в web!taujavarob
13.10.2016 16:06>А потом оказывается что React умер. Angular 2 — не «пракатило!!!».
Все пишут на «WebAssabley». И вообще все хотят assembler в web!
Вряд ли мы можем СЕЙЧАС предугадать что будет через ПЯТЬ лет.
sumanai
13.10.2016 16:41А потом оказывается что React умер. Angular 2 — не «пракатило!!!».
Все пишут на «WebAssabley».
WebAssembly не исключает ни React, ни Angular, ни даже JQuery, наоборот, он им даёт новые возможности.
bustEXZ
07.10.2016 16:33+27У меня дежавю, или я уже читал что-то в точности похожее на хабре? Даже повествование было таким же)
Gbdrm
07.10.2016 17:17Странно, похоже автор оригинала данной статьи не указал, что он дополнил другую.
prostofilya
07.10.2016 17:17+7А в чём прикол с python3? Он же офигенный <3
BasicWolf
07.10.2016 17:21+4Вы — счастливый человек, если не приходилось поддерживать код, который бы работал под 2.7 и 3.х одновременно :)
khim
07.10.2016 21:19-7А не могли бы объяснить — зачем себя так мучить? Используйте python2 и не парьтесь.
abatyuk
08.10.2016 23:30+4я на данный момент занимаюсь разработкой в неком стартапе, у которого, кроме бизнес-пользователей, есть еще две категории разработчиков:
— математики/актуарии, которые привыкли к питону 2.
— современные разрабочики, интегрирующие нашу систему в целевые платформы, разрабатывающиеся сейчас, язык интеграции — питон 3
Первых с каждым годом становится все меньше, вторых все больше (с учетом того, что многие компании пинками загоняют своих разработчиков только в питон3).
Ну так вот. Я это научное сообщество, которое привыкло к двойке и не привыкло меняться, хочу молотками по головам постучать. Они любят, например, jupyter, у которого ядро по умолчанию — питон 3. И любят они numpy/scipy etc, которые тоже сейчас по умолчанию под питон 3 разрабатываются. Но — они будут плакать и колоться, но жрать кактус, пытаясь установить jupyter + scipy + matplotlib + еще кучу всего, вместо двух команд в pip3.
Physmatik
10.10.2016 12:54+2Как молодая часть этого научного сообщества, я пытаюсь использовать и продвигать Python3. Но есть одна проблема: все расчёты обычно выполняются для кучи очень дорогих данных (как пример — коллайдерные коллаборации). И тут очень важно верифицировать инструменты, ведь один баг может привести к неправильным результатам для данных стоимостью в пару десятков-сотен миллионов доларов. Поэтому все по максимуму держатся за старые и проверенные временем инструменты.
lamo4ok
11.10.2016 22:33Довольно редкая ситуация, как мне кажется.
khim
12.10.2016 22:48Нет. Как раз абсолютно типичная. Стартапы могут позволить себе использовать python3, потому что им «нечего терять». И то не всегда, как видим.
В крупных же сообществах только сейчас потихоньку-полегоньку начинают задумываться о том, что они будут делать в 2020м году. Причём я не удивлюсь если будет принято решение выделить средства на то, чтобы поддерживать python2 — благо и делать-то там особо много не нужно будет.
В том же Android'е куча скриптов на python'е — и нет даже планов никаких по адаптации python3. Та же самая история — в Chromium'е. Обратите внимание на активность разработчиков в соответсвующем баге.lamo4ok
13.10.2016 03:25Я все-таки про общую картину со всеми разработчиками и проектами, в смысле что вообще со всеми.
khim
17.10.2016 16:16А «вообще со всеми» — ситуация такая, как я и сказал: подавляющее большинство разработчиков — используют python2 и о переходе если и задумываются, то не очень сильно. Потому что для них python — это инструмент и переделывать всё-на-свете из-за того, что кому-то моча в голову ударила и нормального плана перехода так никто и не придумал — они не будут.
Люди, которые познакомились с python'ом после 2008го года, в основном используют python, но их пока — далеко не большинство. К тому же когда они приходят в компанию, где python начали использовать раньше они начинают «жрать кактус» вместе со всеми.
В результате после семи лет пения «всё хорошо, прекрасная маркиза» разработчики python3 начали задумываться над тем, как бы всё-таки убедить этих «ретроградов» перейти на новую версию.
Придумали много разных вещей, но не поняли главного: не будут люди в коммерческих компаниях переписывать свои скрипты. Не будут. Либо будут разработаны «транспайлеры», либо python2 заживёт отдельной жизнью рано или поздно.
P.S. На Хабре вы этого, впрочем, можете и не заметить, так как работает очень хороший отбор: людям, которые сделали что-то новое — важно об этом заявить на Хабре, людям, которые работают над проектом, которому лет 20-30 — это нафиг не нужно. Но правда заключается в том, что новых проекты — быстро возникают и быстро умирают, а проекты 30-летней давности остаются. Вместе с python2. Так что я, когда писал, что нужно писать на python2 и «не париться» не лукавил ни разу. Не бойтесь вы 2020го года — что-нибудь да придумают.taujavarob
17.10.2016 16:31lamo4ok > Либо будут разработаны «транспайлеры», либо python2 заживёт отдельной жизнью рано или поздно.
Эка право. И тут Javascript обошёл всех, с идеей использования этих самых «транспайлеров».
:-0
YuriM1983
10.10.2016 08:18+1Не вижу никаких проблем поддерживать код, который бы работал под 2.7 и 3.4+.
Вот поддерживать одновременно 2.7 и 3.0 — это да…
Gbdrm
07.10.2016 17:22+1да офигенный, это просто хороший пример того, как можно делать версионность без 7 вариантов, которые нужно транспайлить из одного в другой.
Похоже, для персонажа из статьи, это не то, что ему нравится.khim
07.10.2016 21:18-3О как? А как по мне — так это отвратительный пример. Приведший к тому, что существует такое себе сферическое сообщество питонистов, объясняющих друг-другу как у них всё хорошо. И есть люди, которые реально используют питон — и им все эти чудеса по барабану. И которые просто используют python 2 — и всё. Ни о каком python 3 речь просто не идёт.
Если вы считаете, что это лучще, чем транспайлеры… ну это ваши проблемы.
synedra
10.10.2016 08:57Реально использую питон3. ЧЯДНТ? Правда, свежие версии андроида я не пишу, ну так им прекрасный мир программирования не ограничивается.
khim
12.10.2016 22:54А вашими стартапами — ограничивается? Правда заключается в том, что переход от python2 к python3 — один из самых неудачных подходов к «версионности».
Не самый неудачный, впрочем. Попытка перехода от perl5 к perl6 или от php5 к php6 — ещё мрачнее (обе кончились тем, что никто никуда так и не перешёл — причём php6 в конечном итоге просто умер).
Причём очень может быть что python окажется там же, где perl: просто в конечном итоге, потеряв несколько лет, разморозят развитие 2й ветки и всё.
Я лично знаю достаточно много людей, которые просто отказались от использования python3. Уже одно то, что в нём нельзя безопасно получить список файлов в каталоге — много говорит о том, какую траву курили разработчики.
shyr1punk
07.10.2016 17:18+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
jehy
08.10.2016 11:48+21Всё хорошо. За исключением того, что это неправда в любом случае кроме вывода hello world.
shyr1punk
08.10.2016 12:36+1create-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
jehy
08.10.2016 12:47Только при этом в простейшем виде нужно использовать компонент для таблицы вроде https://www.npmjs.com/package/react-sortable-table — это уже приводит к знанию jsx. А данные для таблицы надо откуда-то брать, для этого делать серверную часть с апи, для этого использовать что-нибудь вроде express плюс модуль для работы с СУБД, а данные нынче модно хранить в redis… В общем, даже такая простейшая задача превращается в какое-то исследование и больше всего напоминает мне работу с C++.
andreysmind
09.10.2016 17:21+3В Реакт приложении все самое сложно как раз и начинается после подключения redux. Код начинает обрастать reselect, recycle, reduxThunk и код постепенно превращается в набор черных ящиков, которые гоняют данные между собой и что-то с ними делают.
hacke151
10.10.2016 08:18-3В первый раз за 10 лет чтения хабра пожалел, что не могу поставить плюс комментарию
andyzee
10.10.2016 08:18Сам сегодня совершенно случайно обнаружил в webstorm замечательный вариант React Starter Kit при создании проекта, с отличной документацией и работой всего стека из коробки. Как для реальной разработки, пока оценить не могу, но для ознакомления — волшебно!
a-motion
10.10.2016 10:59+3— Мне нужно установить специальные IDE, такие как Visual Studio, Android Studio, или XCode?
— Нет, просто создай свое приложение командой create-react-app my-cool-app и ты готов к пути.— Что, даже текстовый редактор не потребуется?
— Нет, реакт настолько крутой, тебе вообще не придется писать код.
taujavarob
10.10.2016 16:03>Нет, реакт настолько крутой, тебе вообще не придется писать код.
Сбылась мечта программиста. (С)
;-)
AndreySu
11.10.2016 11:59да но зачем мне nodejs и npm если я хочу сделать только SPA приложение которое общается с бэкэндом который не на nodejs работает? Т.е. чисто фронтэнд. В том вопрос.
mayorovp
11.10.2016 12:48+2А зачем вам текстовый редактор, если вы делаете фотогалерею? Но, я думаю, без него вы мало что наверстаете.
Вот и с nodejs и npm так же — это инструменты разработки, которые делают разработку удобнее. Не надо относиться к nodejs как к серверу — на самом деле, это всего лишь консольная запускалка скриптов.
a-motion
11.10.2016 12:56-2А чем в качестве «консольной запускалки скриптов» плоха (извините) консоль?
mayorovp
11.10.2016 13:59+2Консоль сама по себе ничего не запускает. Консоль лишь рисует символы.
mayorovp
11.10.2016 18:56Могу я узнать причину минуса? Может быть, я не знаю какого-то определения, но я слабо себе представляю запуск скрипта в консоли без каких бы то ни было консольных программ.
MacIn
12.10.2016 15:17В качестве предположения: слово «консоль» используется зачастую и для обозначения интерпретатора командной строки, запущенного в консоли («набери в консоли, запусти в консоли» и т.д.). Просто в силу того, что масса приложений ныне — GUIевые, и консоль прочно ассоциируется с и.к.с.Тот же .bat файл, интерпретируемый инт. командной строки, это скрипт.
mayorovp
12.10.2016 15:20+1Я и сам слово "консоль" в этом смысле часто использую. Но даже в этом случае скрипт на js не может быть запущен "в консоли" напрямую, вот ведь в чем дело...
mayorovp
12.10.2016 16:36+1Если вы про консоль браузера — то она является неплохим инструментом для отладки клиентских скриптов. Но js-скрипты не делятся на клиентские и серверные, есть еще одна категория скриптов — системные скрипты. (Прилагательное "системный" в данном случае означает, что ими пользуется не конечный пользователь, а разработчик)
А именно, есть такие скрипты как
browserify — обычному веб-разработчику этот скрипт и правда не интересен. Но разработчику библиотеки этот скрипт позволяет просто писать код, а не думать про правильные обертки для модуля в разных окружениях;
babel — компилятор js, позволяет использовать при разработке самые свежие фичи, не дожидаясь пока они дойдут до браузера;
webpack — умеет минифицировать и склеивать скрипты и таблицы стилей.
Это — исключительно полезные скрипты, которые стоит попробовать любому веб-разработчику. Они ничего не усложняют и не замедляют — напротив, после начального изучения они нехило упрощают веб-разработку и ускоряют работу веб-приложения (webpack, за счет минификации). И каждый из них для своей работы должен читать файлы с диска и записывать их на диск, чего нельзя добиться в консоли браузера. Поэтому для их запуска нужна nodejs
AndreySu
13.10.2016 08:12Но все таки мой вопрос была немного о другом, что делать если у меня уже есть бэкэнд сервер и и мне нужно создать SPA которое соответственно полностью выполняется только на стороне браузера?
mayorovp
13.10.2016 08:21Извиняюсь за грубость, но вы чем читаете? Какая вообще разница, какой у вас есть бэкэнд, и есть ли он вообще?
nodejs — это не сервер.
AndreySu
13.10.2016 08:25Да, но тогда получается для фронтэнд разработки ставить nodejs, и прочие вещи описанные в статье и получать весь этот ад? Пытался разобраться в этих кучах фреймворков, но похоже что каждый день выходит новый фреймворк обещающий убрать проблемы своих прендшественников, но в итоге получается еще один стопицотый фреймворк.
mayorovp
13.10.2016 08:29Какой ад?
Во-первых, фреймворк вам надо выбрать один раз и его использовать. Старый фреймворк устаревает когда его перестают поддерживать разработчики, а не когда выходит новый.
Во-вторых, клиентские фреймворки к nodejs не имеют ни малейшего отношения.
AndreySu
13.10.2016 08:32Во-вторых, клиентские фреймворки к nodejs не имеют ни малейшего отношения.
Тогда для чего мне nodejs если у меня клиент в виде SPA как я написал?mayorovp
13.10.2016 08:34Читайте выше. https://habrahabr.ru/post/312022/#comment_9855448
andybelo
13.10.2016 13:12-2Вашим коментам не верю. Блин, одна публикация, и карма 44! У вас в Ч(и)елябинске НЛО часто бывает?
var-log
13.10.2016 17:34А для чего нужен gcc в с++ проектах? Для сборки. На node.js написан софт, который собирает ваш SPA, все, больше он не нужен. Если переписать эти сборщики с node.js на питон или даже на плюсы, для SPA ничего не поменяется.
mayorovp
07.10.2016 17:19+7Не надо выдавать бредни воображаемого "специалиста" за состояние технологии...
JQuery? Да, можно. Но ты еще не устал?
…
— Что случилось с HTML?
— Ничего не случилось. Но для динамической разметки нужен свой язык.
— Типа шаблонизатора?
— Да, JSX — это шаблонизатор.
…
— Другая библиотека? Что за Babel?
— Компилятор. Позволяет пользоваться новыми фичами языка раньше, чем их поддержка появится в браузере.
…
— Слушай, я просто хочу загрузить кучу данных с сервера, просто подключить JQuery из CDN и просто получить данные с помощью AJAX. Почему я не могу сделать это?
— Ты можешь так и сделать, но ведь потом эти данные надо еще вывести на страницу.
…
— Давай придерживаться React, я уже узнал слишком много о нем. Так что, если мне нужно использовать React, я вытяну его из этого NPM, а затем использую Browserify?
— Да.
— Это кажется слишком сложным, чтобы просто взять кучу зависимостей и связать их вместе.
— Не сложнее чем скачивать каждую библиотеку вручную.
…
Фрагмент про менеджеры задач не нужен — потому что они не нужны для этой задачи. Как и про TypeScript, функциональное программирование и прочее.
…
— О, да. Fetch это имя нативной реализации для выполнения XMLHttpRequests.
— О, AJAX.
— Ну да, Fetch это новая реализация AJAX. Помнишь, XMLHttpRequest был настолько неудобен, что все использовали только jquery-обертку вокруг него? Теперь обертка не нужна.
…
— А методы AJAX JQuery не возвращают промисы?
— Да, возвращают.
…
— Это третий раз, когда ты говоришь о await, но я понятия не имею, что это такое.
— Синтаксический сахар для промисов.
— У… а можно его не использовать?
— Можно. Наверное, так будет даже лучше первое время — потом будет понятно что за магия внутри происходит.andreysmind
09.10.2016 17:32-1Ну вот. А у меня другой опыт и последние пару месяцев депрессия и аллергия на js buzzwords.
— Другая библиотека? Что за Babel?
— Компилятор. Позволяет пользоваться новыми фичами языка раньше, чем их поддержка появится в браузере.
Причем каждую «фичу» типа того же Реакта нужно скачивать отдельно.
— Слушай, я просто хочу загрузить кучу данных с сервера, просто подключить JQuery из CDN и просто получить данные с помощью AJAX. Почему я не могу сделать это?
— Ты можешь так и сделать, но ведь потом эти данные надо еще вывести на страницу.
Ну, прямо там взял и вывел данные, даже не выходя из метода.
— Ну да, Fetch это новая реализация AJAX. Помнишь, XMLHttpRequest был настолько неудобен, что все использовали только jquery-обертку вокруг него? Теперь обертка не нужна.
Кроме случаев, когда нужно обрабатывать progress event.
ЗЫ. Заметил, что чем больше денег приносит приложение, тем меньше парятся что у него внутри.
mayorovp
10.10.2016 10:02Причем каждую «фичу» типа того же Реакта нужно скачивать отдельно.
Реакт — это не фича, Реакт — это библиотека.
Кроме случаев, когда нужно обрабатывать progress event.
Ни разу не было такой задачи за два года веб-программирования...
andreysmind
10.10.2016 10:08-1Поэтому в кавычках. Я не про сам Реакт, а его плагин для Babel.
А у меня все время прогресс загрузки хотят видеть поэтому приходится или XHR «вручную» использовать или сторонние типа axios который еще и в промисы умеет.mayorovp
10.10.2016 10:11-1Загрузки чего? Вы грузите пару мегабайт в ajax-запросе, да еще и "все время"?
prostofilya
07.10.2016 17:38+2надо было ставить
linuxEmber
DenimTornado
07.10.2016 22:24Вот уж да!!! Очень мне он нравится, вроде всё тоже, что и раньше, но при этом современный код!
handicraftsman
07.10.2016 22:52Не учтено, что он тяжеловес (серверная сторона) тот ещё.
prostofilya
08.10.2016 08:44Ну потому и тяжеловес, потому что всё из коробки) Там уже в основном вся тяжесть из-за специфического поведения npm, который тащит всё что можно
avost
07.10.2016 17:57+14Чорт, я как раз перестал иметь дело с фронтендом 6 лет назад, а сейчас мне надо получить немного данных по rest'у и вывести их на страничку… И тут такой ужос!..
Stalker_RED
08.10.2016 03:42+11Хинт: jQuery все еще развивается, новые версии выходят и т.д… Вы можете сделать все в стиле 2010, и оно будет прекрасно работать во всех современных браузерах включая сафари.
Обычные пользователи вашей странички скорее всего не будут заглядывать в код и никогда не догадаются о том, что он не модный.
А весь этот выше перечисленный зоопарк можно оставить тем, кто ведет действительно крупные проекты или гонится за модой.
vabolshakov
09.10.2016 17:38Согласен, это все нужно для одностраничных сайтов с динамическим всем-всем, а для простейших задач jQuery и ее армии плагинов за глаза хватает.
taujavarob
10.10.2016 16:48+1> а для простейших задач jQuery и ее армии плагинов за глаза хватает.
Простейшие задачи не в тренде. ;-)M-A-XG
11.10.2016 14:10+1Ну да.
В тренде решать не задачи (самым простым возможным способом), а надуманные проблемы, которые сами создали при решении задач. :)taujavarob
11.10.2016 16:28+1>В тренде решать не задачи (самым простым возможным способом), а надуманные проблемы, которые сами создали при решении задач. :)
Верно. Это как первая модель авто типа «Форд-Т» — прост и понятен.
Сейчас же, чтобы поехать, надо аж столько в авто всего запихнуть — что страшно становится… разработчику авто, но не водителю этого современного авто, жмущему на кнопку! ;-)
Terras
07.10.2016 18:05+1Я наверное странный человек, но неужели не хватит стека:
js +jQuery +backbone/angular/ember/react (на выбор что-то одно)? + grunt (если надо сборку делать).Odrin
07.10.2016 18:24+7Для описанной задачи хватит даже более простого стека:
js + jQuery + DataTables (jQuery плагин) + grunt (если надо сборку делать).
А автор статьи просто не умеет выбирать подходящие инструменты и способы решения поставленной задачи, создавая для себя проблемы на пустом месте.
taujavarob
07.10.2016 21:09-7>Я наверное странный человек, но неужели не хватит стека:
Если вам этого хватает, то вы — откатываетесь назад стремительным домкратом. :-)
Чтобы оставаться только(!) на месте, вам надо… бежать. (Как говорил известный персонаж).
l0rda
07.10.2016 18:48+8Прямо все, что я думаю о фронтенде. Начал использовать angular, а он уже устарел оказалось, а angular 2, это какой-то ад. Вернусь на jQuery, мне всего-то данные с rest отобразить в таблице.
handicraftsman
07.10.2016 21:56Именно потому я использую VanillaJS и jQuery. Максимум, могу добавить шаблонизатор на стороне сервера (вроде liquid, erb).
ertaquo
08.10.2016 00:43+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 и прочим. Профессионалы этого дела запросто заткнут меня за пояс, да и вообще презрительно прочитают этот комментарий и гневно уничтожат одной тирадой. Но лично для меня все эти штуки до сих пор сыроваты и сложны в использовании, тем более когда под рукой уже есть наработанный и вполне готовый функционал.mayorovp
08.10.2016 12:22Но черт побери, почему в 2016 году в самом популярном и простом фреймворке нужно вручную подключать такие функции, как парсинг форм и cookie?
А что если вам не нужен парсинг форм? Что, если вы не используете печеньки?
rails new myapp -B && cd myapp && echo "gem 'devise'" >> Gemfile && bundle install && rails g devise User && rake db:setup.Ок, вы подключили библиотеку devise и она сделала то, что вам нужно. Почему вы в таком случае не догадались использовать passport?
ertaquo
08.10.2016 14:31+1Догадался. Но если использовать только стратегию local, без OAuth и прочего, эта библиотека становится практически бесполезной. Все манипуляции с базой (поиск и добавление пользователей, проверка пароля и т. п.) производятся вручную. И получается, что все, что выполняет данная библиотека, это хранение данных в сессии.
По факту эта библиотека более-менее полезна тем, кто использует различные стратегии в ней (вход через соцсети). Для local-only толку от нее практически нет.
Поправьте, пожалуйста, если я не прав.
boolive
08.10.2016 00:48Расскажите, как оно учить С++ в 2016 году, чтобы писать программы конкурентоспособные на мировом рынке? Мне реально интересно узнать в практических целях.
bogolt
08.10.2016 12:32+3Установить IDE + компилятор, читать книги, пробовать примеры.
А дальше уже в зависимости от цели. Если гуи то можно в Qt погрузится. Если сервера то многообразие разных возможностей, начиная от голых сокетов, boost.asio, libev ну или еще чего-нибудь. И отдельно читать книги про многопоточность. Если игры… ну опять же можно хоть на opengl а можно взять популярный фреймворк ( тот же cocox2dx ).
зы. Читая книги, помните что те из них которые написаны до появления 11 стандарта не будут охватывать все то многообразие безумных возможностей которые у нас появились. Поэтому про них нужно будет читать отдельно.
zenkz
08.10.2016 00:59Спасибо! Классная статья, которая отражает рельное положение дел в веб-разработке.
Куча библиотек, фреймворков и прочего соединённых костылями и дополнительными библиотеками. Всё это сдобрено всякими пакетными менеджерами и трансляторами.
С одной стороны хорошо, что есть выбор, с другой стороны появляется куча проблем:
— высокий порог входа в проект.
— то что ты выучил и использовал на одном проекте скорее всего не пригодится в другом. К тому же будет считаться устаревшим.
Можете считать меня отсталым, но меня связка ASP.Net MVC или WebAPI + JQuery + KnockoutJS вполне устраивает и пока менять не собираюсь. (Разве что может быть попробую ангуляр).
Для меня хороший набор технологий, это тот, который позволяет создать и скомпилировать пустой проект за 10 минут. И разработка которого потребует как можно меньше написанного кода для рутинных операций.
Мне кажется, что пока 80% браузеров не будут поддерживать TypeScript/ES2016 из коробки без необходимости перекомпиляции/преобразования — нет смысла использовать эти языки.
Мне кажется, что эта мешанина библиотек и фреймворков должна пройти лет через 5 и путём естественного отбора оставить только то, что действительно удобно (как тот же JQuery в своё время)
foxmuldercp
08.10.2016 12:10Я к своему стыду аспнет кор, который 5й так и не осилил, хотя на 4м написал маленькую веб бухгалтерию пару лет назад.
Сейчас вот пишу на рельсах панель управления хостингом приложений (не сайтов, это важно), с реактом на фронде и понимаю, что мне надо очень сильно помучаться чтобы подключить вебпак и внешние компоненты к реакту. Так что пока тренируюсь на кошках и реализовываю все сам, пока нет готового прототипа и денег на отдельного фронтендера
mayorovp
08.10.2016 12:24Мне кажется, что пока 80% браузеров не будут поддерживать TypeScript/ES2016 из коробки без необходимости перекомпиляции/преобразования — нет смысла использовать эти языки.
Почему вы смело используете C#, у которого довольно сложный процесс построения (build) — но отрицаете необходимость этапа построения для клиентских языков?
zenkz
13.10.2016 21:49Потому что для того, чтобы собрать C# приложение мне не нужно устанавилвать и конфигурировать кучу инструментов. Всё происходит «само» по нажатию одной кнопки из среды разработки. А также потому, что в C# нет зоопарка стандартов и мне нет смысла писать на .Net 4.6, а потом конвертировать с помощью специальных инструментов в .Net 2.0, чтобы это заработало.
Как должно быть: поставил VS for JS, создал проект, пишешь на ES2016/TypeScript/что либо ещё. Нажал кнопку скомпилировать и оно открылось в браузере и заработало (хоть в IE10, хоть в хроме последнем).
ertaquo
08.10.2016 14:37Я бы все-таки посоветовал обратить внимание на React, вместо Knockout. Ибо Knockout — довольно тормознутая штука (по крайней мере была, до введения deferred updates в 3.4.0).
zenkz
13.10.2016 21:50Спасибо за совет. Я планирую перейти на реакт или ангуляр, но в первом меня отпугивает, что на каждый чих нужно ставить плагин, а второй — тем, что он всё же избыточен, т.к. заточен на SPA
lastmac
08.10.2016 12:24-3Во время прочтения вспомнился один «продажник» который в подобном изложении пытался объяснить заказчику (скорее запутать заказчика) почему он хочет много денег от него. Подобный текст можно написать о чём угодно, хоть о плюсах.
— Я хочу кодить игры на плюсах, и буду использовать <тут любой движок 90х годов>
— Ээ-э не чувак, давай я тебе сейчас расскажу как там всё развивалось и куда всё это привело…
Это я к тому, что сильно напыщенный текст, который должен показать всю «сложность» фронтэнд разработки. Все работы хороши.
Gorthauer87
08.10.2016 12:41+2Фронтенду явно не хватает некоторого универсального промежуточного представления, которое может целиком заменить js+html+css и которое будет достаточно стабильным и низкоуровневым чтобы во всех браузерах работать идентично.
andd3dfx
08.10.2016 19:34Еще раз убеждаюсь, что до сих пор актуальна статья Пола Форда (опубликованная в книге Спольски — «Лучшие примеры разработки ПО»), в которой он сетует на то, что для веба до сих пор не изобрели dsl, как уже сделали для текстов и звуков
Capito
09.10.2016 00:41+1Похоже теперь я осознал, почему Enterprise часто выбирают Sencha (ExtJS) и готовы за него платить $10К. -)
Для серьезных учетных систем и всяких RIA аналогов нет по-сути.
Сейчас пишу довольно крупный проект на нем, ни каких зоопарков, все из коробки. И сборщик тоже SenchaCmd.
Документация там просто шикарная.Вот реально сидишь и пишешь код, ни каких головняков не возникает. Это реально очень приятно, после всех зоопарков с разными либами и всяких тулз на Node.
Причем старые версии, 3я, 4я, были довольно багованными и тормозили прилично, текущая 6.2.0 просто песня.
YourDesire
10.10.2016 08:19Извините, не могли бы вы описать основные преимущества ExtJS, которые вас привлекли, за исключением уже описанного? Мне, как начинающему front-end разработчику, будет очень интересно почитать ваше мнение, как человека, который использовал ExtJS в своих текущих проектах.
Не менее интересно будет почитать, что же вы осознали, в плане «почему Enterprise часто выбирают Sencha (ExtJS)», более конкретно.Capito
10.10.2016 12:41В этом и есть преимущество, что там все из коробки, и работа с данными и компоненты все и скины и графики, в 6.2.0 еще и адаптер для d3.js появился. Это не только фреймворк, но и большая экосистема. Сборщик, визуальный редактор, тестовое окружение, дебаг тулза и т.д. + к этому саппорт который оперативно чинит баги в фреймворке (если вы купили Premium есть доступ к night builds).
Стоит да, 10К долларов, но на большом проекте это сэкономит много человеко-часов времени разработчикам, поэтому это окупается. Ну и да, это актуально для долгоиграющих enterprise систем. Для каких-то стартапов или небольшой админки конечно он не нужен, как из пушки по воробьям и может не окупить себя просто.
alexstz
10.10.2016 21:40Там немало вещей, за которые его можно любить. Это и богатая библиотека компонентов, и шикарный набор классов для работы с данными. Сам фреймворк написан в едином стиле, плюс он подталкивает к определённой структуре проекта, которую легко сопровождать и понимать другим программистам.
В Ext JS отлично реализованы те функции, которые очень часто требуются в enterprise. Если ещё не видели их демку, то вот она Ext JS Kitchen Sink.
bano-notit
12.10.2016 20:54… плюс он подталкивает к определённой структуре проекта...
Вообще-то фреймворк на то и фреймворк, чтобы проекты под него имели определённую структуру. Если этой структуры нету, то это не фреймворк, а библиотека.
alexstz
12.10.2016 21:21+1Хм, никогда не придавал значения этим терминам, а сейчас погуглил и обнаружил, насколько забавно отличаются русская и английская Wiki по этому поводу :)
In computer programming, a software framework is an abstraction in which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. A software framework is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, tool sets, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.
При этом, в тексте статьи нет ни одного слова «структура». Зато чуть ниже есть «архитектура».
Фре?ймворк (иногда фреймво?рк; англицизм, неологизм от framework — каркас, структура) — программная платформа, определяющая структуру программной системы; программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта.
А здесь сразу о структуре.
Теперь впору поговорить о разнице между структурой и архитектурой, но я, пожалуй воздержусь :))
AlexPu
09.10.2016 13:55И вель все верно — во всей этой катавасии надо как-то разбираться… Даже не то чтобы разираться — просто понимать общуюю картины и направление движения в случае тех или иных обстоятельств… У меня скажем сейчас реальная каша в голове… Поэтому я сижу на angular и использую сборку на базе докер-контейнеров (спасибо хабру) — это позволяет избежать проблем с установкой хреновой тучи программных инструментов просто для того, чтобы сбилдить более двух десятков проектов в которых используются разные средства разработки (ну в основном классика конечно — JS+java)
chemtech
10.10.2016 06:35+1Интересно, про другие языки или направления можно такое написать?
taujavarob
10.10.2016 16:58>Интересно, про другие языки или направления можно такое написать?
Про другие такого не замечено.
Например Java.
Java — это Cobol сегодня. — Новые версии переносятся непрерывно (Java 9 недавно передвинули на пол-года).
Java 2 EE похоже вообще уже «труп».
bano-notit
10.10.2016 08:19+1Мне кажется была уже эта статья… А может я и ошибаюсь.
KvanTTT
10.10.2016 12:00Ага: It’s the future. Странно, почему это сразу не заметили.
Gbdrm
10.10.2016 12:12Это тоже перевод, написаный другим автором, в другое время. Похоже что автор оригинала данной статьи решил его дополнить.
Botchal
10.10.2016 08:19Чем выше порог входа, тем выше заработные платы. Всё идёт по плану (по плану порабощения мира). Ну а если серьёзно, то как ещё можно писать на современной версии языка, так чтобы он отрабатывал везде? Я думаю, что этот эволюционный период пройдёт и всё будет хорошо.
taujavarob
10.10.2016 17:11> Я думаю, что этот эволюционный период пройдёт и всё будет хорошо.
Странно то, что этот СКАЧОК эволюции JS вообще возник, после 10-ти то лет «плавного обычного развития».mayorovp
10.10.2016 17:17Ничего странного. СКАЧОК начался когда появился движок V8, ускоривший выполнение js в разы.
taujavarob
10.10.2016 17:44>СКАЧОК начался когда появился движок V8, ускоривший выполнение js в разы.
Хорошо. Тогда вопрос будет звучать так: Странно что движок V8 ускорил выполнение js в разы, а не на 5-10%, как это обычно происходит с НОВЫМ движком на рынке.mayorovp
10.10.2016 19:32А что странного в скачке производительности при переходе от интерпретации к компиляции?
taujavarob
10.10.2016 20:13>А что странного в скачке производительности при переходе от интерпретации к компиляции?
Всё верно. В 2008-2009 году в JS движках произошло резкое увеличение (в разы, а не на %) производительности и JS… взлетел. ;-)
areht
17.10.2016 15:23> как ещё можно писать на современной версии языка, так чтобы он отрабатывал везде? Я думаю, что этот эволюционный период пройдёт и всё будет хорошо.
я это слышу со времён… изобретения DHTML
Deka87
10.10.2016 08:19Назвать себя инженером не могу, скорее просто верстальщик. До сих пор использую jQuery в небольших приложениях — заказчики довольны.
PS: Я понимаю, что простая манипуляция с DOM это еще не JS программирование!
arhangelsoft
10.10.2016 08:19+1Вывод: пишите на том что проверено годами, просто потому что оно будет актуально ещё большую часть вашей сознательной жизни. А весь этот однодневный буллшит надо просто игнорировать.
Smagold
10.10.2016 08:19+4Пишу на чистом JS, абсолютно никаких библиотек. Чувствую себя хорошо, все в порядке. И нет, я не из адептов pure JS, просто мои приоритеты в разработке — скорость работы, и никакая связка из 3 библиотек не будет работать быстрее чистого языка.
toxadx
10.10.2016 08:19Описывает муки моего выбора на этой неделе. Вернулся к JavaScript спустя год для написания небольшой web-службы отображения данных из БД. Также рассуждал и в конце остановился на JQuery, Backbone, Marionette, lodash + coffee скрипты + бекэнд на Python.
Слишком быстро скачет JavaScript.
Divar
10.10.2016 08:20+1— Я бы сделал транспайл из TypeScript с помощью комбо Webpack + SystemJS + Babel.
Чем лучше SystemJS в сравнении с вебпаковским require.ensure?
pawlo16
10.10.2016 08:22-2Трудно найти более дебильный ЯП нежели чем JS, но гуглофейсбуку этого показалось мало — они дополнили его перечисленными автором хакерскими примочками. Да ещё и TypeScript изобрели, который не имеет даже банальных мапов, зато требует ещё больше примочек. Казалось бы — пиши себе на НОРМАЛЬНОМ языке с адекватными инструментами (ClojureScript, Elm, F#, PureScript ), используй js/css/html в качестве целевой платформы покуда не придумали что-то лучше. Но не тут то было:
Палка в заднице у левого зайца как-бы символизирует webpack
taujavarob
10.10.2016 17:16>Трудно найти более дебильный ЯП нежели чем JS, но гуглофейсбуку этого показалось мало — они дополнили его перечисленными автором хакерскими примочками. Да ещё и TypeScript изобрели, который не имеет даже банальных мапов, зато требует ещё больше примочек.
TypeScript изобрёл Microsoft. — Так что надо писать вам НЕ «гуглофейсбуку этого показалось мало», а «гугло-фейсбук-майкрософту этого показалось мало».
Да, эта троица («гугло-фейсбук-майкрософт») вообще ЗАХВАТИЛА МИР! Похоже на то. ;-)
M-A-XG
11.10.2016 14:20+1>Трудно найти более дебильный ЯП нежели чем JS
Почему же он дибильный?taujavarob
11.10.2016 16:34Потому что на нём можно писать по разному — и «дебильный» и «дибильный» и он будет работать. ;-)
pawlo16
11.10.2016 17:59Или не будет. Или будет, но не так как надо и не долго. Билды ломаются — рандомно. И рандомно же чинятся со второго-третьего-четвертого запуска npm install и npm dedupe.
M-A-XG
11.10.2016 23:06Так это ж норм.
Именно это — причина его успеха.
Таких языков куча.
С — тоже дибильный?
При желании можно сделать, чтобы работало только в одном случае, ну или управлять типизацией явно, проверяя переменные.
А переменные и функции в JS регистрозависимые.Source
12.10.2016 00:22Слабая типизация + полиморфизм операторов — довольно взрывоопасная смесь, которая мало кому нравится.
M-A-XG
12.10.2016 09:54Вообще-то много кому :)
taujavarob
12.10.2016 16:22>Вообще-то много кому :)
Всем рисковым чувакам! ;-)M-A-XG
12.10.2016 17:19В вебе большинство таких :)
Source
12.10.2016 18:23Большинство может вообще один/два языка только знать… А вопрос нравится/не нравится — это вопрос осознанного выбора. Попрограммируйте несколько лет на слаботипизированном языке, а потом несколько лет на сильнотизированном.
Я не видел пока ни одного человека, который после этого тяготел бы к слабой типизации.taujavarob
12.10.2016 18:38>Я не видел пока ни одного человека, который после этого тяготел бы к слабой типизации.
Я есть он. (С)
Я удрал из мира Java в мир JavaScript. Удрал через GWT. Но удрал.
Мир JavaScript — это мир свободы! (С)Source
12.10.2016 22:38К Вам тогда вопрос такой, Вы пробовали языки с сильной динамической типизацией?
taujavarob
12.10.2016 23:40> пробовали языки с сильной динамической типизацией?
Странный вопрос у вас.
«Сильная / слабая типизация (также иногда говорят строгая / нестрогая). Сильная типизация выделяется тем, что язык не позволяет смешивать в выражениях различные типы и не выполняет автоматические неявные преобразования, например нельзя вычесть из строки множество. Языки со слабой типизацией выполняют множество неявных преобразований автоматически, даже если может произойти потеря точности или преобразование неоднозначно.
Примеры:
Сильная: Java, Python, Haskell, Lisp;
Слабая: C, JavaScript, Visual Basic, PHP.»
Сильная: Java!!!Source
13.10.2016 00:20+1А что странного? Это же отдельный вопрос. А типизация помимо деления на сильную/слабую делится ещё и на динамическую/статическую.
У JavaScript — слабая динамическая, у Java — сильная статическая. Отсюда и вопрос про другие языки.taujavarob
13.10.2016 16:11Статическая / динамическая типизация.
Статическая: C, Java, C#;
Динамическая: Python, JavaScript, Ruby.
Сильная / слабая типизация
Сильная: Java, Python, Haskell, Lisp;
Слабая: C, JavaScript, Visual Basic, PHP.
То есть, программировал ли я на Python?
Ответ — нет.
Source
13.10.2016 16:59То есть, программировал ли я на Python?
Ну необязательно именно Python, кроме него есть ещё Ruby, Lua, Smalltalk, Lisp, Erlang и ещё масса языков с сильной динамической типизацией. Пока непонятно какие языки кроме Java и JavaScript Вам знакомы?
Весьма вероятно, что Ваш восторг от смены Java на JavaScript связан с переходом от статической типизации без вывода типов к динамической типизации, а не со слабостью типизации.taujavarob
13.10.2016 17:25>Ну необязательно именно Python, кроме него есть ещё Ruby, Lua, Smalltalk, Lisp, Erlang и ещё масса языков с сильной динамической типизацией. Пока непонятно какие языки кроме Java и JavaScript Вам знакомы?
Все языки начиная от «программировать в кодах» до времени появления Java. Исключая выше вами перечисленные.
Java в СВОЁ время произвёл восторг! Но его время ушло. Имхо.Source
13.10.2016 18:03Все языки начиная от «программировать в кодах» до времени появления Java. Исключая выше вами перечисленные.
Смешно )))taujavarob
13.10.2016 18:18Ладно, — Все ШИРОКО ИЗВЕСТНЫЕ языки начиная от «программировать в кодах» до времени появления Java. Исключая выше вами перечисленные и «нишевые» (но включая ADA).
Source
13.10.2016 20:45Проще было бы перечислить… Впрочем, ладно, понятно, что с сильной динамической типизацией Вы не сталкивались.
taujavarob
13.10.2016 21:08-1>Впрочем, ладно, понятно, что с сильной динамической типизацией Вы не сталкивались.
Вместе нет похоже. Только по раздельности:
Сильная: Java
Динамическая: JavaScript
Вот с этой парочкой в последнее время и живу. ;-)
pawlo16
11.10.2016 19:10Потому что https://www.reddit.com/r/programming/comments/4eh9qc/why_javascript_development_is_crazy/
Вкратце: примитивный язык, примитивный тулинг, примитивная рефлексия, смехотворно крошечная стандартная библиотека, поле невидимых граблей, хаков и шамантва и так далее. Унылый ЯП, который распространился благодаря монопольному положению в веб-стеке, реактивно набирающем популярность.taujavarob
11.10.2016 19:40-1>Унылый ЯП, который распространился благодаря монопольному положению в веб-стеке,
СТОП. Веб-броузеры НЕ монопольны. Есть минимум НЕСКОЛЬКО разных ХОЗЯЕВ:
IE, FF, Хром, Опера.
Никто им НЕ мешает и никогда НЕ мешал ставить какие-угодно плагины(или встраивать прямо в броузер) для интерпретации (или компиляции на лету ) для каких угодно языков.
И эти языки были — Java (апплеты — удалены из-за постоянных дыр), Флеш (отказываются из-за прожорливости).
Так что дело именно в «примитивной» ПРОСТОТЕ JS, разогнавшегося в броузерах благодаря успехам в деле его изощрённой компиляции на лету.
Так что «МОНОПОЛИЯ» тут произошла путём КОНКУРЕНЦИИ, а не чей-то «сильной руки».
Да и попытки «сбросить» JS с пьедестала осуществляются постоянно. ;-)pawlo16
12.10.2016 00:43-2ой, не смешите мои тапки. Плагины для браузеров писать — да в рот им ноги! «конкуренция» — что за блаженные глупости, где вы видели конкуренцию? :-) При малейшей возможности с js бы сбежали все, кроме геев и даунов, неспособных изучить второй ЯП из за умственной ограниченности. Хоть в джаву или С#.
taujavarob
12.10.2016 16:29>ой, не смешите мои тапки.
Не буду.
>Плагины для браузеров писать — да в рот им ноги!
Не поверите, но писали. Всякий НОВЫЙ язык пытался либо напрямую (как Java — прямо в поставке броузера пролезть) либо через плагин — но со временем все отваливались. По разным типа причинам, но отваливались. — Остался ОДИН — JavaScript — он и ОДЕРЖАЛ ПОБЕДУ! :-)
>«конкуренция» — что за блаженные глупости, где вы видели конкуренцию? :-)
В IT-мире она всюду. Стартап за стартапом так и валит так и валит. ;-)
>При малейшей возможности с js бы сбежали все, кроме геев и даунов, неспособных изучить второй ЯП из за умственной ограниченности. Хоть в джаву или С#.
Я удрал из мира Java в мир JavaScript.
Java — это Cobol сегодня (С)
Java — это перманентное отставание и перманентный перенос строков выхода новой версии (и новых фич).
А JavaEE — вообще при смерти.
Короче — Java — это болото. Это скучно. Это нетрендово. Это печально.
Я удрал из мира Java в мир JavaScript. Удрал через GWT. Но удрал.
Мир JavaScript — это мир свободы! (С)
;-)Source
12.10.2016 18:27Я удрал из мира Java в мир JavaScript.
А почему не в .NET?taujavarob
12.10.2016 20:11>А почему не в .NET?
Когда я пришёл в мир Java — C# ещё не было и в помине. ;-)Source
12.10.2016 21:07Я не про «пришёл» спросил, а про «удрал»… Судя по упоминанию GWT касательно того периода, C# уже был и давно.
taujavarob
12.10.2016 22:17Хм, так C# — это же «сахарная Java» — Чего туда беч то?
Source
12.10.2016 22:42Ну, когда Вы пишете про перманентное отставание Java, возникает вопрос отставание от кого… и ответ тут один — от C#. Потому что остальных сравнивать с Java тупо некорректно.
> Мир JavaScript — это мир свободы!
Это из серии «анархия — мать порядка» )))
Т.е. в теории вроде могло бы работать, а на практике люди не так уж способны к самоорганизации.taujavarob
12.10.2016 23:48>Ну, когда Вы пишете про перманентное отставание Java, возникает вопрос отставание от кого… и ответ тут один — от C#. Потому что остальных сравнивать с Java тупо некорректно.
Почему. Например функциональщина наступает во ВСЕ языки по ВСЕМ фронтам.
Теперь вопрос — когда Лямбда-выражения в Java? — Ответ — в Java 8
> Это из серии «анархия — мать порядка» )))
Это из серии — НЕТ ДИКТАТУРЕ! ;-)Source
13.10.2016 00:33Например функциональщина наступает во ВСЕ языки по ВСЕМ фронтам.
И что? По такому критерию любой императивный язык будет в вечных догоняющих, в том числе и C#(несмотря на то, что лямбды там лет 9 назад появились).
С какими ещё языками по-вашему уместно сравнивать Java и по каким критериям?taujavarob
13.10.2016 16:18>С какими ещё языками по-вашему уместно сравнивать Java и по каким критериям?
По критерием ОБНОВЛЕНИЯ и ВНЕДРЕНИЯ новых фич, появление НОВЫХ фреймворков. — Гула! ;-)
Java в этом отношенни к JavaScript как… прыгающая лягушка к летающему стрижу. ;-)Source
13.10.2016 17:58-1По критерием ОБНОВЛЕНИЯ и ВНЕДРЕНИЯ новых фич, появление НОВЫХ фреймворков.
Фичи языка активно появляются на этапе стабилизации языка. А новые фреймворки — на этапе стабилизации экосистемы. В данном отношении, JavaScript можно охарактеризовать как пока ещё незрелый и нестабильный ЯП. Да, он существует очень давно, но по сути начиная с 2009 года пилят новую версию языка, которая до сих пор не устаканилась.
Сложно это записывать в плюс. Конечно, язык не должен скатываться в стагнацию аля Java, но очень бурное развитие адекватнее смотрится до версии 1.0. Самое фиговое, что, несмотря на новые версии ECMAScript, избавляться от bad parts никто не торопится.
taujavarob
13.10.2016 18:26>В данном отношении, JavaScript можно охарактеризовать как пока ещё незрелый и нестабильный ЯП.
Хм. Это язык 1995 года — ему 20 лет!
>но по сути начиная с 2009 года пилят новую версию языка, которая до сих пор не устаканилась.
Ну, до этого было аж 5 версий (4-я с полноценным ООП — НЕ покатила и была отвергнута).
>Самое фиговое, что, несмотря на новые версии ECMAScript, избавляться от bad parts никто не торопится.
bad parts — это фичи языка. Имхо. ;-)Source
13.10.2016 21:05-1Хм. Это язык 1995 года — ему 20 лет!
Я же пояснил… Тот язык, который развивался с 1995 года, навсегда остался в версиях 1.x, хотели сделать 2.0, но не договорились.
У ECMAScript своя нумерация версий, и это совсем не тоже самое, что версия JavaScript. Касаемо самого JavaScript, сейчас активно пилят версию 3.0, которая находится на уровне альфа-версий, и на каждую альфа-версию выпускают новую редакцию ECMAScript. Стабильная версия (1.8.x) тоже есть, но она не развивается уже лет 6 и ей никто не пользуется :-)taujavarob
13.10.2016 21:39+1Место «ECMAScript 2015» в вашей системе версий?
Source
13.10.2016 22:44Да, я ж написал «У ECMAScript своя нумерация версий», «на каждую альфа-версию выпускают новую редакцию ECMAScript».
ECMAScript в моём восприятии это документ, описывающий стандарт. Разве нет? Т.е. примерно такая фраза «JavaScript 3.0 удовлетворяет стандарту ECMAScript 2020» будет корректна по смыслу.
В любом случае, ECMAScript и JavaScript — это не одно и то же :-)taujavarob
13.10.2016 22:58+1>В любом случае, ECMAScript и JavaScript — это не одно и то же :-)
Это то ясно, но обычно в реальном мире считают версии Javascript так:
Редакция 3
Редакция 4 (отброшена)
Редакция 5 (текущая для всех)
Редакция 6 (продвинутая)
Редакция 7 (вот вот будет принята).
Слово редакция обычно — отбрасывают.
Вообще нумерация версий что Javascript что Java — это смехотрон. Имхо. ;-)Source
13.10.2016 23:32Это то ясно, но обычно в реальном мире считают версии Javascript так
Но это ж не версии JavaScript, а редакции ECMA. Всё-таки не надо путать, у JavaScript есть свои собственные версии… Даже тут статейка была про текущую стабильную: JavaScript 1.8
А Java, да, забавна… она нумеруется в стиле Emacs (с отбрасыванием мажорной версии). Т.е. Java 8 значит Java 1.8
M-A-XG
11.10.2016 23:16Чем проще язык, тем лучше.
Я манал в рот хитроумные загогулины.
Да и не настолько он примитивный, это примитивный взгляд. :)
ПО ссылке какая-то ерунда, не относящаяся к языку: DOM, jquery, html, Windows. Ну и оно на бусурманском. :)
Стандартная библиотека унылая из-за того, что он использовался только в браузерах. :)
Грабли, хаки, шаманство — это проблемы DOMа в IE как правило. :)pawlo16
12.10.2016 00:32-2== Чем проще язык, тем лучше.
брэйнфаке и асм ещё проще
==. Да и не настолько он примитивный, это примитивный взгляд. :)
дв вы шо?? и что же там есть не примитивного? кроме хитрых граблей конечно
== ПО ссылке какая-то ерунда, не относящаяся к языку: DOM, jquery, html, Windows. Ну и оно на бусурманском. :)
это называется не читал но осуждаю :-)
== Стандартная библиотека унылая из-за того, что он использовался только в браузерах. :)
никакой логической связи
== Грабли, хаки, шаманство — это проблемы DOMа в IE как правило. :)
а new / this в js — это что?
M-A-XG
12.10.2016 10:11+1>брэйнфаке и асм ещё проще
Зачем всегда вдаваться в крайности?
Так ли прост asm? Ага, щас.
>это называется не читал но осуждаю :-)
Всю ту ерунду не читал, пробежал по диагонали.
>а new / this в js — это что?
А что с ними не так? Это прям такая распространенная проблема? :)
Alter2
10.10.2016 08:22Этому диалогу просто необходим сопутствующий пошаговый лог создания Hello world странички.
SPAHI4
10.10.2016 08:22Не понимаю, в чем сложность проблемы, описываемой в статье. Взять первый попавшийся webpack boilerplate,
использовать первую попавшуюся библиотеку для отображения данных, хоть es6 template strings, и подключить для старых браузеров whatwg-fetch. Все.
madmages
10.10.2016 08:23актор, отвечающий на вопросы, это стопроцентный хипстер: все новое, фу это уже не можно.
Пишу на первом ангуляре + browserify и както вообще нет ощущения что это провалpawlo16
10.10.2016 10:13-1А без разницы на чём писать Хелуволд. Но на чистом js проще чем на Ангуляре. React бесит навязыванием хакерских примочек, но сам по себе он не плох. А Ангуляр — это наихудший факиншэт из всех альтернатив.
madmages
10.10.2016 10:15Интересно, а чем этот вариант худший?
pawlo16
10.10.2016 10:26Впечатление, что дизайнили какие-то шизофреники — плотность дебильных eDSL, замаскированных хаков и неочевидного на квадратный сантиметр зашкаливает. Ну и пропертибиндинг — это в корне ущербная парадигма. Как и мутабельный VDOM.
(function () { angular .module('app.widgets') .directive('iconButton', iconButton); function iconButton() { return { restrict: 'E', templateUrl: 'app/widgets/buttons/icon-button.html', scope: { click: '&', icon: '@' }, replace: true }; } })();
Особенно мне нравится часть про «click: '&', icon: '@'».
Для сравнения тоже самое на React+Typescript:
export function iconButton(icon: string, onClick: () => void) { return dom.div({ className: $"bo-icon-button fa fa-{icon}", onClick }); }
madmages
10.10.2016 10:44Особенно мне нравится часть про «click: '&', icon: '@'».
тут согласен, дикая штука.
Ну а в остальном я бы сказал это придирки.
Навскидку больше и вспомнить проблемных мест не могу(точно были но вспомнить не могу). Но их не то количество изза которого я бы сказал что это худший вариант.
Мне нравится в ангуляре то что оно более менее законченное решение из коробки: это именно фреймворк а не библиотечка, а-ля react. Чтобы реакт начал быть похож более менее на фреймворк то туда нужно воткнуть flux или redux, а еще немного плясок с бубном и оно должно будет заработать.
Мне нравится в реакте как там устроены компоненты и сама концепция их там же. В ангуляре директивы на легкость не тянут да и ангулярные компоненты огрызки директив тоже так себе. Но те же директивы в ангуляре хороши своей полнотой декларации. В маленьких проектах полнота не важна, и в маленьких проектах реакт будет очень хорош, а там где нжуно поддерживать проект то я бы сказал что многословность(самодокументируемость) это скорее плюс чем минус.
В общем я скорее склонен думать что это в большей степени разные технологии и сравнивать их лоб в лоб это скорее не правильно чем обратное и возглас «ангуляр хуже чем реакт» у меня вызывает легкое недоумение.pawlo16
10.10.2016 11:13Решение из коробки в js в принципе нет, Реакт в этом ничуть не хуже Ангуляра. Если надо — берите Elm.
проблемное место Ангуляра — это любая чуть более чем тривиальная директива на нём. Это становится очевидно, если сравнить идентичный (именно идентичный, а не аналогичный) по функциональности код на Ангуляре и Реакте.
Чтобы реакт начал быть похож более менее на фреймворк то туда нужно воткнуть flux или redux
да ни фига.
В Реакте неизменяемый стэйт, что важно для многопоточных приложений.
Чтобы нормально писать jsx, достаточно знать html, а в Ангуляре надо учить очередной шаблонный движок и гей-синтаксис его шизофреничных директив + html. Все шаблонные движки сами по себе следствие ущербности языка. Собственно то, что есть jsx, в нормальных ЯП реализована на уровне языка в виде списковых включений.
В Реакте есть гуманная система оповещения об ошибках времени выполнения. В Ангуляре в этом смысле почти ноль
Nibiru
10.10.2016 08:23-2Возможно я слишком критичен, но я стараюсь не использовать готовые решения типа JQuery и прочих библиотек. По моему опыту часто времени на устранение их багов уходит гораздо больше, чем написать с нуля. И копаться в чужом коде для устранения багов — неблагодарная задача.
NIKOSV
10.10.2016 08:23Как-то приходилось иметь дело с реактом. А там на слуху библиотечка redux, о которой везде пишут, доклады на конференциях делают, пропагандируют, вплоть до того что без нее реакт не реакт, 20k звездочек на github и все такое. Ее автор, Ден Абрамов, важный человек на front end конференциях, ездит по миру, выступает, блог о библиотеке ведет. Я себе думаю, видать нереально крутая библиотека раз такой хайп. Потом посмотрел исходники, а там… примерно 200 строк кода, финиш.
mayorovp
10.10.2016 10:07Полезность кода не измеряется его объемом.
PS https://github.com/reactjs/redux/blob/master/src/createStore.js — 254 стороки, и это только один файл. Где-то не там вы смотрели.
NIKOSV
10.10.2016 10:28+3Там комментариев и документации больше чем кода. Убрать все лишнее и будет 200 строк.
Я не о том полезный код или нет. Я о том, что в джаваскрипт мире хайп делают из ничего, из того что можно свелосипедить за пол дня и забыть, вместо того чтобы тащить 101-ую зависимость в проект со всеми вытекающими, читать мануалы по ней, разбираться почему не работает, дебажить, и т.д…
i_user
13.10.2016 09:48Некоторые вещи концептуальны) Это как доказательство в математике :-D — его полезность измеряется не объемом, а тем, насколько полезные результаты дает применение результата и насколько долго не могли получить это доказательство. Redux — это концептуальная штука, как раз. Фреймворк, навязывающий некоторые стиль написания кода. Я не буду сейчас утверждать, что это ограничение спасет вас от всех проблем — но, anyway — не стоит недооценивать его значимость)
andreysmind
10.10.2016 10:33+3Он не только библиотечку написал, он в принципе топит за функциональный подход в разработке, написал кучу полезных штук кроме самого redux для этого, постоянно везде помогает и советует.
a-motion
10.10.2016 15:02+1Аксиомы поля вещественных чисел вообще в 10 строчек помещаются.
Чем меньше кода в полезной полной сущности — тем лучше.
var-log
13.10.2016 02:57+1Redux это больше паттерн управления состоянием приложения (что-то вроде улучшения flux). И этот паттерн успешно применяется и без самой библиотеки и даже на других языках (re-frame для reagent — реализация Redux для ClojureScript).
Собственно, сама библиотека не ограничивается redux, для использования редакса с реактом нужно еще react-redux.
Idot
11.10.2016 12:20-3Теперь понятно, почему у меня, на неслабом компьютере на котором летает новый DOOM, часто виснут сайты с джава-скриптами :(
mayorovp
11.10.2016 12:57+1Не по-этому. Сайты с js виснут потому что:
- забыли поймать и обработать исключительную ситуацию;
- подключили сразу две версии jquery (что привело к исключительной ситуцаии, которую никто не поймал и не обработал);
- показан баннер на Flash;
- показан анимированный баннер на HTML5, который подключил свой jquery (см. выше);
- нестабильная связь с сервером (что привело к исключительной ситуации, которую никто не поймал и не обработал);
- jquery-программист не умеет отменять таймеры.
Все эти ситуации я сам наблюдал на чужих сайтах (включая мой интернет-банк!). А вот чтобы сайт тормозил просто из-за обилия скриптов на современном компьютере — я не видел (хотя на старом железе — наблюдал не раз).
Idot
11.10.2016 13:24Не знаю, но когда открываешь какой-нибудь сайт нередко сразу начинается загрузка процессоров на 25%, и эта загрузка длится и длится, порой свыше получаса. И это ещё ДО того как окончательно завис сайт.
taujavarob
11.10.2016 16:40>показан баннер на Flash;
как он прорвался то этот баннер на Flash? В каком броузере такая оплошность ЕЩЁ допускается то?
stychos
11.10.2016 13:50+1— NPM?
— Это очень большое общественное хранилище, где умные люди постят код и зависимости в виде модулей.
— Как CDN?
— На самом деле, нет. Это больше похоже на централизованную базу данных, где каждый желающий может опубликовать и скачать библиотеки, так что ты можешь использовать их локально для разработки, а затем загрузить их на CDN, если захочешь.
— О, как Bower!
Я ничего не понял, Bower же — тоже для npm (никогда не понимал, зачем менеджеру пакетов нужен менеджер пакетов), как такой диалог может быть уместен?
А по сабжу, я вообще не понимаю ничего. Где надо, мне как правило достаточно браузерного JavaScript, даже jQuery-плюхи уже давно не нужны — http://youmightnotneedjquery.comtaujavarob
11.10.2016 16:46> Bower же — тоже для npm (никогда не понимал, зачем менеджеру пакетов нужен менеджер пакетов)
Пакеты разные.
lamo4ok
12.10.2016 15:04-1Bower и npm — это два разных подхода. Если второй тащит за собой кучу своего барахла и зависимостей и вообще является эдакой стартовой точкой для формирования проекта, со всеми инструментами, то первый позволяет просто закачать необходимые пакеты и потом использовать их там, где это нужно, при этом набор пакетов во втором больше заточен на фронтенд.
Другими словами, npm лучше подходит для бекенда, Bower — для фронтенда. А так да, если не обращать внимание на эту мелочь и на то, что по набору пакетов они не тождественны, в целом это одно и то же.stychos
12.10.2016 15:30Я ничего не понял. Bower же — пакет для npm. Как можно притащить его, не притащив ещё «кучу барахла и зависимостей» npm?
taujavarob
12.10.2016 16:16+1Забудьте оба. Вы же в мире JS, тут всё меняется, тут никто не стоит на месте. Все бегут. ;-)
Встречайте НОВУЮ звезду — НОВЫЙ пакетный менеджер: Yarn
https://code.facebook.com/posts/1840075619545360
«A new package manager for JavaScript»
sumanai
12.10.2016 17:28тут никто не стоит на месте. Все бегут. ;-)
Скорее тут нужно бежать, чтобы стоять на месте. А чтобы продвигаться дальше, нужно бежать с удвоенной скоростью )taujavarob
12.10.2016 17:53>Скорее тут нужно бежать, чтобы стоять на месте.
Нет. — Тут многие остановились.
Смотрите сколько минусов я получил за то, что высказался как вы:
https://habrahabr.ru/post/312022/?reply_to=9855604#comment_9847766
Так что многие тут отстали. (С)
funnybanana
12.10.2016 01:40А я только в этом году начал использовать SVG и работаю с jQuery…
Я видимо уже совсем безнадёжен =( Не успеваю следить за всем… Даже html5 боюсь в проектах использовать…
Toshiro
13.10.2016 16:27Я что-то не понял, а что это за наезд на python в конце? Ну да, у нас в сообществе идет вялотекущий переход с версии 2 на 3. Но возникающие проблемы не идут ни в какое сравнение с бардаком творящимся на фронтенде.
И сколько бы фронтендщики ни пытались залезть на бек со своим Node.js, идите вжопу! Я скорее потрачу дополнительное время, добавив в проект поддержку обеих версий питона, чем соглашусь кодить на JS до конца жизни!taujavarob
13.10.2016 16:37>Я скорее потрачу дополнительное время, добавив в проект поддержку обеих версий питона, чем соглашусь кодить на JS до конца жизни!
Да, ладно. Вскорости все везде будут писать на JS. ;-)
Остальные? — Остальные уйдут в свои ниши. Если… найдут их. ;-)Toshiro
13.10.2016 17:28Никогда все везде не будут писать на JS) Вскорости его попытка вылезти на бекенд обломится и он вернется на фронтенд, где ему и место.
var-log
13.10.2016 17:36+1Но ведь это уже не попытка, он успешно перелез на бекенд и крепко там засел…
a-motion
13.10.2016 20:11+1Я очень надеюсь, что когда-нибудь какой-нибудь транспайлер из списка https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS допилят, и, наконец-то, можно будет без респиратора открывать фронтовой код. Хотелось бы, конечно, чтобы победил http://luvv.ie/
:)
denisei
17.10.2016 14:07+1В данном случае автор постарался художественно связно перечислить все современные наработки в мире JS. Но на самом деле не все так плохо. Имея в вебе опыта чуть более чем ноль, и полгода работая над своим проектом, освоил такую связку: Webpack + Vue.js для фронтенда, nodejs для бэкенда (чтобы не учить другой язык). Сервер сам собирает и отдает клиента. Дальше промисов в сторону (async/await) не пошел (хотя ознакомился и даже написал пару модулей). Мне не очень нравится, когда пихают в язык новые ключевые слова. По этой же причине до сих пор работаю с require() — очень уж пришелся по душе тот факт, что такую модульную систему можно реализовать средствами самого языка 5 версии. Но если честно, перейти на async/await и прочие прелести не проблема, т.к. под капотом Vue.js на стороне сервера все равно работает Babel.
Так что не стоит драматизировать.taujavarob
17.10.2016 14:18>Мне не очень нравится, когда пихают в язык новые ключевые слова.
Вы уже, в самом начале, вступили на дорогу отстающего.
denar90
Неплохие мысли от Эдди Османи по этому поводу. https://medium.com/@addyosmani/totally-get-your-frustration-ea11adf237e3#.3opyc4gll