Привет, приятель!
Ниже ты найдешь большой список компоновки инструментов и фреймворков. Не волнуйся! Ты можешь выбрать один, в котором точно уверен, или проигнорировать все и придумать свой вариант.
Данная статья предназначена для того, что бы помочь тебе узнать и упорядочить список инструментов которые используются в сфере frontend-разработки. А так же, это неплохой список, из которого ты можешь выбрать то, что тебе придется по душе.
Пользуюсь ли я этим сам?
Да, я использую это как напоминалку с разными вариантами настройки которые мне могут пригодится.
Кроме того, именно сюда я направляю людей, которые спрашивают меня: «Что мне использовать для разработки?». Потому что, как вы знаете, нет идеального варианта, но есть возможность упростить себе выбор.
А так же, я часто переписываю эту статью, потому что узнаю что-то новое и меняю свое мнение о старом. (И потому-что, пока вы читали эту статью, было собрано и выпущено 37 новых библиотек).
С чего же начать?
Если у вас крупный и, в перспективах, долгоиграющий проект, вам пригодится:
1. Модульная структура проекта. Лично я предпочитаю модульную архитектуру. И многие фреймворки мне ее предоставляют. Но в крайних случая можно пользоваться и BOT, Elm Architecture, re-frame и CycleJS.
2. Загрузчик модулей/Bundler (RequireJS, Browserify, Webpack, ComponentJS, SystemJS). Эти вещи помогут сохранить ваш код легкочитаемым и простым в поддержке.
3. Менеджер пакетов (npm, jspm, bower). Лично я остальным предпочитаю npm, ибо, де-факто, это стандарт в мире JS- и node-разработчиков.
Так же, я полагаю, что bower со временем станет популярней — это замечательный инструмент для быстрой загрузки компонентов. Но, увы, он не так силен в управлении компонентами и зависимостями как npm. Ваше мнение может отличаться.
4. Автоматизация сборки и компиляции (grunt/gulp/broccoli). Ибо жизнь и без того коротка, чтобы делать это снова, и снова, и снова.
5. CSS-препроцессоры (jss/stylus/sass/css-modules) и -постпроцессоры (csso/autoprefixer/postcss). Эти инструменты сделают ваш CSS чуточку лучше и исключат некоторые проблемы с кросс-браузерностью.
Да, я знаю. 2016. Но в любом случае, это до сих пор, как заноза в заднице.
6. Markup/UI-фреймворки (Bootstrap, Zurb Foundation, Elemental UI, Material Lite). Эти вещи несут тонны знаний и 1000 лет страданий веб-разработчиков. Они помогут вам справиться с основной разметкой и стилями.
Однако, если вы считаете, что вы герой разметки и эксперт фронтенда, или вашей компании нужен свой собственный стиль, вы можете разработать собственное решение.
В таком случае, я предлагаю выбрать вам методологию (BEM, OOCSS), что сэкономит ваше время.
Лично я предпочитаю схему BEM и собственное рабочее окружение. Пару мыслей об этом вы можете найти в стайлгайде для Brainly.com, который я помогал собирать.
Если вы не знаете с чего начать разработку собственных методов, вам стоит посмотреть на HTML5 Boilerplate.
7. Тестеры (jasmine, karma, mocha, tape, intern). Все требует проверки. Без исключений.
8. Инструменты, обеспечивающие качество кода (eslint, husky, editorconfig). Вы же не хотите превратить свой код в свалку?
9. Сообщества, где вам помогут (chats, IRC, meetups, twitter).
Вы живете не в бункере (ведь так?). Люди могут знать. И в общем то, любят помогать другим.
Хорошо, что дальше?
А вот набор важных вопросов, на которые необходимо ответить, прежде чем приступать к разработке и решению поставленных проблем.
Вы готовы?
1. Нужно ли работать над проектом в команде? Кто они и чего хотят? Данный ответ поможет выбрать вам язык и рабочее окружение, полезные для вас и вашей компании.
2. На чем лучше сосредоточиться: качество, скорость, простота поддержки? Здесь вы поймете, на сколько сильно можно экспериментировать и не ошибиться в выборе инструментов.
3. Стоит ли передавать мой проект в «Третьи руки»? Понимая это, вы сможете ограничить набор инструментов и выбрать, для помощи и поддержки, наиболее подходящее сообщество.
4. Стоит ли браться за основной продукт, или ограничиться дочерними проектами? Если вы возьметесь за основной проект, это позволит использовать вам проверенные технологии и фреймворки, что сохранить ваше время и нервы.
5. Является ли проект интерактивным, или это набор статических документов? Может оказаться, что все что вам понадобится это HTML, CSS и немного магии. А также генератор сайтов или CMS.
6. Это один проект или группа родственных проектов? Вы сможете использовать набор компонентов и стайлгайд, если даже ваш проект — набор статических документов, что бы уменьшить рутинную работу и упорядочить ваш код. А так же, предусмотреть СЕО и рендер со стороны сервера.
Список языков и надстроек
Ответив на эти важные вопросы, настало время поговорить со своими товарищами и выбрать язык. Потому что, есть много вещей удостоенных внимания, помимо этого безумного javascript!
1. Есть ли у вас команда JS-разработчиков? Рассмотри возможность использования ES6 (с Babel). Это сделает твою жизнь чуточку легче.
2. Вы предпочитаете типизированные языки? С типами вы на «Ты»? Посмотри на typescript.
3. Вы спокойно плаваете в функциональном программировании? Ты можешь начать с малого, с ES6 и библиотек типа lo-dash или ramda. Есть несколько хороших книг и уроков, которые помогут тебе освоиться на этом пути.
4. Вы пробовали себя в функциональном JS, и хотите еще больше хороших плюшек? Попробуй elm. Это просто шикарно!
5. Вы full stack разработчики? Попробуй clojurescript. Это не менее шикарно!
6. Вам нравится Scala? Пробуем scalaJs.
7. Вы знаете и любите Haskell? Попробуй purescript. Без понятия, на сколько это круто.
8. Не хватает безумия? Вот список язык, компилирующихся в javascript. Выбирай любой и наслаждайся.
Список фреймворков
1. Все что тебе нужно, это простое работающее приложение? Нет времени на «фундаментальные разработки»? Твой выбор — angular. Начинай без промедлений.
2. Необходима простота и скорость? А так же есть время на поддержку в будущем? Выбирай angular. Но, будь во всеоружии.
3. Вы бекэндеры, пытающиеся заниматься фронтендом, так как нет иного выхода? Да, да, angular. Начни разрабатывать фронтенд!
4. Необходимо быстро начать и быстро разработать. с возможными допущениями? Пробуем ampersand/backbone + библиотеки, подходящие под ваши запросы.
5. Запросы те же, проекты больше? Добавляем marionette/chaplin к backbone и подумываем о переходе на ReactJs.
6. Есть время на эксперименты, с желанием, в будущем получить работающий вариант? Пробуем mithril/knockout/aurelia с необходимыми библиотеками.
7. Ты в целом неплохо разбираешься в интерфейсах и знаешь базу функционального программирования? Пробуй ReactJs + redux + ImmutableJS + библиотеки.
8. Больше навыков функционального программирования? Безумное приложение? Добавь реактивного программирования (bacon, rxJS) или попробуй Cycle.js (на свой страх и риск).
Примечание 0: Возможно, будет хорошей идеей взяться за реактивное программирование в любом случае, и походу обучать ему других.
Примечание 1: Пожалуйста, не путайте реактивное программирование с FRP
9. Ваше приложение будет расти, команда развиваться, и у вас есть время на обучение? Потратьте его на emberjs. Поверьте, это не плохое вложение.
10. Приложению необходим функционал его «страших братьев»? В нем будут таблицы, чаты и прочие вещи для аналитики? Корпоративное приложение? Пробуй ExtJS.
11. Вы студия? Тогда, у вас уже должен быть набор любимых инструментов. В любом случае, ориентируйтесь на то, что вы лучше знаете и чаще используете.
12. Фрилансер? Адаптируйся под условия. Попробуй Angular. Не мучайся. Пусть страдают другие, если хотят.
Примечание: Но вряд ли вы что-то сделаете, если клиент не захочет за это платить.
13. Пытаешься собрать конечный продукт? Адаптируйся под конкретные нужды и выбирай из приведенного выше списка.
14. Ты точно знаешь, что хочешь получить на выходе (например, мобильное приложение с десятью экранами)? Поэкспериментируйте пару недель с ionic, famous, Sencha Touch.
Как начать программировать?
1. Изучите документацию для фреймворков и инструментов, которые вы выбрали.
2. Поспрашивайте более опытных людей для лучшего старта.
3. Настройте инструменты.
4. Хак. Я бы посоветовал вместо проектирования.
5.…
6. PROFIT!1
Я понятия не имею как начать пользоваться фреймворками, которые вы посоветовали?
Посмотрите на TodoMVC Examples и найдите пример с фреймворком, который вы выбрали.
Но помните, что это лишь примеры, которым вряд ли суждено разрастись до серьезных проектов
Я не могу принять решение. Как мне быть?
Хорошо, хорошо успокойтесь.
Если вы не можете решить, возьмите EmberJS, или, если чувствуете в себе силы ReactJs + Redux + ES6 + webpack + npm + jss + autoprefixer + eslint + Elemental UI + karma. И прочтите это!
Это оно. Не спрашивайте почему, а просто возьмите и начинайте разрабатывать.
Слишком много упоминаний ReactJs. С чего бы?
За ним будущее веб разработок. Вот неплохая статья, объясняющая это.
А так же им пользуется огромное количество людей. Вы несомненно должны попробовать его в каком-нибудь из своих проектов. Это будет весело, я гарантирую!
Счастливого плавания!
Если вас заинтересовало, и вы желаете более детально углубиться во фронтенд разработку, загляните сюда.
P.S.: Целью перевода было не уличение автора во лжи, обмане и невежестве. Не разбавления своими мыслями и замечаниями. Целью перевода был перевод.
Комментарии (61)
spmbt
19.02.2016 14:07-4К аудитории: расскажите, кто что думает о скрещении Angular 1.x + React + ES6 ?
Везде этот вопрос тщательно обходят, считая, что Angular самодостаточен. Но скрещивание имеет такие плюсы: 1) в A2.0 реактивная модель DOM, скорее всего, будет, судя по намёткам и статьям; 2) появляется возможность перетащить логику из шаблонов (фирменный недостаток Ангуляра и большинства движков) в JS, работая с моделью DOM в стиле React (JSX), 3) ангулярщики будут пользоваться, в основном, привычными инструментами. В и-нете попадалась статья о том, как практически это делать:
http://www.sitepoint.com/react-for-angular-developers/
https://habrahabr.ru/post/215607/
https://habrahabr.ru/company/eastbanctech/blog/232229/
Devgru
19.02.2016 15:21+2Ничего особо сложного, из ангуляра легко отрендерить риактовский компонент. Но и смысла не очень много, только если ради ускорения отрисовки сложных элементов.
lega
19.02.2016 15:491) в A2.0 реактивная модель DOM
Что вы имеете ввиду? Будет то же самое что и в A1, только $digest/$apply не надо* будет вручную дергать, т.к. они все отложенные вызовы (setTimeout/setInerval/...) заврапили.
2) появляется возможность перетащить логику из шаблонов (фирменный недостаток Ангуляра и большинства движков) в JS, работая с моделью DOM в стиле React (JSX),
Это откуда?, там почти так же как в А1, только парсер HTML шаблонов самописный (не стандартный).
Houston
19.02.2016 16:12+2Мы используем такую связку.
Жаловаться особо не на что, впрочем как и хвалить тоже нечего. Производительность не выросла на порядки, а скорее даже снизилась т.к. добавляется лишняя логика по связыванию react и angular, с ней добавляются баги, так как иногда lifecycles ангуляровских директив и реактовских компонентов не увязываются. Добавляется лишний оверхед, так как получается много DOM нод, которые выступают рутами для react-компонентов. Это медленнее, чем одна нормальная DOM root node, в которую нарендерено чистое react приложение.
В нашем случае преимущество достигается в том, что у нас одни react компоненты используются и в react-приложениях, и в angular.lega
19.02.2016 16:50Производительность не выросла на порядки, а скорее даже снизилась
Скорость снизилась потому что в большинстве случаев React работает медленнее чем Ангуляр, (смотрите бенчмарки).
not_ice
19.02.2016 17:15Хм, почему-то ни разу не упомянут Polymer, хотя это в какой-то мере аналог ReactJS, только построенный по-человечески, а не через выплевывание ошметков html-разметки в render().
serf
19.02.2016 19:27+1выплевывание ошметков html-разметки в render().
Ну а что вы хотило это ведь facebook == php like подход
faiwer
19.02.2016 17:26Подскажите, пожалуйста, а какова область применения AngularJS?
Автор оригинального поста столько раз упомянул его как серебрянную пулю, что у меня сложилось впечатления, будто это не развитый инструмент для построения сложных SPA, а некая универсальная библиотека, которая хорошо подойдёт и для реализации примитивного интерактива в "уютном бложеге", типа всяких "каруселей", слайдеров, форм регистрации, корзин заказов и пр… Это действительно так?
Просто: TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр. штуки… Зачем это всё, скажем, для реализации слайдера или формы обратной связи? Да даже для интерактивной страницы заказов. А маршрутизация на стороне клиента так вообще заставит вас всё перевернуть вверх дном.
Насколько комфортно и вообще разумно тащить Angular2 в обычные проекты, не SPA? Там где не нужна никакая клиентская маршрутизация и нет огромного backend API.
Спрашиваю не троллинга ради, а потому что дальше tutorial-а первого Angular-а не ушёл. и по сему плохо понимаю его область применения. А сам для решения насущных проблем использую KnockoutJS и свои собственные велосипеды, благо там многого от них не требуется. Конечно, можно и по старинке — взять jQuery или, скажем, Atom, и писать всё руками, без всяких data-bind-ингов и пр… Но решения на Knockout-е позволяют это сделать гораздо быстрее и надёжнее. При этом в нём нет всех этих страшных архитектурных штук.lega
19.02.2016 18:13-2примитивного интерактива в «уютном бложеге», типа всяких «каруселей», слайдеров, форм регистрации, корзин заказов и пр… в обычные проекты, не SPA
Посмотрите на Angular Light, на нем удобно и мелкие штуки делать, эта либа похожа* на Knockout.js, но данные не нужно заворачивать в observable объекты, ну и биндинги удобней.
serf
19.02.2016 19:55Просто: TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр. штуки
Эти штуки помогают структурировать и стандартизировать код, плюсы очевидны, но для мелких одноразовых задач конечно ангуляр может быть не оправдан. Роуты кстати это отдельный компонент, его совсем не обязательно подключать.
TypeScript вообще отдельный разговор с ангуляру не связанный, по очевидным причинам это очень хорошее подспорья для больших проектов где горы кода. MS молодцы что не повелись на все тот же "сахар" в ECMAScript, а решили сдеать по своему.faiwer
19.02.2016 20:14Эти штуки помогают структурировать и стандартизировать код
Потому я и говорю, что каждому инструменту своё место. И мне совершенно непонятна эта попытка затолкать Angular куда можно и куда нельзя.
Fen1kz
19.02.2016 21:22В отношении ajax корзин/форм регистрации ангуляр спокойно можно использовать просто ради дата-биндинга. Вы получите простую форму с валидацией практически без js-кода, а значит и без "TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр."
И как бонус — если вдруг вашей форме понадобится стать n-страничной или появится хитропридуманный элемент — вы имеете возможность структурированно расширить её функционал, не превращая все в веселую jquery кашу.
Серебрянная пуля — потому что с одной стороны, на ангуляре можно писать полноценные одностраничные приложения, с другой — можно иметь ангулярную приложеньку просто в отдельном диве и она обеспечит вам любой уровень интерактивности внутри него.faiwer
19.02.2016 22:02Вы получите простую форму с валидацией практически без js-кода
Вот это уже интересно. Примеры, что мне попадались, обязательно были сопровождаемы грудой инфраструктурного кода, который, на простых примерах, многократно превышал саму логику, которую необходимо реализовать. Получается это всё можно обойти в пару строк?
Я набросал примитивную форму на knockout-е. Можно ли решить такую задачу на AngularJS, без всех этих архитектурных излишеств (в рамках простой задачи) и boilerplate?lega
19.02.2016 23:55+1Сделал вариант на Angular Light
Т.к. там нет штатной библиотеки валидации, пришлось написать дополнительно 2 функции.
Много кода нужно дописать в пример на knockout, что-бы сделать такую же подсветку ошибок?
PS: Кстати в вашем примере не работает "minLenght: 5"lega
20.02.2016 00:01нет штатной библиотеки валидации, пришлось написать дополнительно 2 функции.
С другой стороны, это дает больше гибкости (у каждого css-фреймворка свой стиль ошибок) и не нужно грузить лишние +6кбfaiwer
20.02.2016 08:52Сделал вариант на Angular Light
Спасибо. Наглядно. Похоже принцип работы у Angular отличается от Knockout. Попробовал сделать сброс модели из setTimeout-а, не сработало. Получается, изменения сами по себе, как в Knockout-е повсеместно не отслеживаются, и необходимо Angular как-то уведомлять о том, что модель изменилась?
С другой стороны, это дает больше гибкости (у каждого css-фреймворка свой стиль ошибок) и не нужно грузить лишние +6кб
Knockout Validation это отдельная либа. Но можно и свою настрочить. А можно практически продублировать ваш пример.
Много кода нужно дописать в пример на knockout, что-бы сделать такую же подсветку ошибок?
Красным border-ом? Нет, код будет практически идентичным вашему (css: { error: !data.name.isValid() }). Ну и отключить поведение по-умолчанию.lega
20.02.2016 11:26и необходимо Angular как-то уведомлять о том, что модель изменилась?
Да, у этого подхода есть и плюсы и минусы. В данном случае нужно запустить .$scan() jsfiddle.net/lega911/5sd9oof7
Для Angular 1 можно использовать $timeout/$http, В Angular 2 есть zone.js который подменяет* все глобальные «отложенные»-методы (setTimeout/setInterval/xhr...)
Для меня это все равно удобней чем оборачивать все данные в observable бертки (я использовал ko до ангуляра), да и работает гораздо быстрее (судя по тестам).
код будет практически идентичным вашему
Тогда (бессмысленный) контр пример, тут в ko кода должно выйти поболее.
bromzh
20.02.2016 02:21+1Немного переделал пример отсюда
http://plnkr.co/edit/8YYsB0dB7iv1T4h3UbyY?p=preview
В реале $timeout заменяется на что-то типа
$http.get('/api/data'/) .then((response) => { this.data = response.data })
Если, например, нужна только валидация, то можно вообще почти без js:
http://plnkr.co/edit/PM8FkQZgkhmqaT9Or11B?p=previewfaiwer
20.02.2016 08:59Спасибо за пример. Интересно. И вправду немногословно. Вопрос, вы и lega в примерах всю валидацию перенесли в HTML. Это стандартный подход в Angular или просто для примера так удобнее?
В Knockout-е я обычно определяю конструктор для модели, в котором каждое поле обвешано валидаторами (как стандартными, так и специфичными, даже групповыми), а затем их просто использую в нужных местах (как в JS, так и в HTML). Т.к. одна и та же модель может быть использована в разных формах и вообще в разных ситуациях, а ещё, ввиду того, что логика валидации может быть очень непростой, мне кажется, что выносить её в HTML некорректно. Хотя в простых случаев, вроде моего примера, так даже проще.lega
20.02.2016 11:31+1или просто для примера так удобнее?
В данном случае, просто удобнее (меньше кода).
Вообще можно сделать расширение и вместо
писатьal-value="name"
илиal-value.validate="name"
илиal-value="name; validate"al-value="name" al-validate="options"
bromzh
20.02.2016 11:56Нет, валидация не в HTML. Вся логика валидатора — в скрипте. В HTML добавляется только атрибут в input-тег. У атрибута могут быть значения (ng-minlength="число"), либо могут отсутствовать. В моём примере я подключил модуль ngMessage просто для удобного вывода сообщений. Но можно вполне обойтись и без него, валидация в ангуляре из коробки. Есть стандартные валидаторы (общие для всех инпутов см. тут), но можно сделать и свой.
Чтобы сделать свой валидатор в ангуляре нужно:
1) создать директиву и указать у неё в зависимостях директиву ngModel
2) так как ngModel есть в зависимостях, мы можем получить контроллер этой модели в функции link
3) в полученном контроллере есть объект$validators, добавляем в него кастомную функцию-валидатор
4) сама функция должна либо возвращать булевское значение, либо возвращать промис
5) добавить созданную директиву в атрибуты валидируемого поля
Случай промиса очень интесен, так как позволяет делать асинхронные валидаторы. Например, в таком валидаторе можно сделать запрос на сервер, проверить валидность поля, и, в зависимости от ответа с сервера, либо сделать resolve промиса, либо reject. А вообще, через контроллер модели и через контроллер всей формы можно очень гибко управлять состояниями любых полей ввода, даже своих.
Ну и валидатор хранится не в модели. Он создаётся 1 раз и добавляется к валидируемой модели путём простого добавления атрибута в тег.
Пример кастомного валидатора в доках в главе Custom Validation (или см. тут). Как по мне, тут очень мало лишнего кода.faiwer
20.02.2016 12:14В HTML добавляется только атрибут в input-тег.
5) добавить созданную директиву в атрибуты валидируемого поля
Именно это и смущает. Почему это в HTML? Я ещё понимаю, когда логика UI во многом декларативно описывается в HTML, но валидация модели…bromzh
20.02.2016 13:55+1Мне сложно объяснить простыми словами…
Считайте эти валидаторы (которые в виде директив) лишь неким предварительным фильтром.
Внутри формы нам доступен контроллер самой формы. Он следит за дочерними инпутами. А ещё есть контроллер всего view. Они разные. Первый нужен, например, чтобы проверять введённые данные на корректность. Второй же связывает данные во view с самим приложением через контроллер этого view.
Ну например, нам нужно поле ввода IP адресов. В HTML нет такого поля. Но его можно сделать из инпута. Мы можем сделать так:
<input name="address" ng-model="vm.data.address" pattern="^(?:[0-9]{1,3}\.){3}[0-9]{1,3}$"/>
А можно создать свою директиву для такого поля ввода. Допустим, мы сделали такую директиву, теперь можем писать так:
<ip-input ng-model="vm.data.address"/>. Просто чтобы не создавать каждый раз свою директиву, которая будет по-сути алиасом, можно в старые добрые инпуты HTML добавить несколько аттрибутов, и получить немного другое поле ввода...
В HTML же есть валидаторы: required для input, min/max для input[number] и т.д. Ангуляр умеет работать с ними, но, помимо этого, позволяет расширить этот список своими собственными.
При всём при этом, сама модель может быть валидной с точки зрения пользовательского ввода, но быть невалидной после серверной валидации...lega
20.02.2016 17:05В HTML же есть валидаторы: required для input, min/max для input[number]
Я вот тоже про это хотел написать, тот же type=«number» и пр. можно назвать валидатором/модификатором. Т.е. это уже начато в HTML (в стандарте), и мне кажется, что указать «pattern/min/max» в HTML — это удобнее чем конфигурировать в коде.
Fen1kz
21.02.2016 05:13Пожалуйста: https://jsfiddle.net/jnjpszqa/
У вас, кстати, баг — можно стереть до vasy и нажать сабмит. ну и ошибки не сразу обновляются.
MrMig
21.02.2016 03:42+2Как автор оригинальной статьи, могу сразу же предложить почитать вот это: http://www.fse.guru/2-years-with-angular
У ангуляра вообще всё сложно с историей и "самоидентификацией". Из него в итоге и слепили комбайн для всего, по примеру джавы (оттуда все эти контроллеры и фабрики-сервисы-провайдеры).
Зачем это всё, скажем, для реализации слайдера или формы обратной связи?
Нафиг не нужно.
Но позволяет нафигачить слайдер чуть быстрее, чем на голом жс.
А маршрутизация на стороне клиента так вообще заставит вас всё перевернуть вверх дном.
Не нужна — не используйте.
Насколько комфортно и вообще разумно тащить Angular2 в обычные проекты, не SPA?
На данный момент, по моему мнению, абсолютно рискованно и неразумно его тащить даже в SPA.
При этом в нём нет всех этих страшных архитектурных штук.
Стоит учесть, что люди выбирают ангуляр в том числе и из-за хайпа. А потом страдают от архитектурных изворотов :)
hudson
19.02.2016 17:37-1Поддерживаю вопрос. Я сейчас выбираю фронтэнд для двух проектов, предварительно остановился на Angular2. Прошел туториал, написал ToDo и вроде как готов продолжать изучать и пользоваться, но у меня не SPA и сижу в раздумьях: "а стоит ли оно того". Слайдеры, попапы, календари, тултипы, формы, ajax — на текущий момент вероятно основные потребности...
hudson
19.02.2016 17:38Черт, ошибся веткой. Это был комметарий к вопросу faiwer (https://habrahabr.ru/post/277547/#comment_8778819)
serf
19.02.2016 19:59-1А почему нет, как минимум у вас будет опыт работы с ангуляром2 и далее при выборе инстурментов для новых проектов вы уже сможете решать основываясь на своем опыте, и опыт сам по себе ценен. Только вот вокруг первого ангуляра уже уйма библотек/компонентов, а второй еще этим не особенно оброс, иногда это важный момент (когда нужно быстро что-то сварганить, прототип какой и тд).
hudson
19.02.2016 20:56-1Хочу рискнуть со вторым. Мне понравилась изолированность компонентов, кроме того я некоторое время интересуюсь БЭМ и Material Design Lite, а эти вещи хорошо стыкуются судя по всему.
serf
19.02.2016 21:17-1Поему рискнуть, это как раз самый потенциально толковый интсурмент (особенно для крупных проектов), я их уважаю хотя бы за то что понимают ценностьTypescript (по крайней меня для библиотек/фреймворков).
hudson
19.02.2016 22:29-1Ну элемент риска присутствует. Angular2 пока не production-ready, как выше упоминалось — компонент готовых нет, коммьюнити еще вялое. Ну и опыта у команды с ним около нуля. Но на одном проекте точно надо попробовать )
stardust_kid
19.02.2016 19:00Ну то есть статья сводится к тому, что надо выбирать Angular, а если не Angular, то React?
Diaver
19.02.2016 19:14+12Мдаа… сейчас чтобы сделать простую страничку с двумя формачками надо знать over 9000 инструментов и человеко-неделю времени чтобы это все запустить. Как-то печально.
serf
19.02.2016 20:03+1Если заранее известно что это простая страничка, самодостаточная без шансов на дальнейшее развитие или интеграцию в крупный проект, то никакие горы инструментов не нужны (хотя по мне так подобные простые задачи как раз место, где можно пробовать новые штуки в деле, тк работая с крупными проектами пробовать что-то новое в деле не так просто). Но речь ведь может идти об обносительно комплексных проектах, с длительной стадией разработки и не совсем четкими пдланами на бужующее — в этом случае к выбору инструмента лучше подойти внимательно.
Diaver
19.02.2016 23:25+1Я задумался, кто-то может попробовать предсказать что с веб-фронтэндом будет лет так через 10?
Потому что если просто провести прямую между количеством инструментов сейчас и 5 лет назад, то становится страшно. Воображение рисует будущее, в котором БАК представляется милой детской игрушкой в сравнии с веб-фронтэндом будущего.strannik_k
20.02.2016 12:48Предположу, что фронтэнд технологии будут группироваться в отдельные стеки и будут искаться специалисты под них.
Как сейчас на сервере стеки технологий — .NET, Java, PHP, Node.JS, Python, так и потом будет на клиенте — React со своим набором технологий, Angular со своим, еще несколько каких-нибудь фреймворков.
Верстка вряд ли, но тоже может на 2-3 направление разделиться: верстальщик, верстальщик анимационных эффектов.
MrMig
21.02.2016 03:46Достаточно иметь человека в коммунити, который сможет отговорить вас от использования лишних инструментов :)
И сразу же всё становится сильно проще.
mib
19.02.2016 20:32-3такое ощущение, что те, кто пишут на ява-скрипте, jquery — пишут практически на ассемблере, это ужасно неудобно, медленно и прошлый век
serf
19.02.2016 21:51Если писать грамотно на jquery то медлено не будет, но очень часто код на jquery это код школоты так как с первого взгляда порог вхождения не высокий. Прошлый век потому что в этом веке стали модны SPA, то есть много логики и в целом кода переехало на клиентсайд (а бэкенд стал stateless — наоборот упростился), это все нужно структурировать, а jquery создан лишь для DOM манипуляции. Еслил хотите jquery это всего лишь винтик в общем стеке.
igor-petrov
21.02.2016 18:46+1К слову, сборщик Component, о котором упоминается в статье, больше не разрабатывается и находится в статусе deprecated.
Ninjak
а LESS нынче не котируется? ;)
Bellicus
Перейдя по ссылке в первом предложении, вы можете, лично, задать вопрос автору оригинальной статьи о том, как это он посмел позабыть про LESS, попутно обрушив на него все проклятия и беды этого мира.
Ninjak
это скорее был вопрос к сообществу ;)
spmbt
Тем более, что автор оригинала MrMig — настолько иностранец, что приводит ссылку "chats" — на русские чаты пo IT.
(переводчику — проще и полезнее просто добавить ссылку на Less в статью, в скобках с "прим. перев.")
Bellicus
Ну что ж, всем не угодишь. Кому то не понравилось, что забыли про less, кто-то не согласиться с высказываниями про react и bower, кто-то вспомнить о существовании еще пары тысяч линтеров. И в итоге весь перевод будет "прим. перев"
Вот для таких случаев и был оставлен постскриптум.
spmbt
Вы пришли сюда хорошие статьи писать или делать хорошие переводы? )
Статья ценна информацией, и если в оригинале что-то забыли, как Less, то ради информации стоит добавить. По крайней мере, я так делал в переводах.
Заодно, вопрос к MrMig задам — почему Вы в конце советуете Ember тем, кто не может выбрать? Чем он решительно лучше? Не сильно ли он завязан на Ruby?
MrMig
Я советую Эмбер потому, что он решает много задач, и решает их хорошо.
Эмбер вобрал в себя много устоявшихся и прагматичных решений, в том числе "из мира Ruby".
Я бы не сказал, что он "завязан на руби". Но это вопрос трактовки.
MrMig
Автор беларус, так что русский язык родной :)
Devgru
забудьте про всё это, используйте PostCSS :-)
leMar
Почему комментарий про PostCSS в минусах? Что с ним не так?
VolCh
Слишком категоричен бех аргументов
Apathetic
Он предлагает забыть всё остальное.
barkalov
Кстати, как синдром: новый Bootstrap 4 будет под SCSS, а не под LESS.
MrMig
SCSS умеет больше, чем LESS.
Если писать что-то сложное, то SCSS предоставляет чуть больше инструментов для абстрагирования CSS-кода и контроля сложности.
barkalov
Даже не знаю, за что вам влепили минус. Я с вами согласен. Один факт, который кое о чем говорит: SASS (в отличие от LESS) — тьюринг-полный.
Shablonarium
Для приличия можно было и сказать на чем будет Bootstrap 5.
barkalov
И на чем же?
MrMig
LESS нынче не котируется. ;)
Apathetic
С чего бы? Вижу, что ответил выше. Но это неправда. LESS умеет не меньше, чем SCSS, и я был бы рад увидеть примеры обратного — с учетом того, что это в принципе разные вещи, хоть и пытающиеся делать одно и то же.