Комментарии 31
коммент не в тот пост..(удалено)
Ну вот опять. Побыстрее и попроще разработать, а уж как оно будет работать это проблемы пользователей.
А flutter рассматривали? Легче и быстрее электрона
Я так понимаю, что даже если писать на флаттере, UI часть все равно нужно писать с нуля, а этим ребятам важно побыстрее выкатить рабочий вариант. То, что оно будет кривое, косое и жручее, их не сильно волнует.
Flutter рассматривали, да. Для нас он был в одной категории с Qt примерно. Переиспользовать существующий UI нельзя, но вариант привлекательный. Возможно, в дальнейшем попробуем провести R&D с ним уже :)
Если не охота ковырять Dart, то лучше посмотреть в сторону Tauri - пишем основной процесс на Rust/C++/чем угодно (для чего есть биндинги), фронтенд на любимом JS-стеке. На выходе получаем легкий бинарник, который вертит свой UI в нативном для системы WebView, без хромиума и V8
Думали о решениях с нативным WebView тоже. Там нас немного отталкивали потенциальные проблемы с разными ОС и их версиями (WebView API не везде одинаковый, и там много раз нюансов есть).
Взяли пока Электрон как раз по той причине, что казалось, что поскольку там хромиум внутри — мы уверены, что наше приложение точно будет работать везде и именно так, как мы ожидаем. НО да, расплата — его объём.
В целом, в будущем, может быть погрузимся в эту тему глубже, спасибо за комментарий :)
70 метров Qt? Это у вас на 50 метров иконок? Рантайм Qt, если вам достаточно UI+сеть+SQLite ужимается до ~13-20 мегабайт.
не эксперт в Qt и не буду спорить (скорее всего Вы правы!), информацию брал из открытых источников (может ошибся). В статье она нужна больше для сравнительного порядка, чем для точной цифры, поэтому тщательно не проверял :)
говорят, что для разработчиков на электроне сталелитейни в аду разработали особый проект котла. Он очень быстрый в проектировании отливке, быстро можно выкатить первый котел в продуктив по мере появления их востребованности. Но есть у котлов особенность, очень толстые стенки, из-за чего даже по окончанию срока прожарки и отключения подачи магмы и серы в систему нагрева, то за счет огромной теплоемкости котел еще будет долго-долго отдавать жар на максимуме теплоотдачи. ;)
давно под Линуксом использую Visual Studio Code, который, как известно, на Электроне. Отлично работает (почти. Пару раз завешивал мне десктоп)
Вот и черти из R&D отдела тоже так рассудили. технология рабочая, хоть и тяжеловатая для юзера, но все формально соответствует ТЗ и главное выкатили в короткие сроки. Как никак у них там сейчас жуткий кранч под новые срочные задачи, связанные с необходимость обеспечить масштабирование сервисов из-за прогнозируемого возрастания загрузки.
А можно хоть немного подробностей как реализовывали синхронизацию SQLite с сервером?
У нас было только одно write действие, поэтому мы сделали очень просто: при наличии интернета мы сразу идём на сервер, а при отсутсвии изменяем локально + добавляем в специальную очередь событий пользователя, которая процессится при появлении интернета. Мы не сильно беспокоились о всех возможных кейсах, так как делали просто прототип.
Возможно вам интересен момент: "Что делать, если на сервере, пока на клиенте не было интернета, произошло что-то еще?" и всякие такие подобные колизии. Если кратко — то всегда доверять серверу, но лучше почитать непосредственно про подобные приложения отдельно, на том же хабре. Таких приложений много, особенно в мобильной и десктопной разработке.
Спасибо. Меня больше интересует "протокол". Т.е. на сервере есть API, которое дергается из клиента? Какие-то самописные команды или есть какой-то фреймворк/либа? Если просто флаг обновить, то возможно простого запроса к скриптику и хватит, а вот если много всяких разных данных, структур и пр? Как "взрослые" делают offline first синхронизацию с SQL(ite) локальным хранилищем?
Да сервер, в данном случае тот же самый сервер, который отдаёт данные для web-версии и мобильных приложений. У нас аля REST API.
По поводу синхронизации, попробуйте покопаться вглубь CQRS (Command and Query Responsibility Segregation) — обычно этот паттерн используется в offline first системах. Предупреждаю, это на самом деле все очень непросто :)
Сколько в итоге потребляет это приложение? Интересно сколько получилось для такого исследовательского решения.
Надо было просто сделать PWA, и опубликовать его в магазин MS если есть такая необходимость. А вообще скорее всего лучше бы подошел Tauri
+1. Tauri - это то, каким должен быть электрон. А не это недоразумение, что сейчас.
Не увидел специфических API, тем более на десктопе их куча для веба доступно. Подошло бы PWA. Одна кодовая база с браузерной версией, оффлайн режим, все тоже самое. Не пришлось бы городить какие-то electron обертки, а авторизация бы УЖЕ была, если юзер авторизован в браузере был.
Я пишу, почему нельзя было сделать PWA в статье. Проблема именно в том, что один из основных запросов клиентов – выгрузка части писем локально (не в базу, а прям файлом) и взаимодействие с ними. Собственно поэтому и нужен толстый клиент и полноценная работа с файловой системой.
На сколько у вас толстые письма? Не изучали возможности indexeddb? Вы знаете что на десктопе у веба практически не ограниченный размер там?
Про это есть в статье) Речь же ещё была про попытку заюзать уже готовый северный код на Go.
Про размер: гигабайты (возможно десятки их). Совершенно легко может быть кейс — выгрузить локально весь ящик за последние N лет со всеми аттачами и файлами в письме. Нам не нравилась история с загрузкой всего этого добра в браузер и перекладка в IndexedDB и обратно (Хотя, в статье я пишу, что это возможно конечно).
Я сам готов бесконечно евангилировать за PWA и весь веб-стэк.
Но наш эксперимент пошёл по-другому пути и я много уделяю внимания в тексте, чем мы руководствовались. Я вообще не претендую на то, что выбранные технологии — это самый лучший выбор из возможных. Это больше "вот мы взяли это, попробовали сделать PoC, вот что у нас получилось и к каким выводам мы пришли".
Go скорее всего получилось бы использовать в Wasm модуле. Загрузку можно было организовать через воркер, в приложение уже отдавать готовые ответы сетевые. Жаль что для эксперимента не взяли тогда tauri, если в рамки PWA боялись не вписаться. Electron нужно активно хоронить, уже не одна хорошая альтернатива ему есть.
Как вариант можно было бы попробовать поработать с https://web.dev/file-system-access/#opening-a-directory-and-enumerating-its-contents В общем не очень понял в чем в итоге был эксперимент...
На https://wails.io/ не смотрели?
От Web до Desktop за 2 недели: технология Electron на практике