what all is missing as compared to electron
Closed this issue · 24 comments
If you list out what all is missing i/we(community) can help out with this.
Have you considered Cordova or nodekit though
PS: Not a c++ or even a desktop guy.
Fair enough, also when you get working the windows basic functionality could you define some common API that could be implemented in other platforms so others can start contributing.
Edit: @awebdeveloper Cordova use almost the same approach I think, it just uses the build in html renderer and javascript engine, also the think is this project aims to be electron compatible (@jscherer92 can you correct me if I'm wrong) and cordova (as far I know, is different). Also about nodekit don't know much about the project, but seems to be unmaintained, but I think this project aims to replace only the chromium embed engine and not node, node binaries are just 4~mb or so, and I think is not worth to rewrite a node compatible engine.
We actually use nw at my current job ;) not unmaintained just not as popular as Electron.
In terms of not reimplementing node, this is going to be tough. I want to do some testing to see how the bare bones engine runs compared to say just running Chakra Engine or bare bones V8, but we may be able to get away with a bare bone version of node.
That is a little bit of a dream but I can tell you that Node is roughly 20MB of RAM used right away. If we are going for as slim as possible, we may need to make a nodelite (have already thought of ways to handle this, do not know if we still use libuv or just go with a basic thread pool)
I would say the end goal/pipe dream is allowing user choice when getting a version of the application. Something like: I want window's x64, with V8, with nodelite. Or I want OSX with Chakra with node. Very lofty goal but that is where I see this project.
But the ram isn't the issue, and will be hard to beat node (v8) in performance, at least Electrino's goal was lightweight apps in terms of disk size, the performance I think will be similar to Electron, but each time you download an Electron app they carry 40~mb of the Chromium Embedded Framework and thats something disgusting (at least to me), i.e. I've installed on Mac some Electron based apps
- Postman 200~mb
- Slack 230~mb
- Trello 320~mb
- Twitch 320~mb
- Whatsapp 235~mb
Saying that I just have 200mb of the same thing, Electron core, and yes 200mb is nothing this days if you have a desktop PC but if you have a notebook with limited disk space is a lot, and just looking at the popularity of Electron theres a tons of apps that I want to install but I cannot afford to have so much wasted space.
Maybe I've got the wrong idea behind Electrino or Quark, but I think this must be the goal, just offer thinner apps, you use the OS web frameworks (JavascriptCore on Mac, Chakra on Linux/Windows)
PD: now that I remember theres an implementation of node on Chakra, so maybe for linux and windows would be an option to use it, is officially maintained by node foundation, i think, and is in the ChakraCore roadmap
Well this will definitely be lighter in terms of Disk. In terms of what we are actually offering, you use the OS's "Browser". So for Windows, in terms of the winapi, you use the IWebBrowser2 interface, and for OSX you would use Webkit. For the JavaScript engine on the "backend", you would be using something like Chakra for Windows (though, you don't get chakra out of the box on this) or you use Trident.
For OSX, you would use JavascriptCore. I think out of all of this, some confusion has come up on exactly what Electrino was going for, and maybe how I viewed it was different. But, I am aiming for Quark to be both lighter in disk usage and memory footprint.
I can go into the design details when I write up the wiki, but just hooking Node into the native rendering engine is not going to solve a majority of the problems that I think people are having with Electron/NW.
Again, I am not against bringing Node into the mix here nor am I against any of the ideas that Electrino may have been going for, but my main goals are to make a cross OS system, that can make apps lighter in both disk/ram usage. Disk is relatively simple by using the native rendering engine. RAM usage comes from trying to not spin up VMs the way V8/Node does.
How do you think that can be reduced the memory footprint? I'm clueless in this aspect.
If that one of the goals of this project I think it can be worked later on and in the mean time use just node or chakra-node, because in the end this will be fully node compatible, I'm right?
We can reduce the footprint fairly easily by getting rid of a lot of Node's functionality. I've been doing quite a bit of research into this and there are a few areas that make it quite heavy.
I'm all for using NodeChakra having it as a baseline and using that in the beginning to get this ramped up.
As per the discussion going in the other thread, picking the rendering engine is tough because you never know what environment the user is going to be in. I would say that using a cross platform webview is the thing we are trying to avoid, so we should probably develop for one desktop environment such as Gnome or Cinnamon and work from there. Once we have a standard way of building this, I think it should become easier to build the next webview.
But if you strip some node functionality there will be node modules that will not work with quark, and I think the big thing about electron is the ability to use all the available node modules.
That is a good point. I would say we will most likely move forward with Node for the time being, but do another project you listed on another thread did and start writing their own wrappers for the functions.
In terms of what makes Node bloated are calls to the V8 engine and even the libuv instance that it is using.
I was doing some research last night on trying to find different techniques for achieving what libuv does and there seem to be a few out there.
Again, I am being ambitious in that aspect and I would really like it to work.
But, also seeing a lot of movement for people just wanting a system that is working and is less of a hog on resources, moving forward with one implementation in the beginning is not bad.
The reason so many people were interested to Electrino, was that the goal seemed to be a drop-in replacement for Electron so that the API matches although some might be missing.
[electrino] implements a minuscule portion of the APIs available in Electron, but the output app size is much smaller.
It seems the plan was to increase the API to try to achieve parity with Electron to some degree.
The plan is to examine API usage of real-world apps that use Electron but don't really need the full capabilities.
If you implement something that doesn't mimic the Electron API, then it will be just another cross platform UI tool.
Not to keep bombarding this thread and I'll be at work, but that is why I want to get this PoC up and running to show the possibilities of actually building this. With actual code and usability there, I think a much better understanding of the design will come out.
I am eager for other developers, but I want to make sure that there is something tangible for other devs to see and work with. Along with users to be able to run something tangible.
This is me guessing, but I think it's the node API specifically.
To reiterate @norman784, if you strip some node functionality there will be node modules that will not work with quark.
This was the unique thing that Electron did: marry the web API with the node API so you get a real file system.
The other parts of the Electron API don't seem particularly hard to port so probably aren't as important, but its also not a huge surface area to cover (I think).
I definitely agree. That's why I don't want to strip functionality that a majority of users are using.
I think my point is, are there features people are not using in the Node API that we can just remove? I want to do an implementation without libuv, so mimic the NodeAPI. I would do this piece by piece and maybe as a starting point just plug in the node system. But do realize that this is an executable, so it would be mean work changing it into a dll/so for the different systems.
I just want to make sure we all realize that the entire bulk is not just on the embedded chromium instance, but also on the Node/libuv side.
@jscherer92 I think the selling point of the framework need to be bring to quark the actual electron apps, so developers can migrate without any or at least too much work their apps to quark. So thats why I think we need to maintain the Electron API and Node API as much as possible.
But didn't work too much with Electron so I really not fully aware of how deep and big is their API, but maybe its just the Node ecosystem that brings most of the power to Electron apps.
If you also take a look at electrino he was only mimicking part of the Electron API and none of the node system. So I don't know what the plans were moving forward
@jscherer92 That is incorrect.
There were a couple node.js core APIs that were implemented including url and path.
Also the __dirname global.
See the demo app for more.
Yep. I took a look and he did implement those. But, it was not Node that he was using as the library. They were ObjectiveC routines he wrote that hook into the runtime. That is my plan for implementation on this project. Writing C++ routines that mimic the node API
I am totally in favor of @jscherer92 suggestions and plan.
For me, the concept of Electrino/Quark is to enable the developer to create desktop apps that uses much less disk and much less RAM.
Thanks @paulocoghi! Progress has been a bit slower than I expected (though, this is usually how software dev goes). Part of this goes into my learning process in modern C++. I always used a C like variation of C++, but I am trying to follow modern design considerations now.
Second, after a 9-10 hour workday, I am usually not in the mood to code, but I have been pushing through that. Just know that I really believe in this project and know that there a lot of improvements that can be made on the codebase, along with what this project is. I think once the MVP for Windows is out there and it becomes stable, there will be a good understanding of the implementation for other OSs.
Also, the current runtime will not be correct for the MVP in Windows since I am statically binding all of the library code with the project. Once it is up and running and a good demo is created, I will be moving most of the code into a dll and a shared location. With this, the memory size will go down.
With the current Buffer implementation, the system is running around 10MB. With the other pieces that need to get up and running, I expect that w/o a DLL of the library code, it will be around a 18MB runtime. Once that library code is not statically linked and is a DLL, it should go down to a 9-11MB runtime. This is compared to the 50MB runtime of NWjs and 42MB runtime of Electron.
@jscherer92 as i stated above if you can list out what all is missing or what all you plan to add. We (the community) can help you.
@awebdeveloper, the current wiki has the MVP plan for Windows. This is the main development goal. All of this is C++ work and specifically the Windows API. I'm all for others jumping in, but this is where the work is currently at.
The wiki also shows the current dependencies to build out each module.