191–200 of 256 posts
Earlier quoted context omitted.
Each of those apps does a lot more than the most common use for electron: "online messengers" Also, you're arguing in typical FYGM fashion. Not a good look.
I was merely comparing an Electron app (VSCode, not at all an "online messenger") to average apps running on the desktop because your original comment implied "200Mb for the smallest apps" which isn't true.
No idea why VSCode is being sparing for you, but i've seen plenty of electron-based online messengers use that much just by running.
This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entire browser inside. But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. The fact is, for many types of applications,…
>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating pl…
I think the points raised are solid, but at this point it seems like Electron is the best worst solution for cross platform UI. Having worked with Qt I never wanna do that again. There's also a much more significant portion of developers who can work on Electron based apps. Part of picking the best tool for the job involves considering maintainability and ease of development after all.
What are your problems with Qt? I was using PyQt, and I found it nice (Qt's integration is good).
It goes out of its way to not rely on the STL, so that std::string and QString are separate, non-convertible classes. QList and std::list are the same, same for QMap and so on and so forth. So data communication is already a pain.
We then have further issues with function invocation. Slots and sockets are simple with python, because functions are first-class in python. In C++, they are very much not, so slot-socket binding looks like: connect(sender, SIGNAL (valueChanged(QString,QString)), receiver, SLOT (updateValue(QString)) );
This is less than ideal.
Earlier quoted context omitted.
Even if the app is smaller on drive, it still takes ~200mb in ram for even the smallest apps.
Dropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it. All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram. If you want to go against bloat, you might just as well uninstall every single software from your computer, inc…
Earlier quoted context omitted.
"Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept." From a systems perspective that is emminently rant worthy, it indicates the system has completely failed the developer who cannot easily express what they can in a single page web app as a real application in the system.
Yep, all the native toolkits failed, that's worthy of ranting about, but that is not what OP was doing.
Earlier quoted context omitted.
Yep, all the native toolkits failed, that's worthy of ranting about, but that is not what OP was doing.
I can't see how Cocoa failed at anything.
Will my Cocoa app run on Windows, Linux and the web?
(A well-designed web app built with Electron will).
Why should any company that wants their product to be widely available invest in Cocoa developers?
Earlier quoted context omitted.
>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating pl…
But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.
Not that there aren't a lot of posts here defending Electron that basically say the same thing but don't you feel embarrassed in the slightest for saying that?
Yes, there's a lot of things we, as coders, can do to make our lives more convenient by treating bandwidth, RAM, and CPU wastage as an externality that can be shoved off onto the end-user to pay for. That doesn't mean we should.
Earlier quoted context omitted.
Even if the app is smaller on drive, it still takes ~200mb in ram for even the smallest apps.
Dropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it. All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram. If you want to go against bloat, you might just as well uninstall every single software from your computer, inc…
I call bullshit on that one.