Ищем разработчика на Electron в стартап Blynk
Всем привет.
Мы запускаем проект с нуля для нашего нового клиента. В связи с этим ищем хорошего Front-End разработчика на фул-тайм, который готов взять на себя бремя новых технологий. Желателен опыт с React, можно фул-стек.
Для сомневающихся по поводу электрона — google trends. Да, мы знаем про этот риск. Но это не проблема для нашего клиента.
Ищем в первую очередь самостоятельных, мотивированных к изучению нового людей.
Кому интересно — пишите на [email protected]
Сайт проекта.
Что происходило с проектом за 2 года можно почитать тут — dou.ua/users/DOOM/articles и ту habrahabr.ru/users/doom369/topics.
44 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівА чего не Sciter ( sciter.com ) ?
Йеп.
vc.ru/…/how-to-build-b2b-startup
Чего-то вспомнилась эта статья.
Статья правильная. Наш новый клиент хочет «красивый» и «няшный» дизайн в первую очередь. Потому что продажи их продукта (сенсоры) падают из-за «страшного» и не удобного UI/UX.
они еще и базы данных не юзают: dou.ua/…a/columns/dont-use-rdbms
так что я бы сказал, что прямиком из 70хАвтор статьи и ТС (который не юзает БД) разные люди вроде бы. Хотя, если избегания электрона я ещё могу понять, то избегание БД — вряд ли.
автор статті на доу — Дмитрий Думанский
автор статті, про яку говорить Gennady Dogaev — Joseph Gentle
Пока Вы меня осуждаете, наш паблик клауд уже хендлит 10к рек-сек и стоит 60$, мы подписали нескольких энтерпрайзов и к нам стоит очередь из мелкого бизнеса. С БД мы были бы на год позади.
Технологии — это последнее, о чем следует думать в бизнесе. Говорю Вам как CTO :).
Не звертайте уваги, давно пора звикнути з менталітетом «краще піду пораджу іншому, ніж сам щось зроблю»
так у них теперь есть шанс вырости, а не родится мертворожденным бизнесом
Мы не делали свою реализацию СУБД. Это у коментаторов из того треда разошлось воображение.
А потом ВНЕЗАПНО мигание курсора грузит ЦПУ в Visual Studio на 100%
И внезапно, VS не на электроне )) Так и к чему тут эта байка про курсор? Понимаете, есть две стороны. С одной — да, тащить браузер это оверхед по ресурсам, причем здоровый такой. Поэтому для приложения из двух функций или просто копирующего полностью сайт это делать неразумно. Но с другой стороны медали скорость разработки и лёгкость создания UI. И это очень весомо. Собственно в UI всё и упирается. А не в то что кому-то лень выучить C/C++/C#/Rust/Java/Whatever. Ну и ещё маленький плюсик электрона — с тем же YT не интегрируешься без встраивания в программу браузера. Хочешь показывать видео — встраивай web view. Иначе — нарушаешь TOS, если напишешь свой проигрыватель на любимом нативном языке.
Почему байка? Известный баг:
geektimes.ru/post/287342 (13% CPU — это полная нагрузка на ядро)
А сейчас страшное — ГУЯ — это просто правильно спроектированая прослойка между логикой (игры/бизнес приложения) и оболочкой и если последняя спроектирована так что жить не может без QT/MFC... Наверное всё ок...
VS != VS Code. Это разные вещи. VS Code — да, сделан на Electron-е. Но он не имеет отношения к VS
Ну то есть обосрались в Chromium с тем что css-анимация курсора ест 8%, а виноват Electron.
Ну как же, надо же нативно писать без электронов всяких, и было бы всё ок )
Ну я лично минималист и для меня ресурсы системы — весомый аргумент. Но когда я октрыл примеры приложений на электрон и сравнил с приложениями на QT. Выбор стал очевиден. А альтернатив то, по сути, и нету.
Можете показать, что такого умеет электрон и чего не умеет Qt/QML?
думаю вопрос в колве действий для реализации одной и той же логики
С плюсами я бы еще согласился, но QML??
Покажите мне, пожалуйста, красивое приложение на QML. Только не теслу и медиком, плиз, там миллионные бюджеты.
Unity в убунте? большая часть интерфейса KDE? да вот хотя бы: aseman.co/en/products/cutegram
Я не представляю, что уникального есть в электроне, что бы не реализовывалось так же легко на QML.
Разумеется, что если человек знает электрон и не знает qml, выбор будет очевиден.
но
Это не аргумент. Аргумент был бы собрать UI по дизайну на QML и электроне и сравнить что проще в итоге будет
Вы не можете поверить что нарисовать кастомный UI на html+css проще и быстрее? Не говоря о большом количестве уже нарисованного и написанного.
Имя опыт с qml и знакомство с html+css «постольку поскольку», уверен, что это займет примерно одинаковое время. Но вслучае qml +десктоп/мобильного приложения не придется тащить весь браузер в приложение
«На вкус и цвет». Мне, например, радикально не нравится дизайн макоси.
Например в программе есть прогресс-бар вот такой codepen.io/thathurtabit/pen/ymECf А потом внезапно решили поменять его на такой red-team-design.com/…ylish-css3-progress-bars Сколько это займет на QML? На CSS это будет пару часов если делать с нуля и гуглить как. Пару минут если скопировать уже готовый (которых много на разный вкус).
Аналогично,
познакомьтесь с QML: doc.qt.io/…les-progressbarstyle.htmlQML настолько охрененен, что две разных комманды чуваков начали делать транспайлер из QML в HTML+CSS+JS:
github.com/qmlweb/qmlweb (достаточно сырой)
github.com/pureqml/qmlcore (покрутил, выглядит рабочим. На выходе даже html5)
Это шутка?
Страшноватенько.
Авто-апдйты из коробки, куча готовых бесплатных либ, огромная армия разработчиков, все бесплатно (Кт стоит 300$ в мес за разраба). Я пытался найти плюсы у кт/кмл, но не смог. Может я что-то упускаю?
**Я понимаю, что решение вы уже приняли, и переубедить не пытаюсь.
Из перечисленных плюсов, соглашусь с «автоапдейтами», хотя и не понимаю насколько оно необходимо
— есть в QML — если вы про всех фронтэнд разработичков, то им понадобится одинаковое время что бы разобраться в электроне или в qml. Если вы «армию разработчиков которые знают электрон» — смею вас разочаровать. а зачем вам коммерческая лицензия? В чем вас ограничит LGPL 3.0?По моему скромному опыту, электрон полезен когда есть знающий его человек и готовый код, который нужно перенести из веба на десктоп.
Весь остальной опыт использования — или приложение жрет гиг паямити (этот текстовый редактор, на минуточку), или крешится.
С чего вы взяли? Открывать нужно, если модифицировали сам фреймворк, и то, только его.
en.wikipedia.org/…er_General_Public_License
Пользовался VS Code/Atom несколько месяцев для больших Python/Cpp проектов, при октрытии проекта занимает около 200 метров памяти, без перезапуска, через2-3 дня уже гиг памяти. Рекорд, который я видел — 2.5 гб памяти. 2.5 гб памяти видел именно на VS Code.
Да, верно, я с AGPL перепутал.
Да, Вы правы, лицензия не нужна.
Из плюсов еще мугу добавить — у нас уже есть все стили и перенести их в электрон вопрос одного дня. + у нас есть другие веб-проекты и в случае чего можно будет перекинуть людей туда.