181–190 of 214 posts
Earlier quoted context omitted.
You can control people's screens through Messages? And you can write simple webhooks and bots with a few lines of Ruby? Please send me some links, I'd love to do that.
Screen sharing w/ control: https://support.apple.com/guide/messages/screen-sharing-icht... As to web hooks and bots, if you really think that necessitates having it be a bloated Electron app, I don't know what to say.
Earlier quoted context omitted.
Screen sharing w/ control: https://support.apple.com/guide/messages/screen-sharing-icht... As to web hooks and bots, if you really think that necessitates having it be a bloated Electron app, I don't know what to say.
AppleScript is still a thing, right?
Earlier quoted context omitted.
No one else doing it right can be an argument to show that its because no alternative is much better, and so Electron is actually the possibly right choice. It still being too slow or memory hungry for your liking still remains though. But it seems that there might not be an obvious solution to this that does not compromise on features.
"No better alternative" != "right". As you observe, a compromised choice is still compromised.
So if you know a way to achieve your ideal, then you can propose that alternative, and you can say, here is how, without much more cost of development, you can achieve X, Y, X improvement on performance while keeping all features. But, if you do not know, and have no known examples, it could indicate that it is not currently technically known how, and thus impossible with the current hardware and software knowledge at hand.
I'd also say that in the case of Slack, their ideal is probably defined more in terms of profits. So it could be said to be the right choice, simply because of how popular their service is and has remained, even though they picked Electron for their desktop client.
Earlier quoted context omitted.
In year 2000 you might only have to care about Win98. And that’s it. In 2017 there’s no tech stack that lets you write consistent UIs across multiple platforms. Except, unsurprisingly, Electron
https://news.ycombinator.com/item?id=14066784 . Here's a discussion on alternatives. It's really not the only choice.
As a Linux laptop user, I fully endorse Electron. There’s so much more available for Linux because of it that would have no client at all otherwise. Between NVMe disks and the ability to have 64gb of RAM if I want...keep it coming. I’d rather have heavy software than no software.
Indeed. Some posters seem to think that, because you CAN build a chat app consuming a few megabytes of RAM, it means you should and it's practical. It's like pointing to 64KB demoscene games and saying "see, you can write a game in 64KB, why does this one take multiple gigabytes". Well, by all means, create a Slack competitor in hand-optimized assembly if you wish. Or whatever else you prefer (Rust?). If it's a bette…
Earlier quoted context omitted.
Oh what a lovely cycle. Every dev knows 16gb is the new 8gb so sure, why not have every desktop app consist of 20 independent webview/node processes. Can't wait until 32gb is the new 16gb. Eventually, when every single desktop app is like this, and we can no longer keep shoving more RAM into computers, we'll realise that the only way to manage such hogs is to pickle background apps to disk Android-style and to just h…
32 is already the new 16.
As a Linux laptop user, I fully endorse Electron. There’s so much more available for Linux because of it that would have no client at all otherwise. Between NVMe disks and the ability to have 64gb of RAM if I want...keep it coming. I’d rather have heavy software than no software.
Same here, it's really nice to have VSCode, atom, slack, etc. RAM is pretty cheap, I'd rather put money towards a better Linux machine than give that money to Microsoft for the OS.
There are many laptops which have fairly low total system RAM limits. Those in our workplace are 4GB and 8GB for example. Once you hit that limit the cheapness of RAM is irrelevant.
Earlier quoted context omitted.
> Harder to work with than CSS. Harder for a web developer for the first two weeks. UI builders are more suitable for making app layouts than CSS. > Harder to align look of web and desktop. Thousands of mobile apps do it without much trouble.
Many mobile apps do rely on web views. Think about it, it's already difficult to make Android and iOS apps look similar. You need devs for both platforms. Teams are already squeezed supporting web (4 browsers with their own quirks), mobile web (screen size matters), mobile native (android and iOS) without also having to spread their talent thinner across completely native desktop experiences in Mac, Windows, and Linu…