Комментарии 62
CSS-препроцессоры (jss/stylus/sass/css-modules)
а LESS нынче не котируется? ;)
Перейдя по ссылке в первом предложении, вы можете, лично, задать вопрос автору оригинальной статьи о том, как это он посмел позабыть про LESS, попутно обрушив на него все проклятия и беды этого мира.
это скорее был вопрос к сообществу ;)
Тем более, что автор оригинала MrMig — настолько иностранец, что приводит ссылку "chats" — на русские чаты пo IT.
(переводчику — проще и полезнее просто добавить ссылку на Less в статью, в скобках с "прим. перев.")
(переводчику — проще и полезнее просто добавить ссылку на Less в статью, в скобках с "прим. перев.")
Ну что ж, всем не угодишь. Кому то не понравилось, что забыли про less, кто-то не согласиться с высказываниями про react и bower, кто-то вспомнить о существовании еще пары тысяч линтеров. И в итоге весь перевод будет "прим. перев"
Вот для таких случаев и был оставлен постскриптум.
Вот для таких случаев и был оставлен постскриптум.
Вы пришли сюда хорошие статьи писать или делать хорошие переводы? )
Статья ценна информацией, и если в оригинале что-то забыли, как Less, то ради информации стоит добавить. По крайней мере, я так делал в переводах.
Заодно, вопрос к MrMig задам — почему Вы в конце советуете Ember тем, кто не может выбрать? Чем он решительно лучше? Не сильно ли он завязан на Ruby?
Статья ценна информацией, и если в оригинале что-то забыли, как Less, то ради информации стоит добавить. По крайней мере, я так делал в переводах.
Заодно, вопрос к MrMig задам — почему Вы в конце советуете Ember тем, кто не может выбрать? Чем он решительно лучше? Не сильно ли он завязан на Ruby?
Автор беларус, так что русский язык родной :)
забудьте про всё это, используйте PostCSS :-)
Кстати, как синдром: новый 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.
LESS нынче не котируется. ;)
К аудитории: расскажите, кто что думает о скрещении 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/
Везде этот вопрос тщательно обходят, считая, что 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/
Ничего особо сложного, из ангуляра легко отрендерить риактовский компонент. Но и смысла не очень много, только если ради ускорения отрисовки сложных элементов.
1) в A2.0 реактивная модель DOMЧто вы имеете ввиду? Будет то же самое что и в A1, только $digest/$apply не надо* будет вручную дергать, т.к. они все отложенные вызовы (setTimeout/setInerval/...) заврапили.
2) появляется возможность перетащить логику из шаблонов (фирменный недостаток Ангуляра и большинства движков) в JS, работая с моделью DOM в стиле React (JSX),Это откуда?, там почти так же как в А1, только парсер HTML шаблонов самописный (не стандартный).
Мы используем такую связку.
Жаловаться особо не на что, впрочем как и хвалить тоже нечего. Производительность не выросла на порядки, а скорее даже снизилась т.к. добавляется лишняя логика по связыванию react и angular, с ней добавляются баги, так как иногда lifecycles ангуляровских директив и реактовских компонентов не увязываются. Добавляется лишний оверхед, так как получается много DOM нод, которые выступают рутами для react-компонентов. Это медленнее, чем одна нормальная DOM root node, в которую нарендерено чистое react приложение.
В нашем случае преимущество достигается в том, что у нас одни react компоненты используются и в react-приложениях, и в angular.
Жаловаться особо не на что, впрочем как и хвалить тоже нечего. Производительность не выросла на порядки, а скорее даже снизилась т.к. добавляется лишняя логика по связыванию react и angular, с ней добавляются баги, так как иногда lifecycles ангуляровских директив и реактовских компонентов не увязываются. Добавляется лишний оверхед, так как получается много DOM нод, которые выступают рутами для react-компонентов. Это медленнее, чем одна нормальная DOM root node, в которую нарендерено чистое react приложение.
В нашем случае преимущество достигается в том, что у нас одни react компоненты используются и в react-приложениях, и в angular.
Хм, почему-то ни разу не упомянут Polymer, хотя это в какой-то мере аналог ReactJS, только построенный по-человечески, а не через выплевывание ошметков html-разметки в render().
Подскажите, пожалуйста, а какова область применения AngularJS?
Автор оригинального поста столько раз упомянул его как серебрянную пулю, что у меня сложилось впечатления, будто это не развитый инструмент для построения сложных SPA, а некая универсальная библиотека, которая хорошо подойдёт и для реализации примитивного интерактива в "уютном бложеге", типа всяких "каруселей", слайдеров, форм регистрации, корзин заказов и пр… Это действительно так?
Просто: TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр. штуки… Зачем это всё, скажем, для реализации слайдера или формы обратной связи? Да даже для интерактивной страницы заказов. А маршрутизация на стороне клиента так вообще заставит вас всё перевернуть вверх дном.
Насколько комфортно и вообще разумно тащить Angular2 в обычные проекты, не SPA? Там где не нужна никакая клиентская маршрутизация и нет огромного backend API.
Спрашиваю не троллинга ради, а потому что дальше tutorial-а первого Angular-а не ушёл. и по сему плохо понимаю его область применения. А сам для решения насущных проблем использую KnockoutJS и свои собственные велосипеды, благо там многого от них не требуется. Конечно, можно и по старинке — взять jQuery или, скажем, Atom, и писать всё руками, без всяких data-bind-ингов и пр… Но решения на Knockout-е позволяют это сделать гораздо быстрее и надёжнее. При этом в нём нет всех этих страшных архитектурных штук.
Автор оригинального поста столько раз упомянул его как серебрянную пулю, что у меня сложилось впечатления, будто это не развитый инструмент для построения сложных SPA, а некая универсальная библиотека, которая хорошо подойдёт и для реализации примитивного интерактива в "уютном бложеге", типа всяких "каруселей", слайдеров, форм регистрации, корзин заказов и пр… Это действительно так?
Просто: TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр. штуки… Зачем это всё, скажем, для реализации слайдера или формы обратной связи? Да даже для интерактивной страницы заказов. А маршрутизация на стороне клиента так вообще заставит вас всё перевернуть вверх дном.
Насколько комфортно и вообще разумно тащить Angular2 в обычные проекты, не SPA? Там где не нужна никакая клиентская маршрутизация и нет огромного backend API.
Спрашиваю не троллинга ради, а потому что дальше tutorial-а первого Angular-а не ушёл. и по сему плохо понимаю его область применения. А сам для решения насущных проблем использую KnockoutJS и свои собственные велосипеды, благо там многого от них не требуется. Конечно, можно и по старинке — взять jQuery или, скажем, Atom, и писать всё руками, без всяких data-bind-ингов и пр… Но решения на Knockout-е позволяют это сделать гораздо быстрее и надёжнее. При этом в нём нет всех этих страшных архитектурных штук.
примитивного интерактива в «уютном бложеге», типа всяких «каруселей», слайдеров, форм регистрации, корзин заказов и пр… в обычные проекты, не SPAПосмотрите на Angular Light, на нем удобно и мелкие штуки делать, эта либа похожа* на Knockout.js, но данные не нужно заворачивать в observable объекты, ну и биндинги удобней.
Просто: TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр. штуки
Эти штуки помогают структурировать и стандартизировать код, плюсы очевидны, но для мелких одноразовых задач конечно ангуляр может быть не оправдан. Роуты кстати это отдельный компонент, его совсем не обязательно подключать.
TypeScript вообще отдельный разговор с ангуляру не связанный, по очевидным причинам это очень хорошее подспорья для больших проектов где горы кода. MS молодцы что не повелись на все тот же "сахар" в ECMAScript, а решили сдеать по своему.
В отношении ajax корзин/форм регистрации ангуляр спокойно можно использовать просто ради дата-биндинга. Вы получите простую форму с валидацией практически без js-кода, а значит и без "TypeScript, компоненты, директивы, сервисы, контроллеры, роутеры и пр."
И как бонус — если вдруг вашей форме понадобится стать n-страничной или появится хитропридуманный элемент — вы имеете возможность структурированно расширить её функционал, не превращая все в веселую jquery кашу.
Серебрянная пуля — потому что с одной стороны, на ангуляре можно писать полноценные одностраничные приложения, с другой — можно иметь ангулярную приложеньку просто в отдельном диве и она обеспечит вам любой уровень интерактивности внутри него.
И как бонус — если вдруг вашей форме понадобится стать n-страничной или появится хитропридуманный элемент — вы имеете возможность структурированно расширить её функционал, не превращая все в веселую jquery кашу.
Серебрянная пуля — потому что с одной стороны, на ангуляре можно писать полноценные одностраничные приложения, с другой — можно иметь ангулярную приложеньку просто в отдельном диве и она обеспечит вам любой уровень интерактивности внутри него.
Вы получите простую форму с валидацией практически без js-кода
Вот это уже интересно. Примеры, что мне попадались, обязательно были сопровождаемы грудой инфраструктурного кода, который, на простых примерах, многократно превышал саму логику, которую необходимо реализовать. Получается это всё можно обойти в пару строк?
Я набросал примитивную форму на knockout-е. Можно ли решить такую задачу на AngularJS, без всех этих архитектурных излишеств (в рамках простой задачи) и boilerplate?
Сделал вариант на Angular Light
Т.к. там нет штатной библиотеки валидации, пришлось написать дополнительно 2 функции.
Много кода нужно дописать в пример на knockout, что-бы сделать такую же подсветку ошибок?
PS: Кстати в вашем примере не работает "minLenght: 5"
Т.к. там нет штатной библиотеки валидации, пришлось написать дополнительно 2 функции.
Много кода нужно дописать в пример на knockout, что-бы сделать такую же подсветку ошибок?
PS: Кстати в вашем примере не работает "minLenght: 5"
нет штатной библиотеки валидации, пришлось написать дополнительно 2 функции.С другой стороны, это дает больше гибкости (у каждого css-фреймворка свой стиль ошибок) и не нужно грузить лишние +6кб
Сделал вариант на Angular LightСпасибо. Наглядно. Похоже принцип работы у Angular отличается от Knockout. Попробовал сделать сброс модели из setTimeout-а, не сработало. Получается, изменения сами по себе, как в Knockout-е повсеместно не отслеживаются, и необходимо Angular как-то уведомлять о том, что модель изменилась?
С другой стороны, это дает больше гибкости (у каждого css-фреймворка свой стиль ошибок) и не нужно грузить лишние +6кбKnockout Validation это отдельная либа. Но можно и свою настрочить. А можно практически продублировать ваш пример.
Много кода нужно дописать в пример на knockout, что-бы сделать такую же подсветку ошибок?Красным border-ом? Нет, код будет практически идентичным вашему (css: { error: !data.name.isValid() }). Ну и отключить поведение по-умолчанию.
и необходимо Angular как-то уведомлять о том, что модель изменилась?Да, у этого подхода есть и плюсы и минусы. В данном случае нужно запустить .$scan() jsfiddle.net/lega911/5sd9oof7
Для Angular 1 можно использовать $timeout/$http, В Angular 2 есть zone.js который подменяет* все глобальные «отложенные»-методы (setTimeout/setInterval/xhr...)
Для меня это все равно удобней чем оборачивать все данные в observable бертки (я использовал ko до ангуляра), да и работает гораздо быстрее (судя по тестам).
код будет практически идентичным вашемуТогда (бессмысленный) контр пример, тут в ko кода должно выйти поболее.
Немного переделал пример отсюда
http://plnkr.co/edit/8YYsB0dB7iv1T4h3UbyY?p=preview
В реале $timeout заменяется на что-то типа
Если, например, нужна только валидация, то можно вообще почти без js:
http://plnkr.co/edit/PM8FkQZgkhmqaT9Or11B?p=preview
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
Спасибо за пример. Интересно. И вправду немногословно. Вопрос, вы и lega в примерах всю валидацию перенесли в HTML. Это стандартный подход в Angular или просто для примера так удобнее?
В Knockout-е я обычно определяю конструктор для модели, в котором каждое поле обвешано валидаторами (как стандартными, так и специфичными, даже групповыми), а затем их просто использую в нужных местах (как в JS, так и в HTML). Т.к. одна и та же модель может быть использована в разных формах и вообще в разных ситуациях, а ещё, ввиду того, что логика валидации может быть очень непростой, мне кажется, что выносить её в HTML некорректно. Хотя в простых случаев, вроде моего примера, так даже проще.
В Knockout-е я обычно определяю конструктор для модели, в котором каждое поле обвешано валидаторами (как стандартными, так и специфичными, даже групповыми), а затем их просто использую в нужных местах (как в JS, так и в HTML). Т.к. одна и та же модель может быть использована в разных формах и вообще в разных ситуациях, а ещё, ввиду того, что логика валидации может быть очень непростой, мне кажется, что выносить её в HTML некорректно. Хотя в простых случаев, вроде моего примера, так даже проще.
или просто для примера так удобнее?В данном случае, просто удобнее (меньше кода).
Вообще можно сделать расширение и вместо
al-value="name"al-value.validate="name"al-value="name; validate"al-value="name" al-validate="options"Нет, валидация не в HTML. Вся логика валидатора — в скрипте. В HTML добавляется только атрибут в input-тег. У атрибута могут быть значения (ng-minlength="число"), либо могут отсутствовать. В моём примере я подключил модуль ngMessage просто для удобного вывода сообщений. Но можно вполне обойтись и без него, валидация в ангуляре из коробки. Есть стандартные валидаторы (общие для всех инпутов см. тут), но можно сделать и свой.
Чтобы сделать свой валидатор в ангуляре нужно:
1) создать директиву и указать у неё в зависимостях директиву ngModel
2) так как ngModel есть в зависимостях, мы можем получить контроллер этой модели в функции link
3) в полученном контроллере есть объект
4) сама функция должна либо возвращать булевское значение, либо возвращать промис
5) добавить созданную директиву в атрибуты валидируемого поля
Случай промиса очень интесен, так как позволяет делать асинхронные валидаторы. Например, в таком валидаторе можно сделать запрос на сервер, проверить валидность поля, и, в зависимости от ответа с сервера, либо сделать resolve промиса, либо reject. А вообще, через контроллер модели и через контроллер всей формы можно очень гибко управлять состояниями любых полей ввода, даже своих.
Ну и валидатор хранится не в модели. Он создаётся 1 раз и добавляется к валидируемой модели путём простого добавления атрибута в тег.
Пример кастомного валидатора в доках в главе Custom Validation (или см. тут). Как по мне, тут очень мало лишнего кода.
Чтобы сделать свой валидатор в ангуляре нужно:
1) создать директиву и указать у неё в зависимостях директиву ngModel
2) так как ngModel есть в зависимостях, мы можем получить контроллер этой модели в функции link
3) в полученном контроллере есть объект
$validators, добавляем в него кастомную функцию-валидатор4) сама функция должна либо возвращать булевское значение, либо возвращать промис
5) добавить созданную директиву в атрибуты валидируемого поля
Случай промиса очень интесен, так как позволяет делать асинхронные валидаторы. Например, в таком валидаторе можно сделать запрос на сервер, проверить валидность поля, и, в зависимости от ответа с сервера, либо сделать resolve промиса, либо reject. А вообще, через контроллер модели и через контроллер всей формы можно очень гибко управлять состояниями любых полей ввода, даже своих.
Ну и валидатор хранится не в модели. Он создаётся 1 раз и добавляется к валидируемой модели путём простого добавления атрибута в тег.
Пример кастомного валидатора в доках в главе Custom Validation (или см. тут). Как по мне, тут очень мало лишнего кода.
В HTML добавляется только атрибут в input-тег.
5) добавить созданную директиву в атрибуты валидируемого поля
Именно это и смущает. Почему это в HTML? Я ещё понимаю, когда логика UI во многом декларативно описывается в HTML, но валидация модели…
Мне сложно объяснить простыми словами…
Считайте эти валидаторы (которые в виде директив) лишь неким предварительным фильтром.
Внутри формы нам доступен контроллер самой формы. Он следит за дочерними инпутами. А ещё есть контроллер всего view. Они разные. Первый нужен, например, чтобы проверять введённые данные на корректность. Второй же связывает данные во view с самим приложением через контроллер этого view.
Ну например, нам нужно поле ввода IP адресов. В HTML нет такого поля. Но его можно сделать из инпута. Мы можем сделать так:
А можно создать свою директиву для такого поля ввода. Допустим, мы сделали такую директиву, теперь можем писать так:
В HTML же есть валидаторы: required для input, min/max для input[number] и т.д. Ангуляр умеет работать с ними, но, помимо этого, позволяет расширить этот список своими собственными.
При всём при этом, сама модель может быть валидной с точки зрения пользовательского ввода, но быть невалидной после серверной валидации...
Считайте эти валидаторы (которые в виде директив) лишь неким предварительным фильтром.
Внутри формы нам доступен контроллер самой формы. Он следит за дочерними инпутами. А ещё есть контроллер всего 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] и т.д. Ангуляр умеет работать с ними, но, помимо этого, позволяет расширить этот список своими собственными.
При всём при этом, сама модель может быть валидной с точки зрения пользовательского ввода, но быть невалидной после серверной валидации...
В HTML же есть валидаторы: required для input, min/max для input[number]Я вот тоже про это хотел написать, тот же type=«number» и пр. можно назвать валидатором/модификатором. Т.е. это уже начато в HTML (в стандарте), и мне кажется, что указать «pattern/min/max» в HTML — это удобнее чем конфигурировать в коде.
Пожалуйста: https://jsfiddle.net/jnjpszqa/
У вас, кстати, баг — можно стереть до vasy и нажать сабмит. ну и ошибки не сразу обновляются.
У вас, кстати, баг — можно стереть до vasy и нажать сабмит. ну и ошибки не сразу обновляются.
Как автор оригинальной статьи, могу сразу же предложить почитать вот это: http://www.fse.guru/2-years-with-angular
У ангуляра вообще всё сложно с историей и "самоидентификацией". Из него в итоге и слепили комбайн для всего, по примеру джавы (оттуда все эти контроллеры и фабрики-сервисы-провайдеры).
Нафиг не нужно.
Но позволяет нафигачить слайдер чуть быстрее, чем на голом жс.
Не нужна — не используйте.
На данный момент, по моему мнению, абсолютно рискованно и неразумно его тащить даже в SPA.
Стоит учесть, что люди выбирают ангуляр в том числе и из-за хайпа. А потом страдают от архитектурных изворотов :)
У ангуляра вообще всё сложно с историей и "самоидентификацией". Из него в итоге и слепили комбайн для всего, по примеру джавы (оттуда все эти контроллеры и фабрики-сервисы-провайдеры).
Зачем это всё, скажем, для реализации слайдера или формы обратной связи?
Нафиг не нужно.
Но позволяет нафигачить слайдер чуть быстрее, чем на голом жс.
А маршрутизация на стороне клиента так вообще заставит вас всё перевернуть вверх дном.
Не нужна — не используйте.
Насколько комфортно и вообще разумно тащить Angular2 в обычные проекты, не SPA?
На данный момент, по моему мнению, абсолютно рискованно и неразумно его тащить даже в SPA.
При этом в нём нет всех этих страшных архитектурных штук.
Стоит учесть, что люди выбирают ангуляр в том числе и из-за хайпа. А потом страдают от архитектурных изворотов :)
Поддерживаю вопрос. Я сейчас выбираю фронтэнд для двух проектов, предварительно остановился на Angular2. Прошел туториал, написал ToDo и вроде как готов продолжать изучать и пользоваться, но у меня не SPA и сижу в раздумьях: "а стоит ли оно того". Слайдеры, попапы, календари, тултипы, формы, ajax — на текущий момент вероятно основные потребности...
Черт, ошибся веткой. Это был комметарий к вопросу faiwer (https://habrahabr.ru/post/277547/#comment_8778819)
А почему нет, как минимум у вас будет опыт работы с ангуляром2 и далее при выборе инстурментов для новых проектов вы уже сможете решать основываясь на своем опыте, и опыт сам по себе ценен. Только вот вокруг первого ангуляра уже уйма библотек/компонентов, а второй еще этим не особенно оброс, иногда это важный момент (когда нужно быстро что-то сварганить, прототип какой и тд).
Хочу рискнуть со вторым. Мне понравилась изолированность компонентов, кроме того я некоторое время интересуюсь БЭМ и Material Design Lite, а эти вещи хорошо стыкуются судя по всему.
НЛО прилетело и опубликовало эту надпись здесь
Мдаа… сейчас чтобы сделать простую страничку с двумя формачками надо знать over 9000 инструментов и человеко-неделю времени чтобы это все запустить. Как-то печально.
Если заранее известно что это простая страничка, самодостаточная без шансов на дальнейшее развитие или интеграцию в крупный проект, то никакие горы инструментов не нужны (хотя по мне так подобные простые задачи как раз место, где можно пробовать новые штуки в деле, тк работая с крупными проектами пробовать что-то новое в деле не так просто). Но речь ведь может идти об обносительно комплексных проектах, с длительной стадией разработки и не совсем четкими пдланами на бужующее — в этом случае к выбору инструмента лучше подойти внимательно.
Я задумался, кто-то может попробовать предсказать что с веб-фронтэндом будет лет так через 10?
Потому что если просто провести прямую между количеством инструментов сейчас и 5 лет назад, то становится страшно. Воображение рисует будущее, в котором БАК представляется милой детской игрушкой в сравнии с веб-фронтэндом будущего.
Потому что если просто провести прямую между количеством инструментов сейчас и 5 лет назад, то становится страшно. Воображение рисует будущее, в котором БАК представляется милой детской игрушкой в сравнии с веб-фронтэндом будущего.
Предположу, что фронтэнд технологии будут группироваться в отдельные стеки и будут искаться специалисты под них.
Как сейчас на сервере стеки технологий — .NET, Java, PHP, Node.JS, Python, так и потом будет на клиенте — React со своим набором технологий, Angular со своим, еще несколько каких-нибудь фреймворков.
Верстка вряд ли, но тоже может на 2-3 направление разделиться: верстальщик, верстальщик анимационных эффектов.
Как сейчас на сервере стеки технологий — .NET, Java, PHP, Node.JS, Python, так и потом будет на клиенте — React со своим набором технологий, Angular со своим, еще несколько каких-нибудь фреймворков.
Верстка вряд ли, но тоже может на 2-3 направление разделиться: верстальщик, верстальщик анимационных эффектов.
Достаточно иметь человека в коммунити, который сможет отговорить вас от использования лишних инструментов :)
И сразу же всё становится сильно проще.
И сразу же всё становится сильно проще.
такое ощущение, что те, кто пишут на ява-скрипте, jquery — пишут практически на ассемблере, это ужасно неудобно, медленно и прошлый век
Если писать грамотно на jquery то медлено не будет, но очень часто код на jquery это код школоты так как с первого взгляда порог вхождения не высокий. Прошлый век потому что в этом веке стали модны SPA, то есть много логики и в целом кода переехало на клиентсайд (а бэкенд стал stateless — наоборот упростился), это все нужно структурировать, а jquery создан лишь для DOM манипуляции. Еслил хотите jquery это всего лишь винтик в общем стеке.
Спасибо Bellicus за перевод.
Прикольно читать свою переведённую статью :)
Есть ряд мест с искажённым смыслом, отпишу в личку.
Прикольно читать свою переведённую статью :)
Есть ряд мест с искажённым смыслом, отпишу в личку.
К слову, сборщик Component, о котором упоминается в статье, больше не разрабатывается и находится в статусе deprecated.
Посмотрел несколько фреймворков на TodoMVC. Мне одному кажется, что это полный ахтунг? Это не упрощает разрабоотку, а делает её в разы сложнее, особенно в случае небольших приложений, имхо.
Меня сейчас скорее всего закидают минусами сторонники MVC подхода, но серьёзно, сравните код на jQuery (с того же сайта), и остальную жесть. Может, с опытом и изучением придёт просветление, и это будет казаться проще, но мне пока не очень ясно, какие вообще преимущества это может дать.
Разделение и структурирование кода? Ну так не мешайте код и разметку, используйте модульный подход. Одна библиотека — один файл и один модуль-объект. Если проект ещё крупнее — используем подпапки (в случае CMS так и получается, там каждый плагин имеет свои JS библиотеки, и они лежат вместе с ним). Если сам модуль очень крупный — используем второй уровень иерархии, вкладываем в него подмодули. Даже это — уже какой-то очень редкий случай, который я с трудом себе представляю.
Инициализация — одна функция init, активирующая ряд других функций, каждая из которых отвечает за свою часть страниц (если у наc SPA) или блоков (если более традиционное приложение). Часть этих других функций могут быть функциями init наших модулей, кстати. В HTML — по возможности только HTML.
Сортировка и фильтрация на клиенте? Эм, ну я всё понимаю, но зачем?) Сейчас каналы конечно стали толще, но если у нас в базе тысячи или десятки тысяч строк, вы серьёзно предлагаете получать их ВСЕ при каждой загрузке страницы? Это не только трафик и время на передачу, но ещё и время на сортировку — JS не всегда достаточно быстрый. Издавна такие вещи было принято делать на серверной стороне.
Байндинг модели и вида? Ну ОК, возможно, но когда у нас модель — отдельная группа функций (а лучше — модуль, класс, или что-то вроде того), контроллер — отдельная, а вид — это сам HTML — это разделение вроде как само получается.
Подскажите, чего я не понял)
Меня сейчас скорее всего закидают минусами сторонники MVC подхода, но серьёзно, сравните код на jQuery (с того же сайта), и остальную жесть. Может, с опытом и изучением придёт просветление, и это будет казаться проще, но мне пока не очень ясно, какие вообще преимущества это может дать.
Разделение и структурирование кода? Ну так не мешайте код и разметку, используйте модульный подход. Одна библиотека — один файл и один модуль-объект. Если проект ещё крупнее — используем подпапки (в случае CMS так и получается, там каждый плагин имеет свои JS библиотеки, и они лежат вместе с ним). Если сам модуль очень крупный — используем второй уровень иерархии, вкладываем в него подмодули. Даже это — уже какой-то очень редкий случай, который я с трудом себе представляю.
Инициализация — одна функция init, активирующая ряд других функций, каждая из которых отвечает за свою часть страниц (если у наc SPA) или блоков (если более традиционное приложение). Часть этих других функций могут быть функциями init наших модулей, кстати. В HTML — по возможности только HTML.
Сортировка и фильтрация на клиенте? Эм, ну я всё понимаю, но зачем?) Сейчас каналы конечно стали толще, но если у нас в базе тысячи или десятки тысяч строк, вы серьёзно предлагаете получать их ВСЕ при каждой загрузке страницы? Это не только трафик и время на передачу, но ещё и время на сортировку — JS не всегда достаточно быстрый. Издавна такие вещи было принято делать на серверной стороне.
Байндинг модели и вида? Ну ОК, возможно, но когда у нас модель — отдельная группа функций (а лучше — модуль, класс, или что-то вроде того), контроллер — отдельная, а вид — это сам HTML — это разделение вроде как само получается.
Подскажите, чего я не понял)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как выбрать фреймворк для frontend-разработки