Should have funded the entire GIL-removal effort by selling carbon credits. Here's an industry waiting to happen: issue carbon credits for optimizing CPU and GPU resource usage in established libraries.
I wonder about the total energy cost of apps like Teams, Slack, Discord, etc... Hundreds of millions of users, an app running constantly in the background. I wouldn't be surprised if the global power consumption on the clients side reached the gigawatt. Add the increased wear on the components, the cost of hardware upgrades, etc...
All that to avoid hiring a few developers to make optimized native clients on the most popular platforms. Popular apps and websites should lose or get carbon credits on optimization. What is negligible for a small project becomes important when millions of users get involved, and especially background apps.
If we go by Microsofts 2020 account of 1 billion devices running Windows 10 [0], and assume all those are running some kind of electron app (or multiple?) you easily get your gigawatt by just saving 1 watt across each device (on average). I suspect you'd probably go higher than 1 gigawatt, but I'm not sure as far as making another order of magnitude. I also think the noisy fan on my notebook begs to differ and maybe the 10 GW mark could be doable...
There are 30,000 different x-platform GUI frameworks and they all share one attribute: (1) they look embarrassingly bad compared to Electron or Native apps and they mostly (2) are terrible to program for.
I feel like I never wasting my time when I learn how to do things with the web platform because it turns out the app I made for desktop and tablet works on my VR headset. Sure if you are going to pay me 2x the market rate and it is a sure thing you might interest me in learning Swift and how to write iOS apps but I am not going to do it for a personal project or even a moneymaking project where I am taking some financial risk no way. The price of learning how to write apps for Android is that I have to also learn how to write apps for iOS and write apps for Windows and write apps for MacOS and decide what's the least-bad widget set for Linux and learn to program for it to.
Every time I do a shoot-out of Electron alternatives Electron wins and it is not even close -- the only real competitor is a plain ordinary web application with or without PWA features.
> Every time I do a shoot-out of Electron alternatives Electron wins and it is not even close
Only if you're ok with giving your users a badly performing application. If you actually care about the user experience, then Electron loses and it's not even close.
Many times this. Native path is the path of infinite churn, ALL the time. With web you might find some framework bro who takes pride in knowing all the intricacies of React hooks who'll grill you for not dreaming in React/Vue/framework of the day, but fundamental web skills (JS/HTML/CSS) are universal. And you can pretty much apply them on any platform:
- iOS? React Native, Ionic, Web app via Safari
- Android? Same thing
- Mac, Windows, Linux – Tauri, Electron, serve it yourself
Native? Oh boy, here we fucking go: you've spent last decade honing your Android skills? Too bad, son, time to learn Android jerkpad. XML, styles, Java? What's that, gramps? You didn't hear that everything is Kotlin now? Dagger? That's so 2025, it's Hilt/Metro/Koin now. Oh wow, you learned Compose on Android? Man, was your brain frozen for 50 years? It's KMM now, oh wait, KMM is rebranded! It's KMP now! Haha, you think you know Compost? We're going to release half baked Compost multiplatform now, which is kinda the same, but not quite. Shitty toolchain and performance worse than Electron? Can't fucking hear you over jet engine sounds of my laptop exhaust, get on my level, boy!
Qt costs serious money if you go commercial. That might not be important for a hobby project, but lowers the enthusiasm for using the stack since the big players won't use it unless other considerations compel them.
Depends on the modules and features you use, or where you're deploying, otherwise it's free if you can adhere to the LGPL. Just make it so users can drop in their own Qt libs.
QT only costs money if you want access to their custom tooling or insist on static linking. We're comparing to electron here. Why do you need to static link? And why can't you write QML in your text editor of choice and get on with life?
Some widgets and modules, like Qt Charts (or Graphs, I forget), are dual GPL and commercially licensed, so it's a bit more complicated than that. You also need a commercial license for automotive and embedded deployments.
> You generally can't adhere to the LGPL in automotive
"Can't" or "won't"?
The UI process is not usually the part that need certification.
> Slint has a similar license
Indeed, but Slint's open source license is the GPL and not the LGPL. And its more permissive license is made for desktop apps and explicitly forbid embedded (so automotive)
...which is the same as Flutter. Both don't use native UI toolkits (though Qt doesn't use Skia, I'll give you that (Flutter has Impeller engine in the works)). And Qt has much worse developer experience and costs money.
Qt costs money if you for some reason insist on static linking AND use all the fancy components, the core stuff is all LGPL.
Anyway it does look native and it is way faster than electron, which also doesn't look native so I don't understand why it's a problem for Qt but not for electron.
I actually built this analysis while I worked at Microsoft so I 100% agree. Doing the work at the platform level is the way to go and you can actually make a significant impact with this kind of approach.
The other value of this that's not obvious is that doing it client side ends up touching all the grids/generators in the world outside of the market based accounting that tends to drive the datacenter carbon impact analysis.
The solution is ironically, LLMs. You can construct a set of Claude skills to walk you through a code review, or understand code (anything, even course) fast.
This complexity to understanding compression will be a big market going forward.
Great art isn't necessarily about popularity / wide appeal, though. In fact, the art that isn't of wide, general appeal, is what stands to benefit the most from this kind of benefit.
Both are broad spectrum antivirals, but completely different mechanism.
DRACO "is a chimeric protein with one domain that binds to viral double stranded RNA (dsRNA) and a second domain that induces apoptosis when two or more DRACOs crosslink on the same dsRNA." (Ridder et al 2011). This article is about packaging mRNA for a set of 10 interferon-stimulated genes that express multiple proteins that target various stages of viral replication.
reply