Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Photino: A lighter Electron

tryphotino.io

Post reply on HN
Print view View original

11–20 of 57 posts

Re: Photino: A lighter Electron

#11

Post by quotemstr »

VyseofArcadia wrote: post #9

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.

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.

Re: Photino: A lighter Electron

#12

Post by saagarjha »

anaisbetts wrote: post #8

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…

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.

Re: Photino: A lighter Electron

#13

Post by quotemstr »

anaisbetts wrote: post #8

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…

The phenomenon you're discussing is part of a broader trend towards simplifying development and deployment by just vendoring all dependencies, dammit. Fewer dependencies, fewer headaches, both for app makers and OS vendors. The sky didn't fall when Android stopped providing openssl and libstdc++ with the OS.

Sharing centrally managed dependencies made some sense in the days of infrequently-updated boxed software, but now? Brute force has made the size advantage of sharing irrelevant. (People complain about Electron memory use, but still use it.) Security advantages? App makers are perfectly capable of shipping their own security updates now that we have cloud auto-updating whenever we want it.

I just don't think that there's still a real technical case for Debian-style dependency sharing in general purpose operating systems and that we can save ourselves a lot of time and pain by getting out of our 1990s shared library mindset.

and it's taken a lot of time and a lot of retirements to change this mentality.

Re: Photino: A lighter Electron

#14

Post by quotemstr »

saagarjha wrote: post #12
anaisbetts wrote: post #8

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…

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.

> 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.

Re: Photino: A lighter Electron

#15

Post by [deleted] »

anaisbetts wrote: post #8

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…

[deleted]

Re: Photino: A lighter Electron

#16

Post by [deleted] »

VyseofArcadia wrote: post #9

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.

[deleted]

Re: Photino: A lighter Electron

#17

Post by synergy20 »

Blahah wrote: post #3

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

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.

Re: Photino: A lighter Electron

#18

Post by saagarjha »

quotemstr wrote: post #14
saagarjha wrote: post #12

Earlier quoted context omitted.

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.

> 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,…

Are you going to pay for the extra RAM I need to run your VM too?

Re: Photino: A lighter Electron

#19

Post by synergy20 »

quotemstr wrote: post #14
saagarjha wrote: post #12

Earlier quoted context omitted.

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.

> 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,…

isn't that docker is for?

Re: Photino: A lighter Electron

#20

Post by anaisbetts »

saagarjha wrote: post #12
anaisbetts wrote: post #8

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…

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.

Here's a real, actual bug that we had in the old Slack for Mac app (which was Webkit-based, so effectively the same approach as Tauri et al) - some users, only on older versions of macOS, report that whenever they paste in a YouTube link, the embedded video has a pink tint.

Tell me, how would you fix this bug?

Post reply on HN