[Discussion] Project Goals
paramaggarwal opened this issue · 6 comments
I think we need to explicitly mention the goals of this project. The tradeoffs that are made using this project are definitely worth it I feel.
The tradeoffs that it makes is to use platform native tools for the web context and js context. To achieve this it is only able to offer a subset of features in Electron.
I think even if we just had two APIs child_exec and fs - it would still be totally worth it. It allows the creation of simple apps that are able to display a UI and access CLI and filesystem.
Definitely. I think it would have been nice if @pojala could have made his initial goals and reasoning a little more explicit in the beginning, thankful that he started this nice idea in the first place. At this point I think it would be good to leave the goals a little bit open for discussion. It seem to me like the major goal should be to support Node.js-like desktop apps using the built-in WebView, with minimal additional requirements. Thanks @paramaggarwal for all of your contributions!
Good point. Let's make this thread that discussion. What should be the goals of this project?
Here are the goals I think we should have for this project:
- Maintain a minimal subset of the electron APIs
- Aim to be an alternative to electron for small to mid sized apps
- Embed node in electrino
Thoughts on these goals?
Yes. I currently go to Electron when I want to make an internal tool/console that needs access to the filesystem and hence cannot work in a browser. For this use case I find it insane to ship large 70MB binaries.
For situations like these Electrino should be the go-to solution. And then if someone needs even more granular APIs, they could switch to Electron.
I personally actually just desire a light-weight web context with access to the filesystem.
I went through the list here Full Electron API and I think to start with, dock icon and file system access is the most important.
As I understand it, people are really interested in this project because it's lightweight, which solves one of the biggest problem with Electron right now. The assumption is that many projects don't need everything that electron has, and that it can be stripped down.
However, if you add the NodeJS runtime, that of course adds overhead by itself. Vendoring a NodeJS runtime with every app is not great, although it's smaller than Electron.
Another issue is passing file system paths from the browser window (either through an input field or drag-and-drop). If the app should open user-defined files this is a must.
Then there's building, distribution and updating. Even simple apps should be updated. If this doesn't work smoothly a lot of the benefit is lost.
Before investing in this, I think it's really worth investigating whether Electron, nw.js or some other project can be modularized and stripped down for these cases. I'm sure there's a lot of research made already, and I'm as excited as the next person about having a lightweight alternative, but I'd like to see proof for that there are no alternatives in the existing projects first.
I'm going to start following this project as it looks like there has been some life injected into it. I have an ad-hoc XCode template project with a WebView loaded into it to make these quick apps, which I put together quickly because of the intractable dumpster fire that is Electron.
Then there's building, distribution and updating. Even simple apps should be updated. If this doesn't work smoothly a lot of the benefit is lost.
I believe the goal should be for updating to be done with Sparkle and WinSparkle.