Ищем разработчика на Electron в стартап Blynk

Всем привет.

Мы запускаем проект с нуля для нашего нового клиента. В связи с этим ищем хорошего Front-End разработчика на фул-тайм, который готов взять на себя бремя новых технологий. Желателен опыт с React, можно фул-стек.

Для сомневающихся по поводу электрона — google trends. Да, мы знаем про этот риск. Но это не проблема для нашего клиента.

Ищем в первую очередь самостоятельных, мотивированных к изучению нового людей.

Кому интересно — пишите на dmitriy@blynk.cc

Сайт проекта.
Что происходило с проектом за 2 года можно почитать тут — dou.ua/users/DOOM/articles и ту habrahabr.ru/users/doom369/topics.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Писать надо, я так понимаю, на жабаскрипте? Никакого кложаскрипта?

Статья правильная. Наш новый клиент хочет «красивый» и «няшный» дизайн в первую очередь. Потому что продажи их продукта (сенсоры) падают из-за «страшного» и не удобного UI/UX.

Да, мы знаем про этот риск.
Ой, всё. Автор той статьи наверняка уверен что не нужно использовать и фреймворки, потому что это расход ресурсов. Это такие люди, которые отказываются видеть всё что не укладывается в их мировоззрение родом из 90х (если не 80х).

они еще и базы данных не юзают: dou.ua/…​a/columns/dont-use-rdbms

мировоззрение родом из 90х (если не 80х)
так что я бы сказал, что прямиком из 70х

Автор статьи и ТС (который не юзает БД) разные люди вроде бы. Хотя, если избегания электрона я ещё могу понять, то избегание БД — вряд ли.

Автор статьи и ТС (который не юзает БД) разные люди вроде бы
да вроде один и тот же.

автор статті на доу — Дмитрий Думанский
автор статті, про яку говорить Gennady Dogaev — Joseph Gentle

Пока Вы меня осуждаете, наш паблик клауд уже хендлит 10к рек-сек и стоит 60$, мы подписали нескольких энтерпрайзов и к нам стоит очередь из мелкого бизнеса. С БД мы были бы на год позади.
Технологии — это последнее, о чем следует думать в бизнесе. Говорю Вам как CTO :).

Не звертайте уваги, давно пора звикнути з менталітетом «краще піду пораджу іншому, ніж сам щось зроблю»

Технологии — это последнее, о чем следует думать в бизнесе. Говорю Вам как 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, выбор будет очевиден.

но

Но когда я октрыл примеры приложений на электрон и сравнил с приложениями на QT.

Это не аргумент. Аргумент был бы собрать UI по дизайну на QML и электроне и сравнить что проще в итоге будет

Unity в убунте?
Не видал UI уродливее и неуобнее. Как будто рисовали для смартфона, а потом натянули на десктопную ось.
Аргумент был бы собрать UI по дизайну на QML и электроне и сравнить что проще в итоге будет
Вы не можете поверить что нарисовать кастомный UI на html+css проще и быстрее? Не говоря о большом количестве уже нарисованного и написанного.
Вы не можете поверить что нарисовать кастомный UI на html+css проще и быстрее?

Имя опыт с qml и знакомство с html+css «постольку поскольку», уверен, что это займет примерно одинаковое время. Но вслучае qml +десктоп/мобильного приложения не придется тащить весь браузер в приложение

В целом, rich widgets на QML сильно проще делать.

Не видал UI уродливее и неуобнее.

«На вкус и цвет». Мне, например, радикально не нравится дизайн макоси.

Например в программе есть прогресс-бар вот такой codepen.io/thathurtabit/pen/ymECf А потом внезапно решили поменять его на такой red-team-design.com/…​ylish-css3-progress-bars Сколько это займет на QML? На CSS это будет пару часов если делать с нуля и гуглить как. Пару минут если скопировать уже готовый (которых много на разный вкус).

Аналогично,

На CSS это будет пару часов если делать с нуля и гуглить как.
познакомьтесь с QML: doc.qt.io/…​les-progressbarstyle.html

QML настолько охрененен, что две разных комманды чуваков начали делать транспайлер из QML в HTML+CSS+JS:
github.com/qmlweb/qmlweb (достаточно сырой)
github.com/pureqml/qmlcore (покрутил, выглядит рабочим. На выходе даже html5)

Unity в убунте?

Это шутка?

да вот хотя бы: aseman.co/en/products/cutegram

Страшноватенько.

Я не представляю, что уникального есть в электроне, что бы не реализовывалось так же легко на QML.

Авто-апдйты из коробки, куча готовых бесплатных либ, огромная армия разработчиков, все бесплатно (Кт стоит 300$ в мес за разраба). Я пытался найти плюсы у кт/кмл, но не смог. Может я что-то упускаю?

**Я понимаю, что решение вы уже приняли, и переубедить не пытаюсь.

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

куча готовых бесплатных либ
 — есть в QML
огромная армия разработчиков
 — если вы про всех фронтэнд разработичков, то им понадобится одинаковое время что бы разобраться в электроне или в qml. Если вы «армию разработчиков которые знают электрон» — смею вас разочаровать.
Кт стоит 300$ в мес за разраба
а зачем вам коммерческая лицензия? В чем вас ограничит LGPL 3.0?
Я пытался найти плюсы у кт/кмл, но не смог.

По моему скромному опыту, электрон полезен когда есть знающий его человек и готовый код, который нужно перенести из веба на десктоп.
Весь остальной опыт использования — или приложение жрет гиг паямити (этот текстовый редактор, на минуточку), или крешится.

В чем вас ограничит LGPL 3.0?
В том, что нужно свой исходный код открывать. Вроде, даже под такой же лицензией.
или приложение жрет гиг паямити, или крешится
VS Code ни прожорлива на память ни крешится. Сейчас открыт средних размеров проект и кушает 12.9 MB всего.
В том, что нужно свой исходный код открывать

С чего вы взяли? Открывать нужно, если модифицировали сам фреймворк, и то, только его.
en.wikipedia.org/…​er_General_Public_License

VS Code ни прожорлива на память ни крешится. Сейчас открыт средних размеров проект и кушает 12.9 MB всего.

Пользовался VS Code/Atom несколько месяцев для больших Python/Cpp проектов, при октрытии проекта занимает около 200 метров памяти, без перезапуска, через 2-3 дня уже гиг памяти. Рекорд, который я видел — 2.5 гб памяти. 2.5 гб памяти видел именно на VS Code.

Да, Вы правы, лицензия не нужна.

Из плюсов еще мугу добавить — у нас уже есть все стили и перенести их в электрон вопрос одного дня. + у нас есть другие веб-проекты и в случае чего можно будет перекинуть людей туда.

Подписаться на комментарии