If you build something functional fast with your favorite tool (not suited for the job), then you will probably spend many months maintaining/hacking your codebase to keep it functional and well designed.
If you build something functional fast with your favorite tool (not suited for the job), then you will probably spend many months maintaining/hacking your codebase to keep it functional and well designed.
An Electron app is not equal to a native app when it comes to UX and UI. Right off the bat: they require more resources to run, thus making your computer slower, a laptops battery last less on a single charge, and don't look and work like native apps thus requires the user to learn a new paradigm.
So instead of you, the developer, using a couple of months to learn a new paradigm, you put that burden on your users, and end up with something that is a whole lot worse than standard native apps on Mac, Linux and Windows.
If you only have 1 user, that is no hassle, but if you have 5 million users, that is a whole lot of time that a whole lot of users needs to spend collectively because you are lazy and want to ship something fast instead of shipping something great.
And no, I have never tried a great Electron app. I don't think they exist.
Exactly. That's the externality a lot of software companies nowadays generate.
But yet you used a either a browser or the HN mobile app (cordova) to post here... guess that means function > fitness.
You get the picture.
The barrier to entry for Electron apps is 0, the same as for native apps.
At first glance, Electron apps should be more maintainable, not less, because it's one toolset for multiple platforms, which should translate to faster development time and less total cost of maintenance at the tradeoff of app performance and size.
Also, whether an app is difficult to maintain ought owe more whether (1) you have multiple diverse codebases and toolchains to maintain, and (2) that you have a disciplined engineering strategy.
Again, whether or not Electron is the right tool for the job is a business decision based on business constraints.
Unfortunately, usability and ergonomics are rarely reflected in business "fitness functions" (hell, even making an actually useful tool rarely is these days, thanks in part to marketing having better ROI than delivering value). Business people take care of business goals, and I think it's our responsibility as developers to make applications that don't suck, whether or not it is reflected in the organizational "fitness function".