Комментарии 26
Не используйте React там, где есть сложные интерфейсы. React очень удобен для обычного сайта, но если вы делаете сложные компоненты, управляемые с помощью стрелок на клавиатуре, фокуса, горячих клавиш, с большой связанностью элементов между собой, то пишите код на чистом js.
Вот тут не соглашусь. Я предпочитаю именно Реакт, потому что он позволяет внятно разбубенить логику.
Грубо говоря я пишу
<>
<ComponentWithHotkeys/>
<ComponentWithArrows/>
<ComponentEsheKakoiTo/>
</>
не задумываясь об имплементации. А вот когда понимаю, что они должны быть связаны, то начинается вселуха с выносом стейта наверх. НО! Это важная веселуха. Потому что на чистом js оно уйдет под капот и прокатит только в простом интерфейсе, в сложном же легко себя загнать в архитектурный адъ и погибель
Сами ваши аргументы очень сомнительные:
Во-первых это круто.
не-а
Во-вторых у вас будет гораздо больше контроля за поведением.
Это да, но я предпочту меньше контроля с большим количеством абстракции
В-третьих высокая производительность достигается самим фактом написания кода на чистом js.
Чеее?
Я не смог написать код на чистом js работающий медленнее и обладающий большим количеством багов, чем приложение на React, написанное людьми с опытом React более 7 лет.
Бывает
Ну и не очень ясно что именно эта ваша ИДЕ, я так понял что это типа комбайн для всей команды сразу с "упрощением" разработки за счет WYSIWYG и вижуального программирования через блоксхемы?
Абстракции это хорошо, до тех пор, проект не превращается в абстракцию над абстракциями с кучей связанных сущностей. Когда структура проекта начинает напоминать конвейер абстракций, то смысл и плюсы реакта начинают теряться. Но минусы конечной имплементации никуда при этом не деваются.
Тот же компонент files tree из любой популярной IDE, который будет работать так же, т.е. поддерживать множественные выделения мышкой, клавиатурой, хоткеи для выделения, какую-то работу с выделенными элементами, каким-то образом отдавать все это наверх написать можно хорошо только исключительно при наличии полного ТЗ на этапе начала разработки и достаточно опытным разработчиком в подобных задачах. Если этого нет, то компонент превращается в простыню из неконтролируемого кода, который невозможно поддерживать и развивать. Начинаются баги связанные со стейтом и перерисовками.
Да, всегда можно сказать, что автор компонента плохой разработчик, особенно если он уже уволился, заложить месяц на рефакторинг, кинуть в бэклог и уйти пить латте. И в конечном итоге получается классическая схема развития веб-продуктов из моей статьи.
Про веселуху в выносом стейта наверх - вот тут начинается самая веселая часть. Что использовать? Redux с его тонной бойлерплейта на каждый чих точно не подходит если цель сделать задачу, а не получать зарплату. Локальные стейты GraphQL - лучше вообще не вспоминать. MobX лучше, но у него тоже есть ограничения. Далее почти всегда начинается простыня из прокиданных слушателей. Итого полез поправить кнопочку, а открыто 30 файлов с невнятными названиями.
Чеее?
На тему скорости. К сожалению, статью не нашел, но нашел наше обсуждение ее про то, как atom хотели переписать на react
Hidden text
Мы имеем более 100 мс скорости реакции на React и около 10 на чистом js. В какой-то момент это становится критично.
Потому что на чистом js оно уйдет под капот и прокатит только в простом интерфейсе, в сложном же легко себя загнать в архитектурный адъ и погибель
К сожалению, я видел много примеров архитектурного ада и погибели не выходя из React, чтобы сказать что в React этого добиться сложнее.
Ну и не очень ясно что именно эта ваша ИДЕ, я так понял что это типа комбайн для всей команды сразу с "упрощением" разработки за счет WYSIWYG и вижуального программирования через блоксхемы?
А вот за этот вопрос огромное спасибо. Сказать честно, мы пока не придумали как описать WE достаточно кратко и понятно.
По своей сути WE состоит из 3 частей:
1) Технологии - мета-фрейморк, который понимает машина и может с ним работать. На нем можно, вполне себе, писать без IDE. Пока не знаю, зачем это может понадобиться, но можно. Предположим, чтобы написать крутую библиотеку компонентов и сразу собрать ее для всех популярных фрейморков.
2) Идеология и подходы к разделению труда - в целом описана в статье.
3) Непосредственно IDE, которая является примерно именно тем, что вы сказали. Только упрощение не в кавычках. Оно ощущается, иначе бы это был очередной (сбился со счета) забракованный мной проект, пылящийся где-то на харде.
Мне очень не нравится как у вас чистый js без реакта начинает проявлять какие-то чудесные магические свойства.
Если этого нет, то компонент превращается в простыню из неконтролируемого кода, который невозможно поддерживать и развивать.
Вот тут я правильно понял, что не будь реакта, на чистом js такого бы не случилось?
Это же бред. Вы когда доказываете, что реакт плох - доказывайте по существу, а не просто "ну на чистом js збс по моим ощущением, а реакт какой-то сложный". Точно так же и скорость "я видел много примеров" - это вообще не аргумент. Я тоже много чего видел, и что теперь?
В какой-то момент это становится критично.
Предположу, что это от того что там сделали точечную оптимизацию, а не потому что просто выкинули реакт и сделали то же самое на чистом js. Хотя без статьи, просто по двум графикам сложно понять.
Напомню изначальное утверждение - "В-третьих высокая производительность достигается самим фактом написания кода на чистом js.". Каюсь, я его понял не как "точечная оптимизация критического участка на чистом будет быстрее", а как "если писать приложение на чистом js, оно по дефолту будет быстрее чем реакт"
===
Я как раз думаю слезть с вебшторма и поэтому прочитал статью 2 раза, хотел даже посмотреть какой у вас intellisense, но меня смутило что если я в своих пет-проектах и дизайнер и разраб - то мне lowcode не сдалось.
Как вам ниже написали, нехватает юзер сторей, но это от того что вы не смогли донести мысль, что такое WE.
Мой мессадж заключается в том, что написать плохо можно как с фреймворками, так и без. А вот действительно хорошо можно написать исключительно на чистом js. Даже в вопросах архитектуры подход с чистым js позволяет одним импортом в корневом файле добавить какой-либо функционал в любое место. Это, кстати, позволяет писать расширения для IDE любой сложности без каких либо трат на поддержку. Просто пройтись в цикле по массиву ссылок на js файлы. Примерно так работают плагины в vscode.
Вопрос не только в точечных оптимизация, но и глобальных. Сам подход написания на чистом js позволяет не думать о перерисовках и рисовать только нужное и когда нужно. Написать рендеринг и отклик на события медленнее, чем это сделано в реакте - нужно реально очень постараться.
Я как раз думаю слезть с вебшторма и поэтому прочитал статью 2 раза, хотел даже посмотреть какой у вас intellisense, но меня смутило что если я в своих пет-проектах и дизайнер и разраб - то мне lowcode не сдсдалось.
На самом деле нужно, но моя проблема в том, что я не смог объяснить зачем. Я пробовал делать тестовые проекты и вёрстка получается быстрее в несколько раз, чуть ли не на порядок. Текущая проблема решения заключается в том, что пока оно сырое. Много вещей можно сделать понятнее и быстрее. Или просто сделать.
Еще один плюс WE заключается в том, что продвинутый intellisense в теории не нужен. Автокомплита и инструмента рефакторинга пока более чем достаточно.
Для кода, если он вдруг потребуется, у нас есть встроенный monaco (vscode), но в первом релизе, кажется, мы никак не успеем сделать непосредственно написание кода в любом виде, включая lowcode. Сейчас мы сфокусированы на удобном инструменте для верстки, включая примитивную логику типа проброса пропов и стилей, и вывода всего этого в красивый react-код, поверх которого можно писать любую логику.
Я могу написать вам в тот момент, когда мы будем готовы показывать WE хотя бы не публично.
Спасибо!
Думаете при таком различии мнений есть смысл?)
В целом смотрите сами, я собираюсь писать игру на react+pixijs+node с самописным движком, если думаете что под это влезет WE то пишите
А вот действительно хорошо можно написать исключительно на чистом js.
А реакт на каком-то грязном js написан? Ни в коей мере не защищаю его, но недоумеваю с вашей логики.
Реакт это прекрасный фреймворк, который отлично подходит для большинства задач. Но он обладает рядом архитектурных особенностей, ограничений и проблем с производительностью. И это является следствием его удобности.
Мысль такая: Каждой задаче подходят свои технологии. Если вы делаете сложную программу, то, вероятно, стоит подумать чуть дольше.
Сам js обладает рядом архитектурных особенностей, ограничений и проблем с производительностью, но это вам почему-то не мешает утверждать что он няшка, а вот реакт плохой.
Например, вы рассказываете про время реакции интерфейса в 10мс, а в геймдеве рендерят 100+ кадров в секунду (включая UI, некислую 3D-сцену, сеть, звук и обсчёт сущностей в игровом мире) и недоумевают с ваших цифр.
Да, поэтому JS не используют для разработки игр. Если бы я написал "пишите игры на плюсах, а не на js", то вы бы пришли отстаивать js или говорить о том, что в сравнении с асмом плюсы работают медленно?) Мне кажется нет. Для задач отображения сложного UI производительность JS достаточная, производительности React уже не хватает. Архитектурно - аналогично. Там, где начинаются ref, заканчивается красивый реакт и начинается неуправляемый спагетти-код на костылях.
Даже в вопросах архитектуры подход с чистым js позволяет одним импортом в корневом файле добавить какой-либо функционал в любое место. Это, кстати, позволяет писать расширения для IDE любой сложности без каких либо трат на поддержку. Просто пройтись в цикле по массиву ссылок на js файлы. Примерно так работают плагины в vscode.
Можете раскрыть мысль про расширения чуть подробнее, пожалуйста?
Лучше бы концепты описали что оно должно делать и как должно работать, а так потратили много времени на много букав, а по сути только "враппер над фреймворками" с обещаниями облегчить верстку.
Концепты в каком формате? Различные User Story по IDE? Более подробное описание технологий?
У меня нет опыта продвигать и рассказывать про технологии, поэтому написал такую многословную солянку из абстрактного текста и немного затронул интерфейсы. Нужно учиться этому. Либо давать интервью людям, которые умеют, а я таких не знаю :-(
Различные User Story по IDE
Да. В каждой истории нужно подчеркнуть ту лёгкость разработки, которую вы обещаете. Видимо истории делятся на две группы - по IDE с указанием упрощений в сравнении с другими IDE, и по "мета-фрейморку" (как вы его называете), с указанием, что конкретно он делает за разработчика и что конкретно остаётся делать разработчику.
И есть сомнение, состоящее в том, что вы собрались конкурировать с другими разработчиками IDE, которые пилят свои проекты уже десятки лет и накопили очень большой багаж знаний. Плюс команды разработки у них на пару порядков больше вашей. Даже не знаю, как в таких условиях можно выжить.
Поэтому мы имеем возможность на лету менять технологический стек и собирать проект в любом желаемом конечном виде. Например, использовать React на основе cra или next.js, или переключиться на Vue.
Если набросать на одну страницу разных компонент, то на неё подтянет сразу все фреймворки? А скоро ждать поддержки $mol?
в теории нет необходимости использовать человекочитаемые фреймворки как промежуточную точку компиляции и можно добиваться реактивности за счет страшного машинного js
А можно всё же генерировать красивый машинный js?
Только комментарий сверху выдает то, что этот код написал не живой разработчик, а машина.
Так и вижу, что разработчик вместо передачи кнопке флага активности, меняет её на другую кнопку только для того, чтобы немного поменять её цвет.
Представляем себе что-то типа xaml
Зачем переусложнять себе жизнь? Используйте view.tree.
Properties. С панелью явно что-то не так, но пока мы не знаем что именно и как это исправить
Не так тут по всей видимости то, что конкретные стили зашиваются прямо в компонент, что затрудняет использование чужих компонент в своём дизайне.
Если набросать на одну страницу разных компонент, то на неё подтянет сразу все фреймворки? А скоро ждать поддержки $mol?
Исключено. Выбирается фреймворк для сборки и все весь результат работы будет на одном стеке.
А можно всё же генерировать красивый машинный js?
Спросите это у вебпака :)
Так и вижу, что разработчик вместо передачи кнопке флага активности, меняет её на другую кнопку только для того, чтобы немного поменять её цвет
А такие есть. Тут же это тестовый проект, кнопки выше разрабатывались до появления props и ui states. Но спасибо, что посмотрели код. Значит я не зря его добавил.
Не так тут по всей видимости то, что конкретные стили зашиваются прямо в компонент, что затрудняет использование чужих компонент в своём дидизайне.
Тут панель для визуального редактирования верстки и моё негодование относительно сложности и перегруженности интерфейса.
Стили можно пробрасывать извне и можно на них ссылаться.
Спасибо за критику, это действительно то, что нужно на этом моменте. Как минимум, чтобы знать то, о чем писать в следующий раз и в документации. А как максимум - пересмотреть какие-то вещи.
Выбирается фреймворк для сборки и все весь результат работы будет на одном стеке.
Так скоро ждать поддержки $mol?
Спросите это у вебпака :)
Может ну его?
Спасибо за критику, это действительно то, что нужно на этом моменте.
Так для критики как раз не хватает деталей. Ну или примера в онлайне. Как задаются/передаются параметры и их типы? Как переопределяются стили в конкретном месте использования? Как задаются направления движения данных? И тд.
Это наверное оффтоп, но все же. Low-code снижает планку для разработчика, причем навыки работы в одной low-code платформе очень специфичны и вряд ли пригодятся в другой. Значит, low-code разработчик менее ценен чем обычный, и по возможности эту стезю нужно избегать?
Да, я это знаю и понимаю. Именно поэтому это не классическое lowcode-решение. В идеале WE должен быть похож на Unreal Engine, соответственно разработчики будут нужны как и раньше. Просто той части разработчиков, что сейчас путаются в синтаксисе (а таких очень много) будет работать несколько проще. В идеальном мире, каким я его вижу, в будущем все придут к подобным движкам для веба.
Если разработчик путается в синтаксисе (то есть, вообще в самой простейшей части, в самых азах), то что он вообще забыл в разработке?
Затыкает дыры в штате, пишет на реакте, очевидно же :) Это вообще по-сути целевая аудитория визуальных редакторов и лоукод по умолчанию.
Но на самом деле это ужасная боль. Рекорд указанного опыта у нулевого разраба - 5 лет. 5 лет человек работал в 4 компаниях, что-то делал на реакте, но не знает синтаксиса js. Куда уже ниже порог?)
Посмотрите AppGyver. В своё время он мне много открытий чудных принёс в стиле "о, а так гораздо логичнее и проще"
Вас обманули, "компоненты" в "реакте" - это более чем шаблоны. Так что тут ни реактивности, ни компонентности.
Немного о WebEngine — low-code IDE для разработки современных веб-приложений