Comments 183
UFO just landed and posted this here
А можете хотя-бы кратко рассказать об их предназначениях?
Я вообще с web и в особенности js фреймворками дела не имел никогда, но интересно.
Я вообще с web и в особенности js фреймворками дела не имел никогда, но интересно.
А где вы увидели в статье сравнение jQuery и AngularJS как сущностей одного уровня? На картинке с лого что ли? Потому что в статье прямо сказано что jQuery не используется как фреймворк, а есть проект «на Ruby on Rails в которых jQuery просто переключает страницы или графики»
UFO just landed and posted this here
Это все равное не ортогональные вещи, насколько я понимаю вряд ли стали бы использовать на одной страничке и ExtJS и AngularJS, так что что-то одно выбрать надо.
Вполне реальная ситуация. Был большой проект на ExtJS 3, сделали новую версию на AngularJS. Пусть скакун и феррари, функции для клиента выполнают те же, хоть и по-разному.
Да, но это озвученных выводов не меняет, какими мы разными не были фреймворки, задачи, которые они решают. Все представлено выше.
Однако можно говорить и сравнивать:
— ExtJS-style
— jQuery-style
— AngularJS-style
Они сравнимы. Они оьличаются. Они плохо совместимы
— ExtJS-style
— jQuery-style
— AngularJS-style
Они сравнимы. Они оьличаются. Они плохо совместимы
Предназначение у них одно — облегчить (в широком смысле) фронт-енд разработку. Используются для этого разные концепции, способы, методы.
Все зависит от степени генерализации вопроса. С точки зрения владельцев бизнеса вопрос «на какой технологии делать веб-продукты компании, если наши программисты, в принципе, могут разобраться в любой из них?» вполне резонен и адекватен.
Особенно в нашем случае, когда UI-пакет ExtJS нам не очень-то подходил, т.к. дизайн и поведение UI-контролов у нас другие.
Задача любого фреймворка — в первую очередь упрощать жизнь разработчикам, делать работу более быстрой, простой, и менее бажной. И именно на вопрос — а как же будет лучше, купить станок или двуручной пилой мы и пытались разобраться.
Ведь в реальной жизни купить станок не всегда экономически выгоднее.
Особенно в нашем случае, когда UI-пакет ExtJS нам не очень-то подходил, т.к. дизайн и поведение UI-контролов у нас другие.
Задача любого фреймворка — в первую очередь упрощать жизнь разработчикам, делать работу более быстрой, простой, и менее бажной. И именно на вопрос — а как же будет лучше, купить станок или двуручной пилой мы и пытались разобраться.
Ведь в реальной жизни купить станок не всегда экономически выгоднее.
Я бы лучше выбрал jQuery + необходимые плагины, чем jQuery + плагины + ExtJS + AngularJS. И из последних будет использоваться 1.5%
нет, не разное. Это всё куски кода на яваскрипте, которые служат задаче реализации чего-то динамического на веб-страничке и сильно затягивающие в использование одного лишь себя.
Нельзя с комфортом использовать вместе ExtJS и Angular, или Angular и React. Надо выбрать что-то одно, поэтому выбирать надо.
Нельзя с комфортом использовать вместе ExtJS и Angular, или Angular и React. Надо выбрать что-то одно, поэтому выбирать надо.
ни разу ни js-скрипист, но статья затягивает, очень понравился стиль изложения.
Забавно что с момента написания статьи Angular 2 вполне себе релизнулся и имеет богатую документацию
Это наркотик. Да вам это нравится. Но со временем вы поймёте, что сидите на нём и не можете слезть, так как привыкание. А вот окружающий мир решает свои проблемы чаем или морфием, но только когда нужно.
Забегая вперед стоит сказать, что описываемая в докладе работа делалась в 2015-м, и сейчас, в 2016-м AngularJS2 получил богатую документацию, примеры, стал стабильным и т.д.
И в итоге, столкнувших с очередным набором проблем, которые нужно было решать руками, мы таки в итоге выбрали AngualrJS 2 вместо React'а, это было коллективное и сомысленное решение с идеей, что лучше пусть будет «потупее или позапутанней», но меньше собственного кода поддерживать и развивать, больше доков и примеров, проще и меньше учиться.
Хотя для Angular2 тоже пришлось придумать более стандартизованную архитектуру, и набор правил как можно и нельзя делать.
Сами по себе костыли и самоделки, которые действительно ускоряют разработку, сделанные с умом хороши, но в масштабах боьлшой компании всегда приходится находить баланс между своими и сторонними решениями, в условиях когда много сил на поддержку собственных выделять не получается.
И в итоге, столкнувших с очередным набором проблем, которые нужно было решать руками, мы таки в итоге выбрали AngualrJS 2 вместо React'а, это было коллективное и сомысленное решение с идеей, что лучше пусть будет «потупее или позапутанней», но меньше собственного кода поддерживать и развивать, больше доков и примеров, проще и меньше учиться.
Хотя для Angular2 тоже пришлось придумать более стандартизованную архитектуру, и набор правил как можно и нельзя делать.
Сами по себе костыли и самоделки, которые действительно ускоряют разработку, сделанные с умом хороши, но в масштабах боьлшой компании всегда приходится находить баланс между своими и сторонними решениями, в условиях когда много сил на поддержку собственных выделять не получается.
Думаю этим Вашим комментарием было бы неплохо закончить текст самой статьи.
Как анонс второй серии, например ;)
Как анонс второй серии, например ;)
А с Angular2 удалось добиться выполнения требований «менее связная архитектура», «чёткое разделение зон ответственности», «не являющийся всё-в-одном», а также удалось ли сохранить пункт в стратегии перехода «старый код не трогаем, новый встраиваем независимыми блоками»?
Может, есть какой-то «тестовый набросок» того, в каком виде у вас Angular2 применяется?
Также присоединяюсь к ораторам, просящим статью на эту тему.
Может, есть какой-то «тестовый набросок» того, в каком виде у вас Angular2 применяется?
Также присоединяюсь к ораторам, просящим статью на эту тему.
Это уже надо просить веб-команду написать вам ответ, щас попрошу, надеюсь, согласятся.
XEK
Забегая вперед стоит сказать, что описываемая в докладе работа делалась в 2015-м, и сейчас, в 2016-м AngularJS2 получил богатую документацию, примеры, стал стабильным и т.д.До сих пор так и остались на AngualrJS 2? И не… жалеете?
И в итоге, столкнувших с очередным набором проблем, которые нужно было решать руками, мы таки в итоге выбрали AngualrJS 2 вместо React'а, это было коллективное и сомысленное решение с идеей, что лучше пусть будет «потупее или позапутанней», но меньше собственного кода поддерживать и развивать, больше доков и примеров, проще и меньше учиться.
Извините, уточню на всякий случай. Вы представитель того же сообщества программистов, что автора статьи? И в конце концов, после того, как зарелизиля второй Ангуляр вы коллективно решили, что целесообразнее использовать его?
Я не понял. Я и есть автор доклада. Написал же, что в итоге поддерживать собственное решение занимало силы, и придумали, по сути, как сократить издержки, используя Angular2. Меньше самописных решений так.
Ой, прошу прощения. Смотрел автора статьи, а это olegbunin. Теперь понял, что автора доклада таки вы. Как-то получается, что заключение доклада — делайте всё своё, превозмогайте. А по итогу выяснилось, что по возможности ищите готовые решение, если они конечно есть. Я правильно понял?
Любой доклад не является руководством к действию, а лишь поводом к размышлению.
Готовое решение было выбрано коллегиально, уже большой командой, и оно тоже потребовало много изучения, допиливания, и переделки архитектуры. Так что просто кол-во костылей стало меньше, ибо саппортить их большое кол-во не очень хотелось.
С Angular2 мучений было еще больше, просто по итогу по совокупности факторов выбрали его.
Готовое решение было выбрано коллегиально, уже большой командой, и оно тоже потребовало много изучения, допиливания, и переделки архитектуры. Так что просто кол-во костылей стало меньше, ибо саппортить их большое кол-во не очень хотелось.
С Angular2 мучений было еще больше, просто по итогу по совокупности факторов выбрали его.
вот ты побольше расскажи про Angular2 пожалуйста.
Мы сделали свою админку на Angular, потом с неё ушли на React и сейчас я уже не уверен в адекватности этого выбора.
Мы сделали свою админку на Angular, потом с неё ушли на React и сейчас я уже не уверен в адекватности этого выбора.
Он релизнулся 1.5 недели назад, имея где-то 5 месяцов попыток, так что не забавно.
UFO just landed and posted this here
Между прочим, KnockoutJS — это не только реализация MVVM, но еще и реализация FRP, о чем почему-то постоянно забывают...
UFO just landed and posted this here
Нет, она не необходима. Множество реализаций MVVM, не являющихся реализациями FRP — тому пример.
UFO just landed and posted this here
Зато есть множество тех, кто не использует реактивные возможности Knockout, работая с ним исключительно как с MVVM-библиотекой. (А после этого приходит к выводу, что Angular удобнее)
Я запилил на похожем подходе сборщик, который автоматически отлеживает изменения в исходниках и пересобирает лишь зависящие от изменившихся исходников бандлы. Надеюсь вы не будете высасывать тут из пальца MVVM? :-)
UFO just landed and posted this here
какое это отношение имеет к реактивному программированию?
Прямое.
к knockout
Почти тот же принцип работы. Каждая задача сборщика — это computed со всеми вытекающими (автоматическое построение дерева зависимостей, автоматическая инвалидация неактуальных зависимостей и тд).
и MVVM?
Очевидно, никакого.
месье знает толк в извращениях ))
Получилось довольно элегантно, на самом деле. Если вы прочитали какой-то конфиг при генерации бандла (например, tsconfig.json), то после изменения конфига получите свежий бандл, без ручного написания вотчеров.
UFO just landed and posted this here
Knockout UI library — плохо… React тоже UI library c ваших слов — но это хорошо. В чем же тогда по-вашему разница между феймворком и библиотекой?
То, что это фрейворк или UI-библиотека — не имеет отношения к «понравилось» или «не понравилось».
Я в самом начале доклада написал, что не буду подробно останавливаться на том, почему не подошло, потому что это будет война религий и закидают помидорами.
Одним из важных моментов был тот, что технология не популярна.
Фактически кодер может лепить html почти также как статику, притом добавить байндинг разработчику несложно и позднее и кодеру этот байндинг не мешает во время последующего редактирования.
На текущий момент звезды сложились так, что верстальщика и не появилось, верстает самый опытный в этом чел из команды, и он же и пишет код для UI-виджетов, с которыми работает эта верстка.
А html темплейт в JS-коде в React приложениях меня например как-то удручает…
Меня он удручает еще больше, про это в докладе много рассказано. Как могли, боролись с этим, но партизаны там толстые, особенно с переводами и окончаниями фраз содержащих пол или число.
Angular будет вечно пытаться заткнуть магией недостатки JS и DOM.
Это тоже меня сильно расстраивает, т.к. в версии 2 появилась еще самодельная реализация Shadow DOM, и с CSS это дает кучу геморроя. Внятного способа создать застилизировать вложенный компонент из родительского так и нет. В общем, костылей стало больше.
Искал в коментах защитника нокаута и нашел. Значит я не один считаю, что все эти реакты и ангуляры — это почти всегда жуткий оверкилл и нокаут прекрасно (и очень давно) решает все аналогичные задачи?
Нокаут очень не быстро это делает: https://eigenmethod.github.io/mol/perf/render/
Поздравляю, такую задачу осилили.
Вообще, имхо, муки оценок и выбора — это, наверное, самое тяжелое, что есть в профессии. И с каждым годом все тяжелее — писателей не остановишь. И внятных оценок на эту тему — единицы
Вообще, имхо, муки оценок и выбора — это, наверное, самое тяжелое, что есть в профессии. И с каждым годом все тяжелее — писателей не остановишь. И внятных оценок на эту тему — единицы
https://hsto.org/getpro/habr/post_images/5f1/038/58b/5f103858bcd821c2a9823932a0d781a8.png
UFO just landed and posted this here
Вы статью вообще читали?
UFO just landed and posted this here
И каким же, позвольте спросить, местом вы читали? Уж не глазами это точно.
Забегая вперед — фреймворк, который мы написали, основан сильно на интерфейсах
Напишем задачу сами себе.… И при этом еще так, чтобы это все дело не было монолитным фреймворком
Мы в итоге взяли фреймворк, который называется Este.js.… Плавно переписывали, пока от него не осталось вообще ничего.
Вот такой мы написали свой собственный парсер этих шаблонов
Для переводов мы сделали штучку
Получился фреймворк с хорошим ООП и с маленьким интерфейсом, с дженериками, близко похожий на то, как это было написано на java.
UFO just landed and posted this here
Читал про ExtJs и во всё прям узнавал свою ситуацию, согласен с каждым пунктом по нему. Я тут тоже недавно для руководства писал небольшое техническое ревью по ExtJs 4, с целью убедить его в необходимости перехода на другую технологию. Многие пункты этого ревью пересекаются с вашими, можно сами почитать и добавлять комментарии в нём прям — техническое ревью по ExtJs 4
Вызовы Ajax запросов генерируются фреймворком, на основании заранее декларированных моделей, такой механизм взаимодействия приводит к:
•Снижению гибкости взаимодействия с сервером ( запросы должны укладываться в рамки текущих клиент-серверных сущностей )
А почему Вы посчитали это недостатком?
Не могли бы Вы привести пример когда запрос может не на основе заранее задекларированных моделей?
Вопрос… просто для саморазвития. Если не лень рассказать.
Со всем остальным согласен (су учетом описанных условий)
Эта проблема по большей части связана с неграмотно написанным кодом компонентов приложения, который был написан ещё до моего прихода в проект. Дело в том что на некоторых страницах запросы к серверу были навешаны на разные неочевидные события и вызывались по 2-3 раза без надобности, распутать этот клубок вызовов довольно непростая задача, особенно сложно дебажить вызовы fireevent.
А… Понятно.
Но тогда это скорее проблема не фреймворка, а проблема изначального проектирования или навешанных потом кучи "технических долгов", которые никто не любит "платить".
Это, к сожалению, ни от фрейма, ни от языка программирования, ни от прочих "магических палочек" не зависит. Сменить фреймворк/переписать код предшественников — это типичное желание при приходе в новый проект.
UFO just landed and posted this here
Я под заранее декларированной моделью считал и эти случаи то же (данные исходя из логики приложения и здравого смысла).
А, если у кого то гоняются, например, все данные вместо ID, и это сильно сказывается на производительности/безопасности, то это ошибка проектирования.
Но мне казалось, что не настолько уж фреймворк(и) ограничивает выбор какие данные будут гонятся между клиентов и сервером и состав этих данных. (могу и ошибаться… мало ли..)
В общем, мне кажется, нет смысла спорить на абстрактных примерах.
На работе споров по подобным тонкостям архитектур и на вполне конкретных примерах хватает.
UFO just landed and posted this here
не согласен
безопасность: ага весело… представим что одним из полей объекта является ваша приватная информация (номер паспорта например)… и выбрав нужную персону вы будете гнать ее со всеми приватными данными в сервис которому нужен только обезличенный айди? например даже находящийся физически в другом ЦОД.
С кем конкретно Вы спорите то?
Сами же процитировали мою фразу: "А, если у кого то гоняются, например, все данные вместо ID, и это сильно сказывается на производительности/безопасности, то это ошибка проектирования"
И тут же "не согласен… выбрав нужную персону вы будете гнать ее со всеми приватными данными в сервис которому нужен только обезличенный айди".
Я как раз ЭТО же и написал, что Вы более подробно изложили. Что неправильно гонять все данные…
Так что я с Вами согласен и предмета спора вообще не вижу.
Посмотрел, очень похоже на внутренние документы которые я делал.
Много людей после доклада подходили и говорили «во, знакомо до зубовного скрежета, у нас также итд итп»
Много людей после доклада подходили и говорили «во, знакомо до зубовного скрежета, у нас также итд итп»
UFO just landed and posted this here
Вот да, тоже было интересно, услышать (прочесть) аргументы против ember.
UFO just landed and posted this here
Честое слово, это всё всё равно вкусовщина, но основных причин было три:
- Крайне редко бывают вещи в которых я не могу разобраться за день — и это был именно такой случай — трудно понять быстро с высоты птичьего полета как что работает, и как сделать быстро какое-нть тестовое одностраничное приложение
- Никто из команды ничего про него не знал, и энтузиазмом изучать не горел
- Шаблонизатор был так себе — как делать анимации или локализацию было непонятно
Был опыт написания проекта на 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 не задумываясь. Моя эффективность на нем определенно выше.
Что понравилось:
– как адепт 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? Это же топик про производительность в фронтенде!
Про React + Flux тоже отлично!
Почему ничего не сказано про Immutable Persistent Data Structures в JS? Это же топик про производительность в фронтенде!
Мы долго пытались жить с immutable.js, но в итоге это был оверкилл, вместо него сформировали одно простое правило — не изменять данные во View-слое, и immutable.js был смело выпилен.
Разверните пожалуйста, в чём были сложности с immutable.js?
В моём проекте на моём собственном рендер движке и Redux я столкнулся с жуткими тормозами без immutable reconciliation.
Сейчас переписываю рендер движок на immutable.js полностью, и мне интересно с какими проблемами я могу столкнуться.
В моём проекте на моём собственном рендер движке и Redux я столкнулся с жуткими тормозами без immutable reconciliation.
Сейчас переписываю рендер движок на immutable.js полностью, и мне интересно с какими проблемами я могу столкнуться.
С immutable.js нафиг не нужен Lodash для работы с данными
С самого начала чтения поста хочется сказать автору: Что-то не так с процессом разработки!
Но когда автор взял бразды правления по ходу доклада, то ещё раз понимаешь, что меняется в первую очередь именно процесс разработки. Фреймвоки не причём.
Поздравляю. Наконец-то занялись правильной разработкой. Почти закончились стоны по круглым коням и ножной разработке. Впрочем по круглым коням нет. Чувствуется не понимание нахождения в сансаре.
Вижу в организации возникли приоритеты и понимание своих требований. Отошли от сбрасывание задач на не компетентных менеджеров, которым всё одно кто и на чём делает фитчи. Понятно — кризис. Издержки. Пора улучшать процесс. Убирать лишние тела из него, а с ними и сокращать зоопарк на других уровнях.
Лучше показать одного раскрученного тигра и козла, так как их легче кормить. Раньше кормили ещё чебурашек плюшевых разных цветов еврами, а они могут съесть сколь угодно, так как не они едят, а через них.
Техническая часть решения всё же не раскрыта. Впрочем не в контексте. а попытка смазана.
Да. Спасибо за качество изложения мыслей, ибо не маркетинговый шлак, а скорее стон от лица потерпевшего. Что воспринимается легко и радостно, так как если где и зацепило, но не твоя боль.
:)
Но когда автор взял бразды правления по ходу доклада, то ещё раз понимаешь, что меняется в первую очередь именно процесс разработки. Фреймвоки не причём.
Поздравляю. Наконец-то занялись правильной разработкой. Почти закончились стоны по круглым коням и ножной разработке. Впрочем по круглым коням нет. Чувствуется не понимание нахождения в сансаре.
Вижу в организации возникли приоритеты и понимание своих требований. Отошли от сбрасывание задач на не компетентных менеджеров, которым всё одно кто и на чём делает фитчи. Понятно — кризис. Издержки. Пора улучшать процесс. Убирать лишние тела из него, а с ними и сокращать зоопарк на других уровнях.
Лучше показать одного раскрученного тигра и козла, так как их легче кормить. Раньше кормили ещё чебурашек плюшевых разных цветов еврами, а они могут съесть сколь угодно, так как не они едят, а через них.
Техническая часть решения всё же не раскрыта. Впрочем не в контексте. а попытка смазана.
Да. Спасибо за качество изложения мыслей, ибо не маркетинговый шлак, а скорее стон от лица потерпевшего. Что воспринимается легко и радостно, так как если где и зацепило, но не твоя боль.
:)
Цитата:
«Очень хочется, чтобы мы, наконец-то, могли подключить нормального верстальщика и нанять разработчика с меньшей зарплатой ...»
Ну очень хочется! :)
P.S. Цель — всё же, оптимизация «накладных расходов» под благие цели?
«Очень хочется, чтобы мы, наконец-то, могли подключить нормального верстальщика и нанять разработчика с меньшей зарплатой ...»
Ну очень хочется! :)
P.S. Цель — всё же, оптимизация «накладных расходов» под благие цели?
Нет, цель экономии была, но совершенно в другом — перестать параллельно разрабатывать на зоопарке технологий, т.к. это постоянно жрало кучу ресурсов у каждого отдела в отдельности, и при этом качественного скачка вида «вот эти трое делают ядро продукта, а эти трое — UI» быть не могло. Специализация, и более специлиализированные рзработчики, шаринг знаний, шаринг ресурсов — вот, что хотел менеджмент.
>Пора улучшать процесс. Убирать лишние тела из него, а с ними и сокращать зоопарк на других уровнях.
А как же микросервисы и зоопарк из сопутствующих технологий тому же Реакту? :)
А как же микросервисы и зоопарк из сопутствующих технологий тому же Реакту? :)
CuTIЕсть ощущение, что докладчик имел в виду фреймворк Qt.
UFO just landed and posted this here
а в опен сорс что-нибудь пойдет?
Прошу прощение, но не менее странно сравнивать ExtJs 4 (и ниже) версий с более новой версией. Скажу честно — уже 6 лет работаю с ExtJs и все эти проблемы очень быстро становяться плюсами. Ведь главное уметь «готовить» то, что уже имеешь.
Sencha пару лет назад выпустила 5 и 6 версию данного framework. И все координально изменилось. Подход к работе, принципы — все. Да, остался MVC, но уже есть и MVVM. Добавили two-way data binding. Я когда начал смотреть Angular и другие проекты удивлялся, почему нет таких простых возможностей, а в ExtJs они есть. Куча реализаций store (возможность работы с данными), как ajax, так и rest, причем с уже готовыми компонентами. Сел, включил, написал, забыл.
Да, конечно, не стоит забывать о его «огромности» и не всегда хороших подходах. Но для корпоративного сегмента рынка, для приложений, которые пользователь «открыл и забыл» — вполне годная вещица. Но не стоит злоупотреблять, конечно же.
Sencha пару лет назад выпустила 5 и 6 версию данного framework. И все координально изменилось. Подход к работе, принципы — все. Да, остался MVC, но уже есть и MVVM. Добавили two-way data binding. Я когда начал смотреть Angular и другие проекты удивлялся, почему нет таких простых возможностей, а в ExtJs они есть. Куча реализаций store (возможность работы с данными), как ajax, так и rest, причем с уже готовыми компонентами. Сел, включил, написал, забыл.
Да, конечно, не стоит забывать о его «огромности» и не всегда хороших подходах. Но для корпоративного сегмента рынка, для приложений, которые пользователь «открыл и забыл» — вполне годная вещица. Но не стоит злоупотреблять, конечно же.
А поделитесь парсером html+mustche в react? Было бы очень полезная тулза.
Не рассматривали Dojo 2? Ну так, в качестве альтернативы? Просто мы используем Dojo около 2х лет, и проблем с пониманием его верстальщиками, программистами, дизайнерами не наблюдалось. Да он не поворотлив в основе, но для «жирного ынтерпрайза» вполне заходит. В основном из-за своего представления ООП в JS. Оно сразу понятно backend разработчикам. Правда если ты, в принципе, не знаком с JS будь готов выстрелить себе в ногу из-за не понимания того, что никакого ООП в JS нет.
сильно не рассматривали, т.к. не было стабильной версии, и популярность была около нуля. И никто из нас про него и не слышал особо.
никакого ООП в JS нетА что же там есть, по вашему, если не ООП?
Ребята, мы ищем программиста-разработчика в управление перспективных разработок.
Начинающего.
Компания — крупнейший российский регистратор АО «Регистратор Р.О.С.Т.»
Функционал:
проектирование и разработка web-приложений;
разработка и поддержка клиентской и серверной части корпоративной информационной системы;
интеграции с поставщиками услуг (SOAP, REST);
доработка чужого исходного кода;
разработка на основе требований заказчика;
командная работа совместно с другими разработчиками и заказчиком.
Требования:
высшее образование / студент старших курсов;
понимание технической документации по программированию на английском языке;
знание Java, SQL;
готовность к поддержке и модернизации программного обеспечения на Java;
желание совершенствоваться в области разработки корпоративных приложений и их интеграции.
Приветствуем:
знания в области технологий и фреймворков Java: Spring, Hibernate, SpringBoot, Servlets, JDBC;
опыт работы с JavaScript, AngularJS;
знание HTML и CSS;
опыт работы с PostgreSQL;
опыт работы с Git.
Возможности:
работа в крупной стабильной компании;
интересные и разноплановые задачи;
медицинская страховка после определенного стажа работы;
ежегодный оплачиваемый отпуск, полное соблюдение ТК;
опытные программисты в дружном коллективе помогут профессионально расти и развиваться (и будут рады поучиться у вас);
офис м. Сокольники.
Если у кого-то есть знакомые перспективные и талантливые, wellcome! На сайте компании есть адрес и телефон.
Начинающего.
Компания — крупнейший российский регистратор АО «Регистратор Р.О.С.Т.»
Функционал:
проектирование и разработка web-приложений;
разработка и поддержка клиентской и серверной части корпоративной информационной системы;
интеграции с поставщиками услуг (SOAP, REST);
доработка чужого исходного кода;
разработка на основе требований заказчика;
командная работа совместно с другими разработчиками и заказчиком.
Требования:
высшее образование / студент старших курсов;
понимание технической документации по программированию на английском языке;
знание Java, SQL;
готовность к поддержке и модернизации программного обеспечения на Java;
желание совершенствоваться в области разработки корпоративных приложений и их интеграции.
Приветствуем:
знания в области технологий и фреймворков Java: Spring, Hibernate, SpringBoot, Servlets, JDBC;
опыт работы с JavaScript, AngularJS;
знание HTML и CSS;
опыт работы с PostgreSQL;
опыт работы с Git.
Возможности:
работа в крупной стабильной компании;
интересные и разноплановые задачи;
медицинская страховка после определенного стажа работы;
ежегодный оплачиваемый отпуск, полное соблюдение ТК;
опытные программисты в дружном коллективе помогут профессионально расти и развиваться (и будут рады поучиться у вас);
офис м. Сокольники.
Если у кого-то есть знакомые перспективные и талантливые, wellcome! На сайте компании есть адрес и телефон.
UFO just landed and posted this here
Начинающего
знание Java(Spring, Hibernate, SpringBoot, Servlets, JDBC), SQL, PostgreSQL, JavaScript, AngularJS
Начинающего
Что-то уровня этого
А что скажите про SmartClient?
не слышал ни разу
выглядит очень и очень не плохо: демо
Отлично написали, спасибо!
В итоге я насчитал, что у нас есть java-люди, ruby-люди, python-люди и php-люди, которые все делают фронтенд. И при этом в компании нет верстальщика, ни одного.
<troll-mod>и эти люди потом кричат что js плохой, может проблема не в языке, а в прослойке между стулом и клавиатурой</troll-mod>
Искали фреймворк, на котором все пишут, чтобы сотрудников легко находить, ведь не в космосе. Нашли Angular, все шикарно, но вот не задача: UI нет… Поэтому решили свой фреймворк написать.
Будь вашим руководителем, то я бы вас уволил.
А в мордокниге написали. :)
Да и куча их появилась в последнее время. Их же кто-то написал. Или их написали идиоты, которых потом уволили за это? :)
Да и куча их появилась в последнее время. Их же кто-то написал. Или их написали идиоты, которых потом уволили за это? :)
В мордокниге ущербные руководители, в отличие от Duke565
И сама мордокнига недостойна чтобы он был там руководителем, не тот у них уровень
И сама мордокнига недостойна чтобы он был там руководителем, не тот у них уровень
Хорошая статья, очень понравился подход к сравнению и выбору инструмента исходя из задач и текущей ситуации. Однако, очень удивляет, что нет ни слова про особенности лицензии на React. (Грубо говоря, Facebook оставляет за собой право отозвать вашу лицензию, если решит, что вы с ними конкурируете. Более подробно здесь.)
Вы сознательно решили, что для Acronis это не актуально или просто предпочли проигнорировать этот момент?
Вы сознательно решили, что для Acronis это не актуально или просто предпочли проигнорировать этот момент?
В конце 2015 года я оказался в сходной ситуации, и так же исследовал рынок фронтенд фреймворков и тренды, точно так же пришел к выводу, что оптимум на ближайшую перспективу только реакт.
Пробовали ли Вы Redux? А Relay+GraphQL?
Пробовали ли Вы Redux? А Relay+GraphQL?
Судя по тесту статьи тогда Redux ещё не изобрели.
А сейчас их наверное это мало трогает — они пилят код уже на Angular2:
https://habrahabr.ru/company/oleg-bunin/blog/311096/#comment_9829536
А сейчас их наверное это мало трогает — они пилят код уже на Angular2:
https://habrahabr.ru/company/oleg-bunin/blog/311096/#comment_9829536
Да, на Redux запиливал тестовый проект.
Для сложных приложений, с болшим кол-вом вложенных экранов Redux не подходит.
Он очень прост, и специально упрощен, сделать ну хоть какую-то динамику (например, открытие вспылвающих окон с частями приложения) было очень сложно. Основная беда для большого приложения как раз в том, что все данные в одно месте, и работать с огромной «елкой» данных очень неудобно.
Для сложных приложений, с болшим кол-вом вложенных экранов Redux не подходит.
Он очень прост, и специально упрощен, сделать ну хоть какую-то динамику (например, открытие вспылвающих окон с частями приложения) было очень сложно. Основная беда для большого приложения как раз в том, что все данные в одно месте, и работать с огромной «елкой» данных очень неудобно.
Интересно было прочитать. Нахожусь в похожей ситуации. Зоопарк проектов и даже Ext4 есть :) Только в своей команде я остался один :(
Возможно это слишком по-капитански, но аргументы о «нетестируемости» flux архитектуры сейчас уже неактуальны, особенно с появлением redux'a (https://github.com/reactjs/redux — первый релиз кстати в августе 2015го). Там конечно сейчас свои заморочки, но тестирование чистых функций, коими являются reducer'ы, не является чем-то сверхсложым
Судить о том, что нет проблем в огромной сложной области исходя из того, что есть один подход к тестированию одного конкретного фреймворка мягко говоря наивно.
Попробуйте запилить действительно большой проект с Redux, возможно вы поймете, что это очень нишевый фреймворк.
Мы для React разрабатывали параллельно аж три разных вида тестов.
Попробуйте запилить действительно большой проект с Redux, возможно вы поймете, что это очень нишевый фреймворк.
Мы для React разрабатывали параллельно аж три разных вида тестов.
Статья напомнила мне, когда сами стояли перед выбором больше трех лет назад, над выбором фреймворка для проекта. Отдали тогда предпочтение ангуляру. Тогда еще была версия 1.1 или 1.2. Уже не помню. Суть была такова — Вау! Датабиндинги! И гугл поддерживает! И комьюнити! И вообще стильно модно молодежно!
Да проводили анализы, сравнивали итд. Выбрали ангуляр. А потом, к сожалению, хлебнули проблем по полной.
Сейчас наблюдаю у многих похожую проблему. Модно выбирать React. И опять читаю фразы, о производительности, большом комьюнити и поддержке большой компании. Признаюсь по правде — меня настораживает это.
Для себя юзаю пока backbone. А дальше видно будет. Может попробуем React.
Да проводили анализы, сравнивали итд. Выбрали ангуляр. А потом, к сожалению, хлебнули проблем по полной.
Сейчас наблюдаю у многих похожую проблему. Модно выбирать React. И опять читаю фразы, о производительности, большом комьюнити и поддержке большой компании. Признаюсь по правде — меня настораживает это.
Для себя юзаю пока backbone. А дальше видно будет. Может попробуем React.
Мне кажется, что заново изобретают Дельфи, только на скрипте.
Переизобретается всё. ;-)
Мне JSX напоминает, например, JSP.
Если в JSP происходит компиляция JSP-страницы в сервлет (java-код), то в JSX происходит компиляция в Javasript-код.
Мне JSX напоминает, например, JSP.
Если в JSP происходит компиляция JSP-страницы в сервлет (java-код), то в JSX происходит компиляция в Javasript-код.
JSX — ужасное смешение всего в кучу, имхо. Мы еще кодга тестовый проект запиливали с двумя экранами уже эту мешанину было сложно читать.
В том что у вас получилась мешанина кода, необязательно виноват JSX.
можно собрать html-конструкции в одной или нескольких функциях, которые вызывать в render.
Культура написания кода во многом определяет результат.
Если предлагается делать плохо — большинство сделает плохо.
Если предлагается делать плохо — большинство сделает плохо.
покажите, где именно в документации React предлагается сделать плохо
>Если предлагается делать плохо — большинство сделает плохо.
Верно. Но если появились паттерны делать хорошо — то все будут делать хорошо. ;-)
Верно. Но если появились паттерны делать хорошо — то все будут делать хорошо. ;-)
Боюсь вы заблуждаетесь.
Не раз наблюдал картину, когда и паттерны хорошие, и принципы установлены, и тренинги проведены. А нет! Таки говнокодят.
Мне кажется, здесь больше будет влиять личный опыт, само-ответственность за проект и код, собственный перфекционизм.
PS прошу прощения, что встрял в вашу дискуссию.
Не раз наблюдал картину, когда и паттерны хорошие, и принципы установлены, и тренинги проведены. А нет! Таки говнокодят.
Мне кажется, здесь больше будет влиять личный опыт, само-ответственность за проект и код, собственный перфекционизм.
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?
vs
https://github.com/reactjs/react-autocomplete/blob/master/lib/Autocomplete.js
Неужели вот этот дикий шаблон в a2 правда лучше того, что в react?
>Неужели вот этот дикий шаблон в a2 правда лучше того, что в react?
Я думаю, что он скажет — да! Имхо.
Ибо в autocomplete.ts, в этом «ужасном» шаблоне в начале кода, он ВИДИТ в этом шаблоне уже типа html код страницы (ну, «грязноват», но намётанный его глаз то заменит все эти ангрулярские теги и в голове станет ясный образ html). — Ибо человек за 2 недели, а уж за 2 месяца, ко всему может адаптироваться.
Даже к ангуляровскому шаблону. ;-)
Я думаю, что он скажет — да! Имхо.
Ибо в 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!»
А все эти тонкости когда у нас иногда [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 \Не-не-не… Ну чесслово, если angular и react еще выглядят хоть как-то понятно, то вот это очень похоже на язык K. :)
Это лишь с непривычки. Всё, что тут есть — это наследование, перегрузка свойств и биндинги.
>Это лишь с непривычки…
Вот это верно. Человек за пару месяцев ко всему привыкает. ;-)
Вот это верно. Человек за пару месяцев ко всему привыкает. ;-)
И это проблема. Привычки мешают оценивать инструмент объективно.
>И это проблема. Привычки мешают оценивать инструмент объективно.
Верно и это. Мало революций в современном мире JavaScript.
;-)
Верно и это. Мало революций в современном мире JavaScript.
;-)
Есть и проект такого «Фреймворка» на JavaScript из поднебесной.
https://github.com/hcchengithub/jeforth.3we
Правда непонятно, но примеры со страницы перестали нормально запускались в браузере. Может пути к файлам нарушились.
P.S. https://github.com/substack/stream-handbook тоже из этого направления.
В природе можно найти ещё вариаты, но насколько это революционно не могу представить.
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?
Давайте:
- Чтобы передать компоненте параметр нужно объявить его в props.
- Чтобы использовать какое-то состояние нужно объявить его в state.
- Отдельно нужно задать создание значений по умолчанию для props и state.
- Чтобы задать атрибут не предусмотренный реактом для данного типа элемента… даже не знаю как.
- Чтобы передать значение нужно вместо кавычек использовать фигурные скобки.
- Если выводится список, то заблаговременно для каждого элемента нужно задать параметр "key".
- Всем элементам нужно проставлять классы, чтобы их можно было стилизовать.
- Нужно не забывать прокидывать в каждый элемент дополнительные классы, чтобы можно было стилизовать в зависимости от контекста (БЭМ и всё такое).
- Для локализации необходимо вставлять получение значения по ключу, при этом не забыв реализовать контекстную перегрузку этого значения.
- Чтобы передать список компонент нужно написать фигурные скобки, внутри них квадратные, внутри которых угловые. Но это уже скорее курьёз.
>Чтобы передать список компонент нужно написать фигурные скобки, внутри них квадратные, внутри которых угловые. Но это уже скорее курьёз.
Почему курьёз?
— фигурные скобки — означает что передаём ОБЪЕКТ.
— внутри них квадратные — означает что это будет список в виде массива.
— внутри которых угловые. — это означает что элемент массива будет КОМПОНЕНТ.
Всё логично. (С)
Почему курьёз?
— фигурные скобки — означает что передаём ОБЪЕКТ.
— внутри них квадратные — означает что это будет список в виде массива.
— внутри которых угловые. — это означает что элемент массива будет КОМПОНЕНТ.
Всё логично. (С)
Или вот:
Тут где-то 80% кода можно переиспользовать в обоих ветках, когда есть headerRows и когда нет. Если бы это был JSX, то можно было бы разбить этот шаблон на мелкие куски, положить их в переменные а потом собрать из них нужное.
заменяется на что-то вроде:
т.к. headerTemplate у нас просто функция, которая возвращает разметку. Самая вкусная фишка JSX, в том, что это просто какой-то JSON объект, который можно положить в переменную, вернуть как результат вызова функции и т.д. Аналог ангуляровского <template>....</template> в react это просто React.cloneElement(myVariable,...)
<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, конечно, выглядит намного лучше, и я в целом ему отдаю предпочтение, но такого рода шаблоны
я имел удовольствие по нопытности и в JSX делать, все зависит от задачи и подкованности разработчика.
Если брать именно обычный какойнть сайт с обычным какимнть списком товаров на продажу, с анонсом цен и какихнть скидок, вполне подобный трудночитаемый мегашаблон и на JSX вероятен.
Ну, по этим двух компонентам хорошо видно отличия в религии одного от второго фреймворка, если брать конкретно компненты, 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 абсолютно все события браузера.
Простите, накипело :)
А вся эта возня с 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» подоспеют. Эх.
>Это то, с чем я столкнулся буквально за первые пару недель копания с 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?"
«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?
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
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
Only those users with full accounts are able to leave comments. Log in, please.
Javascript-фреймворки: должен остаться только один