Комментарии 20
Одна из сложных задач современной разработки — это программирование пользовательского интерфейса.
Простите, не удержался, но мне кажется, что разработать эффективный алгоритм аэродинамического моделирования все же по-сложнее будет, чем кнопочки на формочке разместить.
Заодно расскажет и покажет идеальный JS-фреймворк для программирования UI.
ReactJS? Идеальный фреймворк? Ну есть основания сомневаться.
Невероятно громкий заголовок, а внутри — очередное видео по реакту и как он крут, которых если не тысячи, то миллионы.
С увеличением количества элементов сложность увеличивается нелинейно и совладать с огромным количеством вариантов, состояний и переходов становится практически невозможно.
Вы видели IDE, например, Visual Studio, или какой-то узко специализированный софт на подобие quartus? Современным веб-интерфейсам по обилию состояний и переходов далековато до них, но там как-то вполне ничего так решили проблемы еще 20 лет назад без реактов (про квартус).
Простите, не удержался, но мне кажется, что разработать эффективный алгоритм аэродинамического моделирования все же по-сложнее будет, чем кнопочки на формочке разместить.
Я как-то писал шейдер для генерации трехмерных многослойных текстур и несмотря на несравненно более сложный код, практически нулевую поддержку отладки и задачу которая полностью исключает использование дебага для отладки алгоритма, я все равное считаю, что писать интерфейс сложнее. Не потому что там сложная математика или алгоритмы, а из за объема сценариев которые нужно поддерживать. Это скучно, выматывающе и совершенно не интересно.
Вы видели IDE, например, Visual Studio, или какой-то узко специализированный софт на подобие quartus? Современным веб-интерфейсам по обилию состояний и переходов далековато до них, но там как-то вполне ничего так решили проблемы еще 20 лет назад без реактов (про квартус).
Эти штуки написаны на других языках. Когда HTML создавался, никто не думал, что он будет использоваться для написания полноценных приложений. Проблема не в том, что в общем случае нет решений, а в том что для веб нет решений.
Эти штуки написаны на других языках. Когда HTML создавался, никто не думал, что он будет использоваться для написания полноценных приложений. Проблема не в том, что в общем случае нет решений, а в том что для веб нет решений.
Cloud9 я тыкал еще когда реакта в планах еще не было, а ангулар был на стадии зиготы. И ничего, справлялись.
Я профессионально занимаюсь веб-разработкой, ну и каким-то чудесным образом разработка именно web-app прилипла ко мне, что каждый проект в ней и заключается. Единственная проблема, с которой я сталкиваюсь — требования (порой, радикальные) появляются быстрее, чем реализуются. В итоге все превращается в… кхм… HTML + js на данном этапе своей эволюции в разы обошли по простоте разработки UI WPF, QML и что угодно. На нем настолько проще и быстрее делать UI, что на него переходят все, кому не лень (опустим споры хорошо это или плохо, но это факт). Просто развелся невероятный зоопарк подходов и фреймворков, что просто теряешься. Начинаешь городить события тогда, когда можно напрямую вызвать метод у объекта без запарок с отпиской и подпиской. Все искусственно усложняется, причем само собой, при этом все требуют реализации в невероятно короткие сроки.
Однако если остановится на секунду, выйти из этого урагана, который последние годы окружил JS, подумать немного — да что там эти формочки делать? Как-то мы сами себе накрутили. Да, предусмотреть все варианты поведения пользователя, но черт возьми — если сценарий типа «кликнуть в шапке, кликнуть в статье, вбить текст, нажать отправить и перейти в другой топик» по какой-то причине образно говоря красит вашу аватарку в синий — у вас что-то не так с архитектурой. Так можно и с hello world проблем поиметь, если решить, что этот hello world должен выводиться только когда фаза луны — полнолуние.
сценарий типа «кликнуть в шапке, кликнуть в статье, вбить текст, нажать отправить и перейти в другой топик»
Плюс как минимум показать ошибки валидации, сервера и авторизации, при этом не стерев пользовательский ввод. Это реальные проблемы.
А зоопарк решений будет всегда. Многие веб разработчики вообще не программисты и для них нужны инструменты попроще. Но если вы попробуете писать на ваниле, то дизайнер на ангуляре вас все равно обгонит (никого не хочу обидеть, просто у него низкий порог вхождения), даже если вы в тыщу раз лучший программист.
Верстка HTML проще чем QML? Мне представляется совсем наоборот.
Если вы профессионально занимаетесь веб-разработкой и всё ещё вручную подписываетесь на события и отписываетесь от них, то у меня для вас плохие новости :-) Я уже несколько лет как не вешал событий сам — это неплохо автоматизируется.
Так может того… не нужно использовать HTML для этого?
> все же по-сложнее будет, чем кнопочки на формочке разместить
Встречал такое пренебрежение к задачам UI и мой опыт подсказывает обратное, обычно в этих задачах концентрируется основная сложность. Задачи где не требуется менять UI проходят гораздо проще.
Встречал такое пренебрежение к задачам UI и мой опыт подсказывает обратное, обычно в этих задачах концентрируется основная сложность. Задачи где не требуется менять UI проходят гораздо проще.
Алгоритмы аэродинамического моделирование и программирование пользовательского интерфейса оба сложны. Но сложны по-разному. GUI (как и БД, например) мне сложнее морально делать. Это скучно, неинтересно и так далее по списку aikixd.
Восторгаться Реактом, не имея представления о веб-компонентах и Полимере — как-то не честно.
Для хранения состояния — Flux, Redux сторы.
Реакт это действительно фундаментальная вещь, и на мой взгляд его рост сдерживается, в первую очередь, сложностью инфраструктуры окружающей такую простую, и гениальную при этом концепцию. Обычным прагматичным программистам, у которых никогда не было мечты о написании своего компилятора или создании машины тюринга, и у которых вчера даже ES5 js не был основным языком программирования — вдруг сверху наваливают сразу кучу новых концепций. Именно из-за магических слов flux, immutable, babel, es6 человек берет и по-старинке делает проект на angular или даже jquery, не сильно заботясь о сложности которая будет расти (в близкой к) геометрической прогрессии при усложнении интерфейсов — стартовать-то проще, все из коробки! Это очень важно понимать людям которые развивают реакт. Взлет того же redux по звездочкам показывает как людям нужны предельно простые концепции и что-то понятное и работающее из коробки — в фейсбуковском flux чуть перегнули с заложенной в платформу scalability и все, труба, критичную массу обычных разрабов, использующих технологию, тяжелее набрать за короткое время. На этом немало технологий погорело, забыли про простых людей и остались уделом упоротых гиков которые любят собирать из кирпичиков гениальные шедевры :) Но думаю у реакта в этом плане все будет хорошо, на глазах становятся мейнстримом. Еще пару месяцев назад мы не могли найти разработчика знакомого с react-native, а через полгода ситуация, думаю, кардинально изменится.
От WinAPI убегали средствами VLC, MFC, и тд.
От HTML улетали через jQuery, extJS, и тд. Но в общем случае это визуальные библиотеки. Не фреймворки.
QT, Flux и различные стейтмашины — это уже другой уровень.
В том числе React как-то подозрительно на дельфя(на VLC/CXL) подход смахивает.
Но аналога Flux лет 10-20 назад лично я вспомнить не могу. Слоты/сигналы, MQ… и все…
От HTML улетали через jQuery, extJS, и тд. Но в общем случае это визуальные библиотеки. Не фреймворки.
QT, Flux и различные стейтмашины — это уже другой уровень.
В том числе React как-то подозрительно на дельфя(на VLC/CXL) подход смахивает.
Но аналога Flux лет 10-20 назад лично я вспомнить не могу. Слоты/сигналы, MQ… и все…
ReactJS не фреймворк, а UI библиотека. AngularJS вполне себе фреймворк.
Можно небольшой фидбэк на презентацию? Посмотрел 18 минут, и разговор о том, как сложны переходы между страницами, не завершен. Я не дебил, я понял это еще на 5-й минуте. Можно уже к делу?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему сложно программировать UI и как выглядит идеальный фреймворк