Как выбрать фреймворк для frontend-разработки

Предлагаю вашему вниманию перевод статьи How To Pick a Frontend Web Framework c сайта top.fse.guru.

Привет, приятель!

Ниже ты найдешь большой список компоновки инструментов и фреймворков. Не волнуйся! Ты можешь выбрать один, в котором точно уверен, или проигнорировать все и придумать свой вариант.

Данная статья предназначена для того, что бы помочь тебе узнать и упорядочить список инструментов которые используются в сфере 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. Это один проект или группа родственных проектов? Вы можете захотеть использовать компонентный подход и стайлгайд, если даже ваш проект — набор статических документов, что бы уменьшить рутинную работу и упорядочить ваш код. А так же подумайте над SEO и рендере на стороне сервера в этом случае.

Список языков и надстроек


Ответив на эти важные вопросы, настало время поговорить со своими товарищами и выбрать язык. Потому что, есть много вещей достойных вашего внимания, помимо этого безумного javascript!

1. Есть ли у вас команда JS-разработчиков? Рассмотри возможность использования ES6Babel). Это сделает твою жизнь чуточку легче.

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: Возможно, будет хорошей идеей взяться за reactive streams в любом случае, и походу обучать ему других.

Примечание 1: Пожалуйста, не путайте reactive streams с 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.: Целью перевода было не уличение автора во лжи, обмане и невежестве. Не разбавления своими мыслями и замечаниями. Целью перевода был перевод.
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 62

    +5
    CSS-препроцессоры (jss/stylus/sass/css-modules)

    а LESS нынче не котируется? ;)
      –7
      Перейдя по ссылке в первом предложении, вы можете, лично, задать вопрос автору оригинальной статьи о том, как это он посмел позабыть про LESS, попутно обрушив на него все проклятия и беды этого мира.
        0
        это скорее был вопрос к сообществу ;)
          +2
          Тем более, что автор оригинала MrMig — настолько иностранец, что приводит ссылку "chats" — на русские чаты пo IT.

          (переводчику — проще и полезнее просто добавить ссылку на Less в статью, в скобках с "прим. перев.")
            +2
            Ну что ж, всем не угодишь. Кому то не понравилось, что забыли про less, кто-то не согласиться с высказываниями про react и bower, кто-то вспомнить о существовании еще пары тысяч линтеров. И в итоге весь перевод будет "прим. перев"

            Вот для таких случаев и был оставлен постскриптум.
              –4
              Вы пришли сюда хорошие статьи писать или делать хорошие переводы? )
              Статья ценна информацией, и если в оригинале что-то забыли, как Less, то ради информации стоит добавить. По крайней мере, я так делал в переводах.

              Заодно, вопрос к MrMig задам — почему Вы в конце советуете Ember тем, кто не может выбрать? Чем он решительно лучше? Не сильно ли он завязан на Ruby?
                0
                Я советую Эмбер потому, что он решает много задач, и решает их хорошо.
                Эмбер вобрал в себя много устоявшихся и прагматичных решений, в том числе "из мира Ruby".

                Я бы не сказал, что он "завязан на руби". Но это вопрос трактовки.
              0
              Автор беларус, так что русский язык родной :)
            –7
            забудьте про всё это, используйте PostCSS :-)
              0
              Почему комментарий про PostCSS в минусах? Что с ним не так?
                +1
                Слишком категоричен бех аргументов
                  0
                  Он предлагает забыть всё остальное.
                +1
                Кстати, как синдром: новый Bootstrap 4 будет под SCSS, а не под LESS.
                Moved from Less to Sass. Bootstrap now compiles faster than ever thanks to Libsass, and we join an increasingly large community of Sass developers.

                  –1
                  SCSS умеет больше, чем LESS.
                  Если писать что-то сложное, то SCSS предоставляет чуть больше инструментов для абстрагирования CSS-кода и контроля сложности.
                    0
                    Даже не знаю, за что вам влепили минус. Я с вами согласен. Один факт, который кое о чем говорит: SASS (в отличие от LESS) — тьюринг-полный.
                    0
                    Для приличия можно было и сказать на чем будет Bootstrap 5.
                      0
                      И на чем же?
                    –1
                    LESS нынче не котируется. ;)
                      +1
                      С чего бы? Вижу, что ответил выше. Но это неправда. LESS умеет не меньше, чем SCSS, и я был бы рад увидеть примеры обратного — с учетом того, что это в принципе разные вещи, хоть и пытающиеся делать одно и то же.
                    –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/
                      +2
                      Ничего особо сложного, из ангуляра легко отрендерить риактовский компонент. Но и смысла не очень много, только если ради ускорения отрисовки сложных элементов.
                        0
                        1) в A2.0 реактивная модель DOM
                        Что вы имеете ввиду? Будет то же самое что и в A1, только $digest/$apply не надо* будет вручную дергать, т.к. они все отложенные вызовы (setTimeout/setInerval/...) заврапили.
                        2) появляется возможность перетащить логику из шаблонов (фирменный недостаток Ангуляра и большинства движков) в JS, работая с моделью DOM в стиле React (JSX),
                        Это откуда?, там почти так же как в А1, только парсер HTML шаблонов самописный (не стандартный).
                          +2
                          Мы используем такую связку.
                          Жаловаться особо не на что, впрочем как и хвалить тоже нечего. Производительность не выросла на порядки, а скорее даже снизилась т.к. добавляется лишняя логика по связыванию react и angular, с ней добавляются баги, так как иногда lifecycles ангуляровских директив и реактовских компонентов не увязываются. Добавляется лишний оверхед, так как получается много DOM нод, которые выступают рутами для react-компонентов. Это медленнее, чем одна нормальная DOM root node, в которую нарендерено чистое react приложение.

                          В нашем случае преимущество достигается в том, что у нас одни react компоненты используются и в react-приложениях, и в angular.
                            0
                            Производительность не выросла на порядки, а скорее даже снизилась
                            Скорость снизилась потому что в большинстве случаев React работает медленнее чем Ангуляр, (смотрите бенчмарки).
                          0
                          Хм, почему-то ни разу не упомянут Polymer, хотя это в какой-то мере аналог ReactJS, только построенный по-человечески, а не через выплевывание ошметков html-разметки в render().
                            +1
                            выплевывание ошметков html-разметки в render().

                            Ну а что вы хотило это ведь facebook == php like подход
                            0
                            Подскажите, пожалуйста, а какова область применения AngularJS?

                            Автор оригинального поста столько раз упомянул его как серебрянную пулю, что у меня сложилось впечатления, будто это не развитый инструмент для построения сложных SPA, а некая универсальная библиотека, которая хорошо подойдёт и для реализации примитивного интерактива в "уютном бложеге", типа всяких "каруселей", слайдеров, форм регистрации, корзин заказов и пр… Это действительно так?

                            Просто: TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр. штуки… Зачем это всё, скажем, для реализации слайдера или формы обратной связи? Да даже для интерактивной страницы заказов. А маршрутизация на стороне клиента так вообще заставит вас всё перевернуть вверх дном.

                            Насколько комфортно и вообще разумно тащить Angular2 в обычные проекты, не SPA? Там где не нужна никакая клиентская маршрутизация и нет огромного backend API.

                            Спрашиваю не троллинга ради, а потому что дальше tutorial-а первого Angular-а не ушёл. и по сему плохо понимаю его область применения. А сам для решения насущных проблем использую KnockoutJS и свои собственные велосипеды, благо там многого от них не требуется. Конечно, можно и по старинке — взять jQuery или, скажем, Atom, и писать всё руками, без всяких data-bind-ингов и пр… Но решения на Knockout-е позволяют это сделать гораздо быстрее и надёжнее. При этом в нём нет всех этих страшных архитектурных штук.
                              –2
                              примитивного интерактива в «уютном бложеге», типа всяких «каруселей», слайдеров, форм регистрации, корзин заказов и пр… в обычные проекты, не SPA
                              Посмотрите на Angular Light, на нем удобно и мелкие штуки делать, эта либа похожа* на Knockout.js, но данные не нужно заворачивать в observable объекты, ну и биндинги удобней.
                                0
                                Просто: TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр. штуки

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

                                TypeScript вообще отдельный разговор с ангуляру не связанный, по очевидным причинам это очень хорошее подспорья для больших проектов где горы кода. MS молодцы что не повелись на все тот же "сахар" в ECMAScript, а решили сдеать по своему.
                                  0
                                  Эти штуки помогают структурировать и стандартизировать код
                                  Потому я и говорю, что каждому инструменту своё место. И мне совершенно непонятна эта попытка затолкать Angular куда можно и куда нельзя.
                                  0
                                  В отношении ajax корзин/форм регистрации ангуляр спокойно можно использовать просто ради дата-биндинга. Вы получите простую форму с валидацией практически без js-кода, а значит и без "TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр."

                                  И как бонус — если вдруг вашей форме понадобится стать n-страничной или появится хитропридуманный элемент — вы имеете возможность структурированно расширить её функционал, не превращая все в веселую jquery кашу.

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

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

                                    Я набросал примитивную форму на knockout-е. Можно ли решить такую задачу на AngularJS, без всех этих архитектурных излишеств (в рамках простой задачи) и boilerplate?
                                      +1
                                      Сделал вариант на Angular Light
                                      Т.к. там нет штатной библиотеки валидации, пришлось написать дополнительно 2 функции.

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

                                      PS: Кстати в вашем примере не работает "minLenght: 5"
                                        0
                                        нет штатной библиотеки валидации, пришлось написать дополнительно 2 функции.
                                        С другой стороны, это дает больше гибкости (у каждого css-фреймворка свой стиль ошибок) и не нужно грузить лишние +6кб
                                          0
                                          Сделал вариант на Angular Light
                                          Спасибо. Наглядно. Похоже принцип работы у Angular отличается от Knockout. Попробовал сделать сброс модели из setTimeout-а, не сработало. Получается, изменения сами по себе, как в Knockout-е повсеместно не отслеживаются, и необходимо Angular как-то уведомлять о том, что модель изменилась?

                                          С другой стороны, это дает больше гибкости (у каждого css-фреймворка свой стиль ошибок) и не нужно грузить лишние +6кб
                                          Knockout Validation это отдельная либа. Но можно и свою настрочить. А можно практически продублировать ваш пример.

                                          Много кода нужно дописать в пример на knockout, что-бы сделать такую же подсветку ошибок?
                                          Красным border-ом? Нет, код будет практически идентичным вашему (css: { error: !data.name.isValid() }). Ну и отключить поведение по-умолчанию.
                                            0
                                            и необходимо Angular как-то уведомлять о том, что модель изменилась?
                                            Да, у этого подхода есть и плюсы и минусы. В данном случае нужно запустить .$scan() jsfiddle.net/lega911/5sd9oof7
                                            Для Angular 1 можно использовать $timeout/$http, В Angular 2 есть zone.js который подменяет* все глобальные «отложенные»-методы (setTimeout/setInterval/xhr...)

                                            Для меня это все равно удобней чем оборачивать все данные в observable бертки (я использовал ko до ангуляра), да и работает гораздо быстрее (судя по тестам).

                                            код будет практически идентичным вашему
                                            Тогда (бессмысленный) контр пример, тут в ko кода должно выйти поболее.
                                        +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=preview
                                          0
                                          Спасибо за пример. Интересно. И вправду немногословно. Вопрос, вы и lega в примерах всю валидацию перенесли в HTML. Это стандартный подход в Angular или просто для примера так удобнее?

                                          В Knockout-е я обычно определяю конструктор для модели, в котором каждое поле обвешано валидаторами (как стандартными, так и специфичными, даже групповыми), а затем их просто использую в нужных местах (как в JS, так и в HTML). Т.к. одна и та же модель может быть использована в разных формах и вообще в разных ситуациях, а ещё, ввиду того, что логика валидации может быть очень непростой, мне кажется, что выносить её в HTML некорректно. Хотя в простых случаев, вроде моего примера, так даже проще.
                                            +1
                                            или просто для примера так удобнее?
                                            В данном случае, просто удобнее (меньше кода).
                                            Вообще можно сделать расширение и вместо
                                            al-value="name"
                                            писать
                                            al-value.validate="name"
                                            или
                                            al-value="name; validate"
                                            или
                                            al-value="name" al-validate="options"
                                              0
                                              Нет, валидация не в HTML. Вся логика валидатора — в скрипте. В HTML добавляется только атрибут в input-тег. У атрибута могут быть значения (ng-minlength="число"), либо могут отсутствовать. В моём примере я подключил модуль ngMessage просто для удобного вывода сообщений. Но можно вполне обойтись и без него, валидация в ангуляре из коробки. Есть стандартные валидаторы (общие для всех инпутов см. тут), но можно сделать и свой.

                                              Чтобы сделать свой валидатор в ангуляре нужно:
                                              1) создать директиву и указать у неё в зависимостях директиву ngModel
                                              2) так как ngModel есть в зависимостях, мы можем получить контроллер этой модели в функции link
                                              3) в полученном контроллере есть объект $validators, добавляем в него кастомную функцию-валидатор
                                              4) сама функция должна либо возвращать булевское значение, либо возвращать промис
                                              5) добавить созданную директиву в атрибуты валидируемого поля

                                              Случай промиса очень интесен, так как позволяет делать асинхронные валидаторы. Например, в таком валидаторе можно сделать запрос на сервер, проверить валидность поля, и, в зависимости от ответа с сервера, либо сделать resolve промиса, либо reject. А вообще, через контроллер модели и через контроллер всей формы можно очень гибко управлять состояниями любых полей ввода, даже своих.
                                              Ну и валидатор хранится не в модели. Он создаётся 1 раз и добавляется к валидируемой модели путём простого добавления атрибута в тег.

                                              Пример кастомного валидатора в доках в главе Custom Validation (или см. тут). Как по мне, тут очень мало лишнего кода.
                                                0
                                                В HTML добавляется только атрибут в input-тег.
                                                5) добавить созданную директиву в атрибуты валидируемого поля

                                                Именно это и смущает. Почему это в HTML? Я ещё понимаю, когда логика UI во многом декларативно описывается в HTML, но валидация модели…
                                                  +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] и т.д. Ангуляр умеет работать с ними, но, помимо этого, позволяет расширить этот список своими собственными.
                                                  При всём при этом, сама модель может быть валидной с точки зрения пользовательского ввода, но быть невалидной после серверной валидации...
                                                    0
                                                    В HTML же есть валидаторы: required для input, min/max для input[number]
                                                    Я вот тоже про это хотел написать, тот же type=«number» и пр. можно назвать валидатором/модификатором. Т.е. это уже начато в HTML (в стандарте), и мне кажется, что указать «pattern/min/max» в HTML — это удобнее чем конфигурировать в коде.
                                            0
                                            Пожалуйста: https://jsfiddle.net/jnjpszqa/

                                            У вас, кстати, баг — можно стереть до vasy и нажать сабмит. ну и ошибки не сразу обновляются.
                                          +2
                                          Как автор оригинальной статьи, могу сразу же предложить почитать вот это: http://www.fse.guru/2-years-with-angular

                                          У ангуляра вообще всё сложно с историей и "самоидентификацией". Из него в итоге и слепили комбайн для всего, по примеру джавы (оттуда все эти контроллеры и фабрики-сервисы-провайдеры).

                                          Зачем это всё, скажем, для реализации слайдера или формы обратной связи?

                                          Нафиг не нужно.
                                          Но позволяет нафигачить слайдер чуть быстрее, чем на голом жс.

                                          А маршрутизация на стороне клиента так вообще заставит вас всё перевернуть вверх дном.

                                          Не нужна — не используйте.

                                          Насколько комфортно и вообще разумно тащить Angular2 в обычные проекты, не SPA?

                                          На данный момент, по моему мнению, абсолютно рискованно и неразумно его тащить даже в SPA.

                                          При этом в нём нет всех этих страшных архитектурных штук.

                                          Стоит учесть, что люди выбирают ангуляр в том числе и из-за хайпа. А потом страдают от архитектурных изворотов :)
                                          –1
                                          Поддерживаю вопрос. Я сейчас выбираю фронтэнд для двух проектов, предварительно остановился на Angular2. Прошел туториал, написал ToDo и вроде как готов продолжать изучать и пользоваться, но у меня не SPA и сижу в раздумьях: "а стоит ли оно того". Слайдеры, попапы, календари, тултипы, формы, ajax — на текущий момент вероятно основные потребности...
                                            0
                                            Черт, ошибся веткой. Это был комметарий к вопросу faiwer (https://habrahabr.ru/post/277547/#comment_8778819)
                                              –1
                                              А почему нет, как минимум у вас будет опыт работы с ангуляром2 и далее при выборе инстурментов для новых проектов вы уже сможете решать основываясь на своем опыте, и опыт сам по себе ценен. Только вот вокруг первого ангуляра уже уйма библотек/компонентов, а второй еще этим не особенно оброс, иногда это важный момент (когда нужно быстро что-то сварганить, прототип какой и тд).
                                                –1
                                                Хочу рискнуть со вторым. Мне понравилась изолированность компонентов, кроме того я некоторое время интересуюсь БЭМ и Material Design Lite, а эти вещи хорошо стыкуются судя по всему.
                                                  –1
                                                  Поему рискнуть, это как раз самый потенциально толковый интсурмент (особенно для крупных проектов), я их уважаю хотя бы за то что понимают ценностьTypescript (по крайней меня для библиотек/фреймворков).
                                                    –1
                                                    Ну элемент риска присутствует. Angular2 пока не production-ready, как выше упоминалось — компонент готовых нет, коммьюнити еще вялое. Ну и опыта у команды с ним около нуля. Но на одном проекте точно надо попробовать )
                                              0
                                              Ну то есть статья сводится к тому, что надо выбирать Angular, а если не Angular, то React?
                                                +12
                                                Мдаа… сейчас чтобы сделать простую страничку с двумя формачками надо знать over 9000 инструментов и человеко-неделю времени чтобы это все запустить. Как-то печально.
                                                  +1
                                                  Если заранее известно что это простая страничка, самодостаточная без шансов на дальнейшее развитие или интеграцию в крупный проект, то никакие горы инструментов не нужны (хотя по мне так подобные простые задачи как раз место, где можно пробовать новые штуки в деле, тк работая с крупными проектами пробовать что-то новое в деле не так просто). Но речь ведь может идти об обносительно комплексных проектах, с длительной стадией разработки и не совсем четкими пдланами на бужующее — в этом случае к выбору инструмента лучше подойти внимательно.
                                                    +1
                                                    Я задумался, кто-то может попробовать предсказать что с веб-фронтэндом будет лет так через 10?
                                                    Потому что если просто провести прямую между количеством инструментов сейчас и 5 лет назад, то становится страшно. Воображение рисует будущее, в котором БАК представляется милой детской игрушкой в сравнии с веб-фронтэндом будущего.
                                                      0
                                                      Предположу, что фронтэнд технологии будут группироваться в отдельные стеки и будут искаться специалисты под них.
                                                      Как сейчас на сервере стеки технологий — .NET, Java, PHP, Node.JS, Python, так и потом будет на клиенте — React со своим набором технологий, Angular со своим, еще несколько каких-нибудь фреймворков.
                                                      Верстка вряд ли, но тоже может на 2-3 направление разделиться: верстальщик, верстальщик анимационных эффектов.
                                                      0
                                                      Достаточно иметь человека в коммунити, который сможет отговорить вас от использования лишних инструментов :)
                                                      И сразу же всё становится сильно проще.
                                                      –3
                                                      такое ощущение, что те, кто пишут на ява-скрипте, jquery — пишут практически на ассемблере, это ужасно неудобно, медленно и прошлый век
                                                        0
                                                        Если писать грамотно на jquery то медлено не будет, но очень часто код на jquery это код школоты так как с первого взгляда порог вхождения не высокий. Прошлый век потому что в этом веке стали модны SPA, то есть много логики и в целом кода переехало на клиентсайд (а бэкенд стал stateless — наоборот упростился), это все нужно структурировать, а jquery создан лишь для DOM манипуляции. Еслил хотите jquery это всего лишь винтик в общем стеке.
                                                        +1
                                                        Спасибо Bellicus за перевод.
                                                        Прикольно читать свою переведённую статью :)

                                                        Есть ряд мест с искажённым смыслом, отпишу в личку.
                                                          +1
                                                          К слову, сборщик Component, о котором упоминается в статье, больше не разрабатывается и находится в статусе deprecated.
                                                            0
                                                            Посмотрел несколько фреймворков на TodoMVC. Мне одному кажется, что это полный ахтунг? Это не упрощает разрабоотку, а делает её в разы сложнее, особенно в случае небольших приложений, имхо.

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

                                                            Разделение и структурирование кода? Ну так не мешайте код и разметку, используйте модульный подход. Одна библиотека — один файл и один модуль-объект. Если проект ещё крупнее — используем подпапки (в случае CMS так и получается, там каждый плагин имеет свои JS библиотеки, и они лежат вместе с ним). Если сам модуль очень крупный — используем второй уровень иерархии, вкладываем в него подмодули. Даже это — уже какой-то очень редкий случай, который я с трудом себе представляю.

                                                            Инициализация — одна функция init, активирующая ряд других функций, каждая из которых отвечает за свою часть страниц (если у наc SPA) или блоков (если более традиционное приложение). Часть этих других функций могут быть функциями init наших модулей, кстати. В HTML — по возможности только HTML.

                                                            Сортировка и фильтрация на клиенте? Эм, ну я всё понимаю, но зачем?) Сейчас каналы конечно стали толще, но если у нас в базе тысячи или десятки тысяч строк, вы серьёзно предлагаете получать их ВСЕ при каждой загрузке страницы? Это не только трафик и время на передачу, но ещё и время на сортировку — JS не всегда достаточно быстрый. Издавна такие вещи было принято делать на серверной стороне.

                                                            Байндинг модели и вида? Ну ОК, возможно, но когда у нас модель — отдельная группа функций (а лучше — модуль, класс, или что-то вроде того), контроллер — отдельная, а вид — это сам HTML — это разделение вроде как само получается.

                                                            Подскажите, чего я не понял)

                                                            Only users with full accounts can post comments. Log in, please.