Кажется, об этом знает фронтенд-тимлид компании Wrike Евгений Гусев. Нам удалось отвлечь его от работы и задать несколько вопросов, которые так волнуют тех, кто уже успел попробовать Angular 2 или ещё только слышал о нём. Евгений рассказал нам о преимуществах Angular 2, скорости развития проекта, трудностях и радостях перехода на него. Мы успели обсудить React, JavaScript и Dart, — в общем, сравнить и изменить все силы. Впрочем, хватит тизеров. Магистр, вам слово!
— Расскажите о себе, о том, с чем работаете и как попали в Wrike?
Меня зовут Евгений, и я пишу на Dart и Angular 2. Наверное, странное начало, но надо расставить все точки над «i». Работаю фронтенд-тимлидом в компании Wrike, а начинал с С++ под микроконтроллеры, писал немного на том и на этом, потом дошёл до C#. Когда перешёл в Dell, начал плотнее общаться с фронтендом, причём самым банальным образом: кому-то нужно было писать UI, а никого не было. Причём писать начал сразу на CoffeeScript (да-да!). Годы шли, и я перешёл в компанию, в которой я сейчас и работаю, а именно Wrike. Мы разрабатываем крупную SaaS-платформу для управления задачами и совместной работы. Сейчас у нас почти 30 фронтенд-девелоперов, плюс команда верстальщиков, и мы, как Алиса из небезызвестной сказки, всё растём и растём.
Wrike прошёл довольно большой путь: от совсем небольшого стартапа до двух миллионов строчек кода за 9+ лет разработки. Конечно, за это время у нас сменилась куча фреймворков и технологий. Всё начиналось с Dojo, потом Ext.js. Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать? Собственно о том, какие у нас были варианты, и почему мы в итоге выбрали Angular 2, я и расскажу в своём докладе.
— Ваш доклад на предстоящей HolyJS озаглавлен как «Angular 2: знакомый герой, новые надежды». Какую надежду и кому может дать новая версия Angular?
Если вкратце, то есть Империя (React world), а есть повстанцы (Angular). Когда-то в галактике правила республика, но потом, под давлением превосходящих сил ей пришлось отступить. И теперь в мире везде только и слышно: «React, Redux!» В стане Angular нужен был герой, новая кровь. И вот он пришёл.
А если серьёзно, то так устроен человек, что все падки на хайп и тренды, а в мире web уж тем более, так как он меняется гораздо чаще, чем, например, бекенд. В Java — если технологии меньше 5 лет, это beta. Поэтому у нас царит твиттерократия — правит тот, у кого больше репостов.
Когда-то Angular был самым модным, и тогда на него подсело много людей (т.е. компаний, проектов). Конечно, после мира jQuery — это было что-то очень крутое и могучее, как Старая Республика (привет фанатам Star Wars). Однако годы шли, Angular всё больше отставал, и властителем умов стал React. Сейчас невозможно себе представить ни одной фронтенд конференции без темы о React или Redux и иже с ними.
Отступление: если вы пришли на конференцию, и она оказалась дико скучной, то скоротать время вам поможет такая занятная игра (да-да, вы правильно догадались! Это – «bullshit bingo»): играющие слушают доклад, и, как только спикер говорит «React» —все выпивают. Проигрывает первый, кого выведут из зала. За Redux все пьют два раза. Время пролетит незаметно, это точно. (привет, Лёша aka Flack )
Так вот, Angular 1 уже не может тягаться с конкурентами — подход к разработке, технологиям поменялся. Мы опять пришли к толстым клиентам с большим объёмом бизнес-логики, а требования ко времени отклика и скорости работы не поменялись. Наоборот, пользователь говорит: «У меня топовый компьютер, а ваш сайт работает медленнее, чем гугл!» В итоге складывается такая ситуация: у Angular по-прежнему есть немало поклонников, иногда по собственной воле, иногда вынужденно (legacy code). Однако, они должны переходить на React, потому-что он, конечно, на голову опережает Angular 1.
И вот тут на сцену выходит Angular 2. React хоть и хорош, но не непогрешим, у него есть свои минусы. Для тех, кто хочет альтернативы, или же просто любит Angular, свежая версия и может дать эту самую «новую надежду».
— Angular 2 так значительно отличается от предыдущей версии? Может ли он соперничать с конкурентами?
Да, изменился значительно. Да так, что между первой и второй версиями нет обратной совместимости. Да, конечно, это может звучать как «взять всё и переписать», но в основе Angular 1 лежат подходы, которые сейчас уже не работают. Конечно, в первую очередь, это двусторонний data binding. Сам по себе он не то чтобы плох, но его реализация в первом Angular значительно бьёт по производительности. И конечно, никакого сравнения со скоростью React.
Работа над ошибками была проделана значительная, команда разработчиков постаралась на славу. Я покажу и расскажу об этом в докладе. Преимущества нового Angular мы оценили не только из «синтетических» тестов и ToDo приложений, а, как я уже говорил, не так давно Wrike перешёл на Angular 2. Так что всё, о чём я говорю — «из первых рук». Все желающие могут зайти на www.wrike.com и попробовать, посмотреть. Например, скорость Angular 2 мы оценили сразу же. Причём не одну, а целых две:
- Скорость работы кода. Тут, конечно, сработал момент, что при смене фреймворка код ещё и подчищался, но тем не менее.
- Скорость разработки. На Angular 2 просто приятно и легко писать. Кстати, документация весьма полная, а что отсутствует — легко понять из кода. Тут, в первую очередь, большой плюс в том, что Angular 2 написан на Typecript и транспилится в Dart. Какая частая проблема в JS: хочешь использовать какую-то функцию из библиотеки, и понимаешь, что непонятно — а какие у неё вообще аргументы. В документации не написано, в IDE ставишь точку, начинаешь вбивать — тебе подсказывает десять функций. В типизированном языке с этим, конечно, легче.
— Разве Angular 2 ещё не в beta версии?
В Звёздных Войнах есть такая цитата:«Перемен нельзя избежать, так же как захода солнца». Всегда нужно меняться и подстраиваться под новый лад. Конечно, было немного страшно, но Angular 2 идёт вперёд огромными скачками. Ещё недавно они были в beta, но уже готовится release candidate (https://github.com/angular/angular/milestones).
— И сколько раз всё ломалось из-за новых версий?
На самом деле, ни разу. Конечно, изменения во фрейморке постоянно идут, и бывают breaking changes. Но, во-первых, вся разработка открыта, поэтому о грядущих изменениях обычно всегда известно заранее. И во-вторых, у нас хорошая команда QA+Dev!
— А почему вы выбрали именно Angular, а не тот же React?
Как я уже говорил, мы в Wrike пишем на Dart. О причинах и плюсах такого перехода мы уже рассказывали. О том, почему для большого проекта JS не очень подходит, у меня был доклад, который в свое время вызвал довольно бурную дискуссию.
К view framework мы предъявляем те же требования, что и к языку: богатые возможности «из коробки», модульность, скорость, и совместимость с нашей экосистемой. React хорош, но у него, по моему мнению, есть ряд минусов:
- Нет сущности для событий. Т.е. компоненты могут общаться только с помощью коллбеков, которые вверх всплывают. (https://gist.github.com/bunopus/18792002dd40eab33c83e0252aa955a5#file-ng2vsreact)
- Нет DI из коробки. Из-за этого приходится немного костылей вставлять в виде High Order Component. (Есть несколько решений для DI — тот же redux, reactive-di).
- Нет типизации на уровне языка для описания интерфейсов компонентов (только встроенная через propTypes и возможность привернуть Flow).
- Jsx — на тему которого есть много мнений за и против, т.е. смешивать ли вёрстку и код или нет.
То есть, в целом, React умеет все, у него много точек расширения, отданных на откуп внешним разработчикам, но при этом не так много ресурсов «из коробки». В нашем случае такой плюрализм решений — это не очень хорошо.
Angular 2 многое запрещает, но и многое дает. Для нас в данный момент это оптимальный инструмент, так как его проще адаптировать (нужно менять только одну вещь, а не разрозненный набор), проще учиться. И конечно, большой плюс — его нативная поддержка Dart.
В скором времени мы расскажем о различиях между React и Angular 2, следите за анонсами.
Кстати, мы не единственная компания с таким стеком (Angular 2 + Dart). Крупнейшая рекламная площадка в мире использует те же технологии — я говорю о Google AdWords. Их мотивы в целом похожи на наши, более подробно можно прочесть вот в этой статье.
— Аngular 2 + Dart. Каким проектам вы посоветуете выбирать такую же связку?
Терпеливым разработчикам ;-). Конечно, переход на Dart и Angular 2 делался не по щелчку пальцев — тут было много работы. Но тут надо учитывать нашу специфику, о ней, думаю, мы расскажем в нашем блоге.
Если же это новый проект, или вы задумываетесь: «А не бахнуть ли мне всё заново?», то в, первую очередь, я бы советовал посмотреть именно эту связку. Если выделять какие-то формальные признаки, что я бы назвал такие:
- Ваш проект нужно будет поддерживать продолжительное время. Если вы знаете, что через полгода проект закроют, то можно написать на чём угодно. Знаете JS — пишете на JS. Прочли книжку «Php для самых маленьких» — пишите на нём. На Perl — пожалуйста. Однако, если после вас придёт ещё не одно поколение разработчиков, то, мне кажется, они вам скажут спасибо за самодокументируемый код (например, на Dart).
- Значительный объём кода. Этот пункт отсылает нас к первому. Весь вопрос в поддержке. По моему опыту, код на Dart способен читать человек, который впервые его видит. Достаточно писать на С-подобном языке (C, Java, C# etc).
- Большая команда. Когда в команде от одного до трёх разработчиков — социальные договоры работают: «Давайте будем писать документацию», «Я тут сделал функцию — на выходе строка, а по понедельникам — мапка, окей?», «Я там баг пофиксил, один модуль закомментил, завтра поправлю, пока не трогайте». Но когда разработчиков много, уже невозможно со всеми договориться. А если ещё и кода много — может начаться хаос. Поэтому чем меньшим количеством способов можно написать какую-то логику, тем лучше. Никто же не ругает молоток, что им нельзя стены красить.
- Модульность. Если что-то из вышеперечисленного — про вас, то наверняка вы бы хотели, чтобы команды работали максимально изолировано. Тут Angular (впрочем надо отдать должное и остальным языкам) работает на ура. Dart тоже в этом помогает.
В целом, всё, что я перечислил, — это похоже на серьёзный Enterprise (как к нему не относиться). Это не значит, что никаким другим способом не построишь большое и надёжное приложение — нет, конечно. «Только ситхи всё возводят в абсолют». Однако оба инструмента (а Angular 2 в особенности) заточены именно под сложный клиентский код с обилием логики.
Кому может не подойти: если вы хипстер, любите под стаканчик свежего смузи поковыряться «в кишочках» чего-нибудь и имплементировать архитектуру Flux по-своему («остальные не понимают, а я так вижу»). Нет, не потому, что я имею что-то против хипстеров, а потому, что и Angular 2, и Dart, хотя и дают много, но и запрещают многое. Тут разница в парадигмах: «Single maintainer» vs «Community». Порой бывает, что сам ругаешься: «вот тут бы по-другому», «зачем тут так делать — идиотизм», но это расплата за большие возможности для старта. У конкурентов Angular, например, того же React, куда больше возможностей для кастомизации.
— А какие основные конкуренты Angular 2?
Сравнивая разные фреймворки, зачастую мы сравниваем экосистемы. Я думаю, что сейчас у молодого Angular такие конкуренты, в порядке убывания:
- React. Тут сталкиваются не только экосистемы, но и религии в каком-то смысле. Об этом я расскажу в докладе 5 июня.
- Aurelia. Это тоже достаточно молодой фреймворк, написан выходцем из Google, который разочаровался в Angular 2 и решил написать свою библиотеку «с преферансом и куртизантками». Выглядит достаточно перспективно, но порой создаётся впечатление, что он писался, исходя из принципа «назло маме отморожу уши».
- Polymer. Тут Google конкурирует сам с собой. Впрочем, не совсем корректно их сравнивать, все же Polymer — это скорее огромная библиотека компонентов, а не цельный фреймворк.
- Как ни странно — Angular. Как и всегда бывает с выходом новой версии чего-либо, достаточно трудно понять, зачем переходить на свежую версию, тратить силы и время.
Если резюмировать — у Angular 2 есть огромное преимущество. С одной стороны, опытная команда (многие участвовали в разработке первой версии) и база знаний, как лучше сделать. А с другой, пока ещё фреймворк не обременён грузом обратной совместимости, устаревших архитектурных решений и прочего. Таким образом, Angular может взять всё лучшее из остальных библиотек и привнести мир в галактику.
— В ходе нашей беседы было очень много отсылок к Star Wars. Можно тебя попросить дать несколько рекомендаций фронтенд-разработчикам в стилистике этой кино-саги.
Ну, например так… Если перефразировать слова магистра Йоды «Гордыня, предвзятость… Всё это ведёт на темную сторону силы». Я бы посоветовал никогда не ударяться в крайности и не судить, не узнав. Возможно, ни Dart, ни Angular 2 вам не подойдут. Возможно, это не самые быстрые/удобные/модные инструменты. Но попробовать их определённо стоит. Мы в Wrike, в свою очередь, всегда готовы помочь и ответить на вопросы, заходите в гости в наш питерский офис. Спасибо за интервью, и «Да пребудет с вами сила».
Комментарии (96)
Azy
30.05.2016 13:41+5vue.js добавили бы в конкурентов.
Jabher
30.05.2016 15:23К сожалению, вуй — не нужен. Слава к этой замечательной либе пришла с ее упадком.
Я следил за его развитием с 0.10, и сейчас он превращается в раздутого мастодонта из-за самомнения Эвана (автора), достаточно почитать ишуи — человек не пытается слушать других, у него есть своя точка зрения на проект, и она уводит его из ниши, которую вуй идеально занимал — библиотека для rapid component development. API толще, тяжелее, появляются какие-то странные фичи, синтаксис внутри шаблонов перестает быть гомогенным и все больше напоминает первый ангуляр.
Идея, которая лежала за первыми версиями вуя, была прекрасна — это «the best API is no API». И микроядро довеском, где все остальное — отдельные модули, директивы и компоненты, что тоже прекрасно.
До первой версии все выглядело так, словно ты пользуешься встроенными инструментами языка: объекты это просто объекты, наследование — расширение прототипа (окей, Vue.extend работал как deep assign, но все равно это было очевидно), причем с добавлением маленьких приятных плюшек, аргументы для директив парсились как объекты или массивы (без фигурных скобок). А потом начался атас, Эван начал завидовать славе реакта с ангуляром (видимо, по причине упадка метеора, которым он занимался), и начал тащить из них фичи.
Это видно даже по постам в блоге:
Recently there has been a lot of discussion around the tooling hurdle when you start a React project. Luckily for Vue.js, all you need to do to start with a quick prototype is including it from a CDN via a script tag, so we’ve got that part covered.
или вот эта бессмысленная (в силу ложности утверждения — shouldComponentUpdate и иммутабельные структуры это дополнительные инструменты, а не обязаловка) язвительность:
No need for shouldComponentUpdate or immutable data structures — it just works.
Поэтому я настоятельно советую либо попытаться пообщаться с Эваном, чтобы помочь ему это увидеть, либо предпочесть решение с более взрослыми разработчиками за ним, которые делают фичи не из зависти к другим фреймворкам, а из осознанной необходимости в них.
k12th
30.05.2016 15:52+2Жаль такое слышать. Я недавно открыл для себя vue.js, после Backbone, Angular и React — действительно как глоток свежего воздуха. Что посоветуете взамен?
VasilioRuzanni
31.05.2016 21:17Смотря для чего — если еще не пробовали Aurelia — однозначно стоит на нее посмотреть.
baka_cirno
30.05.2016 15:58+3В каком месте Vue становится «раздутей»? В ветке 1.х API почти не менялся за редкими исключениями. В 2.х наоборот много чего выброшено за ненадобностью. И концепция не поменялась: это все та же простая view-библиотека, которую можно подключить как обычный скрипт и использовать как есть. При этом, если разработчик хочет, он может воспользоваться прекрасным тулингом и готовыми модулями вроде Vuex.
Собственно, что вам не нравится помимо «язвительности» автора?k12th
30.05.2016 16:08-1Я думаю, часть этой язвительности обусловлена беспрерывными вопросами типа «я вот выучил react и доволен, зачем мне vuejs».
Jabher
30.05.2016 18:02+1объективно, избыточные сущности, которые появились в 1х ветке и поздней 0х (по 2х не скажу, к сожалению):
вуй-лоадер (для файлов .vue ) — очень странный ход, в реальности очень трудно держать большие шаблоны рядом с JS-кодом в одном файле, а маленькие шаблоны можно и в темплейт вставить (или внешней переменной)
элемент-директивы (компонент и директив всегда хватало за глаза, а вопрос перфоманса решался немного иначе)
транзишны — их можно было вкрячить куда аккуратнее (объективно можно было, не через глобальные переменные на строках)
фильтры — можно было отдельным модулем. Нахрена в любой проект тащить с собой фильтр для валют, например? В 0.12 и рядом с ним в базовой поставке был минимальный набор фильтров, который в 90% случаев использовался, а даже если нет — это были однострочники типа upperCase.
v-else объективно ОЧЕНЬ грязный хак.
v-for первым ввел дополнительный внутренний синтаксис, отличающийся от общепринятого. До 0.13, если не путаю, он был гомогенен с остальными директивами, используя нотацию обычного объекта без скобок — [key]: value. Потом Эван зачем-то решил заменить двоеточие на in, нахрена — не очень понятно, но теперь зато все как в ангуляре, а не как в остальных директивах либы. Эту боль можно было решить при помощи фильтра, но почему-то никто тогда об этом ему не сказал.
События — какой-то ад вообще стали. v-on=«event: fn», v-on:event=«fn», @ event=«fn» и так далее. Да, это выглядит красиво и лаконично, но это усложнение синтаксиса, это опять же можно было решить не нагораживая монструозных языков. button click.stop.prevent=«doThis» — да, интуитивно можно догадаться, что это, но почему-то никто не сказал, что можно ввести спецсимволы в содержимое, чтобы было что-то вроде button v-on=«click: stop; @prevent; doThis». Это сходу пример, а не прямое предложение к действию. Проблема в том, что теперь очень трудно вылавливать директивы именно вуя — если раньше можно было искать по «v-», то сейчас ситуация усложнилась. Особенно при использовании кастомных событий.
Та же претензия к v-bind с его двоеточечной нотацией.
v-ref вообще какой-то бессмысленный, нахрена было вводить синтаксис v-ref:child, когда можно было все так же пользоваться атрибутом и писать v-ref=«child»?
Подстава в том, что начиная где-то с 0.12 или 0.13 вуй начал потихоньку использовать хтмл и JS как «транспортный протокол», не опираясь на них, но используя только самые базовые свойства.
Для разработчиков, которые пришли на него в последний год — все выглядит логичным и знакомым, вот там ангуляровское что-то, там реактовое, а там вот остатки хороших собственных идей. Но вот те, кто пользовался им хотя бы последние 2 года — стойкое ощущение, что из безумно простого и удобного эдакого «перочиного ножика» начинается наслаивание потыренных идей.
я ни в коей мере не считаю вуй редкостной гадостью, я просто вижу, как он именно что скатывается в раздутость, и это не приведет ни к чему хорошему. А скатывается он в силу личности автора. Более того, то, как он дебажится, я все еще считаю идеальным подходом к отладке, даже у реакта ловить ошибки гораздо сложнее, и много других вещей (типа работы с событиями) — чуть ли не лучшая, на мой взгляд, реализация в вебе.baka_cirno
30.05.2016 18:42+1Фильтры не попали в 2.х как таковые. По остальному я как бы понимаю вашу боль, но для меня вышеописанные моменты не являются минусами (почти, потому что v:ref и v:el действительно выглядят криво). Я ценю Vue именно за прагматичность автора. Он не исповедует никаких религий, не впиливает концепции ради концепций, а делает так, чтобы было максимально удобно и просто. Он не скрывает, что во многом вдохновился Ангуляром, а в ветке 2.х он без лишних сентиментов перешел на virtual DOM, причем сделал это максимально прозрачно и именно в этом месте не поломал обратную совместимость.
С моей точки зрения эта библиотека изначально была очень элегантной, и с момента своего создания становится только лучше. Хотя я понимаю, что других людей некоторые ее аспекты могут сильно раздражать, как меня раздражает React, например.
Darkside73
30.05.2016 20:38+2вуй-лоадер (для файлов .vue ) — очень странный ход, в реальности очень трудно держать большие шаблоны рядом с JS-кодом в одном файле
1 — его можно не использовать, если не нравится; 2 — при грамотном выделении компонентов можно оставаться в разумных пределах по количеству строк; 3 — ультрасовременный гугловский polymer тоже так делает (думаю, у polymer и позаимствовали идею)
По синтаксису — это вопрос вкуса фломастеров). Мне, например, вариант с
@больше нравится
Azy
30.05.2016 21:45+1> Вуй-лоадер (для файлов .vue ) — очень странный ход, в реальности очень трудно держать большие шаблоны рядом с JS-кодом в одном файле, а маленькие шаблоны можно и в темплейт вставить (или внешней переменной)
Это вообще огонь фича. Идеально для компонентов.Jabher
02.06.2016 17:32О, Макс, привет.
окей, ладно, вуй-файлы были моей болью, я не смог даже треть инструментов заставить работать с ними. сборщик, ide, линтер, профилировщик, test coverage, source maps и прочая чертовщина в ступе не заводилась с ними. плюс на момент релиза там точно была абсолютно жопная реализация поддержки очень ограниченного числа прекомпиляторов, что тоже очень спугнуло.
vintage
31.05.2016 09:16А как он дебажится, если не секрет?
Darkside73
31.05.2016 15:58Если включен source map, то breakpoint отлично работают непосредственно в vue файле. Еще есть расширение для хрома — можно любой компонент в консоле потыкать как хочется)
vintage
31.05.2016 17:56А дебаггер на эксепшенах где останавливается?
Darkside73
31.05.2016 19:15Проверил: в vue файле. И в консоли тоже правильно показывает:
vintage
31.05.2016 21:26Речь не про стектрейс в консоли, а про "останавку на исключениях".
Darkside73
01.06.2016 10:10Ваш вопрос:
А дебаггер на эксепшенах где останавливается?
Мой ответ:
Проверил: в vue файле.
bunopus
31.05.2016 19:50Тут ответ такой же, как и для Ember. Конкуренты скорее по хайпу, а не по полному функционалу. Мир фронтенда очень большой, инструментов — море. К сожалению, обычно так происходит, что когда разработчик встаёт перед выбором, на чём писать, он начинает гуглить, искать в твиттере, хабре. И, конечно тут же он натыкается на перечисленные фреймворки. Возможно vue круче, но, пока вокруг него нет хайпа — он будет уделом энтузиастов. А это обычно ведёт к потере интереса мейнтейнеров и угасанию библиотеки.
kurojneko
30.05.2016 13:44+1Почему так мало информации о Ember.js? Это старые темы для холиваров, что лучше взять и пр. но в глобальном достаточно разборе абсолютно забыли про фреймворк который может конкурировать с ангуларом и реактом (ну или имеет потенциал для конкуренции в будущем)
atc
30.05.2016 14:33+2С технической точки зрения Ember.js не уступает Angular2, а в чем-то даже превосходит, например ember-cli зайдействовали для написания аналогичной утилиты для Angular.
Если Евгений нас читает — было бы интересно услышать его мнение по поводу данного фреймворка.bunopus
31.05.2016 19:55Если честно — не могу назвать себя экспертом по Ember.js. По моему мнению, сейчас Ember уже слишком стар, и Angular его может уделать хотя бы за счёт того, что у него нет легаси и поддержки. Впрочем слишком раздувать как доклад, так и статью сравнениями со всем миром JS не хотелось бы. Но, тема интересная, если бы вы написали о том, почему не уступает — я бы с удовольствием почитал бы.
IvanPanfilov
30.05.2016 14:23> большой плюс в том, что Angular 2 написан на Typecript и транспилится в Dart
мухоха
> прошёл довольно большой путь: от совсем небольшого стартапа до двух миллионов строчек кода за 9+ лет разработки. Конечно, за это время у нас сменилась куча фреймворков и технологий. Всё начиналось с Dojo, потом Ext.js. Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать?
т.е. когда выходит очередной новомодны фрейморк или транслятор — вы бежите и переписываете на него.
вы не пробовали на vanilla js framework перейти? я вот перешол и не нарадуюсь.
теперь нет необходимости разбиратся в очередном новом высере чудо-разработчиков фрейморкаserf
30.05.2016 14:35> т.е. когда выходит очередной новомодны фрейморк или транслятор — вы бежите и переписываете на него.
Ну а почему не освоить новую спистоперделку за счет компании :) Справедливости ради переход на Typecript/Dart это не просто переход на новый фреймворк.
Gugic
30.05.2016 15:55Перевод проекта на Typescript/Dart совсем не мешает вам писать на vanilla JS. Но при правильном подходе привносит в ваш код немалую толику самодокументируемости, статическую типизацию, статический анализ, отлов самых простых ошибок еще на этапе компиляции.
Если комбинировать его с мощью ES6 — то получается совсем хорошо.
iKBAHT
31.05.2016 13:07+1Всё начиналось с Dojo, потом Ext.js. Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать?
Проект скачет не по трансляторам, а по библиотекам UI и фреймворкам. Очень интересно как на это смотрит владелец проекта или тот, за чьи деньги проект переписывали 3 раза. Проект явно существует без "архитектора".
Такой большой и старый проект уже должен понять, что не стоит завязываться на фреймворки. Нужно писать модульный код, в котором ни какая библиотека (а тем более фреймворк) не пронизывает все слои приложения. Как кто то сказал Не учите фреймворки, учите архитектуру
alaska332
30.05.2016 14:26Интересно выслушать мнение и опыт с ExtJS.
Думаем остановится на нем.serf
30.05.2016 14:31-1ExtJS для тех кто не может или не хочет освоить JavaScript.
alaska332
30.05.2016 14:41+1И все?
Содержатнльно.
Фронтенд — это немного больше, чем пресловутый яваскрипт, который может освоить ребенок.serf
30.05.2016 16:51> который может освоить ребенок
практика показывает что это не такalaska332
30.05.2016 16:57+1Один из самых простых языков, таким и задумывался изначально под браузер — вот что показывает практика.
serf
30.05.2016 16:59+1Вы видимо никогда не работали с джуниорами, или мне просто постоянно бестолковые попадались (собеседовал их не я). Нюансов на самом деле много, не смотря на видимую простоту.
alaska332
30.05.2016 17:08+1Ньюансы есть везде, джуниоров не нанимаю принципиально, только в редких случаях.
Мой вопрос был про ExtJS, как фреймворк для фронтенда.
Тратить год жизни на собственный на яваскрипте + верстка под различные платформы для нас нет смысла. Это не наш бизнес. ExtJS прошел 10-летний путь, хочу получить отзыв об опыте использования и недостатках.
akzhan
30.05.2016 19:09+1Раньше был интересен, сейчас не принимаю во внимание, так как тяжело под него разработчиков искать.
vintage
31.05.2016 09:25+1Ну вот и представьте себе груду накопившегося за 10 лет… костылей. :-) Лучше не связываться с "коробочными" фреймворками, ибо вы будете больше времени тратить на борьбу с фреймворком, чем тратили бы на кроссплатформенную реализацию.
sormy
31.05.2016 12:33+1Базируясь на моем опыте. Плюсы. ExtJS хорош для быстрой enterprise разработки используя готовый набор хорошо совместимых компонентов. Навороченые гриды, графики и т.п. и все прозрачно совместимо. Новые версии имеют хорошую адаптивность и одни и те же компоненты хорошо ведут себя как на десктопе, планшетах, так и на мобильных устройствах. Это главные плюсы. Легко менять стили и темы. Легко писать новые компоненты. Хорошая документация, много примеров. Минусы. Цена: дорого + платить за апгрейд почти как за новую версию каждый год. Лицензии только 5+, насколько я знаю. Форумы полны негатива, что индивидуальным разработчикам невыгодно покупать лицензию на 5+ разработчиков, чтобы иметь право релизить коммерческие приложения. Синтаксис застрял в 2010, полагаю, с целью совместимости. С точки зрения производительности — удовлетворительно. Безусловно реакт и второй ангуляр быстрее ввиду теневой dom и возможности перерендерить только то, что изменилось. Нужно отметить, что компоненты ExtJS генерируют слишком много html markup, что приводит к тому, что это дело тяжелее рендерится и дебагать его тяжелее с большой тяжелой DoM. В ExtJS в большинстве случаев в качестве оптимизации используется Lazy Rendering. Все ядро привязано намертво к XTemplate, которым рендерятся части DoM, который умеет только перерендеривать все заново, отсюда и тормоза. Там есть костыли для улучшения производительности, но все это выглядит не так красиво, как в случае с реакт или ангуляр2. Еще имеют практику ломать совместимость от версии к версии, довольно серьезно. В общем, ExtJS имеет свои плюсы и свои минусы.
atc
30.05.2016 18:09+1Прототипный подход к наследованию, функциональная и объектная парадигмы, тотальная асинхронность, нюансы с областями видимости, зачатки параллельности в виде вебворкеров, огромное количество способов сделать одно и то же.
Только за счет этих факторов js сложнее большинства скриптовых языков программирования, так что я не рискнул бы утверждать, что изучить javascrpt на хорошем уровне — это действительно детская задача.alaska332
30.05.2016 18:19Прототипный подход, думаю, будет изжит, мультипарадигменность — свойство множества языков, воркеры — не часть языка, а часть экосистемы js + browser, два абзаца про область видимости и ньюансы,…
Опыт и статистика говорят, что js изучается легче.atc
30.05.2016 18:27В самом минимальном и простом варианте это пожалуй так, но дождаться аккуратного и рационального и адекватного современным практикам кода от начинающего javascript программиста будет несколько сложнее, выбери он python ruby или php.
Те. с задачей «анимировать форму с помощью jquery» новообращенный справится вполне достойно, но на более сложных и маштабных задачах будет выдавать лютый нечитабельный треш.
Lostboy
30.05.2016 16:22+2Ext шикарен.
Есть проблемы с сообществом. По свежим версиям совсем грустно что-то гуглить.
Есть проблемы с узкой специализацией. Таблички и графики основная фича (вы естественно можете далать на нём что угодно, но лучше всего получаются таблицы и графики).
Не смотря на вышеречисленное, повторюсь, Ext шикарен.
Лучшего MVC/MVVM на js не встречал.alaska332
30.05.2016 16:40+1Мне интересно почему некоторые компании отказываются от ExtJS через некоторое время.
Lostboy
30.05.2016 17:02+1Думаю из-за сложности в разработке и поддержке.
Иногда на какую-нибудь кнопочку можно убить кучу времени, просто потому что решение не гуглится на раз два и ответы на stackoverflow найдутся в лучшем случае для похожей ситуации, но для версии ExtJs 4.
Единственные источники информации — это официальная документация, которая по большей части описание API, официальные примеры, официальный форум. Всё, если там нет, нигде нет.
serf
30.05.2016 17:06+2Потому что оно очень сильно диктует свои правила, отрисовку, шаг в сторону от стандартных фичей и начинается боль. Что-то не совсем хорошо работает/рендерится и наинается боль. Правда я его трогал последний раз v4, давно было. Как правило его выбирают в командах, где все пишут бэкенд, и те же разработчики пишут фронт по API, можно представить что в итоге получается. Вообще, виджетные фреймворки уже вроде как давно начали умирать, они не достаточно гибкие. Kendo UI смотрели?
alaska332
30.05.2016 17:15Kendo смотрел, те-же виджеты, только функционал беднее.
Выбор вообще простой:
1. виджеты, любое изменение дизайна реально сложно / невозможно;
2. Angular или его конкуренты + HTML полностью на нас;
Меня визуально ExtJS устраивает, интересуют подвадные камни в больших приложениях.
vandoorn
30.05.2016 22:31+3Extjs, конечно — монстр. Везде пишут что высокий порог вхождения — так и есть. Но для enterprise SPA — одно из лучших решений, хотя ценник нынче конский — и система лицензирования от 5 штук минимум.
vintage
31.05.2016 09:08Нет типизации на уровне языка для описания интерфейсов компонентов (только встроенная через propTypes и возможность привернуть Flow).
Есть TypeSript и даже TSX.
Сори, промахнулся веткой.
artemt
31.05.2016 12:31Проблема ExtJS в том, что трудно переходить на следующую версию. Перескочить через версию практически невозможно, потребуется всё переписывать.
bunopus
31.05.2016 20:03Если вкратце, то когда мы поняли, что старый ExtJs нас больше не устраивает, то было несколько «против» новой версии.
* Новый ExtJS давал еще больше готовых виджетов, которые мы как не использовали, так и не используем
* Давал MVVM с абсолютно убожеским и тормознутым биндингом
* Давал свой проприетарный шаблонизатор (верстку прямо в JS-указываешь)
* Старый мы к тому моменту уже перевели на soy, но переводить еще и пятый/шестой совсем не хотелосьalaska332
31.05.2016 21:07А чем именно не устраивал старый? Старый это 4-й?
bunopus
31.05.2016 23:26Старый — это третий. Кода было очень много, Ext перестал масштабироваться. Не знаю насчёт самых свежих версий, но тогда мы поняли, что при существующем положении дел увеличить проект в два раза не получится. Слишком система становится сложной и громоздкой
oneassasin
30.05.2016 15:28Где на их сайте используется Angular? Даже форма авторизации без него сделана.
bunopus
31.05.2016 20:05Если вы купите Enterprise подписку...
Шутка, на самом деле вы можете взять триальную версию, и таки да, весь новый функционал на Ng2. Reports, Header, Forms etc
zim32
30.05.2016 17:27+1Такой опа круто, заходишь такой https://angular.io/docs/ts/latest/guide/router-deprecated.html, опа и забываешь пока про ангулар 2.
serf
30.05.2016 17:31ну всяким хипстерам ведь неймется хуяк и в продакшен, и не важно что еще не зарелизился
Valery4
30.05.2016 22:34Да ладно. Во первых есть router-depricated и новый router. Во-вторых у меня заняло пол-часа прикрутить поддержку нового. И это без документации, которую к тому моменту не успели написать. Просто подсмотрел как и что в примере, в котором он использовался.
zim32
30.05.2016 22:38Есть гарантии что этот новый роутер не станет через пару месяцев деприкейтед или что завтра не поломается что-то при обновлении?
bromzh
06.06.2016 17:35Ломаться он перестал где-то с 11-12-й беты. Я спокойно обновлял 2 проекта, проблем не было. Было 3 момента, когда нужно было править код: изменилось местоположение сервиса
LocationStrategy, немного изменился синтаксисngForи в RC они изменили структуру npm-модулей. Но проблем действительно не было: простого поиска с заменой по проекту было достаточно. А то что роутер сделали deprecated… Лучше сейчас, чем после релиза. На данный момент старый роутер работает нормально. В новом не хватает некоторых фишек, но и его прикрутить не проблема.
FireGM
30.05.2016 22:31С выходом RC1 сильно мне сломал авторизацию вк. Урлы с обычными(не матрикс) параметрами редиректило на урлы без параметров. Т.е. вместо example.com/auth/vk?code=codefromvk, я получил example.com/auth/vk. В бете нельзя было получить эти параметры, парсил в ручную, разбираю урл, а тут и это забрали.
kernel72
30.05.2016 22:31+4Как то я не очень понял, как Angular 2 несет мир. Я так понял, что самой главной причиной почему выбрали Angular 2 это был Dart. А причем здесь мир для всей галактики фронтенда не ясно
Focushift
30.05.2016 22:31-1Все что я вынес из статьи — Angular 2 + Dart это классная вещь.
Или хотябы объясните почему я должен перейти с 1го на 2й, если целью статьи было рассказать какой новый фреймворк классный? Статья чисто реклама предстоящей конференции.
9rats
31.05.2016 12:34+1Если нет желания думать и строить свою архитектуру самолично — что в эквиваленте называется быть обезьянкой которая просто молотит по клавишам — Ангуляр в этом случае лучший друг. С Реактом бывает много интересных историй, здесь думать надо а это опасно))
bromzh
06.06.2016 17:58Тут теперь тоже думать надо, т.к. появилось больше возможностей организовать своё приложение. Можно в стиле flux/redux (однонаправленный data-flow, диспатчеры, глобальное состояние). Можно в стиле первого ангуляра с двусторонней привязкой данных. Можно делать "чистые" компоненты, без состояния, которые выводят данные и генерят события, а подавать данные и обрабатывать события в родительских компонентах. Можно всё это совмещать как хочется. Свободы, по сравнению с первой версией, явно стало больше.
k12th
06.06.2016 18:04А вот этот flux/redux-стиль он из коробки, или надо что-то доставлять?
bromzh
06.06.2016 18:43+1Из коробки.
Ангуляр зависит от Rxjs, а с её помощью легко можно организовать реактивный флоу. В самом же ангуляре так же есть штуки, упрощающие и организацию всего этого дела (например, пайп async). Если сделать всё правильно, можно изменить стратегию отслеживания изменений, что ускорит приложение (см., например, тут)
Ещё ссылки:
http://victorsavkin.com/post/137821436516/managing-state-in-angular-2-applications
https://medium.com/front-end-developers/managing-state-in-angular-2-using-rxjs-b849d6bbd5a5#.uwf5wk5ac
https://dzone.com/articles/how-to-build-angular-2-apps-using-observable-data-1
caballero
31.05.2016 14:22-1Эти войны от того что ни один фреймворк не решает нормально задекларированной им задачи. Скорее всего просто потому что перетаскивать бизнес-логику на клиента особенно с учетом развития облачных (серверных) технологий и относительно слабых браузеров мобильных девайсов, не имеет никакого смысла.
Посему эти войны закончатся когда пройдет мода налабутеныклиентские фреймворки.
FluorescentHallucinogen
31.05.2016 17:25> Все же Polymer — это скорее огромная библиотека компонентов, а не цельный фреймворк.
Polymer — это не фреймворк и не огромная библиотека компонентов. Это набор полифиллов и синтаксического сахара для веб-компонентов. Web Components — это совокупность спецификаций HTML Imports, Shadow DOM, HTML Templates и Custom Elements — того, что в скором времени станет стандратом W3C. Polymer просто предоставляет более удобный способ создания и использования веб-компонентов уже сегодня. Помимо Polymer есть ещё X-Tag, Brick, Bosonic, ScateJS и др.
Библиотека компонентов — это Element Catalog (https://elements.polymer-project.org) и CustomElements.io (https://customelements.io). Хотя готовые компоненты можно искать и брать в Bower, NPM или напрямую с GitHub.
Я бы не сказал, что Polymer огромный: сам Polymer ~35KB, полифиллы ~11KB (minified & gzipped). X-Tag и Brick используют те же полифиллы (webcomponenets-lite.js). Есть надежда, что в ближайшем будущем поддержка веб-компонентов будет реализована нативно во всех мейнстримных браузерах, полифиллы можно будет отключить и все продолжит работать.
Если нужен Dart, то есть ещё Polymer Dart, также известный как Polymer.dart (https://github.com/dart-lang/polymer-dart).bunopus
31.05.2016 20:08У Polymer Dart есть проблема — это надстройка над самим Polymer. А из этого следует то, что код остаёт по функционалу, там есть свои баги и пр. У Angular такого нет, так как из-за траснпиляции разработчики Ng2 сразу пишут как бы на Dart.
Bolbat
01.06.2016 13:17Отличная статья, спасибо!
Имею положительный опыт написания нескольких достаточно больших проектов на Angular 1 и с нетерпением жду финального релиза Angular 2 для новых проектов.
И вот теперь посмотрю более глубоко на связку Dart + Angular 2.
feligz
07.06.2016 12:08Использовал в проекте недавно. Несмотря на релиз кандидат все еще очень сыро, до сих пор переписывается новый роутер, я так понимаю чуть ли не с нуля. Релиз кандидата 2 уже нет почти месяц. Первый релиз кандидат был срочно сделан для ng-conf и совсем не похож на релиз, особенно после router-deprecated. В github.com до сих пор очень много не закрытых issues ( 1300+ было 1400+), новые появляются каждый день. Документация в некоторых местах кривая, а в части роутера ее почти нет. Из всего этого я сделал вывод, что пока Angular 2 рановато в продакшн ставить. Версия 1.x сейчас на пике — есть куча книг, отличные доки, есть бест практики, есть великолепный ui-router, так что можно еще годик использовать вполне себе, если не требуется сверхзвуковая скорость.
handymade
Скажите какие 3rd party плагины/компоненты для Аngular2 вы подключали в проекте — и насколько потом все удавалось заставить собираться и работать? Или «все сами писали»? потому что по моему это пока главная проблема Аngular2 — не устоявшееся апи и слабая экосистема; а так то он уже в виде сырого RC2
bunopus
В большинстве своём писали сами. Из-за наших задач + многое уже написано было на Polymer. Есть интересный репозиторий https://github.com/angular/material2, который можно заюзать.
По-поводу экосистемы: да, это так. Впрочем коммьюинити пока хоть и небольшое, но очень активное, так что я думаю, что за этим дело не станет.