6 ms·

Photino: A lighter Electron

32 points by AbuAssar 2y ago

ano-ther 2y ago
Looks promising. Does anyone have experience with it, or their backers https://codemag.com/ https://codemag.com/ ?
- pathartl 2y ago
  I'm using it in my project LANCommander for a game launcher: https://github.com/LANCommander/LANCommander https://github.com/LANCommander/LANCommander I will probably be switching to Electron unless the project gets any sort of meaningful update. The releases on their GitHub are still v2, while the packages available on NuGet are v3. There hasn't been any code changes in the past couple of months. For the Blazor integration, it's actually broken completely for Linux (and maybe macOS). Overall it does save on build sizes and RAM a bit, but I'm not sure about the long term viability.
  - Blahah 2y ago
    Tauri might be a nice alternative to electron. I've had good experiences with it, developing and distributing small internal tools that work cross-platform.
Blahah 2y ago
I'd really like to see it compared to Tauri [0] which is the established leader in this space. 0: https://tauri.app https://tauri.app
- __natty__ 2y ago
  Or Wails with Go. It’s good we have more competitors in the desktop space.
  - nathell 2y ago
    Or with Socket Runtime (https://socketsupply.co/ https://socketsupply.co/).
- M4v3R 2y ago
  Same, I'm using Tauri for few toy projects and I'd like to know whether this is worth checking out. I love Tauri but Rust has a very steep learning curve for me (as a mainly frontend web developer), for basically everything I want to do I have to resort to Claude/ChatGPT. Fortunately they're quite good at writing (not so complex) Rust code.
- synergy20 2y ago
  I'd really like not to see Rust-can-do-it-too mentioned in each post just once these days. After all it's using webview, which has its limits no matter what sugar you lay on top, not to mention, Wails with Go is 10x easier to code than Rust if you must use webview.
  - junon 2y ago
    There shouldn't be a difference. Tauri doesnt even require you write rust. It's entirely optional.
  - Blahah 2y ago
    That's not at all what this is. Tauri is written in rust but doesn't require writing any rust. You can use just frontend js, or node on the backend, or rust, python, c++, etc.
    - synergy20 2y ago
      Wails needs to write Go for the backend side, I would assume Tauri needs Rust to do backend side work too, after all UI is just the surface and we need the backend(or system side) code to do the heavy lifting. If the frontend is JS/HTML/CSS and the backend can be any language of choice, what is Rust doing here then? I must be missing something.
- k__ 2y ago
  Is it? As far as I understood it, Tauri is a safer Electron, not a lighter one.
  - krapp 2y ago
    Isn't it both? Tauri is lighter because it doesn't bundle an entire Chromium instance for each app, rather it uses the native OS's existing webview.
    - antifa 2y ago
      Which gives it all the compatibility issues of each platform.
croes 2y ago
Is it really cross platform if it uses the OS render engine? Aren't there still differences between Chromium and Webkit. And what if a breaking change in the WebView2 is deployed per update? Isn't that the advantage of Electron that you have total control over used render engine version?
anaisbetts 2y ago
I cannot describe how Bad an idea it is to try to rely on the OS-provided web browser. We chose Electron at Slack, partly because of the numerous unfixable bugs with Slack for Mac for people on downlevel operating systems, and that was just on macOS! Telling people, "You need to install a new OS" or even in the case of macOS on old devices, "You need to buy a new computer", in response to a user writing in with a bug in your app is a real uncomfortable conversation to have in Support Tauri even themselves are building their own embedded browser (based on Servo) because they too realize that using "whatever the OS happens to have" is fundamentally not Workable as a platform. This idea Just Does Not Work for production apps with Real amounts of users
- saagarjha 2y ago
  Ok, so not only do you want to use the lowest common denominator in terms of programming language and platform API, but you think it’s impossible to write apps if the web engine you’re using isn’t the exact same across every OS and version? Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs.
  - quotemstr 2y ago
    > Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs. This, but unironically. Why not ship an app as a VM? Firecracker is super fast. The only thing really stopping is is that we don't have VM friendly APIs that let VM guests act like desktop apps. (Well, nested virtualization should be more supported.) Also, we're already in a world in which we ship apps as basically containers. Is that all that different? What should be the interface between an app and its host OS (and other apps)? At one extreme, we have "thick", "batteries included" interfaces like old win32, with tons of convenience APIs and OS-provided in-process code, and at the other extreme, we have VM-style "thin" interfaces with only the most essential OS services provided and apps (well, VM guests) expected to bring their own batteries --- things like a virtio framebuffer. Whether an app interfere is implemented as a VM hypercall virtio thing, IPC, or in-process client library is an implementation detail. What matters is the thickness of the API surface. We're in the middle of a secular trend from thick interface surfaces to thin ones. I don't see that as a bad thing. Thin, arms-length interfaces maximally decouple app and OS development. They encourage cooperation over explicit, stable, and versioned interfaces. They simplify the entire industry. The technological environment that generated the old thick interfaces doesn't exist anymore. Freed of its constraints, we can do better now.
VyseofArcadia 2y ago
I just want to say, I really miss for-real native desktop apps. As an old-school desktop app developer, everything about web dev feels awkward and unnatural to me, and I'm not too keen on the performance of the end result. I appreciate that Photino at least is lighter in terms of install footprint and RAM use, but it is still as CPU hungry.
- quotemstr 2y ago
  You might be romanticizing the past. The old desktop world was full of custom toolkits --- remember how Word would style itself with Windows.next controls even when running downlevel? Remember Athena and Motif? Even today, we're split between Qt/Gtk. The mobile world is only slightly better. (Flutter.) We've never really had consistent appearance or behavior. So, I just don't get the Electron hate. It's just another GUI toolkit. That it's based on web stuff inside is an implementation detail. Electron wasn't the first GUI toolkit and it won't be the last. IME, speed, memory use, and so on are all adequate. My only real gripe is that it's cumbersome to theme the things and that you have to jump through a million hoops to inject your own JS as a user. .(GTK4 is also trending theme-hostile though, so this gripe isn't specific to Electron.) It'd also be nice to use web technologies with a language other than JavaScript. I'm sure the WASM people will come up with adequate multi-language interop eventually.
  - VyseofArcadia 2y ago
    It is true that as a GUI toolkit Electron as at least as complicated and quirky as everything that came before. I would argue more, but I'm willing to chalk that up to unfamiliarity. The thing about apps, though, is that the frontend isn't the only end, and in web dev your backend is also radically different and likely more complex. Now it's a good thing that there is an architectural boundary between the frontend and backend. God knows not every desktop app is good about that. But the problem in web dev is that it is a complex architectural boundary that has its own footguns. Suddenly you have to do everything concurrently and securely. And on the backend, you can no longer just serialize to a file in a known directory. You have to learn securely connect to a database, be competent in a query language, and be able to manage all the infrastructure or sysadmin work that comes with databases. Oh, and you can no longer just distribute your application as a binary or with an installer. Now you have to be a master of all the sysadmin and process work that comes with deploys and cloud infrastructure. Debugging is no longer just gdb and depends on competent logging, you're likely to have to finagle calls to several REST APIs (all with slightly different auth) instead of just linking in a library, you have a hell of a lot more things to mock when you're testing... The list of added complexity goes on and on and on, and all of this is on top of whatever complexity is inherent in the problem domain to begin with. Web dev adds just adds a ton of complexity.
elashri 2y ago
On a somewhat off-topic point, the photino, which is the proposed superpartner of the photon, will not be massless. If it exists, we know for sure that it will have a mass significantly larger than that of the electron. For starters, we would have already discovered it if it had such a low mass. Therefore, it is incorrect from a particle physics perspective to consider the photino lighter than an electron. And yes, I know this is why people don't like talking to physicists. Good luck with the project anyway :)
- eointierney 2y ago
  Thank you. This was the comment I was looking for.
romwell 2y ago
TL;DR: >Photino uses the OS’s built-in Chromium or WebKit-based browser control for Windows, macOS and Linux. So, same difference. Native and lighter than light my arse, pardon my French. It's still using a browser under the hood to render UI.
butz 2y ago
"on Linux it uses WebKitGTK+ 2" - is this counted into download size comparison, or conveniently left out?
butz 2y ago
Is you already are writing .NET application, why not use UI library they provide and actually build a desktop application? You can even do pretty good optimizations when packaging such .NET app to reduce its size and even include runtime, to remove requirement for external dependencies.

32 points by AbuAssar 2y ago

ano-ther 2y ago

Looks promising. Does anyone have experience with it, or their backers https://codemag.com/ https://codemag.com/ ?

pathartl 2y ago
I'm using it in my project LANCommander for a game launcher: https://github.com/LANCommander/LANCommander https://github.com/LANCommander/LANCommander I will probably be switching to Electron unless the project gets any sort of meaningful update. The releases on their GitHub are still v2, while the packages available on NuGet are v3. There hasn't been any code changes in the past couple of months. For the Blazor integration, it's actually broken completely for Linux (and maybe macOS). Overall it does save on build sizes and RAM a bit, but I'm not sure about the long term viability.
- Blahah 2y ago
  Tauri might be a nice alternative to electron. I've had good experiences with it, developing and distributing small internal tools that work cross-platform.

Blahah 2y ago

I'd really like to see it compared to Tauri [0] which is the established leader in this space. 0: https://tauri.app https://tauri.app

__natty__ 2y ago
Or Wails with Go. It’s good we have more competitors in the desktop space.
- nathell 2y ago
  Or with Socket Runtime (https://socketsupply.co/ https://socketsupply.co/).
M4v3R 2y ago
Same, I'm using Tauri for few toy projects and I'd like to know whether this is worth checking out. I love Tauri but Rust has a very steep learning curve for me (as a mainly frontend web developer), for basically everything I want to do I have to resort to Claude/ChatGPT. Fortunately they're quite good at writing (not so complex) Rust code.
synergy20 2y ago
I'd really like not to see Rust-can-do-it-too mentioned in each post just once these days. After all it's using webview, which has its limits no matter what sugar you lay on top, not to mention, Wails with Go is 10x easier to code than Rust if you must use webview.
- junon 2y ago
  There shouldn't be a difference. Tauri doesnt even require you write rust. It's entirely optional.
- Blahah 2y ago
  That's not at all what this is. Tauri is written in rust but doesn't require writing any rust. You can use just frontend js, or node on the backend, or rust, python, c++, etc.
  - synergy20 2y ago
    Wails needs to write Go for the backend side, I would assume Tauri needs Rust to do backend side work too, after all UI is just the surface and we need the backend(or system side) code to do the heavy lifting. If the frontend is JS/HTML/CSS and the backend can be any language of choice, what is Rust doing here then? I must be missing something.
k__ 2y ago
Is it? As far as I understood it, Tauri is a safer Electron, not a lighter one.
- krapp 2y ago
  Isn't it both? Tauri is lighter because it doesn't bundle an entire Chromium instance for each app, rather it uses the native OS's existing webview.
  - antifa 2y ago
    Which gives it all the compatibility issues of each platform.

croes 2y ago

Is it really cross platform if it uses the OS render engine? Aren't there still differences between Chromium and Webkit. And what if a breaking change in the WebView2 is deployed per update? Isn't that the advantage of Electron that you have total control over used render engine version?

anaisbetts 2y ago

I cannot describe how Bad an idea it is to try to rely on the OS-provided web browser. We chose Electron at Slack, partly because of the numerous unfixable bugs with Slack for Mac for people on downlevel operating systems, and that was just on macOS! Telling people, "You need to install a new OS" or even in the case of macOS on old devices, "You need to buy a new computer", in response to a user writing in with a bug in your app is a real uncomfortable conversation to have in Support Tauri even themselves are building their own embedded browser (based on Servo) because they too realize that using "whatever the OS happens to have" is fundamentally not Workable as a platform. This idea Just Does Not Work for production apps with Real amounts of users

saagarjha 2y ago
Ok, so not only do you want to use the lowest common denominator in terms of programming language and platform API, but you think it’s impossible to write apps if the web engine you’re using isn’t the exact same across every OS and version? Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs.
- quotemstr 2y ago
  > Next you’re going to say that shipping VMs to users is the only way to deploy apps, lest people use different (or, gasp, out of date) OSes that might have bugs. This, but unironically. Why not ship an app as a VM? Firecracker is super fast. The only thing really stopping is is that we don't have VM friendly APIs that let VM guests act like desktop apps. (Well, nested virtualization should be more supported.) Also, we're already in a world in which we ship apps as basically containers. Is that all that different? What should be the interface between an app and its host OS (and other apps)? At one extreme, we have "thick", "batteries included" interfaces like old win32, with tons of convenience APIs and OS-provided in-process code, and at the other extreme, we have VM-style "thin" interfaces with only the most essential OS services provided and apps (well, VM guests) expected to bring their own batteries --- things like a virtio framebuffer. Whether an app interfere is implemented as a VM hypercall virtio thing, IPC, or in-process client library is an implementation detail. What matters is the thickness of the API surface. We're in the middle of a secular trend from thick interface surfaces to thin ones. I don't see that as a bad thing. Thin, arms-length interfaces maximally decouple app and OS development. They encourage cooperation over explicit, stable, and versioned interfaces. They simplify the entire industry. The technological environment that generated the old thick interfaces doesn't exist anymore. Freed of its constraints, we can do better now.

VyseofArcadia 2y ago

I just want to say, I really miss for-real native desktop apps. As an old-school desktop app developer, everything about web dev feels awkward and unnatural to me, and I'm not too keen on the performance of the end result. I appreciate that Photino at least is lighter in terms of install footprint and RAM use, but it is still as CPU hungry.

quotemstr 2y ago
You might be romanticizing the past. The old desktop world was full of custom toolkits --- remember how Word would style itself with Windows.next controls even when running downlevel? Remember Athena and Motif? Even today, we're split between Qt/Gtk. The mobile world is only slightly better. (Flutter.) We've never really had consistent appearance or behavior. So, I just don't get the Electron hate. It's just another GUI toolkit. That it's based on web stuff inside is an implementation detail. Electron wasn't the first GUI toolkit and it won't be the last. IME, speed, memory use, and so on are all adequate. My only real gripe is that it's cumbersome to theme the things and that you have to jump through a million hoops to inject your own JS as a user. .(GTK4 is also trending theme-hostile though, so this gripe isn't specific to Electron.) It'd also be nice to use web technologies with a language other than JavaScript. I'm sure the WASM people will come up with adequate multi-language interop eventually.
- VyseofArcadia 2y ago
  It is true that as a GUI toolkit Electron as at least as complicated and quirky as everything that came before. I would argue more, but I'm willing to chalk that up to unfamiliarity. The thing about apps, though, is that the frontend isn't the only end, and in web dev your backend is also radically different and likely more complex. Now it's a good thing that there is an architectural boundary between the frontend and backend. God knows not every desktop app is good about that. But the problem in web dev is that it is a complex architectural boundary that has its own footguns. Suddenly you have to do everything concurrently and securely. And on the backend, you can no longer just serialize to a file in a known directory. You have to learn securely connect to a database, be competent in a query language, and be able to manage all the infrastructure or sysadmin work that comes with databases. Oh, and you can no longer just distribute your application as a binary or with an installer. Now you have to be a master of all the sysadmin and process work that comes with deploys and cloud infrastructure. Debugging is no longer just gdb and depends on competent logging, you're likely to have to finagle calls to several REST APIs (all with slightly different auth) instead of just linking in a library, you have a hell of a lot more things to mock when you're testing... The list of added complexity goes on and on and on, and all of this is on top of whatever complexity is inherent in the problem domain to begin with. Web dev adds just adds a ton of complexity.

elashri 2y ago

On a somewhat off-topic point, the photino, which is the proposed superpartner of the photon, will not be massless. If it exists, we know for sure that it will have a mass significantly larger than that of the electron. For starters, we would have already discovered it if it had such a low mass. Therefore, it is incorrect from a particle physics perspective to consider the photino lighter than an electron. And yes, I know this is why people don't like talking to physicists. Good luck with the project anyway :)

eointierney 2y ago
Thank you. This was the comment I was looking for.

romwell 2y ago

TL;DR: >Photino uses the OS’s built-in Chromium or WebKit-based browser control for Windows, macOS and Linux. So, same difference. Native and lighter than light my arse, pardon my French. It's still using a browser under the hood to render UI.

butz 2y ago

"on Linux it uses WebKitGTK+ 2" - is this counted into download size comparison, or conveniently left out?

butz 2y ago

Is you already are writing .NET application, why not use UI library they provide and actually build a desktop application? You can even do pretty good optimizations when packaging such .NET app to reduce its size and even include runtime, to remove requirement for external dependencies.