Javascript-фреймворки: должен остаться только один

    Сергей Аверин ( XEK )


    Сергей Аверин

    Изначально я хотел сделать доклад про сравнение фреймворков, но потом подумал, что закидают помидорами, поэтому доклад — просто адский троллинг, как водится у меня. И он, скорее, не про HighLoad, а про менеджерскую задачу, которая стоит над всем этим делом, включая фронтенд.

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



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

    А вот теперь настало время очешуительных историй.

    Немного про компанию:



    Acronis — очень большой российский бизнес, который обслуживает 5 млн. пользователей, из которых примерно процентов 10 — это корпоративные клиенты, которым их работы покупают лицензии. Соответственно, компания сама по себе тоже очень большая, у нас 17 разных офисов, R&D находятся в трех разных странах, и самый большой R&D находится в Москве. Но при этом разработка у нас распределенная, и есть удаленщики, которых я здесь не посчитал.

    Масштаб разрабатываемого софта самый разный: есть у нас коробочный софт под Windows, есть коробочный софт с веб-интерфейсом, который мы продаем на предприятия, есть софт, который мы сами продаем и сами внедряем, и это смесь и коробочного и cloud-софта. Есть и cloud-софт, который мы продаем по подписке и домашним пользователям, и корпоративным. Есть даже софт, который мы продаем сначала крупным хостинг-компаниям, которые уже от своего имени продают его под своим брендом их конечным юзерам. И у всего этого дела есть огромное количество веб-интерфейсов. Речь идет именно о веб-продуктах, а не о веб-сайтах, как таковых.



    Когда я пришел в компанию, стал разбираться, чего же у нас есть, как же все происходит, выяснилось, что внутри компании есть веб-админки разного рода, которые мы делаем сразу на куче разных технологий, начиная от true-фронтенд типа Ext JS или AngularJS, заканчивая сайтами, которые пишутся на Ruby on Rails и в которых jQuery просто переключает страницы или графики.

    Перед коллективом стояли такие проблемы.



    Во-первых, технологий много, они все разные, разработчиков из одного отдела в другой не перетащить, не помочь какому-то проекту, потому что Ruby on Rails разработчики, которые пишут на jQuery, про AngularJS ничего не знают. Во-вторых, выяснилось, что существенное количество людей работают part-time — то бэкенд-разработчиками, то фронтенд-разработчиками. У нас, например, есть ребята, которые на PHP пишут, и они же делают на AngularJS сайт, который работает с ним как с бэкендом. Их не очень много, у них проект маленький, и смысл заводить им отдельного фронтенд-разраба отсутствует.

    В итоге я насчитал, что у нас есть java-люди, ruby-люди, python-люди и php-люди, которые все делают фронтенд. И при этом в компании нет верстальщика, ни одного. Т.е. есть несколько людей, которые экспертно знают эту область, но обычно они работают кодерами на AngularJS. В итоге в этих проектах совершенно разный стиль кода, совершенно разный стиль комментариев, они по-разному деплоятся, в каком-то месте, с помощью Ruby on Rails мы собираем AngularJS приложения с помощью ruby‘шного сборщика. И в итоге — везде разный зоопарк. В каждом отделе зоопарк свой. А еще, короче, получается так, что наш самый флагманский продукт, в котором написан Ext JS, это огромная админка, там сотни экранов, он сейчас построен на базе версии 4, а в 2015-ом году, совсем недавно, зарелизилась уже версия 6 этого фреймворка и, вроде как, мы отстаем аж на 5 лет от версии фреймворка, которую мы используем. Возможно, тоже надо что-то с этим делать.

    Пришло, конечно же, начальство и поставило задачу. Задача была дана сверху:



    Нам нужен толстый клиент на фронтенд-технологиях, который будет общаться со stateless backend API максимально везде, где мы можем это внедрить. Нужна единая библиотека UI-компонентов, единый look and feel для всей компании, потому что мы немножко страдаем от того, что у нас шрифты где-то разные, где-то по пикселям верстка поплыла, и в итоге получается так, что у нас два соседних отдела рисуют какие-то общие элементы для всех наших админок, которые дизайнерами нарисованы одинаково, немножко по-разному — где-то верстка на HTML, где-то верстка запихана в JS-код в каком-то собственном шаблонизаторе. И CSS-слой тоже принципиально разный, где-то он накладывается из трех-четырех файлов поверх друг друга, заскиневая существующих фреймворк.

    Очень хочется, чтобы мы, наконец-то, могли подключить нормального верстальщика и нанять разработчика с меньшей зарплатой, который бы отвечал, с одной стороны, за общение с дизайнерами, подготовку дизайнов, а с другой стороны java-скрипторам приносил и говорил: «Вот, они хотят этого, здесь нужно анимировать этот интерфейс…». И при этом мы бы могли нанимать JS-кодеров в проекты не топового уровня. Сейчас у нас работает достаточно много ребят, которые прошли огонь и воду, они знают Java, они знают .Net, и в этом плане для них любой javascript-фреймворк — это не проблема, потому что они, в принципе, очень опытные. Поэтому хочется как-то иметь возможность нанимать не одного из ста, а хотя бы двух из пятидесяти.

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



    Посмотрели, что же, на самом деле, мы имеем в компании. Оказалось, что у нас есть партнерский продукт, который написан на Dojo. Для него мы пишем плагины на Dojo, это очень древний фреймворк, очень особенный, он работает как компонентная модель. Это не совсем MVC, но с этим мы решили ничего не делать, потому что мы не можем никакой другой фреймворк использовать, иначе мы не сможем с этой партнеркой работать.

    Для сайта, собственно, у нас почти нет никакой динамики. Нам важно, чтобы его индексировали поисковики, и нам важно, чтобы он работал быстро. Нам там Javascript особо не нужен. Поэтому какой-то суперфреймворк для него, вообще, не уперся. Это задача, которую мы не должны решать.

    Из оставшегося, из чего на самом деле делаются админки, это Angular JS первой версии, это Ruby on Rails, плюс генерирующие страницы на бэкенде, плюс какие-то jQuery-дописки, которые делают некую динамику. И большая часть продуктов написана на ExtJS 4. Это очень высокоуровневые фреймворки, которые больше всего напоминают .Net или QT, на котором большая часть продуктов компании — серьезных и взрослых — написана.



    Полез я разбираться, что же такое этот ExtJS. Оказалось, что это огромная махина, локомотив кода. На главной странице 395 классов этого фреймворка описаны.



    Каждый класс имеет очень глубокое дерево наследования, т.е. в этом плане очень сильно слизано с того, как строится QT, .Net и прочие MVC фреймворки, которые работают где-то в винде или в линуксе под десктоп. В итоге получается, что зачастую код, который ты дебажишь, находится где-нибудь на три уровня выше, чем тебе сейчас надо. Разобраться в этом действительно сложно.

    Класс Ext.panel:



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



    В итоге мне было печально, очень. Я первое время вообще ничего не понимал, смотрел на все это дело и задавал себе такой вопрос: «Господи, зачем же вы все это написали?».

    Индексная страница флагманского приложения была мною напечатана на листах А0 и занимала 51 лист шрифтом 6.



    Вот увеличенное это дело:



    Это DOM-дерево, в нем было 32 с чем-то тысяч нод. Это просто индексная страница, сгенерированная фреймворком, т.е. мы еще ни на одну кнопку не нажали. Это просто загрузилась страница и все отрисовала. Стало очевидно, что, блин, что-то тут странное происходит, явно есть какая-то фигня с этим.



    Полезли смотреть, как же делается UI в этом фреймворке. Оказалось, что пользователь получает сразу библиотеку UI компонентов, которая скинится CSS’ом. Ты должен CSS’ом дописать поверх, тогда получишь свой кастомный скин. И много компонентов, которых не было, их пришлось реализовать с нуля. В итоге зачастую, не везде, но очень часто, я натыкался на что-нибудь такое. Это javascript класс, который с одной стороны UI компонент, но с другой, зачастую видно, что в нем аж три разных сущности смешивается — это javascript-код, html-код и это какие-то очень странные директивы местного шаблонизатора, эти xindex, xcount или этот tipeof values string, запиханные в фигурные, квадратные скобки…

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



    Дальше выяснилось, что это единственный видимый мною фреймворк, в котором есть такая шутка, как layouting. Полезли посмотреть, что же, как же, почему, откуда эти теги? Оказалось, что при изменении размеров окна, при изменении размеров какого-то компонента фреймворк так же, как это на декстопе, вычисляет сам размер блоков и вставляет их inline CSS’ом. Типа left, right, width, height. Мало того, там очень хитрый алгоритм, который берет текст и оценивает его размеры, запихивает его в невидимый div, и смотрит, какого размера этот div получился при заданной ширине. И так он мимикрирует под функции оценки размеров текста, сколько этот текст займет в этом блоке, и вычисляет эти блоки. А потом выяснилось, что алгоритм этот, еще и древовидный, т.е. он по 6-7 проходов делает, потому что он, как браузер, тоже натыкается на какой-то компонент, который не влазит, начинает его увеличивать и родительский компонент тоже пересчитывать. В итоге, начинаешь двигать правую страницу браузера и четко видишь затупы его про изменения размера этого фреймворка. Но, с другой стороны, это дает тебе типа бенефис, что во всех браузерах это работает абсолютно одинаково, и про проблемы совместимости между браузерами ты не паришься, потому что максимально тебе этот вопрос закрыли.



    Попутно выяснилось, что компонентов очень до фига. И все эти компоненты, каждый из них — это инстанс javascript’ового класса, у которого от трех до пяти уровней наследования, а то и до семи-восьми. Для каждого из них этим волшебным layout’ером оцениваются размеры, они высчитываются и выставляются. У родительских потом высчитываются размеры, и в итоге все это дело генерирует такие веселые штучки — inline css’ы, которые вставляются прямо в div’ы этих компонентов, прямо в теги. Поэтому получается такое огромное DOM-дерево, странное.



    В попытке понять, как же этот layouting работает, я наткнулся на такое совершенно страннейшее место.



    В этот момент мне стало совсем плохо, и я понял, что я не пойму никогда, как это происходит.



    Вы все еще помните, что речь идет о производительности?



    Все это дело занимает почти 2 Мб уже в пожатом виде, поэтому совершенно неудивительно, что на каких-то тестах типа «а как это будет работать на мобиле?» выдает веселые времена загрузки. Но, тем не менее, это не такая большая проблема для нас, потому что большинство клиентов корпоративные, и они лезут в админку, когда им нужно либо что-то настроить, т.е. в первую неделю после покупки продукта, либо когда адский пипец, т.е. нужно достать бэкап. И человек, у которого адский пипец, готов подождать 16 секунд, пока, наконец, загрузится админка. Тем более, здесь речь идет о достаточно тонком канале.



    С фреймворком понятно, очень сложно и запутано. А сам приложение? Полезли в код приложения.



    Получается так, что в коде мало комментариев. Какие-то трудные места не объяснены. Все приложения жестко связаны. Вместо одного класса — длинного, на 2,5 тыс. строк, мы имеем дело обычно с тремя-четырьмя классами по 1000 строк, которые очень жестко знают друг про друга и так по кольцу, общаясь, пересылают себе события, меняют состояния внутри себя. И у нас внутри очень большие проблемы с границами между моделью и бизнес-логикой, и между бизнес-логикой и view. Получается так, что у нас есть view-классы, которые называются как-нибудь типа «волшебная реализующая определенный функционал панель», которая и одновременно отрисовывает себя и отрисовывает дочерние компоненты, и еще у нее до фига бизнес-логики, которая умеет переключать какие-то панели внутри, и которая умеет отсылать уведомления, даже зачастую они из view-классов лазят на сервер.



    Поэтому (очень условно) получилось так, что у нас такой не mvc, а M+CV. Т.е. граница между контролем и view очень не определена. Получилось так, что и в моделях есть бизнес-логика, и в контроллерах есть бизнес-логика, и во view есть бизнес-логика, и UI логика, и состояние приложения тоже размазано по всем трем видам классов. Поэтому трудно, например, понять откуда пришли эти данные, или кто является авторитативной точкой, откуда эти данные взялись, и кто хранит на текущий момент самую достоверную копию этих данных, потому что она есть в нескольких частях приложения.



    А еще получилось так, что сам фреймворк Ext JS всех очень толкает к архитектуре построенной на publish/subscribe, потому что, в принципе, у него все UI компоненты завязаны на этот механизм, и программисты невольно выбирают то, что предлагает фреймворк. И, вроде как, publish/subscribe — правильный паттерн, но когда ты начинаешь смотреть на приложение, в котором типа 100 страниц, в итоге получается, что ты пытаешься разобраться: «Блин, а к чему же приводит нажатие вот этой кнопки в этой панели, и что же она дергает?».



    И выясняется, что, во-первых, события могут неявным образом попадать в родительские классы, которые, в свою очередь, генерят вторичные события, которые попадают в какие-нибудь классы с бизнес-логикой, которые в свою очередь генерят еще события. Затем часть событий игнорируется фреймворком, потом меняется какая-то модель, эта модель генерирует события о том, что «данные во мне поменялись». Появляется еще пяток классов, которые подписаны на ее изменения, и в себе меняют какое-то состояние, которое зависит от состояния этой модели.

    В итоге, через три часа ты, наконец, строишь стройную картину и понимаешь, что у всех событий названия очень похожи, и везде есть onclick. И тебе нужно понять, это onclick от этой кнопки, которую ты нажал или onclick от соседней кнопки, которую ты нажал. Потому что фреймворк не запрещает подписку любого компонента на любой. Т.е. ты можешь добраться из кого-нибудь суперконтроллера до кнопки в конкретной панели и подписаться на нее onclick. И это будет просто onclick в кавычках. И такие дела очень трудно дебажить, потому что нет какой-то уникальной селективности этих компонентов. Т.е. там есть свой механизм, называется ComponentQuery, похожий на XPath, в котором можно написать RegEx-запрос, который тебе говорит: «Найди мне там все кнопки, которые вложены в определенную панель с определенным названием». Поэтому, когда ты пытаешься чего-то отрефакторить, очень трудно найти все, вообще, места, где мы реагируем на конкретное событие. Зачастую у нас это даже приводило к циклам событий, когда приложение зависает, потому что постоянно появляются дочерние события, оно начинает их обрабатывать, и этот цикл бесконечен. Пока ты не напишешь какой-нибудь хитрый if типа «если ко мне это событие уже приходило, я его не обрабатываю», то мы дальше его не обрабатываем. Т.е. речь идет о запутанной архитектуре.

    Все нормально.



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



    Вот так вот получилось. Причем непонятно, на самом деле, почему получилось. Потому что, на мой взгляд, могло быть лучше. Но, короче, объекты Arrays мы проверили, остальное — как получится. И вечная эта история про то, что когда ты начинаешь писать тесты, ты многое узнаешь про свое приложение, что на самом деле ни фига не надо было делать такое количество связей, потому что замокать 15 объектов ради вызова одной функции, очень геморройно. И в этом плане получили тесты «давай, до свидания».

    Какие выводы? Как бы, вот такие, конечно, выводы…



    Но на самом деле, настоящие выводы в чем?



    Что фреймворк очень сложный для понимания разработчиков, особенно разработчиков, которые до этого не защищали докторскую диссертацию по Java. Во-вторых, код, который получился, очень запутанный. В нем очень много связей, все классы друг про друга знают, и события, которые появляются, никем не контролируются, и это приводит к фейерверко-образным взрывам изменения стейтов приложения, когда 15 мест подписаны на какой-нибудь стейт, события потом генерируют свои дочерние события, и еще какие-нибудь другие места начинают обрабатывать эти события… В этом плане фреймворк жутко асинхронный, и эта асинхронность взрывает мозг. Получается так, что компоненты правят люди, которые понимают одновременно язык шаблонизатора, намешанный JS-код, html, CSS и все это в одном файле. Обычного верстальщика нанять? Я не знаю… Сколько сейчас получает верстальщик? За 40-60 тыс. невозможно найти верстальщика и посадить его за простую рутинную работу «в этой панели убери эту кнопку», потому что сборка всего UI происходит в JS-коде методом созданий инстансов JS-классов. Т.е. ты описываешь большое дерево, какую кнопку в какую панель вложить, какие параметры передать, какие ссылки, на какие события потом подписаться.

    Соответственно, главный мой вопрос был — виноват ли в этом фреймворк? На самом деле, конечно, виноват. Частично. Потому что он подталкивает тебя к publish/subscribe, потому что он подталкивает тебя к такому mvс, который они сами делают, псевдо mvc. Потому что в нем нет dependency injection из коробки, потому что он не говорит тебе, как тестировать это все дело…



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

    Нужно четкое разделение работы по людям: одни люди делают верстку, другие люди в верстку вдыхают что-то, третьи люди ответственны за работу с API, четвертые– с дизайнерами. Нужно разделение языков и технологий, желательно по-файлово, чтобы можно было каким-то людям, которые не разбираются в JS-коде давать какие-то вторичные задачи, например, переводы, т.е. локализацию на нужный язык.

    Конечно, хочется менее связанную архитектуру, потому что тестировать это нереально, написать тесты для этого очень трудно. Поэтому хочется какой-то изоляции. Понятные микрокомпоненты, каждый из которых ответственен за свой маленький кусочек. И проще UI слой.



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

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

    Конечно, я полез в Интернет. Ну, а что делать? Тут все бы полезли в Интернет.



    Выяснилось, что за пять лет, пока я управлял и работал на PHP, в мире JS многое поменялось, в этом плане пришлось многое выучить заново.



    И эти тысячи фреймворков, каждый из которых как две капли воды зачастую похож на друг друга, особенно во flux фреймворках — это прямо «придумай свое название точка JS». И из этого ада там, где Google Web Toolkit уже давно умер, надо как-то выбрать. Блин, что делать? Конечно, надо было что-то подумать, как бы посмотреть, как другие где-то что-то выбирают в Интернете, залезть и где-то спереть результат.

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



    Именно про компании и сайты я оттуда слайды вырезал, остаются именно честные цифры. Это количество строчек кода, написанных вообще с момента появления Github на разных технологиях. Плюс-минус.



    Это слайд рассказывает о том, сколько было докладов по каким технологиям на каких крупных конференциях, посвященных именно фронту, в 2015 году за рубежом.

    И везде картинка разная.



    На этой картинке тренд популярности запросов в гугле. Их тут несколько… Здесь, если присмотреться, видно, что все технологии идут на самом деле на спад, кроме React js и Angular js.



    Если взять какие-нибудь старые более-менее фреймворки дипа Dojo, Yahoo ui и нашего любимого Ext js, то тоже все идет на спад. В этом плане с React js и Angular js никто не поборется, потому что это единственное, что идет вверх.

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



    Это американская компания, которая делает и продает cloud IDE. Получилась вот такая картина, совершенно другая. Т.е. те разработчики, которые поддерживают продукты, у них еще силен, например, Backbone, который по большому счету устарел, но, тем не менее, есть много проектов на нем, которые еще доделывают.



    А это уже российский рынок. Мы пытались оценить, кого же мы можем нанять, потому что очевидно, что мы не в космосе работаем, и нам нужно делать продукты в компании, продуктов много и планов — громадье, поэтому кого-то надо нанять. Здесь, вообще, картина другая. Выяснилось, что так или иначе с какой-то из версий ExtJS (поскольку он достаточно долог) и с какой-то из версий Backbone (поскольку он тоже родился в 2008 году) так или иначе кто-то имел дело. Т.е. это никакой гарантии не дает на то, что этот человек прямо сейчас готов чего-то делать realtime на этом фреймворке, но, тем не менее, выяснилось, что среди растущих технологий React js и Angular js, появились внезапно Backbone и ExtJS, причем вакансии по ним есть, и их достаточно много. Вакансий по Backbone больше, чем со знанием React. Вот какая удивительная картина на российском рынке.



    В итоге мы все эти исследования максимально скрестили и оставили то, что нам интересно. Туда добавили еще Dojo и добавили ExtJS 6, на который изначально хотели переходить. А Dojo, потому что его используют Parallels, с которым мы тесно интегрируемся, и на котором у них кое-что написано.



    Здесь нагло было вырезано пять слайдов. Я не буду рассказывать про то, почему нам это все не подошло, потому что рассказ там очень скучный. Я не буду на этом останавливаться. Если вы полезете изучать для себя, то сформируете и какую-то картину для себя. Мы оценивали, исходя из наших задач. Одна из задач была в том, что технология должна быть более-менее встраиваемой по частям в существующий код, т.е. нам нужен не монолитный фреймворк, а, скорее, набор каких-то методик и библиотек, которые мы можем потихоньку внести. В этом плане оказалось, что Knockout — это вообще не фреймворк, а UI библиотека, Dojo — это просто мамонт, а ExtJS 6, хоть и привносит новую архитектуру, но на самом деле мало чем отличается от ExtJS 4. Т.е. там появилась поддержка какая-то, более хорошая работа с мобильными устройствами, но концепция не поменялась. Там чуть лучше стала архитектура, но для нас, как мы оценили, примерно одинаковая, что мы на ExtJS 6 будем переписывать честно архитектуру, прямо так, как они предлагают, что мы будем на любом другом фреймворке переделывать — примерно одинаково по затратам. В итоге отказались, потому что все тот же UI слой, все тот же publish/subscribe.

    Истинных кандидатов, на самом деле, было только два.



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

    Наше собственное зрение на это дело такое, что если брать версию 1, на которой у нас в компании есть два проекта, и посидеть-покурить исходники, то у этого фреймворка реально хорошая модульность разделения на отдельные кусочки, каждый из которых делает свой маленький функционал — вот это очень полезно и хорошо. Но нет единого стиля раскладки по файлам, нет единого стиля именования каких-то переменных и единого стиля форматирования кода, т.е. это та вещь, которую хотелось бы как-то получить до кучи с фреймворком, но ни фига не получится. И со временем этот стиль раскладки меняется. Также от себя добавлю, что зачастую находятся места в коде, которые по-хорошему должны бы быть отдельными классами, но почему-то их в виде объекта с функциями туда пихают. Трудно дебажить, очень много разной хитрой «магии», очень сложно интегрировать с какими-то новыми технологиями, потому что стандарты абсолютно все свои… Как собирать это дело — тоже не очень понятно, однако этот вопрос можно решить. Но самая беда, что начальству я это продать не мог, потому что мы все говорили, что «Ребята, они делают новую версию, и код будет несовместим». Что делать дальше — непонятно.



    ОK, полезли смотреть версию 2. Версия 2 прямо вообще отлично выглядит, как то, что нужно, такой бэкендно-ориентированный подход, все разложено по полочкам, хороший очень синтаксис на TypeScript — то, что надо. Но, блин, нет шансов на релиз, вообще, нет. Я, самое главное, не понимаю, эта супер-мега гугл корпорация, она давно работает с python… Пример того, как python переходит с версии 2 на 3 — это просто хрестоматийный пример того, как надо это делать. Надо поддерживать синтаксис старой версии, надо быть backword compatible. А здесь какой-то адский ад просто. Он будет несовместим. «Мы сейчас что-то новое делаем. Вот альфа-версия, для нее ни хрена нет документации. Когда мы запустимся — непонятно и, самое главное, у нас во всех трех языках еще разный синтаксис». Ну, зашибись, блин!

    Это что, это решение? Вы извините меня, это локомотив фронтенд-разработки, это, типа, самый крутой фреймворк, который все страшно любят? И что мне делать с админками, которые сейчас пишет четыре человека на AngularJS? Прийти и сказать: «Ребята, вы знаете, мы просто садимся и все переписываем. У нас ничего не станет лучше, мы просто переезжаем на новую версию». — «А зачем переезжаем?» — «Ну, потому что старую забросили». А они меня, конечно же, спросят: «Слушай, а есть такая штука, как в python, типа, «by 2 to 3». Т.е. давай натравим какой-то парсер, и он нам сейчас переформатирует код, и оно хоть как-то начнет собираться». Ты говоришь: «Извините, нет. Причем, мало того, что нет, оно сейчас еще все поменяется. Завтра у нас будет другой синтаксис». И это продать тоже никому невозможно. Совет директоров на меня посмотрит и уволит на завтра и все. Т.е. что делать с AngularJS — непонятно.



    Мы дальше стали смотреть, и было второе решение — это React JS, который сделал Facebook. C удивлением оказалось, что это не фреймворк, а всего лишь UI библиотека. У нее очень четкая понятная структурность, четко понятно, что это единый data flow, который только получает данные, только их отрисовывает. Каждый компонент изолирован, у каждого компонента есть декларация, чего он получает на вход, чего он в итоге отрисовывает, чего внутри он хранит в виде промежуточного стейта. Нет, вообще, каких-то магических фильтров и прочей фигни, которую надо откуда-то подключать, учить и знать, как работает… В этом плане все максимально предсказуемо и это очень классно. Мне понравилось, что есть очень простая возможность тюнинга производительности — четко понятно, как она работает, четко понятно, как ее использовать, ничего суперсложного в этом нет. Есть даже серверный рендеринг, который нам не нужен, но круто, что он есть.



    До кучи к этому шла архитектура Flux, которую активно двигает Facebook. Мы посмотрели на все это дело, у нас, как бы, был so-so. С одной стороны то, что one-way data flow, и то, что синхронная обработка как у стейт-машины, где четко понятно определенное состояние приложения — это супер. Но как приложение делится на независимые блоки и как разделить его, как в Angular JS, на какие-то отдельные сущности, не очень понятно. Потому что, мне кажется, там явно есть антипаттерны в виде того, что store’ы хранят данные, одновременно реализуют бизнес-логику, реализуют еще логику изменения этих данных. Т.е. это и модель, и контролер одновременно. Идея с единым диспетчером, как единый Event Bus с уникально именованными событиями, где можно быстро найти в коде, где что поменялось, делать быстрый рефакторинг, и компоненты работают изолировано друг от друга — это супер. Но совершенно непонятно, как обеспечивается динамика, как открыть, например, на одном экране два окна, которые бы работали независимо друг от друга, но при этом генерировали бы одинаково, например, события…

    По большому счету, Facebook ни фига не зарелизил код, этого нет, это ни фига не фреймворк, это некая архитектурная идея. Причем, изобретенная в 80-х годах, которая называется Event Bus.



    ОК. Давайте посмотрим какие-то сторонние фреймворки, которые реализуют эту фигню. Я пересмотрел штук пять, они все как две капли друг на друга похожи, и они все в этом плане намного хуже, чем AngularJS, и намного хуже, чем Ext JS, потому что в них нет почти ничего. Да, там лучше видно, как работает архитектура, но все еще нет речи ни о каком динамическом создании store’ов, их выгрузки и какой-то линковки UI компонентов между store’ами так, чтобы части приложения работали изолировано друг от друга и можно было бы два компонента создать одинаковыми, с одинаковым view, и два контроллера, и они бы не воевали друг с другом этими событиями. Поэтому в этом плане с разработкой веб-приложений все очень странно, т.е. зачастую непонятно, как это делать. Зато в этих фреймворках видно развитие javascript за последние 5 лет, в виде изоморфности, в виде npm-модулей, в виде вынесения функционала библиотеки, в виде поддержки ES6 — это хорошо. Только, блин, ни фига нет, вообще, никакой инфраструктуры тестирования у них, и непонятно как писать тест. Особенно с этой новой суперархитектурой непонятно, как писать тест. И нет интернационализации.

    Попутно мы наткнулись на typescript’ы. В этом плане это, вообще, бомба.



    Я подумал, что самый супер — убрать излишний креатив разных разработчиков, которые очень любят делать свои «велосипеды» — с помощью этого отлично можно. Typescript — это транс-компилятор, т.е. ты пишешь код, напоминающий javascript, с таким же синтаксисом, только расставляя типы. Т.е. у каждой переменной есть какой-то тип, причем, они могут быть сложными, может быть у переменной одновременно несколько типов, и в итоге он эти типы убирает, создавая тебе javascript-файл с абсолютно таким же синтаксисом, где просто убраны эти типы, и там еще есть несколько полезных syntactic sugarвещей, которые соответствуют стандартам ECMAScript 2006. Т.е. просто компилятор из ECMAScript 6 в 5.



    Там, например, есть такие сложные типы данных, когда ты можешь сделать целый контракт, т.е. там объекты с вложенной структурой, и теперь у тебя разные части приложения заранее знают, что из API приходит вот такой вот хитрый вложенный объект, или, например, повторяются в нем поля. Мы используем это как некий клей между отдельными частями приложения, т.е. каждый пишет эту бизнес-логику, ориентируясь на какой-то интерфейс. И компилятор при сборке сразу же проверяет, можно ли скомпилить это, правильно ли ты организуешь доступ к этим полям, правильный ли тип в них подразумеваешь.



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



    Точно так же, как в python’е, есть поддержка дженериков. Есть декораторы, как в в python’е, есть дженерики, как это принято в мире С++, и которыми мы активно пользуемся. И есть составные типы. В редких случаях, можно сказать, что в этой переменной может быть или строка, или число, тогда, когда этого не избежать. Он тоже нормально с этим работает.



    В итоге после этого исследования вопросов стало только больше. Какую архитектуру выбрать? Какое решение правильное? Как идти в ногу с развитием javascript, в виде ECMAScript 6? Где взять библиотеку UI компонентов?

    И в этом плане Ext JS очень активно держит удар, в нем все это есть. В нем есть своя сборка, в нем есть механизм интернационализации, в нем есть понятная архитектура и прочее. Т.е. то, что получилось тогда, получилось странно, но только альтернативы то нет. Ну, как бы, она есть, но ее надо делать самому. В итоге, хотим фреймворк с Typescript, все хотели на этот момент фреймворк с Typescript. Без — уже не хотел никто.



    Ну ладно, чего делать? Напишем задачу сами себе. JS-кодеры должны писать код. Верстальщики должны верстать и общаться с дизайнерами. Явно нужно сделать максимально простой UI слой, чтобы в нем разобрался дизайнер, и чтобы это было понятно программисту без жуткого наследования CSS-стилей в три-четыре уровня без жуткого наследования компонентов. Нужно сделать четкую и понятную архитектуру, код, примерно понятный бэкенд-разработчикам, и нужно разделение зон ответственности — отдельно верстка, отдельно код, отдельно контроллеры, отдельно хранение данных, стараться запихать состояние приложения в один какой-то тип классов, назвав его моделью. И, главное, больше границ, правил и стандартов: именования, форматирования кода, раскладки по файлам, всего этого дела. И при этом на Typescript. И при этом еще так, чтобы это все дело не было монолитным фреймворком, потому что все это дело нужно будет еще внедрить в существующий код.



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

    В итоге было несколько проблем.



    Первая проблема. Получается так, что store — это некий антипаттерн во flux. На практике у нас ничего хорошего с этим не вышло. Мы в итоге обратно разделили их на классы, которые хранят данные и могут их менять, и отдельно бизнес-логику в контроллере. Это примерно то же самое, куда сейчас идет развитие flux, когда у них есть отдельно вынесенные объекты со стейтом. У нас этот объект со стейтом просто называется store.



    Было вот так.

    Получилось примерно вот так:



    Т.е. изолированные блоки, примерно так же, как в AngularJS, с таким же механизмом, в виде модулей. В каждом модуле там один или несколько своих store’ов, которые общаются с одним из нескольких контроллеров. И в итоге все это дело работает отдельно от view. View только читает данные store’ов и генерирует некие action’ы, которые единый dispatcher раскидывает (на самом деле, не единый, у каждого изолированного блока может быть еще свой) между контроллерами, каждый из которых подписывается на события и решает, реагирует он на это событие или нет. В итоге у нас приложение работает как набор вложенных друг в друга приложений, в каждом из которых внутри flux. Это иерархический MVC, где view просто вложены друг в друга, а контролеры изолированы.

    Вторая проблема в том, что шаблоны Facebook предлагает делать вот так:



    Мы, конечно, долго мучились, мы поняли, что это вообще не вариант, и мы стреляем себе в ногу. Я абсолютно не понимаю, зачем мне нужно смешивать кучу JS-кода, фигурных скобочек, круглых скобочек, логику и все вместе в UI компоненте, когда, по большому счету, суть UI компонента в том, что он берет какой-то шаблон и рендерит его в браузере. Мы посмотрели на такой проект как wix-react-templates, написали свой, сильно-сильно похожий. Но в нем нет кода. Только есть блоки, которые обеспечивают итерацию, if, then, else и переменные, больше ничего нет. Т.е. задача компонента — в эту переменную запихать заранее то, что в ней будет выведено. И задача компонента — указать сколько раз итерировать какой блок с какими данными. Так выглядит шаблон:



    Вот такой мы написали свой собственный парсер этих шаблонов, который делает из него DOM-дерево и генерит такие шаблоны, сильно такие же, как их генерит JSХ:



    Вот, это дело уже автоматически генерится, и с этим делом работает React.



    И суть UI компонента в том, что он декларирует некие пропсы, декларирует некие стейты и в самом простом способе эти пропсы запихивает в блоки и в переменные. Построили некое дерево, которое потом рендерится.



    Для переводов мы сделали штучку, которая выкусывает текст из этих шаблонов и генерит нам файл. Мы этот файл ручками переводим на русский язык. Можно туда добавить какую-то верстку. Обратите внимание, там в последней сточке добавлен span. Это дело мы пока закладываем для плюрализации слов.



    И, соответственно, дальше генерится такой же шаблон, но только в нем эти строки заменены на строки на русском языке и этот span тоже распарсен и подставлен в шаблон.



    С динамикой беда в том, что не очень Facebook объясняет, как это делается, как сделать независимой работу двух компонентов. Мы в этом плане нашли несколько вариантов решений и сейчас их прорабатываем.

    Что в итоге получилось?



    Получился фреймворк с хорошим ООП и с маленьким интерфейсом, с дженериками, близко похожий на то, как это было написано на java. С dependency injection, которая обеспечивает связь классов внутри одного модуля, у которого только две внешние зависимости — это React и lodash. В котором можно сделать любую архитектуру — захотим рефлакс, можно сделать рефлакс, захотим MVC — можно сделать MVC. Потому что там три с половиной файла и плюс React. И с нормальным механизмом сборки через web-pack…



    Мы сделали два пилотных проекта — один на Ext JS 6, другой на React. Абсолютно с нуля, без использования существующего кода, оба повторяют один и тот же функционал существующей админки, но только одну единственную страницу на ней, на которой некоторые кнопки не кликаются. Достаточно немного, все это вместе заняло где-то месяц работы в сумме.

    Задачи были — сделать анимации, сделать кастомный, нами рисуемый скроллбар, сделать отдельный интерфейс для узких экранов типа а-ля планшетов, сделать отдельно мобильную версию, когда экран совсем узкий, и сделать, чтобы все это авторизировалось и ходило в json rest, грузило реальные данные, которые у нас есть в API и с ними позволяло работать.

    В итоге получились такие цифры:



    На них можно не смотреть, но суть в том, что оба проекта реализованы с нуля, получились так, что flux + react выигрывал от 2-х до 5-ти раз. Но с большой звездочкой, что когда у нас будет столько же UI компонент, сколько есть в ExtJS, размеры билдов и скорость инициализации, она, конечно, упадет, потому что в этом плане мы тягаемся с монстром индустрии.



    Ясно, что просто так на это дело не переехать. Поэтому мы сели, покурили все существующие интерфейсы с дизайнерами, собрали некий единый файл, в котором 60 простых компонентов типа панелей и кнопок, 15 сложных — это типа у нас есть таблица, в которой можно выключить какую-нибудь колонку, отсортировать ряды или, например, есть дроп-даун, в котором можно теги набирать — это прямо конкретно сложные вещи.



    Я некоторые из них заверстал. Прямо сделал рабочими компонентами на react’е, это у меня заняло где-то 4 дня.



    В итоге получилось так, что мы процентов 10 сделали, оценили, как 2 тыс. строк кода за 4 дня и получили примерную оценку в 2 человеко-месяца для реализации всех UI компонент, из которых состоят наши проекты.



    Долго думали, как делать, но пока решили так, что новые проекты сразу делаем на новом фреймворке, попутно создавая эту UI библиотеку в отдельном репозитории. Старый код не трогаем, но встраиваем «независимыми блоками» в него новый функционал в виде как «берем отдельную панель или страницу, ее переписываем на новой». Либо, если это новый функционал, то, вообще, делаем эту страницу сызнова. Соответственно, новый фреймворк прикидывается UI компонентом внутри Ext JS, делая вид, что это какая-то панель, которая как-то отрисовывается и внутри себя чего-то делает, а наружу, максимум, одно-два события отдает. И, конечно же, при модификации старого кода ты либо портируешь существующий функционал, либо правишь, как есть.



    Так что суть доклада, как всегда: превозмогайте трудности; велосипеды, баги, костыли — делайте все свое. Делайте свое, потому что ваша команда теперь обладает технологией и экспертными знаниями, как она работает. Т.е. мы читали исходники react’а и, наконец, понимаем, как же он, блин, работает.

    Контакты


    » XEK
    » s@averin.ru
    » facebook
    » twitter
    » Блог компании Acronis

    Этот доклад — расшифровка одного из лучших выступлений на конференции разработчиков высоконагруженных систем HighLoad++. Сейчас мы активно готовим конференцию 2016 года — в этом году HighLoad++ пройдёт в Сколково, 7 и 8 ноября.

    Также некоторые из этих материалов используются нами в обучающем онлайн-курсе по разработке высоконагруженных систем HighLoad.Guide — это цепочка специально подобранных писем, статей, материалов, видео. Уже сейчас в нашем учебнике более 30 уникальных материалов. Подключайтесь!

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

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

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

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

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

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

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

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

                                      Также присоединяюсь к ораторам, просящим статью на эту тему.
                                      • 0
                                        Это уже надо просить веб-команду написать вам ответ, щас попрошу, надеюсь, согласятся.
                                      • 0

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

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

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

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

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

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

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

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

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

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

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

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

                                                      • 0

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

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

                                                            Прямое.


                                                            к knockout

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


                                                            и MVVM?

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


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

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

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

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


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

                                                          • 0
                                                            Дмитрий, я все время забываю это слово — «бандл». Оно такое правильное:) Только бандлы надо спустить на уровень пониже.
                                                • 0
                                                  Knockout UI library — плохо… React тоже UI library c ваших слов — но это хорошо. В чем же тогда по-вашему разница между феймворком и библиотекой?


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

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

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

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

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

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

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

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

                                                      Нокаут очень не быстро это делает: https://eigenmethod.github.io/mol/perf/render/

                                                      • 0

                                                        У Alight время на кнопке не работает.

                                                        • 0

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

                                                        • 0
                                                          Там использован development build React'а с проверками и варнингами. Причём только реакта, остальные библиотеки там минифицированные. Интересно, это ошибка или попытка смухлевать?..
                                                  • +2
                                                    Поздравляю, такую задачу осилили.
                                                    Вообще, имхо, муки оценок и выбора — это, наверное, самое тяжелое, что есть в профессии. И с каждым годом все тяжелее — писателей не остановишь. И внятных оценок на эту тему — единицы
                                                    • +1
                                                      Нет, самое сложное в докладе не освещено — это как я все это дело задвигал и «продавал» сотоварищи соседним отделам, подчиненным и начальству. :-)
                                                    • –2
                                                      https://hsto.org/getpro/habr/post_images/5f1/038/58b/5f103858bcd821c2a9823932a0d781a8.png
                                                      • 0
                                                        к чему тут это? человек не пилит своё
                                                        • 0
                                                          Вы статью вообще читали?
                                                          • 0
                                                            Читал, а вы?
                                                            • –2
                                                              И каким же, позвольте спросить, местом вы читали? Уж не глазами это точно.

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

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

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

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

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

                                                              Получился фреймворк с хорошим ООП и с маленьким интерфейсом, с дженериками, близко похожий на то, как это было написано на java.
                                                              • 0
                                                                И? Где тут речь про новый стандарт? Вам навязывают индивидуальное решение? Стандарт, это то, что принимается для общественности. В данном случае люди для себя решение собрали.
                                                                • –7
                                                                  «Не стоит спорить со свиньей. Оба вываляетесь в грязи, но ей это понравится.»
                                                                  Спорить с вами больше не буду. Вам видимо ОЧЕНЬ нравиться.
                                                                  • +1
                                                                    О, отлично, опустились до оскорблений, ок.
                                                                • 0
                                                                  И в итоге все равно все это было задвинуто в 2016-м когда появился стабильный Angular 2.
                                                                  Как я и писал выше — количество самодельных вещей всегда должно регулироваться наличием ресурсов у команды на их поддержку и развитие.
                                                            • 0

                                                              -

                                                          • 0
                                                            Читал про ExtJs и во всё прям узнавал свою ситуацию, согласен с каждым пунктом по нему. Я тут тоже недавно для руководства писал небольшое техническое ревью по ExtJs 4, с целью убедить его в необходимости перехода на другую технологию. Многие пункты этого ревью пересекаются с вашими, можно сами почитать и добавлять комментарии в нём прям — техническое ревью по ExtJs 4
                                                            • 0
                                                              Вызовы Ajax запросов генерируются фреймворком, на основании заранее декларированных моделей, такой механизм взаимодействия приводит к:
                                                              •Снижению гибкости взаимодействия с сервером ( запросы должны укладываться в рамки текущих клиент-серверных сущностей )

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


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


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

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

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


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

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

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


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


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

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

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


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

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

                                                                        • 0
                                                                          Хм, очень странно, в моём случае как раз в плане разобраться как всё работает получилось именно с эмбером быстрее всего. Да и шаблонизация… от jsx прям тошнит, а Хэндлбарс, это что-то совсем родное, после Twig, очень комфортный был переход. Но да, вы правы, это всё-таки вкусовщина.
                                                                        • +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 не задумываясь. Моя эффективность на нем определенно выше.
                                                                          • 0
                                                                            Вот да, с датой пока идеального взаимопонимания у нас нет)
                                                                          • 0
                                                                            Автор вроде бы четко указал, что «всё водном» им избыточно. Хотят переиспользовать части/компоненты в разных проектах с разной сутью. Вон в ExtJS iframe-мом затолкали своё детище =)
                                                                            • 0
                                                                              Да, но в финалисты был записан и Angular)
                                                                          • 0
                                                                            А автор не смотрел в сторону Google Closure (не путать с Clojure)?
                                                                            Года три назад написали свой простенький фреймворк на основе имеющейся либы, полет нормальный.
                                                                            • 0
                                                                              Знал про него, но сильно не смотрел ввиду малой популярности. Этот вопрос был весьма важен для нас.
                                                                            • 0
                                                                              Все про производительность команды правильно сказано.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

                                                                                                          Извините, но вам на "Мой круг" или Хедхантер.

                                                                                                          • +1
                                                                                                            Не будьте так строги, это же крик отчаяния. Посмотрите на требования к начинающему программисту. Ёлки-палки, он ещё и опытных кодеров должен чему-то учить. На хедхантере таких точно нет.
                                                                                                          • 0
                                                                                                            Начинающего

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

                                                                                                            Начинающего

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

                                                                                                                                                Это иное.

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

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

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

                                                                                                                                                А вот, “наплевать на всё» и сделать по своему — как на душе лежит — это уже из другой оперы «навык». ;-)
                                                                                                                                                • 0
                                                                                                                                                  Да, спасибо за пояснение :-)
                                                                                                                                        • 0
                                                                                                                                          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?

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

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

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

                                                                                                                                            Даже к ангуляровскому шаблону. ;-)