Одна из сложных задач современной разработки — это программирование пользовательского интерфейса. С увеличением количества элементов сложность увеличивается нелинейно и совладать с огромным количеством вариантов, состояний и переходов становится практически невозможно. Фреймворки вроде Angular со своим двусторонним связыванием пытается решить эту проблему, но на фундаментальном уровне ничего не меняется.
Со-основатель, технический директор и главный учитель нашего образовательного проекта Хекслет Кирилл Мокевнин рассказывает про сложность программирования интерфейсов и каким образом можно совладать со сложностью если вы знакомы с одной базовой концепцией информатики. Заодно расскажет и покажет идеальный JS-фреймворк для программирования UI.
Доклад с конференции FrontHub 2015. Спасибо за запись организаторам конференции!
Комментарии (20)
i360u
19.01.2016 18:00+5Восторгаться Реактом, не имея представления о веб-компонентах и Полимере — как-то не честно.
restyler
20.01.2016 02:42-2Реакт это действительно фундаментальная вещь, и на мой взгляд его рост сдерживается, в первую очередь, сложностью инфраструктуры окружающей такую простую, и гениальную при этом концепцию. Обычным прагматичным программистам, у которых никогда не было мечты о написании своего компилятора или создании машины тюринга, и у которых вчера даже ES5 js не был основным языком программирования — вдруг сверху наваливают сразу кучу новых концепций. Именно из-за магических слов flux, immutable, babel, es6 человек берет и по-старинке делает проект на angular или даже jquery, не сильно заботясь о сложности которая будет расти (в близкой к) геометрической прогрессии при усложнении интерфейсов — стартовать-то проще, все из коробки! Это очень важно понимать людям которые развивают реакт. Взлет того же redux по звездочкам показывает как людям нужны предельно простые концепции и что-то понятное и работающее из коробки — в фейсбуковском flux чуть перегнули с заложенной в платформу scalability и все, труба, критичную массу обычных разрабов, использующих технологию, тяжелее набрать за короткое время. На этом немало технологий погорело, забыли про простых людей и остались уделом упоротых гиков которые любят собирать из кирпичиков гениальные шедевры :) Но думаю у реакта в этом плане все будет хорошо, на глазах становятся мейнстримом. Еще пару месяцев назад мы не могли найти разработчика знакомого с react-native, а через полгода ситуация, думаю, кардинально изменится.
kashey
20.01.2016 08:24От WinAPI убегали средствами VLC, MFC, и тд.
От HTML улетали через jQuery, extJS, и тд. Но в общем случае это визуальные библиотеки. Не фреймворки.
QT, Flux и различные стейтмашины — это уже другой уровень.
В том числе React как-то подозрительно на дельфя(на VLC/CXL) подход смахивает.
Но аналога Flux лет 10-20 назад лично я вспомнить не могу. Слоты/сигналы, MQ… и все…
Fesor
20.01.2016 19:55Но аналога Flux лет 10-20 назад лично я вспомнить не могу
Event Sourcing + CQRS погуглите.
itblogger
21.01.2016 09:08+2Можно небольшой фидбэк на презентацию? Посмотрел 18 минут, и разговор о том, как сложны переходы между страницами, не завершен. Я не дебил, я понял это еще на 5-й минуте. Можно уже к делу?
kahi4
Простите, не удержался, но мне кажется, что разработать эффективный алгоритм аэродинамического моделирования все же по-сложнее будет, чем кнопочки на формочке разместить.
ReactJS? Идеальный фреймворк? Ну есть основания сомневаться.
Невероятно громкий заголовок, а внутри — очередное видео по реакту и как он крут, которых если не тысячи, то миллионы.
Вы видели IDE, например, Visual Studio, или какой-то узко специализированный софт на подобие quartus? Современным веб-интерфейсам по обилию состояний и переходов далековато до них, но там как-то вполне ничего так решили проблемы еще 20 лет назад без реактов (про квартус).
aikixd
Я как-то писал шейдер для генерации трехмерных многослойных текстур и несмотря на несравненно более сложный код, практически нулевую поддержку отладки и задачу которая полностью исключает использование дебага для отладки алгоритма, я все равное считаю, что писать интерфейс сложнее. Не потому что там сложная математика или алгоритмы, а из за объема сценариев которые нужно поддерживать. Это скучно, выматывающе и совершенно не интересно.
Эти штуки написаны на других языках. Когда HTML создавался, никто не думал, что он будет использоваться для написания полноценных приложений. Проблема не в том, что в общем случае нет решений, а в том что для веб нет решений.
kahi4
Cloud9 я тыкал еще когда реакта в планах еще не было, а ангулар был на стадии зиготы. И ничего, справлялись.
Я профессионально занимаюсь веб-разработкой, ну и каким-то чудесным образом разработка именно web-app прилипла ко мне, что каждый проект в ней и заключается. Единственная проблема, с которой я сталкиваюсь — требования (порой, радикальные) появляются быстрее, чем реализуются. В итоге все превращается в… кхм… HTML + js на данном этапе своей эволюции в разы обошли по простоте разработки UI WPF, QML и что угодно. На нем настолько проще и быстрее делать UI, что на него переходят все, кому не лень (опустим споры хорошо это или плохо, но это факт). Просто развелся невероятный зоопарк подходов и фреймворков, что просто теряешься. Начинаешь городить события тогда, когда можно напрямую вызвать метод у объекта без запарок с отпиской и подпиской. Все искусственно усложняется, причем само собой, при этом все требуют реализации в невероятно короткие сроки.
Однако если остановится на секунду, выйти из этого урагана, который последние годы окружил JS, подумать немного — да что там эти формочки делать? Как-то мы сами себе накрутили. Да, предусмотреть все варианты поведения пользователя, но черт возьми — если сценарий типа «кликнуть в шапке, кликнуть в статье, вбить текст, нажать отправить и перейти в другой топик» по какой-то причине образно говоря красит вашу аватарку в синий — у вас что-то не так с архитектурой. Так можно и с hello world проблем поиметь, если решить, что этот hello world должен выводиться только когда фаза луны — полнолуние.
aikixd
Плюс как минимум показать ошибки валидации, сервера и авторизации, при этом не стерев пользовательский ввод. Это реальные проблемы.
А зоопарк решений будет всегда. Многие веб разработчики вообще не программисты и для них нужны инструменты попроще. Но если вы попробуете писать на ваниле, то дизайнер на ангуляре вас все равно обгонит (никого не хочу обидеть, просто у него низкий порог вхождения), даже если вы в тыщу раз лучший программист.
Zifix
Верстка HTML проще чем QML? Мне представляется совсем наоборот.
vintage
Если вы профессионально занимаетесь веб-разработкой и всё ещё вручную подписываетесь на события и отписываетесь от них, то у меня для вас плохие новости :-) Я уже несколько лет как не вешал событий сам — это неплохо автоматизируется.
Zenitchik
Чисто синтаксические различия.
vintage
С тем же успехом можно сказать, что и JS от ASM имеет лишь синтаксические отличия :-)
evocatus
Так может того… не нужно использовать HTML для этого?
aikixd
Не нужно. Но врядли браузероделатели договорятся о новом стандарте.
orcy
> все же по-сложнее будет, чем кнопочки на формочке разместить
Встречал такое пренебрежение к задачам UI и мой опыт подсказывает обратное, обычно в этих задачах концентрируется основная сложность. Задачи где не требуется менять UI проходят гораздо проще.