Pull to refresh
17
0
Kirill Kosolapov @KirAmp

User

Send message

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

Но на самом деле это ужасная боль. Рекорд указанного опыта у нулевого разраба - 5 лет. 5 лет человек работал в 4 компаниях, что-то делал на реакте, но не знает синтаксиса js. Куда уже ниже порог?)

Да, поэтому JS не используют для разработки игр. Если бы я написал "пишите игры на плюсах, а не на js", то вы бы пришли отстаивать js или говорить о том, что в сравнении с асмом плюсы работают медленно?) Мне кажется нет. Для задач отображения сложного UI производительность JS достаточная, производительности React уже не хватает. Архитектурно - аналогично. Там, где начинаются ref, заканчивается красивый реакт и начинается неуправляемый спагетти-код на костылях.

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

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

Чем больше отличается мнение, тем лучше же :)

WE под ваш проект точно не подойдёт в ближайшее время.

Да, я это знаю и понимаю. Именно поэтому это не классическое lowcode-решение. В идеале WE должен быть похож на Unreal Engine, соответственно разработчики будут нужны как и раньше. Просто той части разработчиков, что сейчас путаются в синтаксисе (а таких очень много) будет работать несколько проще. В идеальном мире, каким я его вижу, в будущем все придут к подобным движкам для веба.

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

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

Я как раз думаю слезть с вебшторма и поэтому прочитал статью 2 раза, хотел даже посмотреть какой у вас intellisense, но меня смутило что если я в своих пет-проектах и дизайнер и разраб - то мне lowcode не сдсдалось.

На самом деле нужно, но моя проблема в том, что я не смог объяснить зачем. Я пробовал делать тестовые проекты и вёрстка получается быстрее в несколько раз, чуть ли не на порядок. Текущая проблема решения заключается в том, что пока оно сырое. Много вещей можно сделать понятнее и быстрее. Или просто сделать.

Еще один плюс WE заключается в том, что продвинутый intellisense в теории не нужен. Автокомплита и инструмента рефакторинга пока более чем достаточно.

Для кода, если он вдруг потребуется, у нас есть встроенный monaco (vscode), но в первом релизе, кажется, мы никак не успеем сделать непосредственно написание кода в любом виде, включая lowcode. Сейчас мы сфокусированы на удобном инструменте для верстки, включая примитивную логику типа проброса пропов и стилей, и вывода всего этого в красивый react-код, поверх которого можно писать любую логику.

Я могу написать вам в тот момент, когда мы будем готовы показывать WE хотя бы не публично.

Спасибо!

Если набросать на одну страницу разных компонент, то на неё подтянет сразу все фреймворки? А скоро ждать поддержки $mol?

Исключено. Выбирается фреймворк для сборки и все весь результат работы будет на одном стеке.

А можно всё же генерировать красивый машинный js?

Спросите это у вебпака :)

Так и вижу, что разработчик вместо передачи кнопке флага активности, меняет её на другую кнопку только для того, чтобы немного поменять её цвет

А такие есть. Тут же это тестовый проект, кнопки выше разрабатывались до появления props и ui states. Но спасибо, что посмотрели код. Значит я не зря его добавил.

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

Тут панель для визуального редактирования верстки и моё негодование относительно сложности и перегруженности интерфейса.

Стили можно пробрасывать извне и можно на них ссылаться.

Спасибо за критику, это действительно то, что нужно на этом моменте. Как минимум, чтобы знать то, о чем писать в следующий раз и в документации. А как максимум - пересмотреть какие-то вещи.

Концепты в каком формате? Различные User Story по IDE? Более подробное описание технологий?

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

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

Тот же компонент 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, которая является примерно именно тем, что вы сказали. Только упрощение не в кавычках. Оно ощущается, иначе бы это был очередной (сбился со счета) забракованный мной проект, пылящийся где-то на харде.

Эмодзи это unicode-символы, т.е. псевдографика, которая есть в большинстве основных шрифтов и работают из коробки везде, где есть юникод.

Смайлики это некая последовательность символов, которую реплейсит каждый конкретный фронтэнд, и рисуя самостоятельно эти смайлики.

Казалось бы, на выходе получается одно и тоже, какая разница? А разница огромна, смайлики — это баловство, их никто не будет поддерживать в 99% софта, а эмодзи — это инструмент и часть стандарта, который работает везде.

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

Так-то эмодзи пошли из очень древнего способа рисования форм, которые использовали еще до появления графического интерфейса в современном виде.

Мы с коллегами тоже думали над хуками и разродились на библиотеку react-hoox, и как-то уже и стейты не нужны стали, и редакс. Все никак не доберемся написать на хабр статью подробную. Пока только readme.md закончили более-менее

Мы с коллегами тоже задумались над этой проблемой, наше решешие — библиотека react-hoox, которая родилась нашими стараниями.
Бойлерплейт отсутствует, один маленький хук и любой объект становится реактивным.
Через какое-то время мы напишем полноценную статью на хабре про нее. А пока в тестовом режиме собираем фитбек и пробуем в продакшене

Увы, я как обладатель 3 мышей от Microsoft никому не посоветую их.
Предыдущее поколение Arc Mouse обладало крайне глючным софтом: тач-прокрутка часто переставала работать до перезагрузки мышки. Также всего за полгода использования она облезла и потрескалась. Стала настолько непрезентабельной, что в руки брать мерзко.
С Designer Mouse все хорошо, кроме того, что у меня за полгода их умерло 2 штуки: у одной сломалась пластиковая ножка на корпусе, отвечающий за клик. У второй колесико стало крутиться свободно, само собой не триггеря события скролла. Собрал из 2 одну, уже скоро полгода — гадаю что еще сломается.
зы: к их клавиатурам никаких нареканий нет. Всю жизнь только их и беру. Сейчас компактная Designer Keyboard второй год живет, выглядит как новая.
Когда разделили хабру на 2 ресурса — стало очень больно читать и пришлось его покинуть, когда отделили тостер — качество и оперативность ответов значительно упали.
Кажется, НЛО движется по спирали.

p.s. Забавно, но предыдущий коммент я оставил ровно 3 года назад
Ну а на автомате тоже не нужно жать газ, чтобы машина поехала. Достаточно только приотпустить тормоз.
Мне кажется, рыть сложнее чем возводить надземные постройки в рамках такой задачи. Да и под землей жить мало кто захочет.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity

Specialization

Frontend Developer
Lead