Как стать автором
Обновить

Комментарии 39

с сообществом любителей Angular

звучит как кружок по интересам)

Отличные новости.
Angular — лучик света в мире фронтенда.

vue? не?)

Из которого в 3 версии делают реакт?

Ну во-первых старый апи никуда не изчезнет. А во-вторых, Эван Ю, держит руку на пульсе и перенимает лучшие практики из других фреймворков. Да и композишн апи — крайне полезная штука для крупных проектов.
Я думал Боб Мартин еще лет 10 назад написал что хорошо для крупных проектов
Например DI, декомпозиция, продуманный нейминг переменных и классов, изменяемый код и так далее.
Вместо этого нам предлагают писать функции в функциях
Теперь посмотрим на супер новое апи, что читабельнее, функции в функциях:
export default {
  setup() {
    const state = reactive({
      count: 0,
      double: computed(() => state.count * 2)
    })

    function increment() {
      state.count++
    }

    return {
      state,
      increment
    }
  }
}


Обычный класс

export class TestComponent {
  count = 0;
  double = 0;

  increment() {
    this.count++;
    this.double = this.count * 2;
  }
}


Что читабельней?
А теперь представьте что функций будет больше 1
Да, писал в браузере пока разговаривал по телефону)
Исправил
Синтаксис может и проще, но от невнимательности (криворукости) ничего не спасёт.


Только вот этот синтаксис существует в angular с 2 версии с кучей других плюшек
Но почему-то реактеры стараются придумать свое, лишь бы не так как у других, при этом выдавая это за конфетку, а разработчики vue повелись на хайп и подхватили.
Изначально придумали синтаксис с кучей mounted, computed, bind this и так далее, потом переписали это на хуки которые не сильно улучшили читабельность и выдают это за прорыв.
Мне тоже казалось странным, что реактщики любят своебразный синтаксис придумывать. Который и так есть в классах, например. Но оказывается, краткость — экономия пары символов, имеет значение.

На своём опыте убедился, что компонент React рефакторится одной командой IDE — extract function. В Angular нужно создать 3+ файла, и перетаскивать руками html, ts. Удобство — это немаловажный фактор.

Мне кажется, что стоит рассматривать React компоненты со всеми хуками как самостоятельный язык для рисования интерфейса. Как прокачанный HTML. Но отсюда следует, что логики в этих компонентах должно быть как можно меньше.
angular тоже позволяет писать все в 1 файле.
я знаю… но одной командой вы не разобьёте компонент на два.

Angular Language Service — постоянно тормозит для VSCode.

Короче, я считаю Angular прекрасным фреймворком. В нём заложено много здравых вещей — ReactiveForms, HttpInterceptors, RouteGuards, стили инкапсулируются для компонента автоматически, CLI прекрасно справляется со своими обязанностями, всё однообразно и со вкусом.

Но в плане удобства написания/сопровождения компонентов — он жёстко уступает React.

Я бы с радостью писал на React, в котором есть все основные фишки из Angular. Или наоборот, с радостью писал бы на Angular, если бы компоненты можно было так же легко писать/рефакторить.

Короче, жду Angulareact/Reangular. И поддерживаю сторонников обоих фреймворков.
Angular Language Service — постоянно тормозит для VSCode.


Думаю это проблема vs code, в webstorm все летает.

с радостью писал бы на Angular, если бы компоненты можно было так же легко писать/рефакторить.

Признаю, что в jsx есть удобные фишки типа передачи компонента в параметры
Но рефакторить и писать компоненты в angular мне намного проще.
Ide рефакторит селектор компонента по всему проекту в пару кликов, то же самое и с названием класса и файла.
1 команда в cli генерирует компонент, дальше пишется только логика.
Может компонент кнопочки и проще писать в react, но все что больше кнопочки — наоборот.
react? не?)
Не вижу смысла использовать React, когда во Vue есть все то же самое + дополнительные удобства. Хотя бы взять изоляцию стилей, которая реализуется всего одним словом scoped из коробки, и сравнить хитровыдуманную css-модульность (которая при необходимости во Vue тоже есть).

HTML-шаблоны так же в разы удобнее для небольшого проекта, вместо JSX-а от которого меня воротит, хотя и допускаю использования в отдельных проектах. В том же Vue по желанию и TS и JSX можно использовать, если хочется.
И, думаю, сейчас популярность React-а обусловлена теперь только тем, что по инерции разрабы продолжают его использовать, с тех времен, когда ему научились, а Vue был еще неизвестен, + поддержкой Фейсбуком.

Еще полезно изучать React чисто для улучшения знаний в JS, но в реальных проектах использовать — так себе удовольствие.

с каких пор vue стал фреймворком?

А чего vue не хватает до фреймворка?

Ну, примерно:


  • routing
  • modules
  • i18n
  • validation
  • reactive form
  • DI
  • AOT
  • Service layer
  • Service Worker

По верхам просто собрал

Роутер для vue есть, валидация тоже, модули есть в es2015. Всё остальное к UI Framework отношения не имеет.

Причем тут модули es2015 и модули аргулара с автоподгрузкой?


Всё остальное к UI Framework отношения не имеет.

на этом месте в мире заплакал еще один котик...

Не знаю я зачем вам в UI фреймворке модули ангуляра. Я даже зачем они нужны в Ангуляре не знаю...

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

Обновлён, до версии 6, линтер TSLint.


TSLint has been deprecated as of 2019

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

Обновлён, до версии 6, линтер TSLint.

Странно, что в новой версии так и не отказались от TSLint в пользу ESLint, а ведь уже года полтора TSLint является deprecated.
в стиле Ангуляра будет не просто заменить линтер, а предоставить тулзу для конвертации стилей. Ну и видимо пока не хотят с этим возиться.
Побежал обновлять свой pet project до десятки. Спасибо за статью. В целом тренд развития Ангуляра мне нравится.
О боже, наконец-то в production-ready фреймворке появился штатный (из коробки!) компонент для выбора диапазонов дат! Не прошло и десятилетия! Наконец-то frontend-разработчики перестанут, пыхтя и чертыхаясь, подпиливать напильником сторонние библиотеки или городить свои кривые велосипеды для выбора периода времени — функционала, который в веб-приложениях используется чуть менее, чем везде, где требуется настраивать фильтр по дате. Это прям эпохальный сдвиг, ящитаю.
Справедливости ради — приведите пример, где это уже реализовано из коробки 100 лет назад.
ну так об этом и речь, что двигатель и трансмиссию постоянно обновляют, а колеса как были велосипедные, так и остались
я просил все таки привести пример, а не материализовать уже сказанное. я вас и тогда прекрасно понял. но пример как надо то есть? даже не ради подтверждения слов, а ради интереса. ведь если сказали, значит что то такое знаете.
Нет, к сожалению, не знаю. Мой сарказм был не про конкретный фреймворк, который отстает, а скорее про один из важных аспектов фронтэнд-разработки в целом — наличие более-менее нормального выбора рабочих компонентов для типовых задач.

Сам я ушел из фронтэнда пару лет назад. Ушел в том числе потому, что устал пилить велосипеды для задач вроде «нам нужно поле для выбора даты и времени» и «нам нужен выпадающий список тэгов с возможностью добавить новый тэг». Каждый раз приходилось много шаманить, городить костыли, подпиливать шершавым напильником сторонние решения или писать свой косой велосипед — и все это забирало ресурсы у бизнес-задачи, для которой такой компонент нужен. Думал, что-то поменялось за это время.

«Разбуди меня через 10 лет и спроси, что делают фронтэндеры, и я отвечу: перелопачивают код под новую версию фреймворка и пишут кастомные select'ы и datepicker'ы».
Полностью согласен!

Но у меня есть предположение о том, что создать всеобъемлющую библиотеку компонентов невозможно. Всё равно каждый проект/дизайнер требует тюнинга того или иного элемента. Причём зачастую затюнить сложнее, чем написать свой велосипед. Мы зациклились на компонентах.

Мне кажется, что следующим шагов в эволюции фронта должен быть инструмент, который позволяет на высоком уровне решать рутинные задачи, связанные с UX. Под UX я подразумеваю поведение элементов. Эдакий конструктор для создания input, select, datepicker, который предоставляет разработчику полную кастомизацию HTML, CSS. Но сохраняет основное поведение.

Дело в том, что UI меняется от проекта к проекту. А вот UX остаётся примерно одним и тем же. Но наши любимые фреймворки оперируют только UI-компонентами, и заточены только под это.
создать всеобъемлющую библиотеку компонентов невозможно


Да нам надо то, как вы сказали, всего лишь input, select, datepicker. Из коробки если уже идут то давно бы уже дали date range picker адекватный, как и сказал комментатор выше :)
Куды перешли, в бэк?
И если да, то на чем сейчас пишите?
Да, в чистый бэк. Node.js (TypeScript), MongoDB, Redis

материал в принципе не богат на компоненты и их функционал.
недавно для себя https://github.com/primefaces/primeng открыл. довольно богатый ui функционал

Интересный тренд, но хотелось бы более развёрнутого описания
Зарегистрируйтесь на Хабре, чтобы оставить комментарий