I still live in the world of heavy desktop native apps (WinForms & WPF) and one thing I've never been able to understand about all of these Electron discussions is what benefit does Electron bring in the first place? Why not simply run the application and connect to it using the local browser instance? For convenience a link can be placed on the users desktop.
It sells the dream of using web developer skills on the desktop, for those who want to develop native apps but don't want to learn new tools/languages.
Square peg, round hole. Electron just gives you a hammer to make it fit anyway :)
It also sells the dream of writing an app that works on multiple platforms. The web is good at this but depending on what your app does you might need more. For instance, in Electron you have access to Node. This lets you do things that you wouldn’t be able to do in the browser. It would let you do lots of things but for example: access local file system, use SQLite or some other storage without requiring a network connection, add an icon to the menu bar or taskbar on Mac/Windows, you could even control a users mouse for something like screen sharing.
I write native applications, cross platform (I generally make releases for Windows, Mac, and Linux), and cross-compiled using FPC + Lazarus.
No trickery, no hidden browser windows, just normal native executables.
Java also solves the cross-platform issue, though it's GUIs tend to not look native (As opposed to Lazarus above, which is native).
If you're impressed by a webserver being able to interact with the OS for things like accessing files or databases, your mind will be absolutely BLOWN when you learn real native development.
You’re making an assumption I haven’t already learned real native development but that’s besides the point.
Java does solve part of this but some people would rather use JavaScript than Java. Even if they know how to use both believe it or not.
However, if one of your platforms is the web browser, nothing is going to work better than a web view if you want a cross platform solution. Slack for example works almost exactly the same in my web browser as it does in electron. If you want a solution that works on Linux, MacOS, and Windows AS WELL as the web browser then the web view approach is pretty obvious.
Lastly the JavaScript web development experience is great with hot module relacement and Chrome’s developer tools. Not to mention the JavaScript open source community is amazingly strong and there is a lot of innovation going on. To simply dismiss all of this because of personal reasons is fine by me but I don’t agree with your view.
“It works the same on the desktop as it does in my web browser” is an indictment, not a feature. People use cross-platform toolkits because they don’t want to do the work to fit in with the platform their user chose, not because they confer any advantages to the user.
That is certainly one way to look at it. I'll propose another way to see it: There are always trade offs. For example, you could hire enough people to simultaneously work on a Mac OS version, a Windows version, an iOS version, an Android version and a web version of your product. Of course this is going to cost a lot of money and this cost will be passed on to the users. If the users prefer the subtle differences between the UI in platforms so much that they would prefer to pay more for a product than that would be an advantage. Otherwise that is a disadvantage. Potentially a really big disadvantage. There is also a case to be made that some people would definitely want the product to work the same in the web browser as it does on their desktop. Slack is a good example of this. I don't want to learn a new user experience for the moments when I'm on another machine without Slack installed and I just want to respond to a comment quickly, I'm very happy the web experience and the desktop experience are similar.
Making absolute statements about why people make certain choices or believing them can definitely lead to false conclusions. People don't only use cross platform toolkits because they do not want to do work. Sometimes it is the best solution given the features and constraints. I like to think of it as being pragmatic.
>If you're impressed by a webserver being able to interact with the OS for things like accessing files or databases,
I don't think anyone is "impressed" by it. It is just useful. The point of electron is being able to write javascript applications that run on multiple platforms.
Using Lazarus (and Pascal) means you need to learn another language to write native applications from the one you use to write web applications.
I'm not taking a position here, I am just pointing out the pros and cons. I am neither a javascript nor pascal programmer so I have no dog in this fight.
Lazarus looks quite cool, but I don't see it addressing mobile app development, which makes it a non-starter for me. Electron doesn't support mobile directly, but the web app built for Electron can also be packaged in Cordova (or similar) for Android and IOS.
Running a server app and pointing your browser to it may work for you. Less sophisticated users will struggle with this approach starting with coordinating two things. You are also getting some bundling advantages with it - in particular electron contains node (and the right version with which the app was tested) which is also not a given on innocent users computers. Last but not least one gets support for building bundles for multiple OS platforms.
Java apps on the desktop became more prevalent and usable when Java was bundled in. The Electron is not so different from what worked for Java.
It’s all about cross platform support. The reason you will see advantages listed this way is because the web browser is the real competitor here. So when people talk about what Electron can do they are comparing to the most obvious alternative of a web app.
You’re also competing with native mobile tool sets on native.
If you want to write software for a platform, write software for that platform. Don’t write software for some other platform, try to make it fit, and then declare it good.