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

41–50 of 57 posts

Re: Photino: A lighter Electron

#41

Post by elashri »

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

Re: Photino: A lighter Electron

#42

Post by Fraterkes »

synergy20 wrote: post #35
Fraterkes wrote: post #28

Earlier quoted context omitted.

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.

Re: Photino: A lighter Electron

#43

Post by codelikeawolf »

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…

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.

Re: Photino: A lighter Electron

#44

Post by lll-o-lll »

quotemstr wrote: post #13
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…

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

Re: Photino: A lighter Electron

#45

Post by eointierney »

elashri wrote: post #41

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…

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

Re: Photino: A lighter Electron

#46

Post by wmf »

typedef_struct wrote: post #34
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 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

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

Re: Photino: A lighter Electron

#47

Post by 0x000xca0xfe »

quotemstr wrote: post #13
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…

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.

Re: Photino: A lighter Electron

#48

Post by romwell »

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.

Re: Photino: A lighter Electron

#49

Post by saagarjha »

whartung wrote: post #36
saagarjha wrote: post #27

Earlier quoted context omitted.

(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 co…

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

Re: Photino: A lighter Electron

#50

Post by 3836293648 »

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…

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

Post reply on HN