Photino: A lighter Electron | Hacker News Reader

Photino: A lighter Electron

tryphotino.io

32 pointsAbuAssar52 comments

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

Or Wails with Go. It’s good we have more competitors in the desktop space.

Or with Socket Runtime (https://socketsupply.co/).

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.

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.

There shouldn't be a difference. Tauri doesnt even require you write rust. It's entirely optional.

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.

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.

Is it?

As far as I understood it, Tauri is a safer Electron, not a lighter one.

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.

Which gives it all the compatibility issues of each platform.

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

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.

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

The success of Electron tells us that memory usage concerns are overblown. Memory is seriously dirty cheap nowadays. Time to spend a bit more to simplify the ecosystem.

Ok, first of all, what is going to ship is not just Electron but a whole VM plus Electron. Just like how people run the JVM in Docker or whatever, because nobody trusts any layer of their stack to actually be abstracted enough that they can feel comfortable with what is underneath. That’s going to be truly awful.

Second, the “success” of Electron is like the “success” of online advertising. Nobody really likes it and it’s basically a local optimum in a deep pit that it’s unfortunate we’re stuck in. It’s just that economic pressures have pushed the market to this being something people tolerate rather than actively desire.

I consider it a little perverse to say "simplify" and Electron in one sentence.

But my main point is that memory requires power so adding memory to a machine shortens battery life (or increases weight due to larger battery).

So far AFAIK no laptop maker has made a laptop that can power off half the RAM to decrease demand on the battery when only half the RAM is needed.

(Also, I do not like apps built on Electron and do not use any.)

isn't that docker is for?

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?

(I assume you’re talking about loading Slack in the website? That’s the only WebKit surface you have that I know about.)

Let me turn the question around for you: why do you think shipping Electron will save you? Sure, maybe WebKit has a broken video decoder this year. What will you do next time when it’s the GPU driver? You already know what the answer is: you diagnose it as far as you can, report it upstream, and communicate the best you can with your users. You seem to have the mindset that every bug exists to be fixed, and that’s not true at all. They are all a tradeoff. It’s easy to go “oh if we bundle everything ourself we can shift more control to ourselves to fix bugs because more of the components are ours”. First of all, you actually have to do that: turns out plenty of companies operating at scale are unable to do that (have you looked at how often Discord updates their dependencies?). And even when you’re committing to doing this and follow up, you have to understand that you’re unconditionally shipping a worse experience to all your users in the hopes of solving saving some time for some small fraction of them. This isn’t something that I am completely against (for example, I advocate for shipping debug symbols to users-but that’s another long argument) but you also have to look back at yourself and go “ok we’re shipping 98% of the same code across platforms and supporting macOS Mojave takes an extra 2 engineer-days a year, maybe this is an OK state of things” rather than being absolutist about something you’re not achieving anyway.

> why do you think shipping Electron will save you?

All of the videos will be pink, not just the macOS ones on an older Safari.

At worst someone could dig into the Webkit (Chome?) distro and fix it and they can release a custom build for the short term before it gets incorporated, fixing "everyone".

I am confused by your response. Did you take into account the part where I was talking about bugs in layers under Electron?

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.

> App makers are perfectly capable of shipping their own security updates now that we have cloud auto-updating whenever we want it.

A large third-party dependency chain is, in my opinion, the most problematic security risk in modern software. Secondly, automatic updates are how we got cloud-strike.

I’m not advocating Debian style dependency sharing, but I am advocating for tight control and auditing over your dependency chain (which will mean building more in house). And allowing IT departments to control update rollouts.

Centrally managed dependencies are invaluable for small/simpler apps.

Not every program is backed by a company that provides continuous updates.

And what happens if the updates stop? Yeah right you have a giant pile of half-broken, bug-ridden and outdated random libraries.

I use some small Win32 and GTK+ utilities that weren't touched in years and they all just work, are nicely integrated into the system theme (even dark mode works without me lifting a finger) and use fresh and up-to-date dependencies courtesy of the OS.

You nailed it. Every time I see a new Electron replacement pop up that uses less resources, less disk space, etc., it's using the OS webview. I would argue that it's almost impossible to ship a reliable version of the app without resorting to polyfills and using only a fraction of the Web APIs available today. I tried Tauri out for a time tracking app that has a week input, and I ended up going back to Electron because the macOS webview (Safari) doesn't support it. If I use a framework that leverages the OS webview, can I use SharedWorkers? Nope. Atomics? Nope. WebGPU? Nope. You're kneecapped by the lowest common denominator (which is pretty much impossible to determine because there's no way to know the oldest version of the OS webview your users might have installed).

Don't get me wrong, I applaud the efforts of the Photino devs, the Tauri devs, and the Wails devs. They're all very cool projects. But if you need to build something non-trivial with them, you're going to have a bad time. The resource usage and large binary size that comes with Electron is the price you pay for having a cross-platform app that doesn't break in weird and unexpected ways. I never see any kinds of warnings or caveats on these framework websites explaining the drawbacks of using the OS webview. Which means every time one of these comes out, I have to explain to the people that I work with why we can't just ditch Electron.

I can buy that using the OS-provided browser is a bad idea, but referencing slack is hardly confidence-inducing.

Slack is by far the slowest and buggiest web app I've had the misfortune of being stuck with. And bundling it with chromium is an even worse idea given that the only way of getting half way decent performance with slack is opening the web version in Firefox (and specifically not Chrome).

And yes, I've heard MS Teams is even slower, but I've never had to use it

> I can buy that using the OS-provided browser is a bad idea, but referencing slack is hardly confidence-inducing.

It would be worse. They could have said Microsoft Teams.

> And yes, I've heard MS Teams is even slower, but I've never had to use it

Oh, dear.

The way you capitalize words reminds me of the style used in newspapers and other writing from the 1800s. Is there a part of the world that still uses capitalization for... whatever you're doing? Or is that just a personal affectation?

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?

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 :)

Thank you. This was the comment I was looking for.

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.

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

I'm using it in my project LANCommander for a game launcher: 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.

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.

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

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.

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.

I'm not sure what point you're making about backend complexity. We're talking about Electron as a toolkit for desktop apps. You can distribute it as a binary with an installer. That's a big part of the Electron value proposition.

Is using web APIs for things like networking and storage really more burdensome than using the corresponding POSIX APIs? It's the same stuff with a different spelling.

If we are comparing a desktop app to a web app, an apples to apples comparison has to include frontend and backend.

>Is using web APIs for things like networking and storage really more burdensome than using the corresponding POSIX APIs?

Yes. Absolutely it is. If nothing else, you don't have an auth step. Not to mention the infrastructural and management overhead of web APIs. I don't have to worry about the care and feeding of a customer's hard drive the same way I do my service's database. Or pay Amazon for the privilege of using something more convenient.

Electron apps don't have to be remotely hosted. It is entirely possible to write a completely local Electron app (and in fact, desirable!)

Gtk4 does not really do Macos these days, Qt costs a leg when you go commercial, Wxwidgets might be the only one left but its community is still quite small. Others(C# based, Flutter based) are not that great either. So yes for cross platform commercial desktop GUIs, Electronjs really has no competitor.

Qt is 500 a year for small businesses, thats basically creative cloud pricing. Could we really solve the current state of desktop ui by just convincing devs to pay 40 dollars a month?

It's way more complex than that in fact, just looked at the license page again and gave up again.

I mean, if you make under 1mil a year and arent shipping physical products, just software, the licensing doesnt seem that complicated. Its pretty draconian of course, but it also doesnt seem prohibitively expensive was my point.

You can't build a "for-real native desktop app" without building half of a browser anyway. Can't use a font without FreeType or HarfBuzz, can't use a secure socket without OpenSSL. Can't afford to redraw the entire screen each frame, so you need a DOM of some kind to cache rendered boxes. The OS doesn't do anything it didn't do 20 years ago. Stack's a mess rn. imo

Thankfully, JavaFX does all of that (fonts, SSL, scene graph), but it's an unpopular option.

Yea, it's not native, but its more the native dev experience, and its actually quite portable.

No, I'm pretty sure OSes provide text rendering, SSL, and some analog of MVC.

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.

Reply on news.ycombinator.com