- /info is broken (try reloading it)
- js is half a mb
- app is polling the db way too fast
- app is a small counter but uses react, which is made for big scale social networks
- its made in 48h, which is wayyy too long?
I don’t see a good reason to use it. When I want to change a value later I use let at the top of the appropriate block, otherwise const. The code reads nicer that way.
Adding the thing that complains is a one-time cost. It may work on Firefox now, but making sure that it continues working on Firefox is a continuous resource investment.
And not adding it and not testing for Firefox would cost nothing, and currently improve the user experience - because it actually just works, as a lot of things just do.
But then what if a bug in their code that only affects FF goes unnoticed due to testing, and causes significant problems for a big client, or a journalist reviewing it, or...
Personally I feel a "We don't officially support this browser, it probably works but we only test for full compatibility in <these browsers>" is a better option if you're going to go in that direction.
But I can understand why even that is a bit of a risk as if a user decides to ignore that warning and then some time later encounters a bug that, let's say, causes them to lose half a day of work, they're likely to walk away blaming the company (and maybe go round telling people they know what a shit thing it is) even if the bug wouldn't have happened had they been using one of the browsers that is fully supported and gets tested.
It seems more like the devs at MS know their code works on Firefox but have been asked by exec to push chromium(-esque) because edge is now webkit.
sidenote: this is a multi-billion $ company, no excuse to ignore any platform with their capacity, front face it looks like they can't build a good app anymore, especially if it works anyway with a simple string change in the browser - heck, web devs had to factor in ie7-8 polyfills built by the community only a few years ago. no excuse.
What´s the problem with this? I have enough space on my drive. Sure the app is bigger but it´s platform independent and works flawlessly. Native apps crash often, use big os dependent frameworks (you have to install sometimes) and only to have a smaller bundle? I don't get it.
The problem? When you start to have 5-6 apps running with Electron in the backend and start to take 10% of your CPU time and 2 Gigs of RAM, you will start to feel how it impacts your working environment, battery life and all.
On a serious note: I never understood why people tell me to buy better hardware to compensate for the shitty performance of their software. No, fix your software!
Nah dude this line of thinking got us here. We need to reach back to what the OG's in computing thought about. Small size, fast performance. Limit ourselves.
I read about this dude who purposely writes software on a shitheap laptop just so that "if it's fast here, it's fast on modern mobile phones."
Even my app written in Elixir and uses 160MB of RAM after letting it run for a week; I've been thinking: "Maybe I could bring it lower to what nzbget uses (around 59MB)". I've been exploring Nim for that.
My app does very little and is meant to be self-hosted for your own use. Or are you talking about Elixir or Nim as a language?
Edit: Oh I get it you actually meant:
"Hehe, kinda funny when your application written for Electron comes with more security vulnerabilities than it has lines of code for its own logic ;-)"
It is about having a color picker (probably just a few lines of code) bundled with quite a set of dependencies and complex chromium runtime environment which does not get updated regularly. Therefore they keep their vulnerabilities even after they are known and fixed in later versions of the dependencies.
With small footprint applications, you are less likely to have such problems.
First, this is a false dichotomy. There are alternatives to Electron that don't require a 120 MiB runtime and don't involve using the OS APIs directly.
Second, this is not a criticism on application writers, but on Electron itself. It could use a runtime available on computers (virtually every computer has a browser) or, at least, a shared runtime that would download itself.
Bundling a browser with EVERY different app is not only a waste of space and of RAM, but also a security issue: now you have to wait for each app developer to update the app in case there's a security problem with Electron, Chromium or any of its 2000 dependencies, and that's "if" they upgrade. And that update takes at least another 120 MiB to download, for each Electron app you have.
Instead of downloading 120 MiB for each app, each app could come in a small package and only download the runtime if it's not available in the computer yet. Java got it right in the 90s, .NET got it right in the 2000s, although downloading the runtime had terrible UX for stupid marketing reasons (you had to provide e-mail to download from the Sun or the MS website).
Every native app I've used works everywhere I've used it, every time as well.
That native apps were wildly unstable, or that it was impossible to find native apps that ran on different platforms before Electron is a myth. Electron didn't solve those problems, because they weren't problems.
Electron solved the problem of "how can I, a web developer, run a website on the desktop but make it seem like a native app and call myself an application developer?"
