Почему Electron до сих пор выбирают вместо Tauri
У Tauri своих проблем хватает:
Он использует системный webview, потому фронтенд рантайм намеренно не фиксирован.
На macOS это WebKit, на Windows — WebView2 (Edge Chromium), на Linux — WebKitGTK (Linux-порт WebKit, но другая системная обвязка). Чек прикрепленную таблицу, это разные движки и системная обвязка.
Поэтому поведение и доступность API зависят от ОС и версий.
Как в обычном вебе, ага, но в чем проблема?
Лично я не вижу большой проблемы работать с Tauri, это буквально та же разработка веб приложений.
Он буквально накладывает те-же обязанности на разработчика, что и в обычном вебе: проверить в нескольких браузерах и осознавать с каких версий браузеров юзер будет открывать апку.
В вебе юзаем caniuse.com, но в десктоп разработке важнее понимать что на древнем MacBook Air 2012 года юзер может вообще не открывать Safari и сидеть в Chrome. Но Tauri все равно запустится на системном WKWebView: Safari 2022 года, который больше не обновится, потому что поддержка macOS на этом железе уже прекращена.
Это всё. Буквально. Для большинства обычных desktop-апок нет минусов. Бекенд апки компилируется в бинарник из rust либо можно цепануть вообще TS-бэкенд в виде Sidecar и работать точно так же как в электроне, с чуть другим апи.
Как итог — заметно меньший базовый расход RAM и почти тот же Electron-опыт разработки... А если боишься rust - попроси агента блять сайдкар прикрутить и делай в TS.
Разрабы всё равно выбирают Electron
Казалось бы - почему тогда мы до сих пор видим новые приложения, по типу Codex desktop app на Electron, когда его же CLI написан на Rust?
Стало быть дело не в языковом барьере разработчиков? (хотя какие языковые барьеры, когда все вокруг — уже вайбкодеры...)
Это прямое следствие использования WebView у Tauri, который и снижает расход RAM.
Причины точно те же что у React vs Vue/Svelte/Lit и тп модными и крутыми фронтенд фреймворками: привычка разработчиков, предсказуемость поведения + зрелый Electron API для управления браузерным слоем.
Electron API — тупо понятнее и предсказуемее, дает более удобный контроль над сессиями, кешем, proxy, protocol interception, web contents и т.д.
И сюда же в копилку берем привычные для веб разработчика нюансы совместимости с клиентским рантаймом, которые в декстопной разработке закрываются просто включением бинарника хрома в сборку 🤷♂️
Если еще не дошло — Следи за буквами:
Речь о пользователях, которые не обновляют системный (!) браузер.
Сам когда обновлял Edge на винде, Safari на маке, или пакет WebKitGTK в линукс?
А твои знакомые? То-то же!))0)
Что еще есть кроме Electron и Tauri?
Небольшой ресерч показал, что действительно есть интересные проекты.
Как альтернативу - за этими ребятами можно последить, у них могут быть интересные перспективы как легковесный кроспплатформенный веб движок для десктопов:
• servo.org
• ultralig.ht
Оба могут быть интересны как легковесные кроссплатформенные веб-рантаймы для десктопа
Но идут по-разному пути: Servo строит собственный движок на Rust, а Ultralight делает компактный WebKit-based стек на C++.
Но прямо сейчас это не прямая замена Tauri или Electron.
Servo все еще экспериментальный.
А Ultralight — C++ SDK со своим стеком, интеграцией и ограничениями совместимости.
Если нужен именно полноценный Chromium, но без Electron — есть CEF. Только это тоже низкоуровневый интерфейс работы с браузером, а оконный слой, канал связи между процессами и архитектуру приложения надо собирать ручками...
Для нормальной продуктовой разработки остается только Electron и Tauri
Electron — для понятной предсказуемой продуктовой разработки.
Tauri — если выигрыш в размере и RAM важнее цены совместимости; особенно когда оборачиваешь высокопроизводительное Rust-приложение в интерфейс. (Я такое делал, у меня есть кейс реалтайм мониторинга речи с микрофона через ЦАП макбука с задержкой меньше 5ms при стандарте 0-3ms на профессиональном оборудовании)
С момента стабильного релиза v2 Tauri прошло больше двух лет, Карл! Какого черта!?
У Tauri своих проблем хватает:
Он использует системный webview, потому фронтенд рантайм намеренно не фиксирован.
На macOS это WebKit, на Windows — WebView2 (Edge Chromium), на Linux — WebKitGTK (Linux-порт WebKit, но другая системная обвязка). Чек прикрепленную таблицу, это разные движки и системная обвязка.
Поэтому поведение и доступность API зависят от ОС и версий.
Как в обычном вебе, ага, но в чем проблема?
Лично я не вижу большой проблемы работать с Tauri, это буквально та же разработка веб приложений.
Он буквально накладывает те-же обязанности на разработчика, что и в обычном вебе: проверить в нескольких браузерах и осознавать с каких версий браузеров юзер будет открывать апку.
В вебе юзаем caniuse.com, но в десктоп разработке важнее понимать что на древнем MacBook Air 2012 года юзер может вообще не открывать Safari и сидеть в Chrome. Но Tauri все равно запустится на системном WKWebView: Safari 2022 года, который больше не обновится, потому что поддержка macOS на этом железе уже прекращена.
Это всё. Буквально. Для большинства обычных desktop-апок нет минусов. Бекенд апки компилируется в бинарник из rust либо можно цепануть вообще TS-бэкенд в виде Sidecar и работать точно так же как в электроне, с чуть другим апи.
Как итог — заметно меньший базовый расход RAM и почти тот же Electron-опыт разработки... А если боишься rust - попроси агента блять сайдкар прикрутить и делай в TS.
Разрабы всё равно выбирают Electron
Казалось бы - почему тогда мы до сих пор видим новые приложения, по типу Codex desktop app на Electron, когда его же CLI написан на Rust?
Стало быть дело не в языковом барьере разработчиков? (хотя какие языковые барьеры, когда все вокруг — уже вайбкодеры...)
Это прямое следствие использования WebView у Tauri, который и снижает расход RAM.
Причины точно те же что у React vs Vue/Svelte/Lit и тп модными и крутыми фронтенд фреймворками: привычка разработчиков, предсказуемость поведения + зрелый Electron API для управления браузерным слоем.
Electron API — тупо понятнее и предсказуемее, дает более удобный контроль над сессиями, кешем, proxy, protocol interception, web contents и т.д.
И сюда же в копилку берем привычные для веб разработчика нюансы совместимости с клиентским рантаймом, которые в декстопной разработке закрываются просто включением бинарника хрома в сборку 🤷♂️
Если еще не дошло — Следи за буквами:
Речь о пользователях, которые не обновляют системный (!) браузер.
Сам когда обновлял Edge на винде, Safari на маке, или пакет WebKitGTK в линукс?
А твои знакомые? То-то же!))0)
Что еще есть кроме Electron и Tauri?
Небольшой ресерч показал, что действительно есть интересные проекты.
Как альтернативу - за этими ребятами можно последить, у них могут быть интересные перспективы как легковесный кроспплатформенный веб движок для десктопов:
• servo.org
• ultralig.ht
Оба могут быть интересны как легковесные кроссплатформенные веб-рантаймы для десктопа
Но идут по-разному пути: Servo строит собственный движок на Rust, а Ultralight делает компактный WebKit-based стек на C++.
Но прямо сейчас это не прямая замена Tauri или Electron.
Servo все еще экспериментальный.
А Ultralight — C++ SDK со своим стеком, интеграцией и ограничениями совместимости.
Если нужен именно полноценный Chromium, но без Electron — есть CEF. Только это тоже низкоуровневый интерфейс работы с браузером, а оконный слой, канал связи между процессами и архитектуру приложения надо собирать ручками...
Для нормальной продуктовой разработки остается только Electron и Tauri
Electron — для понятной предсказуемой продуктовой разработки.
Tauri — если выигрыш в размере и RAM важнее цены совместимости; особенно когда оборачиваешь высокопроизводительное Rust-приложение в интерфейс. (Я такое делал, у меня есть кейс реалтайм мониторинга речи с микрофона через ЦАП макбука с задержкой меньше 5ms при стандарте 0-3ms на профессиональном оборудовании)
А что касается моей RAM - обошёлся без донатов, жду апгрейда 😝