The early 2000s were a different time. While as modern day electron apps are regularly 100+ MB.
...but really. ImageOptim is super awesome and zero-effort.
But really, why isn't ImageOptim itself available in command-line form?
> Automates ImageOptim, ImageAlpha, and JPEGmini for Mac to make batch optimisation of images part of your automated build process.
> Mac
Why would anyone run a CI server on a Mac?
Looking at the output directory, I saw that the fonts I'm using make up about 45% of the whole app!
[0] I would be very happy with Qt/QML and would grudgingly accept GTK, but others apparently are not that complacent
These days, I do* have a couple of Electron-things installed, because I occasionally need them, but they are ugly hacks which bring me no joy.
No JRE either, by the way, if I can help it. Same reasoning.
The electronisms I occasionally have to use are glorified chat-apps like Signal. Hardly complex UI cases.
I personally find it a bloated mess, and like to stick with my Komodo and my Geany - two neat examples of portable UIs done right.
Anyway, I'm sure there are ways of embedding runtime web macinery in somewhat less than 100Mb. Twenty years ago I did so in a megabyte or two, admittedly without the js.
I also remember circa 2000 when the CS meta was, "who cares about optimization when you're riding the perpetual tailcoat of Moore's law"...then homogeneous parallel architectures became a thing overnight and much of the software development community was caught with their pants down.
Flash forward over a decade later with low-power embedded being the dominant end user platform and heterogenous compute already at the competitive forefront. Perhaps it's personal bias, but when I read net-smaller apps, my hardware design instincts immediately kick and scream net-complacency.
How would that work if all the application developers decided that native sucks and all should use Electron?
I created a proof-of-concept called Electrino that uses the platform native libraries to cut down on app size: https://medium.com/dailyjs/put-your-electron-app-on-a-diet-w...
Unfortunately I haven't had the time to work on Electrino due to family, etc. — I wish I did because the need is clearly there.
Electron-like "web" apps (that follow W3C standards) seem to be the future, and I'd love to help out however I can.
I can understand the inconsistencies and lack of feature support that could emerge from using a different browser engine for each OS (Webkit/Edge), but there should at least be away for Electron apps to share Chromium/Node runtimes between them.
Rather than Spotify, Slack, Discord, ... all coming with their own Electron bundle they can be packaged up as a PWA and use the browser as the runtime environment along with all the nice offline stuff, safe OS integration for notifications, sandboxed file system access, ability to still do some work in S0i3 (aka Modern Standy on Windows), etc.
Or am I totally wrong about this? I am not a web developer so I could be :)
Bonus question: how would this work for things like Atom and VS Code that are electron based. Could they become a PWA?
But some UI issues, like the lack of a proper menu, browser's chrome and address bar will still be a turn off. Besides, having unrestriced access to the user's drive is not something a web page should be able to do and is a must for something like a text editor.
It’s going to want access to all files in that directory, not only the ones you are editing.
Not sure how menus are handled. A standard menu API would seem to make the most sense to me?
Adobe AIR was an effort to create a common runtime for similar things... wouldn't mind seeing a few OS vendors coming together to support something similar, but on the flip side, I don't want to be stuck with Node 4.0's API in 2024.
I'd hesitate to make this generalization. I need to use slack on a macbook for work and it crashes regularly. I tried out VS code and it also would crash on occasion. Worse than that, coworkers of mine have rolled bug-ridden electron apps that we're required to use. There are plenty of non-electron apps that are stable.
I don't like that slack consumes some many resources. I love vscode so I don't care.
> coworkers of mine have rolled bug-ridden electron apps that we're required to use
This is quickly becoming one of those things I can't stand, especially when there are open source/free options out there. No, I don't want to use your homegrown application unless there really isn't a good option out there. And if that's the case, make it a good tool and release it OSS and try to get some traction behind it.
Most 'home grown' corporate apps I've used are dependent on internal resources, processes and requirements. They'd be useless to anybody else, there are no alternatives anywhere at any money and in many cases you can't do big chunks of your job without them.
Electron is just outsourcing cross platform development to the Chromium project.
So my 32GB RAM, high specs system, is able to run only up to ~ 30 instances of Discord, not counting even the OS.
Wtf. It feels like malware.
"No JavaScript on the desktop"
And suddenly 8GBs of ram is at least 4x too much(Linux) even when I'm using "bloated" Java apps...
https://suckless.org/sucks/web/:
Millions of jobs are based on outputting HTML in an inefficient way.The fact that no such competitor exists is evidence that the user's preferences aren't what you stated, but is in fact consistent with reality, namely they prefer free and bloated.
It's not so easy for a competitor to show up, because they have to work against heavy first-mover advantage and network effects in software. Those who do a crap job get first to the market and set the trend (and the expectations). Moreover, there's a heavy component of tragedy of the commons here, with commons being users' computing resources - the software is often designed with implicit belief that it's the only thing running on user's machine. It's enough to make a sale, and you don't get a reward for making it so that your users can run many other stuff simultaneously with your application.
... and ultimately to the consumer, who pays for higher spec'd hardware and more electricity.
Yeah, and that's a good thing. Furthermore, there are toolkits that don't, and they are still more efficient than Electron.
That's the point. Why download another framework when you have one on your computer already that's tailored to your platform?