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

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

НЛО прилетело и опубликовало эту надпись здесь
А можете хотя-бы кратко рассказать об их предназначениях?
Я вообще с web и в особенности js фреймворками дела не имел никогда, но интересно.
НЛО прилетело и опубликовало эту надпись здесь
Angular хороший, но мягко говоря не идеальный.
После 2-х лет кропотливого труда эти ребята напишут свой ExtJS.
Все это уже было.
Вставлю свои 5 копеек, ExtJS — платная, jQuery и AngularJS — бесплатные.
А где вы увидели в статье сравнение jQuery и AngularJS как сущностей одного уровня? На картинке с лого что ли? Потому что в статье прямо сказано что jQuery не используется как фреймворк, а есть проект «на Ruby on Rails в которых jQuery просто переключает страницы или графики»
НЛО прилетело и опубликовало эту надпись здесь
Это все равное не ортогональные вещи, насколько я понимаю вряд ли стали бы использовать на одной страничке и ExtJS и AngularJS, так что что-то одно выбрать надо.
Вполне реальная ситуация. Был большой проект на ExtJS 3, сделали новую версию на AngularJS. Пусть скакун и феррари, функции для клиента выполнают те же, хоть и по-разному.
Да, но это озвученных выводов не меняет, какими мы разными не были фреймворки, задачи, которые они решают. Все представлено выше.
Однако можно говорить и сравнивать:
— ExtJS-style
— jQuery-style
— AngularJS-style
Они сравнимы. Они оьличаются. Они плохо совместимы
НЛО прилетело и опубликовало эту надпись здесь
полностью согласен, стоит идти от поставленных задач, каждый по своему хорош, а также от наличия специалистов и их знаний
Предназначение у них одно — облегчить (в широком смысле) фронт-енд разработку. Используются для этого разные концепции, способы, методы.
НЛО прилетело и опубликовало эту надпись здесь
У меня на работе одна из самых нагруженных админок-одностраничек Украины на ExtJS.
В чем вообще трудность? :)
Все зависит от степени генерализации вопроса. С точки зрения владельцев бизнеса вопрос «на какой технологии делать веб-продукты компании, если наши программисты, в принципе, могут разобраться в любой из них?» вполне резонен и адекватен.

Особенно в нашем случае, когда UI-пакет ExtJS нам не очень-то подходил, т.к. дизайн и поведение UI-контролов у нас другие.

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

Ведь в реальной жизни купить станок не всегда экономически выгоднее.
Я бы лучше выбрал jQuery + необходимые плагины, чем jQuery + плагины + ExtJS + AngularJS. И из последних будет использоваться 1.5%
нет, не разное. Это всё куски кода на яваскрипте, которые служат задаче реализации чего-то динамического на веб-страничке и сильно затягивающие в использование одного лишь себя.

Нельзя с комфортом использовать вместе ExtJS и Angular, или Angular и React. Надо выбрать что-то одно, поэтому выбирать надо.
ни разу ни js-скрипист, но статья затягивает, очень понравился стиль изложения.
Забавно что с момента написания статьи Angular 2 вполне себе релизнулся и имеет богатую документацию
Это наркотик. Да вам это нравится. Но со временем вы поймёте, что сидите на нём и не можете слезть, так как привыкание. А вот окружающий мир решает свои проблемы чаем или морфием, но только когда нужно.
Забегая вперед стоит сказать, что описываемая в докладе работа делалась в 2015-м, и сейчас, в 2016-м AngularJS2 получил богатую документацию, примеры, стал стабильным и т.д.
И в итоге, столкнувших с очередным набором проблем, которые нужно было решать руками, мы таки в итоге выбрали AngualrJS 2 вместо React'а, это было коллективное и сомысленное решение с идеей, что лучше пусть будет «потупее или позапутанней», но меньше собственного кода поддерживать и развивать, больше доков и примеров, проще и меньше учиться.

Хотя для Angular2 тоже пришлось придумать более стандартизованную архитектуру, и набор правил как можно и нельзя делать.

Сами по себе костыли и самоделки, которые действительно ускоряют разработку, сделанные с умом хороши, но в масштабах боьлшой компании всегда приходится находить баланс между своими и сторонними решениями, в условиях когда много сил на поддержку собственных выделять не получается.
Думаю этим Вашим комментарием было бы неплохо закончить текст самой статьи.
Как анонс второй серии, например ;)
А с Angular2 удалось добиться выполнения требований «менее связная архитектура», «чёткое разделение зон ответственности», «не являющийся всё-в-одном», а также удалось ли сохранить пункт в стратегии перехода «старый код не трогаем, новый встраиваем независимыми блоками»?

Может, есть какой-то «тестовый набросок» того, в каком виде у вас Angular2 применяется?

Также присоединяюсь к ораторам, просящим статью на эту тему.
Это уже надо просить веб-команду написать вам ответ, щас попрошу, надеюсь, согласятся.
XEK
Забегая вперед стоит сказать, что описываемая в докладе работа делалась в 2015-м, и сейчас, в 2016-м AngularJS2 получил богатую документацию, примеры, стал стабильным и т.д.
И в итоге, столкнувших с очередным набором проблем, которые нужно было решать руками, мы таки в итоге выбрали AngualrJS 2 вместо React'а, это было коллективное и сомысленное решение с идеей, что лучше пусть будет «потупее или позапутанней», но меньше собственного кода поддерживать и развивать, больше доков и примеров, проще и меньше учиться.
До сих пор так и остались на AngualrJS 2? И не… жалеете?
Слушай, ну, я мало сейчас имею отношения к проекту. Ребята там переехали на новую версию Angular, сделали шину сообщений общую для всего проекта. Они довольны. Мы как раз будет релизить скоро ооочень большую веб-консоль на нем. Визуально отзывчивость интерфейса после ExtJS стала сильно приятнее.

Извините, уточню на всякий случай. Вы представитель того же сообщества программистов, что автора статьи? И в конце концов, после того, как зарелизиля второй Ангуляр вы коллективно решили, что целесообразнее использовать его?

Я не понял. Я и есть автор доклада. Написал же, что в итоге поддерживать собственное решение занимало силы, и придумали, по сути, как сократить издержки, используя Angular2. Меньше самописных решений так.

Ой, прошу прощения. Смотрел автора статьи, а это olegbunin. Теперь понял, что автора доклада таки вы. Как-то получается, что заключение доклада — делайте всё своё, превозмогайте. А по итогу выяснилось, что по возможности ищите готовые решение, если они конечно есть. Я правильно понял?

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

С Angular2 мучений было еще больше, просто по итогу по совокупности факторов выбрали его.
вот ты побольше расскажи про Angular2 пожалуйста.

Мы сделали свою админку на Angular, потом с неё ушли на React и сейчас я уже не уверен в адекватности этого выбора.
Поддались моде? :)
а как без этого. В стремительно меняющемся мире яваскрипта, принимать длинные фундаментальные решения надо с помощью утреннего номера модного ежедневника: «что будет актуально сегодня до вечера, а этой ночью будет объявлено устаревшим»

я написал ребятам, пойду еще раз напомню
Он релизнулся 1.5 недели назад, имея где-то 5 месяцов попыток, так что не забавно.
НЛО прилетело и опубликовало эту надпись здесь

Между прочим, KnockoutJS — это не только реализация MVVM, но еще и реализация FRP, о чем почему-то постоянно забывают...

НЛО прилетело и опубликовало эту надпись здесь

Нет, она не необходима. Множество реализаций MVVM, не являющихся реализациями FRP — тому пример.

НЛО прилетело и опубликовало эту надпись здесь

Зато есть множество тех, кто не использует реактивные возможности Knockout, работая с ним исключительно как с MVVM-библиотекой. (А после этого приходит к выводу, что Angular удобнее)

Я запилил на похожем подходе сборщик, который автоматически отлеживает изменения в исходниках и пересобирает лишь зависящие от изменившихся исходников бандлы. Надеюсь вы не будете высасывать тут из пальца MVVM? :-)

НЛО прилетело и опубликовало эту надпись здесь
какое это отношение имеет к реактивному программированию?

Прямое.


к knockout

Почти тот же принцип работы. Каждая задача сборщика — это computed со всеми вытекающими (автоматическое построение дерева зависимостей, автоматическая инвалидация неактуальных зависимостей и тд).


и MVVM?

Очевидно, никакого.


месье знает толк в извращениях ))

Получилось довольно элегантно, на самом деле. Если вы прочитали какой-то конфиг при генерации бандла (например, tsconfig.json), то после изменения конфига получите свежий бандл, без ручного написания вотчеров.

НЛО прилетело и опубликовало эту надпись здесь

Расшифруете для неуча эти два термина или опять в сибирь гугл отправите?


Файл с конфигом — это данные, возвращаемые методом "получить содержимое" объекта "файл".

НЛО прилетело и опубликовало эту надпись здесь

Это вы о чём?

Knockout UI library — плохо… React тоже UI library c ваших слов — но это хорошо. В чем же тогда по-вашему разница между феймворком и библиотекой?


То, что это фрейворк или UI-библиотека — не имеет отношения к «понравилось» или «не понравилось».
Я в самом начале доклада написал, что не буду подробно останавливаться на том, почему не подошло, потому что это будет война религий и закидают помидорами.

Одним из важных моментов был тот, что технология не популярна.

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

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

А html темплейт в JS-коде в React приложениях меня например как-то удручает…

Меня он удручает еще больше, про это в докладе много рассказано. Как могли, боролись с этим, но партизаны там толстые, особенно с переводами и окончаниями фраз содержащих пол или число.

Angular будет вечно пытаться заткнуть магией недостатки JS и DOM.

Это тоже меня сильно расстраивает, т.к. в версии 2 появилась еще самодельная реализация Shadow DOM, и с CSS это дает кучу геморроя. Внятного способа создать застилизировать вложенный компонент из родительского так и нет. В общем, костылей стало больше.
НЛО прилетело и опубликовало эту надпись здесь
Искал в коментах защитника нокаута и нашел. Значит я не один считаю, что все эти реакты и ангуляры — это почти всегда жуткий оверкилл и нокаут прекрасно (и очень давно) решает все аналогичные задачи?
НЛО прилетело и опубликовало эту надпись здесь

Автор ALight обещал в скором времени поправить. Когда работал — показывал существенно меньшее время, чем Angular.

Там использован development build React'а с проверками и варнингами. Причём только реакта, остальные библиотеки там минифицированные. Интересно, это ошибка или попытка смухлевать?..

Поправил.

Поздравляю, такую задачу осилили.
Вообще, имхо, муки оценок и выбора — это, наверное, самое тяжелое, что есть в профессии. И с каждым годом все тяжелее — писателей не остановишь. И внятных оценок на эту тему — единицы
Нет, самое сложное в докладе не освещено — это как я все это дело задвигал и «продавал» сотоварищи соседним отделам, подчиненным и начальству. :-)
https://hsto.org/getpro/habr/post_images/5f1/038/58b/5f103858bcd821c2a9823932a0d781a8.png
НЛО прилетело и опубликовало эту надпись здесь
Вы статью вообще читали?
НЛО прилетело и опубликовало эту надпись здесь
И каким же, позвольте спросить, местом вы читали? Уж не глазами это точно.

Забегая вперед — фреймворк, который мы написали, основан сильно на интерфейсах

Напишем задачу сами себе.… И при этом еще так, чтобы это все дело не было монолитным фреймворком

Мы в итоге взяли фреймворк, который называется Este.js.… Плавно переписывали, пока от него не осталось вообще ничего.

Вот такой мы написали свой собственный парсер этих шаблонов

Для переводов мы сделали штучку

Получился фреймворк с хорошим ООП и с маленьким интерфейсом, с дженериками, близко похожий на то, как это было написано на java.
НЛО прилетело и опубликовало эту надпись здесь
«Не стоит спорить со свиньей. Оба вываляетесь в грязи, но ей это понравится.»
Спорить с вами больше не буду. Вам видимо ОЧЕНЬ нравиться.
НЛО прилетело и опубликовало эту надпись здесь
И в итоге все равно все это было задвинуто в 2016-м когда появился стабильный Angular 2.
Как я и писал выше — количество самодельных вещей всегда должно регулироваться наличием ресурсов у команды на их поддержку и развитие.
НЛО прилетело и опубликовало эту надпись здесь
Читал про ExtJs и во всё прям узнавал свою ситуацию, согласен с каждым пунктом по нему. Я тут тоже недавно для руководства писал небольшое техническое ревью по ExtJs 4, с целью убедить его в необходимости перехода на другую технологию. Многие пункты этого ревью пересекаются с вашими, можно сами почитать и добавлять комментарии в нём прям — техническое ревью по ExtJs 4
Вызовы Ajax запросов генерируются фреймворком, на основании заранее декларированных моделей, такой механизм взаимодействия приводит к:
•Снижению гибкости взаимодействия с сервером ( запросы должны укладываться в рамки текущих клиент-серверных сущностей )

А почему Вы посчитали это недостатком?
Не могли бы Вы привести пример когда запрос может не на основе заранее задекларированных моделей?


Вопрос… просто для саморазвития. Если не лень рассказать.


Со всем остальным согласен (су учетом описанных условий)

Эта проблема по большей части связана с неграмотно написанным кодом компонентов приложения, который был написан ещё до моего прихода в проект. Дело в том что на некоторых страницах запросы к серверу были навешаны на разные неочевидные события и вызывались по 2-3 раза без надобности, распутать этот клубок вызовов довольно непростая задача, особенно сложно дебажить вызовы fireevent.

А… Понятно.
Но тогда это скорее проблема не фреймворка, а проблема изначального проектирования или навешанных потом кучи "технических долгов", которые никто не любит "платить".


Это, к сожалению, ни от фрейма, ни от языка программирования, ни от прочих "магических палочек" не зависит. Сменить фреймворк/переписать код предшественников — это типичное желание при приходе в новый проект.

НЛО прилетело и опубликовало эту надпись здесь

Я под заранее декларированной моделью считал и эти случаи то же (данные исходя из логики приложения и здравого смысла).
А, если у кого то гоняются, например, все данные вместо ID, и это сильно сказывается на производительности/безопасности, то это ошибка проектирования.


Но мне казалось, что не настолько уж фреймворк(и) ограничивает выбор какие данные будут гонятся между клиентов и сервером и состав этих данных. (могу и ошибаться… мало ли..)


В общем, мне кажется, нет смысла спорить на абстрактных примерах.
На работе споров по подобным тонкостям архитектур и на вполне конкретных примерах хватает.

НЛО прилетело и опубликовало эту надпись здесь
не согласен
безопасность: ага весело… представим что одним из полей объекта является ваша приватная информация (номер паспорта например)… и выбрав нужную персону вы будете гнать ее со всеми приватными данными в сервис которому нужен только обезличенный айди? например даже находящийся физически в другом ЦОД.

С кем конкретно Вы спорите то?
Сами же процитировали мою фразу: "А, если у кого то гоняются, например, все данные вместо ID, и это сильно сказывается на производительности/безопасности, то это ошибка проектирования"
И тут же "не согласен… выбрав нужную персону вы будете гнать ее со всеми приватными данными в сервис которому нужен только обезличенный айди".


Я как раз ЭТО же и написал, что Вы более подробно изложили. Что неправильно гонять все данные…
Так что я с Вами согласен и предмета спора вообще не вижу.

Посмотрел, очень похоже на внутренние документы которые я делал.
Много людей после доклада подходили и говорили «во, знакомо до зубовного скрежета, у нас также итд итп»
НЛО прилетело и опубликовало эту надпись здесь
Вот да, тоже было интересно, услышать (прочесть) аргументы против ember.
НЛО прилетело и опубликовало эту надпись здесь
Честое слово, это всё всё равно вкусовщина, но основных причин было три:
  1. Крайне редко бывают вещи в которых я не могу разобраться за день — и это был именно такой случай — трудно понять быстро с высоты птичьего полета как что работает, и как сделать быстро какое-нть тестовое одностраничное приложение
  2. Никто из команды ничего про него не знал, и энтузиазмом изучать не горел
  3. Шаблонизатор был так себе — как делать анимации или локализацию было непонятно

НЛО прилетело и опубликовало эту надпись здесь
Был опыт написания проекта на ember. Даже двух. По масштабам – по ~10-15 человек на каждом проекте. Больше года. С версии 1.7 до 2.6
Что понравилось:
– как адепт RoR, с ходу проникся Convention over Configuration;
– можно было без особого труда давать 5-6 человекам разные таски и сильно не беспокоиться о том, как же все это будет мерджиться, заслуга архитектуры.
– довольно удачные идеи с компонентами, а как перешли на htmlbars с handlebars стало действительно круто
– glimmer
– ember-cli, действительно удобно, с ходу получить какой-то скаффолд для кода и тестов для него, вся сборка, запуск тестов фактически из коробки
– несколько повторяясь, архитектура: если понимаешь, что нужно выносить в сервис, что есть instance initializer, а что просто initializer — все будет в ажуре

Что сложно:
– были проблемы с пониманием ember way в команде. Решалось тяжело, иногда с ошибками, но результатом довольны. В этом плане на angular 1 было проще.
– изменения в api фреймворка. Сделал так, а через версию это стало deprecated. Сильно помогло чтение ember discuss и обсуждений на гитхабе. Ну и вычитывание rfc-шек. Лишь после этого появилось понимание куда все движется и что есть действительно правильно. Стало легко писать код, который не будет сыпать депрекейшенами после обновлений ember'а.
– часть команды воспринимала фреймворк в штыки (почему то это были питонисты)
– ember-data — по мне, это какое-то недоразумение. С простым CRUD все круто, но все начинает идти совсем не туда, когда начинаешь работать с вложенным сущностями.

До этого был опыт с backbonejs, marionette, angularjs. После – react/flux/redux.
На angularjs каждая команда создавала свой локальный ад. На бекбоне – изобретала свое колесо. На Ember — просто следуй за кроликом.
Если нужно будет сделать быстро SPA, не особо думая о размере кода на выходе, и это что-то будет crud'о подобное а-ля админка, то я выберу Ember не задумываясь. Моя эффективность на нем определенно выше.
НЛО прилетело и опубликовало эту надпись здесь
Автор вроде бы четко указал, что «всё водном» им избыточно. Хотят переиспользовать части/компоненты в разных проектах с разной сутью. Вон в ExtJS iframe-мом затолкали своё детище =)
НЛО прилетело и опубликовало эту надпись здесь
А автор не смотрел в сторону Google Closure (не путать с Clojure)?
Года три назад написали свой простенький фреймворк на основе имеющейся либы, полет нормальный.
Знал про него, но сильно не смотрел ввиду малой популярности. Этот вопрос был весьма важен для нас.
Все про производительность команды правильно сказано.

Про React + Flux тоже отлично!

Почему ничего не сказано про Immutable Persistent Data Structures в JS? Это же топик про производительность в фронтенде!

Мы долго пытались жить с immutable.js, но в итоге это был оверкилл, вместо него сформировали одно простое правило — не изменять данные во View-слое, и immutable.js был смело выпилен.
Разверните пожалуйста, в чём были сложности с immutable.js?

В моём проекте на моём собственном рендер движке и Redux я столкнулся с жуткими тормозами без immutable reconciliation.

Сейчас переписываю рендер движок на immutable.js полностью, и мне интересно с какими проблемами я могу столкнуться.
PS. меня в Immutable Persistent Data Structures больше интересует Persistent чем Immutable.
Дело не в тормозах, каких-то диких сложностей не было, просто код разрастался, синтаксис этот специфичный итд
С immutable.js нафиг не нужен Lodash для работы с данными
С самого начала чтения поста хочется сказать автору: Что-то не так с процессом разработки!

Но когда автор взял бразды правления по ходу доклада, то ещё раз понимаешь, что меняется в первую очередь именно процесс разработки. Фреймвоки не причём.

Поздравляю. Наконец-то занялись правильной разработкой. Почти закончились стоны по круглым коням и ножной разработке. Впрочем по круглым коням нет. Чувствуется не понимание нахождения в сансаре.

Вижу в организации возникли приоритеты и понимание своих требований. Отошли от сбрасывание задач на не компетентных менеджеров, которым всё одно кто и на чём делает фитчи. Понятно — кризис. Издержки. Пора улучшать процесс. Убирать лишние тела из него, а с ними и сокращать зоопарк на других уровнях.

Лучше показать одного раскрученного тигра и козла, так как их легче кормить. Раньше кормили ещё чебурашек плюшевых разных цветов еврами, а они могут съесть сколь угодно, так как не они едят, а через них.

Техническая часть решения всё же не раскрыта. Впрочем не в контексте. а попытка смазана.

Да. Спасибо за качество изложения мыслей, ибо не маркетинговый шлак, а скорее стон от лица потерпевшего. Что воспринимается легко и радостно, так как если где и зацепило, но не твоя боль.

:)
Цитата:
«Очень хочется, чтобы мы, наконец-то, могли подключить нормального верстальщика и нанять разработчика с меньшей зарплатой ...»
Ну очень хочется! :)
P.S. Цель — всё же, оптимизация «накладных расходов» под благие цели?
Нет, цель экономии была, но совершенно в другом — перестать параллельно разрабатывать на зоопарке технологий, т.к. это постоянно жрало кучу ресурсов у каждого отдела в отдельности, и при этом качественного скачка вида «вот эти трое делают ядро продукта, а эти трое — UI» быть не могло. Специализация, и более специлиализированные рзработчики, шаринг знаний, шаринг ресурсов — вот, что хотел менеджмент.
>Пора улучшать процесс. Убирать лишние тела из него, а с ними и сокращать зоопарк на других уровнях.

А как же микросервисы и зоопарк из сопутствующих технологий тому же Реакту? :)
CuTI
Есть ощущение, что докладчик имел в виду фреймворк Qt.

Еще RND и MVS (прям как «LSD-экран»). В общем, надо отдавать в редактуру технически подкованному человеку.

Конечно. Текст мне не прислали на вычитку =(
А мне backword понравилось! :)
НЛО прилетело и опубликовало эту надпись здесь

А что в принципе можэно сделать, кроме добавления еще одной кнопки — чтобы не порушить существующий опыт пользователей по взаимодействию с системой?


Или предлагаете делать как MS в своем офисе — вот вам лента и идите на хрен?

НЛО прилетело и опубликовало эту надпись здесь
а в опен сорс что-нибудь пойдет?
Честно говоря маловероятно, т.к. внутрення тулза и опенсор-продукт — разные вещи по степени приложения усилий.
Щас пилим активно Angular 2 вместо React.
Т.е. в итоге все-таки к Angular2 пришли? Расскажете об этом?
В итоге да, но проект уже курирует другой человек, а мне приходится помогать с более сложной задачей.

Можно попробовать позвать его что-нть рассказать.
Прошу прощение, но не менее странно сравнивать ExtJs 4 (и ниже) версий с более новой версией. Скажу честно — уже 6 лет работаю с ExtJs и все эти проблемы очень быстро становяться плюсами. Ведь главное уметь «готовить» то, что уже имеешь.
Sencha пару лет назад выпустила 5 и 6 версию данного framework. И все координально изменилось. Подход к работе, принципы — все. Да, остался MVC, но уже есть и MVVM. Добавили two-way data binding. Я когда начал смотреть Angular и другие проекты удивлялся, почему нет таких простых возможностей, а в ExtJs они есть. Куча реализаций store (возможность работы с данными), как ajax, так и rest, причем с уже готовыми компонентами. Сел, включил, написал, забыл.
Да, конечно, не стоит забывать о его «огромности» и не всегда хороших подходах. Но для корпоративного сегмента рынка, для приложений, которые пользователь «открыл и забыл» — вполне годная вещица. Но не стоит злоупотреблять, конечно же.
Большинство технологий не умирает, а становится «нишевыми».

image
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

А поделитесь парсером html+mustche в react? Было бы очень полезная тулза.

напиши в личку или на мыло
Не рассматривали Dojo 2? Ну так, в качестве альтернативы? Просто мы используем Dojo около 2х лет, и проблем с пониманием его верстальщиками, программистами, дизайнерами не наблюдалось. Да он не поворотлив в основе, но для «жирного ынтерпрайза» вполне заходит. В основном из-за своего представления ООП в JS. Оно сразу понятно backend разработчикам. Правда если ты, в принципе, не знаком с JS будь готов выстрелить себе в ногу из-за не понимания того, что никакого ООП в JS нет.
сильно не рассматривали, т.к. не было стабильной версии, и популярность была около нуля. И никто из нас про него и не слышал особо.
Ребята, мы ищем программиста-разработчика в управление перспективных разработок.
Начинающего.
Компания — крупнейший российский регистратор АО «Регистратор Р.О.С.Т.»
Функционал:
проектирование и разработка web-приложений;
разработка и поддержка клиентской и серверной части корпоративной информационной системы;
интеграции с поставщиками услуг (SOAP, REST);
доработка чужого исходного кода;
разработка на основе требований заказчика;
командная работа совместно с другими разработчиками и заказчиком.
Требования:
высшее образование / студент старших курсов;
понимание технической документации по программированию на английском языке;
знание Java, SQL;
готовность к поддержке и модернизации программного обеспечения на Java;
желание совершенствоваться в области разработки корпоративных приложений и их интеграции.
Приветствуем:
знания в области технологий и фреймворков Java: Spring, Hibernate, SpringBoot, Servlets, JDBC;
опыт работы с JavaScript, AngularJS;
знание HTML и CSS;
опыт работы с PostgreSQL;
опыт работы с Git.
Возможности:
работа в крупной стабильной компании;
интересные и разноплановые задачи;
медицинская страховка после определенного стажа работы;
ежегодный оплачиваемый отпуск, полное соблюдение ТК;
опытные программисты в дружном коллективе помогут профессионально расти и развиваться (и будут рады поучиться у вас);
офис м. Сокольники.
Если у кого-то есть знакомые перспективные и талантливые, wellcome! На сайте компании есть адрес и телефон.
НЛО прилетело и опубликовало эту надпись здесь
Не будьте так строги, это же крик отчаяния. Посмотрите на требования к начинающему программисту. Ёлки-палки, он ещё и опытных кодеров должен чему-то учить. На хедхантере таких точно нет.
Начинающего

знание Java(Spring, Hibernate, SpringBoot, Servlets, JDBC), SQL, PostgreSQL, JavaScript, AngularJS

Начинающего

Что-то уровня этого
А что скажите про SmartClient?
не слышал ни разу
выглядит очень и очень не плохо: демо
Те же проблемы, что и у ExtJS. Все элементы реализованы через position: absolute, пересчет размеров через JS, неоптимальная генерация DOM. Сорри, за некропост)
Отлично написали, спасибо!
В итоге я насчитал, что у нас есть java-люди, ruby-люди, python-люди и php-люди, которые все делают фронтенд. И при этом в компании нет верстальщика, ни одного.


<troll-mod>и эти люди потом кричат что js плохой, может проблема не в языке, а в прослойке между стулом и клавиатурой</troll-mod>
Искали фреймворк, на котором все пишут, чтобы сотрудников легко находить, ведь не в космосе. Нашли Angular, все шикарно, но вот не задача: UI нет… Поэтому решили свой фреймворк написать.

Будь вашим руководителем, то я бы вас уволил.
А в мордокниге написали. :)
Да и куча их появилась в последнее время. Их же кто-то написал. Или их написали идиоты, которых потом уволили за это? :)
В мордокниге ущербные руководители, в отличие от Duke565
И сама мордокнига недостойна чтобы он был там руководителем, не тот у них уровень
Хорошая статья, очень понравился подход к сравнению и выбору инструмента исходя из задач и текущей ситуации. Однако, очень удивляет, что нет ни слова про особенности лицензии на React. (Грубо говоря, Facebook оставляет за собой право отозвать вашу лицензию, если решит, что вы с ними конкурируете. Более подробно здесь.)

Вы сознательно решили, что для Acronis это не актуально или просто предпочли проигнорировать этот момент?
В итоги они выбрали Angular2
https://habrahabr.ru/company/oleg-bunin/blog/311096/#comment_9829536
В конце 2015 года я оказался в сходной ситуации, и так же исследовал рынок фронтенд фреймворков и тренды, точно так же пришел к выводу, что оптимум на ближайшую перспективу только реакт.

Пробовали ли Вы Redux? А Relay+GraphQL?
Судя по тесту статьи тогда Redux ещё не изобрели.

А сейчас их наверное это мало трогает — они пилят код уже на Angular2:

https://habrahabr.ru/company/oleg-bunin/blog/311096/#comment_9829536
Да, на Redux запиливал тестовый проект.
Для сложных приложений, с болшим кол-вом вложенных экранов Redux не подходит.
Он очень прост, и специально упрощен, сделать ну хоть какую-то динамику (например, открытие вспылвающих окон с частями приложения) было очень сложно. Основная беда для большого приложения как раз в том, что все данные в одно месте, и работать с огромной «елкой» данных очень неудобно.
Интересно было прочитать. Нахожусь в похожей ситуации. Зоопарк проектов и даже Ext4 есть :) Только в своей команде я остался один :(
Вы не одиноки в своём состояния одиночества в команде! ;-)

Где зоопарк технологий в проекте просто поражает то!
Возможно это слишком по-капитански, но аргументы о «нетестируемости» flux архитектуры сейчас уже неактуальны, особенно с появлением redux'a (https://github.com/reactjs/redux — первый релиз кстати в августе 2015го). Там конечно сейчас свои заморочки, но тестирование чистых функций, коими являются reducer'ы, не является чем-то сверхсложым
Судить о том, что нет проблем в огромной сложной области исходя из того, что есть один подход к тестированию одного конкретного фреймворка мягко говоря наивно.
Попробуйте запилить действительно большой проект с Redux, возможно вы поймете, что это очень нишевый фреймворк.

Мы для React разрабатывали параллельно аж три разных вида тестов.
Статья напомнила мне, когда сами стояли перед выбором больше трех лет назад, над выбором фреймворка для проекта. Отдали тогда предпочтение ангуляру. Тогда еще была версия 1.1 или 1.2. Уже не помню. Суть была такова — Вау! Датабиндинги! И гугл поддерживает! И комьюнити! И вообще стильно модно молодежно!

Да проводили анализы, сравнивали итд. Выбрали ангуляр. А потом, к сожалению, хлебнули проблем по полной.

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

Для себя юзаю пока backbone. А дальше видно будет. Может попробуем React.
Мне кажется, что заново изобретают Дельфи, только на скрипте.
Переизобретается всё. ;-)

Мне JSX напоминает, например, JSP.

Если в JSP происходит компиляция JSP-страницы в сервлет (java-код), то в JSX происходит компиляция в Javasript-код.

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

В том что у вас получилась мешанина кода, необязательно виноват JSX.


можно собрать html-конструкции в одной или нескольких функциях, которые вызывать в render.

Культура написания кода во многом определяет результат.
Если предлагается делать плохо — большинство сделает плохо.

покажите, где именно в документации React предлагается сделать плохо

>Если предлагается делать плохо — большинство сделает плохо.

Верно. Но если появились паттерны делать хорошо — то все будут делать хорошо. ;-)
Боюсь вы заблуждаетесь.

Не раз наблюдал картину, когда и паттерны хорошие, и принципы установлены, и тренинги проведены. А нет! Таки говнокодят.

Мне кажется, здесь больше будет влиять личный опыт, само-ответственность за проект и код, собственный перфекционизм.

PS прошу прощения, что встрял в вашу дискуссию.
>Не раз наблюдал картину, когда и паттерны хорошие, и принципы установлены, и тренинги проведены. А нет! Таки говнокодят.

Это иное.

Я отвечал на «Если предлагается делать плохо — большинство сделает плохо.»
А у вас посыл типа «Если предлагают делать хорошо, они САМИ придумывают как сделать плохо».

Тут есть разница — одно дело «предложить сделать плохо» (то, что плохо, выясняется уже потом, вначале то типа предлагается это сделать либо как «хороший паттерн», либо как «поясняющий паттерн» который все начинают копировать — копи-пастой заниматься).

Именно на это я и ответил: «если появились паттерны делать хорошо — то все будут делать хорошо. „

А вот, “наплевать на всё» и сделать по своему — как на душе лежит — это уже из другой оперы «навык». ;-)
Да, спасибо за пояснение :-)
https://github.com/primefaces/primeng/blob/master/components/autocomplete/autocomplete.ts
vs
https://github.com/reactjs/react-autocomplete/blob/master/lib/Autocomplete.js

Неужели вот этот дикий шаблон в a2 правда лучше того, что в react?

>Неужели вот этот дикий шаблон в a2 правда лучше того, что в react?

Я думаю, что он скажет — да! Имхо.

Ибо в autocomplete.ts, в этом «ужасном» шаблоне в начале кода, он ВИДИТ в этом шаблоне уже типа html код страницы (ну, «грязноват», но намётанный его глаз то заменит все эти ангрулярские теги и в голове станет ясный образ html). — Ибо человек за 2 недели, а уж за 2 месяца, ко всему может адаптироваться.

Даже к ангуляровскому шаблону. ;-)
В React варианте там очень элегантно сделали render элементов списка. Просто автокомплиту передаётся параметр renderItem, который является функцией, которая возвращает разметку для элемента. По-моему гораздо лучше и очевидней чем <template>.
А все эти тонкости когда у нас иногда [propertyName]=«propertyValue», а иногда [attr.propertyName]=«propertyValue»?
А фишки типа <p-column [field]=«myprop»/> когда myprop=«my.cool.id.with.dots» и это всё ломает, т.к. field-то строка, а компонент-то хочет сделать из неё путь до property какого-то вложенного объекта потому что нельзя передать туда функцию getter? Не уверен, что нельзя, скорее всего можно, но так никто не делает — не принято.
Это то, с чем я столкнулся буквально за первые пару недель копания с Angular 2 т.к. компания выбрала его, а не React, как раз из-за «ну это же framework, это же от Google!»

Оба варианта плохи по своему. В одном варианте — шаблон замусорен кучей логики. В другом — раскидан по всему коду, из-за чего его фиг найдёшь концы.


Для сравнения, шаблон на view.tree:


$mol_suggester $mol_viewer
    suggests /
    event * keydown > eventPress null
    > selectedRow 0
    rower# $mol_suggester_rower
        text < suggest# \
        prefix < value
        eventSelected > eventRowerSelected# null
        selected < selected# false
    childs /
        < stringer $mol_stringer
            value > value \
            hint < hint \
        < lister $mol_lister
            heightMinimal 0
            childs < suggestRows /

$mol_suggester_rower $mol_clicker
    tagName \div
    event * mousedown > eventSelected null
    attr * mol_suggester_selected < selected false
    heightMinimal 36
    childs /
        < dimmer $mol_dimmer
            haystack < text \
            needle < prefix \

Суммарно вместе с логикой — всего 100 строк.

Не-не-не… Ну чесслово, если angular и react еще выглядят хоть как-то понятно, то вот это очень похоже на язык K. :)

Это лишь с непривычки. Всё, что тут есть — это наследование, перегрузка свойств и биндинги.

>Это лишь с непривычки…

Вот это верно. Человек за пару месяцев ко всему привыкает. ;-)

И это проблема. Привычки мешают оценивать инструмент объективно.

>И это проблема. Привычки мешают оценивать инструмент объективно.

Верно и это. Мало революций в современном мире JavaScript.

;-)
Есть и проект такого «Фреймворка» на JavaScript из поднебесной.

https://github.com/hcchengithub/jeforth.3we

Правда непонятно, но примеры со страницы перестали нормально запускались в браузере. Может пути к файлам нарушились.

P.S. https://github.com/substack/stream-handbook тоже из этого направления.
В природе можно найти ещё вариаты, но насколько это революционно не могу представить.
Если мои привычки характерны для индустрии в целом, например, писать html разметку на html или на чем-то очень на него похожем, то мои привычки помогают оценивать сложность входа в технологию более-менее объективно :)

Если бы вы писали HTML, то я бы с вами согласился. Но просто HTML уже почти никто не пишет. Все пишут приложения, компоненты. Так вот, есть более подходящие DSL-и для написания приложений, не мимикрирующие под HTML. Ещё раз: задача создать поддерживаемое приложение, а не запилить html разметку. На HTML удобно делать монолиты, но он не поддерживает переиспользование кода. Поэтому и появляются костыли в духе JSX и WebComponents.

Переучивание верстальщика murkup-developer'а под синтаксически не HTML-подобный DSL занимает значительно больше времени чем под HTML-подобный. Если вообще завершается успехом. А если решаем, что пускай они делают чистый HTML, а мы будем его «натягивать», то «трансляция» (головой и руками) занимает больше времени для синтаксически не HTML-подобных DSL, равно как и усложняется локализация мест применения патчей. С HTML-подобными DSL верстальщика можно пустить непосредственно в шаблоны приложения/компоненты, объяснив ему лишь несколько простых правил, а с не подобными создание и поддержка приложения/компонента требует более квалифицированных специалистов (читай — стоит дороже).
объяснив ему лишь несколько простых правил

Ключевой момент. Обучить view.tree можно объяснив несколько простых правил. Причём на выходе будет результат более высокого качества, который не нужно "натягивать".

Сравним количество и сложность правил с, например, React?

Давайте:


  1. Чтобы передать компоненте параметр нужно объявить его в props.
  2. Чтобы использовать какое-то состояние нужно объявить его в state.
  3. Отдельно нужно задать создание значений по умолчанию для props и state.
  4. Чтобы задать атрибут не предусмотренный реактом для данного типа элемента… даже не знаю как.
  5. Чтобы передать значение нужно вместо кавычек использовать фигурные скобки.
  6. Если выводится список, то заблаговременно для каждого элемента нужно задать параметр "key".
  7. Всем элементам нужно проставлять классы, чтобы их можно было стилизовать.
  8. Нужно не забывать прокидывать в каждый элемент дополнительные классы, чтобы можно было стилизовать в зависимости от контекста (БЭМ и всё такое).
  9. Для локализации необходимо вставлять получение значения по ключу, при этом не забыв реализовать контекстную перегрузку этого значения.
  10. Чтобы передать список компонент нужно написать фигурные скобки, внутри них квадратные, внутри которых угловые. Но это уже скорее курьёз.
>Чтобы передать список компонент нужно написать фигурные скобки, внутри них квадратные, внутри которых угловые. Но это уже скорее курьёз.

Почему курьёз?

— фигурные скобки — означает что передаём ОБЪЕКТ.
— внутри них квадратные — означает что это будет список в виде массива.
— внутри которых угловые. — это означает что элемент массива будет КОМПОНЕНТ.

Всё логично. (С)

Не объект, а интерполяция.

Или вот:
<thead>
                        <tr *ngIf="!headerRows" class="ui-state-default">
                            <th #headerCell *ngFor="let col of columns;let lastCol = last" [ngStyle]="col.style" [class]="col.styleClass" [style.display]="col.hidden ? 'none' : 'table-cell'"
                                (click)="sort($event,col)" (mouseenter)="hoveredHeader = $event.target" (mouseleave)="hoveredHeader = null"
                                [ngClass]="{'ui-state-default ui-unselectable-text':true, 'ui-state-hover': headerCell === hoveredHeader && col.sortable,'ui-state-focus': headerCell === focusedHeader && col.sortable,
                                'ui-sortable-column': col.sortable,'ui-state-active': isSorted(col), 'ui-resizable-column': resizableColumns,'ui-selection-column':col.selectionMode}" 
                                [draggable]="reorderableColumns" (dragstart)="onColumnDragStart($event)" (dragover)="onColumnDragover($event)" (dragleave)="onColumnDragleave($event)" (drop)="onColumnDrop($event)"
                                [tabindex]="col.sortable ? tabindex : -1" (focus)="focusedHeader=$event.target" (blur)="focusedHeader=null" (keydown)="onHeaderKeydown($event,col)">
                                <span class="ui-column-resizer" *ngIf="resizableColumns && ((columnResizeMode == 'fit' && !lastCol) || columnResizeMode == 'expand')" (mousedown)="initColumnResize($event)"></span>
                                <span class="ui-column-title" *ngIf="!col.selectionMode&&!col.headerTemplate">{{col.header}}</span>
                                <span class="ui-column-title" *ngIf="col.headerTemplate">
                                    <p-columnHeaderTemplateLoader [column]="col"></p-columnHeaderTemplateLoader>
                                </span>
                                <span class="ui-sortable-column-icon fa fa-fw fa-sort" *ngIf="col.sortable"
                                     [ngClass]="{'fa-sort-desc': (getSortOrder(col) == -1),'fa-sort-asc': (getSortOrder(col) == 1)}"></span>
                                <input type="text" pInputText class="ui-column-filter" *ngIf="col.filter" [value]="filters[col.field] ? filters[col.field].value : ''" (click)="onFilterInputClick($event)" (keyup)="onFilterKeyup($event.target.value, col.field, col.filterMatchMode)"/>
                                <p-dtCheckbox *ngIf="col.selectionMode=='multiple'" (onChange)="toggleRowsWithCheckbox($event)" [checked]="allSelected" [disabled]="isEmpty()"></p-dtCheckbox>
                            </th>
                        </tr>
                        <tr *ngFor="let headerRow of headerRows" class="ui-state-default">
                            <th #headerCell *ngFor="let col of headerRow.columns" [ngStyle]="col.style" [class]="col.styleClass" [attr.colspan]="col.colspan" [attr.rowspan]="col.rowspan"
                                (click)="sort($event,col)" (mouseenter)="hoveredHeader = $event.target" (mouseleave)="hoveredHeader = null" [style.display]="col.hidden ? 'none' : 'table-cell'"
                                [ngClass]="{'ui-state-default ui-unselectable-text':true, 'ui-state-hover': headerCell === hoveredHeader && col.sortable,
                                'ui-sortable-column': col.sortable,'ui-state-active': isSorted(col), 'ui-resizable-column': resizableColumns}"
                                [tabindex]="col.sortable ? tabindex : -1" (focus)="focusedHeader=$event.target" (blur)="focusedHeader=null" (keydown)="onHeaderKeydown($event,col)">
                                <span class="ui-column-resizer" *ngIf="resizableColumns && ((columnResizeMode == 'fit' && !lastCol) || columnResizeMode == 'expand')" (mousedown)="initColumnResize($event)"></span>
                                <span class="ui-column-title">{{col.header}}</span>
                                <span class="ui-sortable-column-icon fa fa-fw fa-sort" *ngIf="col.sortable"
                                     [ngClass]="{'fa-sort-desc': (getSortOrder(col) == -1),'fa-sort-asc': (getSortOrder(col) == 1)}"></span>
                                <input type="text" pInputText class="ui-column-filter" *ngIf="col.filter" [value]="filters[col.field] ? filters[col.field].value : ''" (click)="onFilterInputClick($event)" (keyup)="onFilterKeyup($event.target.value, col.field, col.filterMatchMode)"/>
                            </th>
                        </tr>
                    </thead>


Тут где-то 80% кода можно переиспользовать в обоих ветках, когда есть headerRows и когда нет. Если бы это был JSX, то можно было бы разбить этот шаблон на мелкие куски, положить их в переменные а потом собрать из них нужное.

<span class="ui-column-title" *ngIf="!col.selectionMode&&!col.headerTemplate">{{col.header}}</span>
                                <span class="ui-column-title" *ngIf="col.headerTemplate">
                                    <p-columnHeaderTemplateLoader [column]="col"></p-columnHeaderTemplateLoader>
                                </span>

заменяется на что-то вроде:


<span className="ui-column-title">
{col.headerTemplate && col.headerTemplate(col) || col.header}
</span>

т.к. headerTemplate у нас просто функция, которая возвращает разметку. Самая вкусная фишка JSX, в том, что это просто какой-то JSON объект, который можно положить в переменную, вернуть как результат вызова функции и т.д. Аналог ангуляровского <template>....</template> в react это просто React.cloneElement(myVariable,...)
А кто сказал что одно безаппеляционно лучше второго или наоборот?
Ну, по этим двух компонентам хорошо видно отличия в религии одного от второго фреймворка, если брать конкретно компненты, ReactJS, конечно, выглядит намного лучше, и я в целом ему отдаю предпочтение, но такого рода шаблоны

<span [ngClass]="{'ui-autocomplete ui-widget':true,'ui-autocomplete-dd':dropdown,'ui-autocomplete-multiple':multiple}" [ngStyle]="style" [class]="styleClass">
            <input *ngIf="!multiple" #in pInputText type="text" [ngStyle]="inputStyle" [class]="inputStyleClass" 
            [value]="value ? (field ? resolveFieldData(value)||value : value) : null" (input)="onInput($event)" (keydown)="onKeydown($event)" (blur)="onModelTouched()"
            [attr.placeholder]="placeholder" [attr.size]="size" [attr.maxlength]="maxlength" [attr.readonly]="readonly" [disabled]="disabled"
            [ngClass]="{'ui-autocomplete-input':true,'ui-autocomplete-dd-input':dropdown}"
            ><ul *ngIf="multiple" class="ui-autocomplete-multiple-container ui-widget ui-inputtext ui-state-default ui-corner-all" (click)="multiIn.focus()">
                <li #token *ngFor="let val of value" class="ui-autocomplete-token ui-state-highlight ui-corner-all">
                    <span class="ui-autocomplete-token-icon fa fa-fw fa-close" (click)="removeItem(token)"></span>
                    <span class="ui-autocomplete-token-label">{{field ? val[field] : val}}</span>
                </li>
                <li class="ui-autocomplete-input-token">
                    <input #multiIn type="text" pInputText (input)="onInput($event)" (keydown)="onKeydown($event)" (blur)="onModelTouched()">
                </li>
            </ul
            ><button type="button" pButton icon="fa-fw fa-caret-down" class="ui-autocomplete-dropdown" [disabled]="disabled"
                (click)="handleDropdownClick($event)" *ngIf="dropdown"></button>
            <div class="ui-autocomplete-panel ui-widget-content ui-corner-all ui-shadow" [style.display]="panelVisible ? 'block' : 'none'" [style.width]="'100%'" [style.max-height]="scrollHeight">
                <ul class="ui-autocomplete-items ui-autocomplete-list ui-widget-content ui-widget ui-corner-all ui-helper-reset">
                    <li *ngFor="let option of suggestions" [ngClass]="{'ui-autocomplete-list-item ui-corner-all':true,'ui-state-highlight':(highlightOption==option)}"
                        (mouseenter)="highlightOption=option" (mouseleave)="highlightOption=null" (click)="selectItem(option)">
                        <span *ngIf="!itemTemplate">{{field ? option[field] : option}}</span>
                        <template *ngIf="itemTemplate" [pTemplateWrapper]="itemTemplate" [item]="option"></template>
                    </li>
                </ul>
            </div>
        </span>


я имел удовольствие по нопытности и в JSX делать, все зависит от задачи и подкованности разработчика.

Если брать именно обычный какойнть сайт с обычным какимнть списком товаров на продажу, с анонсом цен и какихнть скидок, вполне подобный трудночитаемый мегашаблон и на JSX вероятен.
Это PrimeNG https://github.com/primefaces/primeng/tree/master/components/datatable/datatable.ts. Уже больше тысячи коммитов, я не думаю, что автор не разбирается в A2.

А вся эта возня с change detection в ngDoCheck? A2 же делает shallow compare, так что как только у нас компонент хочет на вход массив, приехали, делаем ручками проверку let changes = this.differ.diff(this.value); if(changes) {....}. А внутри у нас три списка added, removed, changed. По-мне так «А давайте просто перерисуем всё заново» c вкраплениями shouldComponentUpdate при необходимости, гораздо приятнее. А, да, и change detection у нас запускается еще чаще чем в A1, теперь и на каждый mouse move. Т.к. мы перехватываем через zone.js абсолютно все события браузера.

Простите, накипело :)
>Простите, накипело :)
>Это то, с чем я столкнулся буквально за первые пару недель копания с Angular 2 т.к. компания выбрала его, а не React

Ну, dema, приходится вам только посочувствовать.

Но, ничего — «стерпится-слюбится». Со временем привыкните, наверное, ко всему девелопер то привыкает, — а там глядишь через пару лет и «Лучшие практики на Англуляр-2» подоспеют. Эх.
>я имел удовольствие по нопытности и в JSX делать,

Да, но это похоже «стандарт Ангуляра», а не неопытность. ;-)

Поздравляю. Вы избавились от легаси :)

Я просто плакал:
«How it feels to learn JavaScript in 2016»

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f

"-Слушай, Это легко. Код все в машинописи. Все модули, использующие Fetch компилировать их целевому ES6, transpile их с Вавилонской на стадии 3-предустановки, и загружать их с SystemJS. Если вам не Fetch, polyfill его, или использовать Bluebird, запрос или AXIOS, и обрабатывать все ваши обещания с AWAIT.

У нас очень разные определения легко.



Я просто хочу, чтобы вернуться к бэкэндом. Я просто не могу справиться с этим много изменений и версий и изданий и компиляторы и transpilers. Сообщество JavaScript безумен, если он думает, что кто-то может идти в ногу с этим.

-Я слышу тебя. Вы должны попробовать сообщество Python тогда.

Зачем?

-Ever Слышал Python 3?"

И теперь в компании все пишут на Angular2?

Новые вещи — да, но приходится и поддерживать существующие, их плавно мигрируем, но медленно, т.к. проектов много и все они большей частью на ExtJS

Что-то не понимаю объективности такого решения. Какие критерии в итоге предъявило начальство, чтобы выбрать ангуляр2? У вас был эксперимент React vs Extjs, выбрали React. А делали потом эксперимент React vs Angular2? Есть чем поделиться?

Using Angular 2? Would you use it again?
2:56 AM — 22 Sep 2016

17% — Yes! Works well for me
23% — Switching to React
5% — Switching to another lib
55% — Haven't used ng2

853 votes • Final results

Using React? Would you use it again?
10:31 PM — 1 Oct 2016

56% — Yes! Works well for me
8% — Switching to Angular 2
4% — Switching to another lib
32% — Haven't used React

1,509 votes • Final results

«Angular 2 vs React: The Ultimate Dance Off»
https://medium.com/javascript-scene/angular-2-vs-react-the-ultimate-dance-off-60e7dfbc379c
Зарегистрируйтесь на Хабре , чтобы оставить комментарий