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

21–30 of 57 posts

Re: Photino: A lighter Electron

#21

Post by VyseofArcadia »

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

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.

Re: Photino: A lighter Electron

#22

Post by synergy20 »

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.

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.

Re: Photino: A lighter Electron

#23

Post by quotemstr »

saagarjha wrote: post #18
quotemstr wrote: post #14

Earlier quoted context omitted.

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

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.

Re: Photino: A lighter Electron

#24

Post by shrimp_emoji »

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

[dead]

Re: Photino: A lighter Electron

#25

Post by quotemstr »

VyseofArcadia wrote: post #21
quotemstr wrote: post #11

Earlier quoted context omitted.

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…

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

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.

Re: Photino: A lighter Electron

#26

Post by VyseofArcadia »

quotemstr wrote: post #25
VyseofArcadia wrote: post #21

Earlier quoted context omitted.

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

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.

Re: Photino: A lighter Electron

#27

Post by saagarjha »

anaisbetts wrote: post #20
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.

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.

Re: Photino: A lighter Electron

#28

Post by Fraterkes »

synergy20 wrote: post #22
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.

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?

Re: Photino: A lighter Electron

#29

Post by saagarjha »

quotemstr wrote: post #23
saagarjha wrote: post #18

Earlier quoted context omitted.

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.

Re: Photino: A lighter Electron

#30

Post by anaisbetts »

VyseofArcadia wrote: post #26
quotemstr wrote: post #25

Earlier quoted context omitted.

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…

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