Comments 102
Скажите какие 3rd party плагины/компоненты для Аngular2 вы подключали в проекте — и насколько потом все удавалось заставить собираться и работать? Или «все сами писали»? потому что по моему это пока главная проблема Аngular2 — не устоявшееся апи и слабая экосистема; а так то он уже в виде сырого RC2
В большинстве своём писали сами. Из-за наших задач + многое уже написано было на Polymer. Есть интересный репозиторий https://github.com/angular/material2, который можно заюзать.
По-поводу экосистемы: да, это так. Впрочем коммьюинити пока хоть и небольшое, но очень активное, так что я думаю, что за этим дело не станет.
По-поводу экосистемы: да, это так. Впрочем коммьюинити пока хоть и небольшое, но очень активное, так что я думаю, что за этим дело не станет.
vue.js добавили бы в конкурентов.
К сожалению, вуй — не нужен. Слава к этой замечательной либе пришла с ее упадком.
Я следил за его развитием с 0.10, и сейчас он превращается в раздутого мастодонта из-за самомнения Эвана (автора), достаточно почитать ишуи — человек не пытается слушать других, у него есть своя точка зрения на проект, и она уводит его из ниши, которую вуй идеально занимал — библиотека для rapid component development. API толще, тяжелее, появляются какие-то странные фичи, синтаксис внутри шаблонов перестает быть гомогенным и все больше напоминает первый ангуляр.
Идея, которая лежала за первыми версиями вуя, была прекрасна — это «the best API is no API». И микроядро довеском, где все остальное — отдельные модули, директивы и компоненты, что тоже прекрасно.
До первой версии все выглядело так, словно ты пользуешься встроенными инструментами языка: объекты это просто объекты, наследование — расширение прототипа (окей, Vue.extend работал как deep assign, но все равно это было очевидно), причем с добавлением маленьких приятных плюшек, аргументы для директив парсились как объекты или массивы (без фигурных скобок). А потом начался атас, Эван начал завидовать славе реакта с ангуляром (видимо, по причине упадка метеора, которым он занимался), и начал тащить из них фичи.
Это видно даже по постам в блоге:
или вот эта бессмысленная (в силу ложности утверждения — shouldComponentUpdate и иммутабельные структуры это дополнительные инструменты, а не обязаловка) язвительность:
Поэтому я настоятельно советую либо попытаться пообщаться с Эваном, чтобы помочь ему это увидеть, либо предпочесть решение с более взрослыми разработчиками за ним, которые делают фичи не из зависти к другим фреймворкам, а из осознанной необходимости в них.
Я следил за его развитием с 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.
Поэтому я настоятельно советую либо попытаться пообщаться с Эваном, чтобы помочь ему это увидеть, либо предпочесть решение с более взрослыми разработчиками за ним, которые делают фичи не из зависти к другим фреймворкам, а из осознанной необходимости в них.
Спасибо, приму к сведению.
Жаль такое слышать. Я недавно открыл для себя vue.js, после Backbone, Angular и React — действительно как глоток свежего воздуха. Что посоветуете взамен?
В каком месте Vue становится «раздутей»? В ветке 1.х API почти не менялся за редкими исключениями. В 2.х наоборот много чего выброшено за ненадобностью. И концепция не поменялась: это все та же простая view-библиотека, которую можно подключить как обычный скрипт и использовать как есть. При этом, если разработчик хочет, он может воспользоваться прекрасным тулингом и готовыми модулями вроде Vuex.
Собственно, что вам не нравится помимо «язвительности» автора?
Собственно, что вам не нравится помимо «язвительности» автора?
Я думаю, часть этой язвительности обусловлена беспрерывными вопросами типа «я вот выучил react и доволен, зачем мне vuejs».
объективно, избыточные сущности, которые появились в 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 года — стойкое ощущение, что из безумно простого и удобного эдакого «перочиного ножика» начинается наслаивание потыренных идей.
я ни в коей мере не считаю вуй редкостной гадостью, я просто вижу, как он именно что скатывается в раздутость, и это не приведет ни к чему хорошему. А скатывается он в силу личности автора. Более того, то, как он дебажится, я все еще считаю идеальным подходом к отладке, даже у реакта ловить ошибки гораздо сложнее, и много других вещей (типа работы с событиями) — чуть ли не лучшая, на мой взгляд, реализация в вебе.
вуй-лоадер (для файлов .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 года — стойкое ощущение, что из безумно простого и удобного эдакого «перочиного ножика» начинается наслаивание потыренных идей.
я ни в коей мере не считаю вуй редкостной гадостью, я просто вижу, как он именно что скатывается в раздутость, и это не приведет ни к чему хорошему. А скатывается он в силу личности автора. Более того, то, как он дебажится, я все еще считаю идеальным подходом к отладке, даже у реакта ловить ошибки гораздо сложнее, и много других вещей (типа работы с событиями) — чуть ли не лучшая, на мой взгляд, реализация в вебе.
Фильтры не попали в 2.х как таковые. По остальному я как бы понимаю вашу боль, но для меня вышеописанные моменты не являются минусами (почти, потому что v:ref и v:el действительно выглядят криво). Я ценю Vue именно за прагматичность автора. Он не исповедует никаких религий, не впиливает концепции ради концепций, а делает так, чтобы было максимально удобно и просто. Он не скрывает, что во многом вдохновился Ангуляром, а в ветке 2.х он без лишних сентиментов перешел на virtual DOM, причем сделал это максимально прозрачно и именно в этом месте не поломал обратную совместимость.
С моей точки зрения эта библиотека изначально была очень элегантной, и с момента своего создания становится только лучше. Хотя я понимаю, что других людей некоторые ее аспекты могут сильно раздражать, как меня раздражает React, например.
С моей точки зрения эта библиотека изначально была очень элегантной, и с момента своего создания становится только лучше. Хотя я понимаю, что других людей некоторые ее аспекты могут сильно раздражать, как меня раздражает React, например.
вуй-лоадер (для файлов .vue ) — очень странный ход, в реальности очень трудно держать большие шаблоны рядом с JS-кодом в одном файле
1 — его можно не использовать, если не нравится; 2 — при грамотном выделении компонентов можно оставаться в разумных пределах по количеству строк; 3 — ультрасовременный гугловский polymer тоже так делает (думаю, у polymer и позаимствовали идею)
По синтаксису — это вопрос вкуса фломастеров). Мне, например, вариант с @ больше нравится
> Вуй-лоадер (для файлов .vue ) — очень странный ход, в реальности очень трудно держать большие шаблоны рядом с JS-кодом в одном файле, а маленькие шаблоны можно и в темплейт вставить (или внешней переменной)
Это вообще огонь фича. Идеально для компонентов.
Это вообще огонь фича. Идеально для компонентов.
О, Макс, привет.
окей, ладно, вуй-файлы были моей болью, я не смог даже треть инструментов заставить работать с ними. сборщик, ide, линтер, профилировщик, test coverage, source maps и прочая чертовщина в ступе не заводилась с ними. плюс на момент релиза там точно была абсолютно жопная реализация поддержки очень ограниченного числа прекомпиляторов, что тоже очень спугнуло.
окей, ладно, вуй-файлы были моей болью, я не смог даже треть инструментов заставить работать с ними. сборщик, ide, линтер, профилировщик, test coverage, source maps и прочая чертовщина в ступе не заводилась с ними. плюс на момент релиза там точно была абсолютно жопная реализация поддержки очень ограниченного числа прекомпиляторов, что тоже очень спугнуло.
А как он дебажится, если не секрет?
Если включен source map, то breakpoint отлично работают непосредственно в vue файле. Еще есть расширение для хрома — можно любой компонент в консоле потыкать как хочется)
Тут ответ такой же, как и для Ember. Конкуренты скорее по хайпу, а не по полному функционалу. Мир фронтенда очень большой, инструментов — море. К сожалению, обычно так происходит, что когда разработчик встаёт перед выбором, на чём писать, он начинает гуглить, искать в твиттере, хабре. И, конечно тут же он натыкается на перечисленные фреймворки. Возможно vue круче, но, пока вокруг него нет хайпа — он будет уделом энтузиастов. А это обычно ведёт к потере интереса мейнтейнеров и угасанию библиотеки.
Почему так мало информации о Ember.js? Это старые темы для холиваров, что лучше взять и пр. но в глобальном достаточно разборе абсолютно забыли про фреймворк который может конкурировать с ангуларом и реактом (ну или имеет потенциал для конкуренции в будущем)
С технической точки зрения Ember.js не уступает Angular2, а в чем-то даже превосходит, например ember-cli зайдействовали для написания аналогичной утилиты для Angular.
Если Евгений нас читает — было бы интересно услышать его мнение по поводу данного фреймворка.
Если Евгений нас читает — было бы интересно услышать его мнение по поводу данного фреймворка.
Если честно — не могу назвать себя экспертом по Ember.js. По моему мнению, сейчас Ember уже слишком стар, и Angular его может уделать хотя бы за счёт того, что у него нет легаси и поддержки. Впрочем слишком раздувать как доклад, так и статью сравнениями со всем миром JS не хотелось бы. Но, тема интересная, если бы вы написали о том, почему не уступает — я бы с удовольствием почитал бы.
правильно ли я понял, что ваш главный аргумент против использования Ember это «слишком стар»? И как вы дифференциируете понятия «слишком стар» и «зрел»?
В Ember взята модель Jquery против legacy кода. При переходе с 1.x на 2.x версию ненужный легаси код был как раз выключен. С заранее опубликованными deprecations и moving paths. Так что ember сообщество довольно безболезненно смогло перейти от версии 1 к версии 2. В отличии от Angular сообщества. Так что здесь не применим ваш аргумент с Angular2. Как раз наоборот, сравнение в пользу Ember
Хорошая компания, жалко что пишут на Ангуляре, хотел-бык ним устроится, но вот ангуляр мне не нравится.
> большой плюс в том, что Angular 2 написан на Typecript и транспилится в Dart
мухоха
> прошёл довольно большой путь: от совсем небольшого стартапа до двух миллионов строчек кода за 9+ лет разработки. Конечно, за это время у нас сменилась куча фреймворков и технологий. Всё начиналось с Dojo, потом Ext.js. Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать?
т.е. когда выходит очередной новомодны фрейморк или транслятор — вы бежите и переписываете на него.
вы не пробовали на vanilla js framework перейти? я вот перешол и не нарадуюсь.
теперь нет необходимости разбиратся в очередном новом высере чудо-разработчиков фрейморка
мухоха
> прошёл довольно большой путь: от совсем небольшого стартапа до двух миллионов строчек кода за 9+ лет разработки. Конечно, за это время у нас сменилась куча фреймворков и технологий. Всё начиналось с Dojo, потом Ext.js. Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать?
т.е. когда выходит очередной новомодны фрейморк или транслятор — вы бежите и переписываете на него.
вы не пробовали на vanilla js framework перейти? я вот перешол и не нарадуюсь.
теперь нет необходимости разбиратся в очередном новом высере чудо-разработчиков фрейморка
> т.е. когда выходит очередной новомодны фрейморк или транслятор — вы бежите и переписываете на него.
Ну а почему не освоить новую спистоперделку за счет компании :) Справедливости ради переход на Typecript/Dart это не просто переход на новый фреймворк.
Ну а почему не освоить новую спистоперделку за счет компании :) Справедливости ради переход на Typecript/Dart это не просто переход на новый фреймворк.
Перевод проекта на Typescript/Dart совсем не мешает вам писать на vanilla JS. Но при правильном подходе привносит в ваш код немалую толику самодокументируемости, статическую типизацию, статический анализ, отлов самых простых ошибок еще на этапе компиляции.
Если комбинировать его с мощью ES6 — то получается совсем хорошо.
Если комбинировать его с мощью ES6 — то получается совсем хорошо.
Всё начиналось с Dojo, потом Ext.js. Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать?
Проект скачет не по трансляторам, а по библиотекам UI и фреймворкам. Очень интересно как на это смотрит владелец проекта или тот, за чьи деньги проект переписывали 3 раза. Проект явно существует без "архитектора".
Такой большой и старый проект уже должен понять, что не стоит завязываться на фреймворки. Нужно писать модульный код, в котором ни какая библиотека (а тем более фреймворк) не пронизывает все слои приложения. Как кто то сказал Не учите фреймворки, учите архитектуру
Интересно выслушать мнение и опыт с ExtJS.
Думаем остановится на нем.
Думаем остановится на нем.
ExtJS для тех кто не может или не хочет освоить JavaScript.
И все?
Содержатнльно.
Фронтенд — это немного больше, чем пресловутый яваскрипт, который может освоить ребенок.
Содержатнльно.
Фронтенд — это немного больше, чем пресловутый яваскрипт, который может освоить ребенок.
> который может освоить ребенок
практика показывает что это не так
практика показывает что это не так
Один из самых простых языков, таким и задумывался изначально под браузер — вот что показывает практика.
Вы видимо никогда не работали с джуниорами, или мне просто постоянно бестолковые попадались (собеседовал их не я). Нюансов на самом деле много, не смотря на видимую простоту.
Ньюансы есть везде, джуниоров не нанимаю принципиально, только в редких случаях.
Мой вопрос был про ExtJS, как фреймворк для фронтенда.
Тратить год жизни на собственный на яваскрипте + верстка под различные платформы для нас нет смысла. Это не наш бизнес. ExtJS прошел 10-летний путь, хочу получить отзыв об опыте использования и недостатках.
Мой вопрос был про ExtJS, как фреймворк для фронтенда.
Тратить год жизни на собственный на яваскрипте + верстка под различные платформы для нас нет смысла. Это не наш бизнес. ExtJS прошел 10-летний путь, хочу получить отзыв об опыте использования и недостатках.
Раньше был интересен, сейчас не принимаю во внимание, так как тяжело под него разработчиков искать.
Ну вот и представьте себе груду накопившегося за 10 лет… костылей. :-) Лучше не связываться с "коробочными" фреймворками, ибо вы будете больше времени тратить на борьбу с фреймворком, чем тратили бы на кроссплатформенную реализацию.
UFO just landed and posted this here
Базируясь на моем опыте. Плюсы. ExtJS хорош для быстрой enterprise разработки используя готовый набор хорошо совместимых компонентов. Навороченые гриды, графики и т.п. и все прозрачно совместимо. Новые версии имеют хорошую адаптивность и одни и те же компоненты хорошо ведут себя как на десктопе, планшетах, так и на мобильных устройствах. Это главные плюсы. Легко менять стили и темы. Легко писать новые компоненты. Хорошая документация, много примеров. Минусы. Цена: дорого + платить за апгрейд почти как за новую версию каждый год. Лицензии только 5+, насколько я знаю. Форумы полны негатива, что индивидуальным разработчикам невыгодно покупать лицензию на 5+ разработчиков, чтобы иметь право релизить коммерческие приложения. Синтаксис застрял в 2010, полагаю, с целью совместимости. С точки зрения производительности — удовлетворительно. Безусловно реакт и второй ангуляр быстрее ввиду теневой dom и возможности перерендерить только то, что изменилось. Нужно отметить, что компоненты ExtJS генерируют слишком много html markup, что приводит к тому, что это дело тяжелее рендерится и дебагать его тяжелее с большой тяжелой DoM. В ExtJS в большинстве случаев в качестве оптимизации используется Lazy Rendering. Все ядро привязано намертво к XTemplate, которым рендерятся части DoM, который умеет только перерендеривать все заново, отсюда и тормоза. Там есть костыли для улучшения производительности, но все это выглядит не так красиво, как в случае с реакт или ангуляр2. Еще имеют практику ломать совместимость от версии к версии, довольно серьезно. В общем, ExtJS имеет свои плюсы и свои минусы.
Прототипный подход к наследованию, функциональная и объектная парадигмы, тотальная асинхронность, нюансы с областями видимости, зачатки параллельности в виде вебворкеров, огромное количество способов сделать одно и то же.
Только за счет этих факторов js сложнее большинства скриптовых языков программирования, так что я не рискнул бы утверждать, что изучить javascrpt на хорошем уровне — это действительно детская задача.
Только за счет этих факторов js сложнее большинства скриптовых языков программирования, так что я не рискнул бы утверждать, что изучить javascrpt на хорошем уровне — это действительно детская задача.
Прототипный подход, думаю, будет изжит, мультипарадигменность — свойство множества языков, воркеры — не часть языка, а часть экосистемы js + browser, два абзаца про область видимости и ньюансы,…
Опыт и статистика говорят, что js изучается легче.
Опыт и статистика говорят, что js изучается легче.
В самом минимальном и простом варианте это пожалуй так, но дождаться аккуратного и рационального и адекватного современным практикам кода от начинающего javascript программиста будет несколько сложнее, выбери он python ruby или php.
Те. с задачей «анимировать форму с помощью jquery» новообращенный справится вполне достойно, но на более сложных и маштабных задачах будет выдавать лютый нечитабельный треш.
Те. с задачей «анимировать форму с помощью jquery» новообращенный справится вполне достойно, но на более сложных и маштабных задачах будет выдавать лютый нечитабельный треш.
Сходите на тостер, почитайте вопросы по JS.
Ext шикарен.
Есть проблемы с сообществом. По свежим версиям совсем грустно что-то гуглить.
Есть проблемы с узкой специализацией. Таблички и графики основная фича (вы естественно можете далать на нём что угодно, но лучше всего получаются таблицы и графики).
Не смотря на вышеречисленное, повторюсь, Ext шикарен.
Лучшего MVC/MVVM на js не встречал.
Есть проблемы с сообществом. По свежим версиям совсем грустно что-то гуглить.
Есть проблемы с узкой специализацией. Таблички и графики основная фича (вы естественно можете далать на нём что угодно, но лучше всего получаются таблицы и графики).
Не смотря на вышеречисленное, повторюсь, Ext шикарен.
Лучшего MVC/MVVM на js не встречал.
Мне интересно почему некоторые компании отказываются от ExtJS через некоторое время.
Думаю из-за сложности в разработке и поддержке.
Иногда на какую-нибудь кнопочку можно убить кучу времени, просто потому что решение не гуглится на раз два и ответы на stackoverflow найдутся в лучшем случае для похожей ситуации, но для версии ExtJs 4.
Единственные источники информации — это официальная документация, которая по большей части описание API, официальные примеры, официальный форум. Всё, если там нет, нигде нет.
Иногда на какую-нибудь кнопочку можно убить кучу времени, просто потому что решение не гуглится на раз два и ответы на stackoverflow найдутся в лучшем случае для похожей ситуации, но для версии ExtJs 4.
Единственные источники информации — это официальная документация, которая по большей части описание API, официальные примеры, официальный форум. Всё, если там нет, нигде нет.
Потому что оно очень сильно диктует свои правила, отрисовку, шаг в сторону от стандартных фичей и начинается боль. Что-то не совсем хорошо работает/рендерится и наинается боль. Правда я его трогал последний раз v4, давно было. Как правило его выбирают в командах, где все пишут бэкенд, и те же разработчики пишут фронт по API, можно представить что в итоге получается. Вообще, виджетные фреймворки уже вроде как давно начали умирать, они не достаточно гибкие. Kendo UI смотрели?
Тоже интерестно послушать про ExtJS, у нас в компании остановились на нем.
Extjs, конечно — монстр. Везде пишут что высокий порог вхождения — так и есть. Но для enterprise SPA — одно из лучших решений, хотя ценник нынче конский — и система лицензирования от 5 штук минимум.
Нет типизации на уровне языка для описания интерфейсов компонентов (только встроенная через propTypes и возможность привернуть Flow).
Есть TypeSript и даже TSX.
Сори, промахнулся веткой.
Проблема ExtJS в том, что трудно переходить на следующую версию. Перескочить через версию практически невозможно, потребуется всё переписывать.
Если вкратце, то когда мы поняли, что старый ExtJs нас больше не устраивает, то было несколько «против» новой версии.
* Новый ExtJS давал еще больше готовых виджетов, которые мы как не использовали, так и не используем
* Давал MVVM с абсолютно убожеским и тормознутым биндингом
* Давал свой проприетарный шаблонизатор (верстку прямо в JS-указываешь)
* Старый мы к тому моменту уже перевели на soy, но переводить еще и пятый/шестой совсем не хотелось
* Новый ExtJS давал еще больше готовых виджетов, которые мы как не использовали, так и не используем
* Давал MVVM с абсолютно убожеским и тормознутым биндингом
* Давал свой проприетарный шаблонизатор (верстку прямо в JS-указываешь)
* Старый мы к тому моменту уже перевели на soy, но переводить еще и пятый/шестой совсем не хотелось
Мы писали на Polymer 0.5, и, когда он стал deprecated (с выходом версии 1.0), перед нами встал вопрос — что же выбрать?
Напоролись с одной сырой технологией и решили взять другую сырую технологию. Мне нравится это упорство!
Где на их сайте используется Angular? Даже форма авторизации без него сделана.
и вы говорите что сайт с ангуляром 2 быстрее… У меня на ноуте 18 сек onload…
Такой опа круто, заходишь такой https://angular.io/docs/ts/latest/guide/router-deprecated.html, опа и забываешь пока про ангулар 2.
ну всяким хипстерам ведь неймется хуяк и в продакшен, и не важно что еще не зарелизился
Да ладно. Во первых есть router-depricated и новый router. Во-вторых у меня заняло пол-часа прикрутить поддержку нового. И это без документации, которую к тому моменту не успели написать. Просто подсмотрел как и что в примере, в котором он использовался.
Есть гарантии что этот новый роутер не станет через пару месяцев деприкейтед или что завтра не поломается что-то при обновлении?
Ломаться он перестал где-то с 11-12-й беты. Я спокойно обновлял 2 проекта, проблем не было. Было 3 момента, когда нужно было править код: изменилось местоположение сервиса LocationStrategy, немного изменился синтаксис ngFor и в RC они изменили структуру npm-модулей. Но проблем действительно не было: простого поиска с заменой по проекту было достаточно. А то что роутер сделали deprecated… Лучше сейчас, чем после релиза. На данный момент старый роутер работает нормально. В новом не хватает некоторых фишек, но и его прикрутить не проблема.
А где Cycle.js в списке конкурентов?
С выходом RC1 сильно мне сломал авторизацию вк. Урлы с обычными(не матрикс) параметрами редиректило на урлы без параметров. Т.е. вместо example.com/auth/vk?code=codefromvk, я получил example.com/auth/vk. В бете нельзя было получить эти параметры, парсил в ручную, разбираю урл, а тут и это забрали.
Как то я не очень понял, как Angular 2 несет мир. Я так понял, что самой главной причиной почему выбрали Angular 2 это был Dart. А причем здесь мир для всей галактики фронтенда не ясно
Все что я вынес из статьи — Angular 2 + Dart это классная вещь.
Или хотябы объясните почему я должен перейти с 1го на 2й, если целью статьи было рассказать какой новый фреймворк классный? Статья чисто реклама предстоящей конференции.
Или хотябы объясните почему я должен перейти с 1го на 2й, если целью статьи было рассказать какой новый фреймворк классный? Статья чисто реклама предстоящей конференции.
Интересно почему решили продолжить использовать Dart, а не перешли на TypeScript которому отдали предпочтение в Google?
Если нет желания думать и строить свою архитектуру самолично — что в эквиваленте называется быть обезьянкой которая просто молотит по клавишам — Ангуляр в этом случае лучший друг. С Реактом бывает много интересных историй, здесь думать надо а это опасно))
Тут теперь тоже думать надо, т.к. появилось больше возможностей организовать своё приложение. Можно в стиле flux/redux (однонаправленный data-flow, диспатчеры, глобальное состояние). Можно в стиле первого ангуляра с двусторонней привязкой данных. Можно делать "чистые" компоненты, без состояния, которые выводят данные и генерят события, а подавать данные и обрабатывать события в родительских компонентах. Можно всё это совмещать как хочется. Свободы, по сравнению с первой версией, явно стало больше.
А вот этот flux/redux-стиль он из коробки, или надо что-то доставлять?
Из коробки.
Ангуляр зависит от 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
И вот такая штука еще есть: ngrx/store
Эти войны от того что ни один фреймворк не решает нормально задекларированной им задачи. Скорее всего просто потому что перетаскивать бизнес-логику на клиента особенно с учетом развития облачных (серверных) технологий и относительно слабых браузеров мобильных девайсов, не имеет никакого смысла.
Посему эти войны закончатся когда пройдет мода налабутены клиентские фреймворки.
Посему эти войны закончатся когда пройдет мода на
> Все же 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).
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).
Отличная статья, спасибо!
Имею положительный опыт написания нескольких достаточно больших проектов на Angular 1 и с нетерпением жду финального релиза Angular 2 для новых проектов.
И вот теперь посмотрю более глубоко на связку Dart + Angular 2.
Имею положительный опыт написания нескольких достаточно больших проектов на Angular 1 и с нетерпением жду финального релиза Angular 2 для новых проектов.
И вот теперь посмотрю более глубоко на связку Dart + Angular 2.
Использовал в проекте недавно. Несмотря на релиз кандидат все еще очень сыро, до сих пор переписывается новый роутер, я так понимаю чуть ли не с нуля. Релиз кандидата 2 уже нет почти месяц. Первый релиз кандидат был срочно сделан для ng-conf и совсем не похож на релиз, особенно после router-deprecated. В github.com до сих пор очень много не закрытых issues ( 1300+ было 1400+), новые появляются каждый день. Документация в некоторых местах кривая, а в части роутера ее почти нет. Из всего этого я сделал вывод, что пока Angular 2 рановато в продакшн ставить. Версия 1.x сейчас на пике — есть куча книг, отличные доки, есть бест практики, есть великолепный ui-router, так что можно еще годик использовать вполне себе, если не требуется сверхзвуковая скорость.
А не было опыта использования компонент из PrimeNG? На сколько они вообще пригодны или есть куда более продвинутые наборы компонент?
К сожалению, все немного не так. Роутер переписан три раза и последнее переписывание еще не завершено, есть баги, переписаны формы еще много чего перелопачивается и дописывается в последний момент. Все это делается в спешке и скорее всего приведет к непродуманным местам в апи. Да, разработчики опытные люди, несомненно, но формы все равно оставляют желать лучшего, новый роутер еще пробовал(и хорошо!), но старые имели существенные недоработки. Многие ограничения связаны с попыткой сделать очень универсальный инструмент, это повлияло и на сложность апи. Реализовать что-то нетривиальное полностью по канонам ангуляра непросто. апи довольно многословное, для разработки пришлось сделать базовые классы для компонентов и директив, чтобы не делать кучу импортов и лишних движений, наследование, к слову, работает только наполовину, метаданные декораторов не наследуются. Размер фреймворка тоже ставит вопросы: вебпак меньше 800кб не выдает. В целом, я затрудняюсь представить целевую аудиторию, когда заматереет может приглянуться энтерпрайзу.
Sign up to leave a comment.
Angular 2 несёт мир в галактику фронтенда